DEVLOG 2023-05-27

This week I started working on the Godot GDExtension (in C++) for the game’s view code. The first step was to setup the build of the godot-cpp library using my build tool build2. I made the package kind of working quite quickly and then we went live trying to use it. However I made a mistake initially and forgot to add some generated code. In the live I ended up adding that generated code to the build, which lead to the discovery of various issues in build2 for this specific scenario, which is very unfortunate, but not a blocker because there are ways to workaround that. The next day I had a discussion about these issues with the main developer of build2 who actually was trying to solve similar issues by adding a new functionality. So I’ll have to wait for it to be available and test it see if it solves my problems.

Meanwhile I will use a workaround: build the lib in CMake and use that in my project. The next step that I will do not-live is setup the configuration flags so that the ABI matches what’s necessary… or maybe that’s not necessary I dont know exactly as godot-cpp also exposes a C api which is what I believe the Godot Engine is actually using.

In any way, I’m close to be able to just build my gdextension which will use the game’s model (which for now is prototype). My goal for next week is to “see” in 3D (using colored cubes) the same scene of the game exposed by the prototype 1.

While all this technical things were ongoing I also tried to think about the story or at least the starting point of the game’s story. I have now a strong idea I think.

The other important thing to think about is how to handle the theorically limitless size of megastructures. What I mean by that is that having a big world doesnt mean it’s an interesting world to explore. Probably the size of each megastructure to explore should not be world-size… I’m thinking about the game (which is not a roguelike) ECHO which features sometime very massive (aka repeating) corridors which kind of shows the type of place that would make sense: infinite corridors and towers but a few relevant packed places where there is something interesting. Basically I’m working at deciding how to structure the world. Like, how often do the player is able or should need to exit a megastructure to get into another one? Maybe making it hard to decide because you have to have some clue as to where to go next, and that clue is hidden in the current megastructure? Or maybe somethign more organic should be done here…

There are various interpretations of the MEGASTRUCTURE word. For example a dyson sphere is supposed to be a megastructure. Only one? How about a dyson swarm? Isnt’that closer to an interconected mesh of megastructures? In “Blame!”, which is the main inspiration for this game, there is 1 megastructure which is bigger than the solar system. However what I would prefer is that each megastructure is the size of a city and have ways to go to another megastructure. A city, in the future, can be big already, so the feel of sheer size should still be there… but it’s smaller than what’s describe in “Blame!”… I have choices here of course, I’m not making a “Blame!” game and can decide what it all means myself. One variation I’m tempted to go with: you start with a first megastructure which is a dyson sphere… then you realize it’s connected to other megastructues which are also dyson spheres. This one is “sexy” to me, although this loses the possibility of ending up in something like a world-ship. Well I can still make this a possibility…