jo3bingham
Excellent OT User
I was chatting with a buddy of mine, and we got on the subject of TFS and its strengths and weaknesses as it currently stands. As we all know, TFS is the engine to use when creating an Open-Tibia server. Sure, it itself is a fork of OTServ, but it lasted the test of time and I would be surprised if any server running today isn't using the TFS engine at its core (no matter how modified it is). And while TFS is battle-tested and, more-or-less, bug-free, it's still based on the original architecture of at least 10-year-old code. There's nothing wrong with old code ("If it ain't broke, don't fix it."), but there's also nothing wrong with looking at what's currently available and asking yourself how could it be better. I'm not knocking TFS (like I said, the engine is solid and his been around for quite some time), but a lot of it is still written using old coding practices (e.g., manually reference-counted pointers) and relying on custom, binary formats (OTB and OTBM), and the downside to this is that it can make it difficult to make major improvements without a lot of effort; to the point no one wants to actually make them. I know there's been a few attempts at different engines (PyOT and like three different C# engines come to mind), but I'm not aware of any public server that uses them.
To get to the point, we came up with some ideas for a more modern engine, and were curious what the community could come up with as well.
Ideas
To get to the point, we came up with some ideas for a more modern engine, and were curious what the community could come up with as well.
Ideas
- Database: SQL is great, but what benefits could come from a NoSQL database? MySQL will be faster, but with how powerful modern CPUs are, you could use a NoSQL database and not notice any performance issues. For example, there's no need to stall the whole game thread when you can load players from the database asynchronously. If you use something like MongoDB, you get the benefit of more-easily readable data (BSON/JSON).
- Items: Currently, items live in two separate files; items.xml and items.otb. I know the original intention for this, but, really, one file is enough, and while you're at it why not use a more modern format like JSON instead of XML or a custom binary format.
- Map: OTBM is basically just XML in a binary format (nodes/attributes/etc.). The single-file format means maps, especially RL maps, are huge in size, and more than one mapper can't realistically work on the map at the same time. Another problem is there is no source-control; if you hire a mapper you have to trust that they didn't hide any secrets in the map. Sure, you can open it in RME and search for items by ID, but that's tedious. A better approach would be to split the map into sector files (256x256 tiles is what CipSoft uses) and in a readable format (again, JSON would be a great option). You could have a single file that holds all of the map files in it; this would allow you to group the map files into sub-directories (e.g., all of the map files for Rookgaard could be in their own folder) and easily say which parts of the whole map you want to load. Then you have the added benefit of using source-control (i.e., GitHub) to track changes to your map at a glance.
- Language: C++ is great (it's in my top 3 languages that I use), but it can be quite difficult for beginners to grasp certain concepts and get their development environment setup properly. If I were building a more modern engine, I'd consider using a language such as Rust. Yes, Rust has a steep learning curve, but it can provide the same performance as C++ (sometimes better, sometime worse) and it's much easier/quicker to get setup to start working with a project. Plus you have the added benefit of it just being harder to write unsafe code, and you can more easily make your code modular (there would be no reason to have a single file with 16k+ lines of code...looking at you luascript.cpp).