DEVLOG 2023-12-09

This week was quite busy both in the project and in dayjob, I’m super tired but things progressed:

I managed to complete a working architecture for the model vs view layers using GDExtension, where the overall game is driven by some code close to the model (that I call “director”, someone suggested “driver” but I ended up using both words). Now I have a basic scene which goes back and forth with the C++ code in a way that effectively makes the C++ side drive Godot instead of the other way around (or more like it’s Godot asking it what to do next). The details are a bit complicated – I know some people around here are interested to know more about that but I think it would be better to just make a short presentation once I’ve cleanedup and made sure it’s the right way to go, so that needs a bit of more practice. I also noted to explain alternatives setup when I’ll make that presentation. Anyway I need to cleanup after experimenting a lot with all that.

While working on this I discovered something that was not as clear when I was protoyping: the C++ interface of Godot is very much not in line with idiomatic C++ programming, which leads to a lot of code just to be able to work with simple containers. For example, godot::Array does not have a way to get iterators, so the language’s for-range loop cannot ever be used with it. Same story for godot::Dictionary. This is very painful. I think I didnt see that previously because it’s mainly important when trying to transfer Godot objects from Godot to C++, while my prototypes were going mainly the other way around. Also I was using JSON to transfer information (events and actions) so that simplified things. But with the new architecture, where I also drive the game from the C++ side (close to the “model”), I do have to have access to some nodes directly, so now it’s clearer how complicated it gets. I plan to progressively setup some Godot-vs-C++ helper code/library to at least make the code easier to read when I jsut want to use a Godot array or dictionary for example.

Yesterday build2 (my build-system and package manager) stage version (not-stable) got re-enabled support of C++ modules with MSVC, which basically means I can finally get back to using Visual Studio to work on the project. I still build and test the game using clang for now so that it’s also easy to do it on Linux and MacOSX later (the CI is currently limited because it’s private on github and you need to pay if your build is longer than a few minutes…). So far using C++ modules has been a blast (when not hitting compiler issues…) or more exactly a big set of pains related to header handlings is relieved for me on this project.

I also managed to almost finished some script to automatically install a godot executable in the project when needed, which is a step towards having automatically running tests inside Godot (and also having a simpel command to just run the game or just edit the game). It’s all investments to speedup development.

While doing the prototypes we (as in me and the few people at the livestreams) realized that almost no Finite State Machine library in C++ I found was doing what I needed, so I will probably have to make my own, although as a start I can just use something already available to me and use mine later. Same thing for the ECS handling the current state of the world.

Next steps:

• I noted to take some time to setup a logging layer: the C++ code must not know how it’s log records will be processed and in the specific case of having a view in Godot, there is some wiring to do so that Godot’s print system is used. Nothing complicated and I have a lot of xp into this kind of thing.
• I need to establish a basic error-handling strategy (part of long-term planning) for the C++ side, as Godot will absorb anything that might crash in the GDExtension (and also to make that error handling independant from the view side). Again, I have xp in this so nothing new to me, although both logging and error handling strategies are these thing that looks simple but are tricky to get right.
• Setting up title screen, game screen, settings screen and navigating between these (even if basically empty). This is to stress the “director”, but also to make sure the whole thing behaves like a normal game or app.
• Setting up basic entities, which implies also basic data structures to represent the spatial arrangement of entities. I already did some thinknig about this so I have a pretty clear idea of how to do it. It will also force me to setup a few first “placeholder” views of these entities, and make them being instantiated automatically. That way adding new entities would just use placeholders when I didnt set specific views for it.