feat: base game entity, state machines and messaging system

[michaeleggers]

Overall, this looks good!

Just get rid of cout and overloading the << operator for printing. Also don't get in the STL's version of C headers and iostream:

#include <cassert>
#include <iostream>
#include <cmath>
#include <ostream>

There are some modern C++ things in it like iterating over the map via auto. I think this is fine for now. Just note that we are going to replace the entire STL later. Look at id-tech3 source, as mentioned before. Not sure about the templated stuff. Again, see tech design document. Also give this a watch (regarding templates): https://youtu.be/qWJpI2adCcs

[michaeleggers]

Thank you for the changes. When including stuff from the C standard library, use <... .h> instad of "... .h". Also include stdio.h where printf is used.

[michaeleggers]

Okay. We're getting into a very important stage of the program now: Looking how we can integrate entities and their logic without creating a really big mess. @benekoehler is going to tackle this (good luck ;) ). A few notes that I want to see (most of it was already communicated in person with @benekoehler):

• Think in systems and data, eg: Do not let the entities render themselves. The renderer just takes the entities (or maybe even just their models) and draws them. As of now I would not change anything regarding the renderer. Just give the renderer the entities' model data, just like it is being done in game.cpp!
• Try not to have pointers to the world within the entities. Again: think in larger systems: If possible implement some logic in CWorld rather than have entities do things by themselves. Take this advice with a little bit caution: If it is the easiest thing to get stuff done and is for everyone the easiest code to understand than storing a pointer to CWorld might be okay (for now).
• If you (@benekoehler ) get into trouble to write clean code, eg. you need globals that go over compilation units bounds, do other things that are bad practice according to frauds and bozos like Robert C. Martin (Uncle Bob), then just DO IT. The goal is to get the steering behaviour running that you have researched. It is always better to create as little of abstractions as possible so the fewer classes we introduce the better.
• Code that can be easily deleted without having to think about 1000 other things is good code! Eg: The deletion of a global variable that other systems rely on will break the whole program but it is trivial to fix! You just go into the files and search replace it with something else (a constant value until you have thought of something better, etc.). Whereas the instances of a Class that hold references to another class that executes logic every frame and does other things, because one thaught "it looks nice, everything is so tightly encapsulated...".... Good luck with that. It might not be bad at the beginning but the further one goes into OOP land the harder it gets to delete code. I don't reject OOP per se but one should be SUPER CAREFUL. What we were taught at university about how to write software is largelay a pile of garbage (sorry to all the professors who taught me 'Software Engineering', but also not sorry! It just sucks.).
• Don't pay too much attention to performance, eg. there is a big fix comment in game.cpp that copying the brush entities' geometry into the world geometry vector every frame to make the collision system happy is super dumb. However, we are lucky to have fast CPUs and it does the job for now. We cannot fix everything at the same time! No problem doing this for now as it is trivially deletable (see above).

I care a lot about this. At the same time I am guilty of all of the things I mentioned above: I tend to overcomplicate things, and it always has hurt me in the past. I know this is not easy to get right and I don't have the absolute answer to how entities should work. I am looking forward to see what you come up with @benekoehler . Good luck :100:

Cheers.