OP
OP
Source
Veteran OT User
You'd have to define those things for me as I'm not familiar with them, at least as words/concepts.
I would wikipedia them if I wasn't so lazy.
I'm doing my best to keep the design clean.
But it's a work in progress. It's messier than TFS for sure, the simpler/minimalistic design that keeps RAM usage low (less than 1/3rd of TFS memory usage for map) makes it perhaps more difficult to get into, and core functions is a work in progress, there are also limitations by the language that makes it so that not everything can be moved into C++ etc.
For example TFS is very object-oriented, there's a function to check every single detail of every single object, but at a big memory and complexity cost, I don't use any such design, my design is minimalism, so you call world.getTile(pos) and now you've got a simple pointer to a worldtile struct, not a C++ class object with 200 different methods.
Here's the struct definition of worldtile:
Code:
struct worldtile {
unsigned char elements; // POISON, FIRE, ENERGY
unsigned char flags; // PZ, REFRESH, NOLOGOUT, AVOID, UNPASS, UNTHROW
unsigned char groundsCount;
unsigned short itemsCount;
unsigned short tilespeed;
unsigned short blockCount;
unsigned short avoidCount;
std::vector<worlditem> items;
worldtile() {blockCount=0, unsigned int avoidCount=0) {
this->elements = this->flags = this->groundsCount = this->itemsCount = this->tilespeed = this->blockCount = this->avoidCount = 0;
}
};I also don't rely on any 3rd party frameworks or libraries, such as Boost.
Everything is hand-written. This means less dependencies, ergo no dependency-hell, and quality assurance in my case since I'm pretty decent at what I'm doing.
For example for my OTClient project I needed a AES-CTR encryption library for Python, the developers of the best library had tens of thousands of lines of code and they couldn't do the job right, it had serious issues with the design, I git cloned a tiny AES-CTR codebase and wrapped it with less than 100 lines of Python to create my own library instead, this way I got a functioning module that I don't have to worry about having functions or parameters replaced/renamed etc in the future, this was a much better solution for me.
When you can't trust other people doing the job, you've gotta do it yourself, that's my motto and what drove me to create "TSSFTW" or CO4 as I call it internally.
The design isn't perfect, but it has no 3rd party dependencies, can be compiled both for Linux and Windows, uses less than 1/3rd of the RAM compared to TFS, has the same or better CPU performance in most areas, and the codebase is less than 1/10th of TFS' size.
These are the advantages in my opinion - I prefer having a small, slightly messy codebase, than 10x the amount of code and high complexity for every single function.
With my server there's no abstractions, so you have to learn how the server (or really any Open Tibia server) is built internally to be able to develop it properly.
Advantage: Simplicity, programmers learn more about how the thing is actually made internally, with less code to read, and less complexity.
Disadvantage: Not well-suited for newbies or people who are not eager to learn, who prefer toys and interfaces (e.g. OOP) to real tools.
Here's my real motto
Keep it up!!!
