DEVLOG 2023-12-23

This week’s progress:

• I improved the system to make the C++ side (model + director) control in broad strokes the Godot side (the view implementation) by doing some changes like defining concrete interfaces for each screen (no string-based naming) and trying to move most Godot-data-specific manipulations in the GDScript side of things. Instead of trying to manipulate a godot::Dictionary in the C++ GDextension code, now I just make that code access a node which is the main scene, and that main scene must provide a few fonctions that does the necessary work like providing the node of a scene given it’s name. Basically the GDExtension side got leaner code-wise while becoming also more interface-solid by making all views interfaces known at compile-time. Meanwhile the GDScript side takes most of the implementation role, which is closer to how I envisionned that setup.

• The basic game’s state machine driving when to display which screen is setup, it’s very very basic but allows me to make sure everything is at the right place all the time. It also allows me to have a specific screen with settings that I can add/remove/change quickly on in the Godot ediotr.

• It took me a while to get it “always correct”, but I finally got a custom command working for installing automatically the right Godot version in the project (it gets the github archive and unzip it and makes a useful symlink) and that allowed me to have 1 command to open the editor or to run the game (as if run through the editor, but without the editor). If run from scratch, just after a git clone, it will get all the dependencies of the project, build all the right builds in the right configuration for playing, run the tests of all the C++ code including the GDEXtension, then install the GDExtension freshly built in the Godot project at the right location and then run the editor in edit mode or to run the game, all correctly in one command. I feel like a wizzard. As part of it I also have a custom command to just build+test+install the GDExtension, which is necessary to have handy when you switch between C++ edited code and Godot.

• Using these commands convinced me even more that the development cycle where you edit C++, then have to remember to build+test+install the GDEXtension before focusing back to the Godot editor definitely could be improved of Godot knew how to “update” (as in build+test+install) the GDExtension, so I noted to maybe prioritize that next time I do a pass on tooling. Not immediately because I want to progress on game-specific stuffs, but still a good confirmation.

• I setup automatic backup system through my own “laboratory” server (which is not in my place, so it’s the 3rd location where the code exists, nice), thanks to a friend clarifying for me a big misunderstanding I had for years about how cron works T_T, I learned a lot. Next backup to setup would be have the source archive files from githup get regularly copied in my Google Drive, not sure how I’ll set that one.

Last week I was planning this week to add the logging layer and error strategy but I pushed that back to make sure the whole C++ -> Godot -> C++ -> Godot communication was actually setup in a way I feel maintainable. So next step is to now do that, and also try to focus on more game-specific stuffs.

I have a pretty good idea of how I will represent space and the shape of things in space in a performant or at least compact way, and easy to process when handling “collisions” of entities. So I will try to start that implementation on the model side. However to represent anything in the view side I intend to setup a mechanism for automatically adding placeholders for things that we didnt add a view for yet. That view-placeholder generation mechanism is crucial for me to be able to progress fast later. But once done I should be able to quickly start generating test maps without characters at first, and progress from that, maybe on the editor front first (I will need to be able to edit space at any time).

In the prototype projects I used EnTT to handle entities data but I emitted several time questionning I had about if it’s actually the right thing for me. I have alternatives around, to make a custom ECS-like system, I’m just not decided yet if I should try that and just continue with EnTT. Before deciding I would like to get more in depth in it’s documentation and compare it to how Bevy is designed, as I recently learned more about Bevy and found it very interesting design-wise. I wish we had something like that in C++ but that would require having actual reflection first (it’s coming for C++26, crossing fingers!). Anyway I also intend to figure out a way to isolate that choice of implementaiton of how data are stored from the rest of the code, as usual I guess, to be able to switch without too much pain if I find my choice was a failure in the end.

I wish I could reach that point where I can show interesting screenshots and videos soon, but at this rate it will not happen this month. Anyway have an excellent Christmas or whatever winter solstice related festivities you have in your place!