DEVLOG 2024-01-06

Past few weeks I have progressed to get to visuals as soon as possible, but kinf of failed cause of a compiler bug. To be very short, the compiler bug happens when using msvc and entt library for ECS, and doing so using C++ modules (which have some issues in msvc, but works most of the time). After spending some time making the smallest repro I could find, I send it to ms. So basically for now I will not use entt but a custom solution to represent entities in the game, which is fine but just it took some time to do all that.

But before that I did a lot related to the game itself: I setup the basic data types for represneting “something in the 3D grid, which have a shape”. It’s not tested yet as I could not connect the data to visuals yet. I’m also setting up the system to represent these “shapes” using default placeholders when the thing in question doesnt have a representation setup yet (this is all on the Godot side).

I have setup a simple logging layer which allows me to have the core/model side of the code emit log records and the other side, the view using Godot, decide if and how to display them. Right now I’m just pushing into the print function of Godot, but for warnings and errors I should add some code so that it gets into Godot’s report system (which you see in the debugger of the editor). I didnt do that yet because no time and it’s not urgent, but the model side do have a notion of error and warning so at least the data is there. I also experimented with using std::source_location to get where the message comes from, it works well but it was noisy to display so I capture the info but dont display it for now. Maybe later I’ll setup some kind of verbose logging option.

I did some cosmetic changes so that whenever you try MEGASTRUCTURES you have several ways to identify which version it is. I also made sure that the GDExtension files have different names depending on the build “mode” (debug, release, etc.) so that Godot can load different versions depending on the situation. See, in the GDExtension system you declare the existence of a GDExtension by adding a text file in the project which lists it’s properties/features regarding for example hot-reloading, and then you define in which platform/architercture + build mode each shared library (plugin) to load. Godot’s editor will apparently load the “debug” version of your gdextension in the editor and when running the game from the editor, but it will actually use the “release” version when you export the project as a publishable package. I setup to deactivate (at build-time) all hot-reloading code when the build is release-mode and setup everything as expected (except I didnt try on linux and macos).

I also spent some time trying to accelerate my development by enabling intellisense which is kind of broken with modules. I use VSCode right now but also try to see if I can setup Visual Studio (not-code) to work with it. Anyway I didnt spend too much on this, but I did spend some time setting up compiledb (actually had to fork it to handle C++ modules files) so that at least in VSCode it doesnt add red squiggles to abotu all the code. Now it works, I mean most of it works, there are some issues but it’s far less noisy.

As mentionned before I progressed on the spatial structure code of the game and that also means I setup some maths fundamentals in there. For now it’s simple and made by myself instead of a library, as long as it’s simple and I can use generaic maths algorithsm (like the ones in Boost) I think it will be ok for the maths of the game. After all, it’s all “discrete” and simple, because the grid is still a grid and not a continuous space. However I still didnt write proper tests for these math code and I really should, so that’s high on the todo list.

Once I connect the spatial data to the placeholder representation code on the Godot side I should be able to setup some basic gameplay, which is what I want to obtain before the end of the month. Setting up a basic camera, controls to do actions, and a default test area is onging.