DEVLOG 2023-11-04

This week I mainly focused on setting up the new project. I’m not done because I had a side-quest of exploring the possibility of using Clang (the C++ compiler) with C++ modules (which currently is only well implemented with MSVC). In that exploration I found issues, but I also found that I could use it as a starting point if I want to use C++ modules from the beginning.

This paragraph will make no sense to people who dont know much about C++ modules so feel free to skip. What I found is that the trunk/in-dev version of Clang 18 works perfectly as long as all the code of your modules is kept into the primary interface module (or maybe also interface partitions). You can also use private module partitions but as soon as you start including standard headers or some random headers (in the global fragment) you will find weird errors due to clang messing it’s merging of names, in particular when coming from the standard. There might be a workaround or something but I dont have time to dig deepper.

The main point is that this means I can work with clang exclusively for some time while waiting for build2 (my package manager and build system) to re-enable support for msvc’s modules (which it will soon, I’m told). I will probably use msvc more because there is a lot of recent C++ features they provide which are still not in clang. This also means that probably for some time the versions of the game I will publish will not be available on linux. I’m not sure yet because it depends on what I need and what I can get as dependencies instead of relying on the compilation toolchain (like recent stl containers, flat_map comes to mind, but also generator).

While doing all this I also thought hard about the consequences and complications of using a 3D grid, with oriented shapes in that grid, in the context of a game where actions take spans of time cycles instead of turns. The option of allowing some overlap of shapes so that for example 2 humanoid bodies needs to be in the same position to be able to melee combat is super interesting but also leads to an interesting (as in “maybe more problematic than it looks”) issue where we need to handle collision in a special way which is based on the time cycles. Even without that feature, the issue is simplified but still exists. When 2 bodies are doing movement actions, how do I handle them trying to enter the same cube? One option that I’m considering is that all actions can be “cancelled”. That is if one body enters the cube where another entity is attempting to to enter, having it’s movement action not-finished yet, then that movement action is cancelled. This would mean that movement is achieved only when the time-span of the action is done. However, going this way also means that for example melee combat actions are effective only once the action is done? Instead I would prefer that it’s some kind of long action that while time cycles happen in that action time-span, melee combat effects are ongoing. But it’s harder to understand so maybe high-level melee combat actions, like “just kunk-fu this dude”, maybe enabled only through mind-software, are actually composed of smaller actions which deal punches every short time-span. BUT that also means that there is no way to defend a hit. So I would like both a system like that and actions which while active, are actually waiting for an event to react. This enables reactive actions, like pure defense, deviating bullets, etc. Ok I’m going into depths here but basically, thinking deep about this subject lead me to a specific plan of implementation of actions, which could fail but is not too hard to setup, just unusual and probably hard to represent to the player without some kind of timeline. We’ll see.

I was also deep-thinknig, vaguely though, about strategies to build the megastructures themselves. While from the beginning I intended to be able to go from one megastructure to another, IFF the player finds a way to do so, this would only mean, in roguelike terms, that the player is able to go into a new generated world if they find a way to get there. Now how about the world itself, how to generate it?

Right now, derived from my general original plans, I intend to setup general shapes for each kind of megastructures: planet-like spheres, “infinite” cities, ring-worlds, world-ships, mega-big-computers, etc. , then generate actual space (or pure networks, in the case of mega-big-computers) inside that shape. So for example, if the megastructure is a massive cube, Borg-spaceship-like, ok I make a cube, with walls and entrances, then generate various flat spaces in it, maybe some vertical connecting them etc. Then come up with the general algorithm to do this, and fill space using traditional procedural generation algorithms. That’s obviously easier said than done well, so dont worry I know it will take a very very very very long time to get right.

But imagining how to do that lead to interesting thoughts: how about a ring-world? Ideally, if the player reaches the surface of such a world, and start going through that world in the direction where they would ultimately reach there starting point again? Should I make a flat grid with warping edges? How do I handle the possibility of jumping very very very high and ending up on the other side? Actually, some of these questions are also interesting in the context of spheres… Should I split megastructures in an interconnected set of areas, which would not be loaded at the same time? Or should I attempt to enable a whole megastruture to be running at the same time? It depends on scale and data and performance and level design… What’s the scale of a megastructure? How do I make it interesting? That’s the most important question. Making a game with a big space is easy. Making it interesting is far harder. I will probably rely on making big distances “short” by allowing the player to move very fast most of the time, but that obviously dont resolve all the problems.

Many questions which will find answers through the slow development and experiments. Can’t wait to start implementing all this!