Quite a busy couple of weeks both on my day-to-day job, and on my personal life. So I didn’t work that much on the project.
I’ve pushed the powershell configure scripts as far as I can, but it quickly became a mess with a load of duplication between projects. To respect my “Keep it simple” mojo, I decided to drop it and replace it with good old CMakeLists files instead. I didn’t knew CMake before Avatar, and now I found some elegance in it.
Also I rollback the one module == one repo thing on Avatar. Now it’s just one repo for all the engine (still on my “Keep it simple” thing), but I kept the one module == one delivery (either a .lib or a .dll).
Regarding Avatar’s modules, I decided to keep them limited. More like the kind of things that you can have on Debian packaging : a minimal (the Core) which will contains the basics to run the product, and a variety of modules which are part of the engine, rely on the Core, but aren’t necessary.
For the moment I have 2 modules : the Core which contains a Datetime class (its purpose is to abstract the system’s specific time representation for the rest of the engine), and Tools which provides a logger. The tools module needs the Core because it use the Datetime to print the timestamp regardless of the system’s specific time representation. But the Core doesn’t need the Tools at all to work.
The strategy here will be to let clients of the engine choose which modules they decide to install on their games. We can even think of provided several version of the same module, like a physics module specialized for spatial themes, and physics module specialized for race themes.