DEVLOG 2023-07-29

This week I had to skip the livestream but still made some interesting progress, here we go.

First thing is that at last livestream I was looking for a library I remembered but didnt remember the name of. The point of the library was to be able to declare the members of a type with a macro, then some reflection layer would expose the information compile-time about that type. The important thing is that once you have something like this you can declare your reflection data for specific types once, but then build various serialization forms based on the reflection data. The goal in my prototyping quest here was to be able to serialize the state of the world AND more importantly be able to easilly convert the type into Godot’s internal type system (basically GDSCript). After some post-livestream search I found again the library I was thinking about: Boost.Describe. It have to be used in combination to Boost.MP11 or equivalent, people used to C++ advanced metaprogramming will know what I’m talking about, but otherwise it does the work very well and without too much noise. I also ranted to my friends about the terrible state of C++ reflection that doesnt seem to have a solution coming for C++26 but we’ll see. Anyway I’m annoyed at the lack of easy reflection in general in any language not providing some.

For now I’m trying to use this to be able to transfert what I call “communication types” back and forth with Godot, namely actions and events. Actions are basically requests to do something an actor (mind) to the bodies (one body most of the time…). Events are the output of all the rules of the game. We need the Godot part to be able to push actions and receive events to then interpret these events in a way that’s understandable to the user, which means with animations. The issue here is that both action and event types are identified by their C++ types, so we need to translaet that to something that can be worked on in the Godot part. For now I assume that the Godot part will be coded in GDScript (I’ll get back on this point later). One of the difficulties so far, and I’m still working on it, is that on the C++ side, we store events and actions in type-erasing types which can contain any such event or action, whatever the type, without having to use inheritance (which is problematic in various ways, I wont get into that rant but yeah). It’s very easy to work with on the C++ side, but it also means you can’t access the actual type directly to get the data needed for interpretation, except if that type knows itself how to do the interpretation. In Hard Glitch I did implement the animations for each event inside the event, but it was problematic in various ways. I prefer the “view” part of the code (Godot or not) to be able to check the type id and deduce the details itself, just “reading” the info specific to that event type and doing it’s thing independently from when the event represents.

I’m having a hard time exposing these event types to Godot because:

• They dont have value-types (they are considering adding a struct type but it’s not even a value type either, although it would be enough for me). For now I decided to go with just converting events to GDSCript’s Dictionaries, as for prototyping it will be enough.
• I’m trying to automate the translation from C++ to GDSCript’s Dictionary to not have to do something manual every time I add a new event type (or aciton type). So far I have trouble with that because of technical details like reading the type-erasing type automatically is not trivial. I managed to expose at runtime the values of the contained events, but I still need to convert the members (mostly ints, vectors, bools and strings) to types from Godot.

While doing all this, I started to realize that, from all the “view” implementations I’m considering to use (including Unreal, Magnum…), Godot with GDSCript is the only one that would require actual type conversion to another language. I’m very tempted to just stop here the type conversion and just implement the interpretations of events in C++ instead, that is, no GDSCript except for setting up the scene. But we are prototyping and I need to see this through to get the complete experience so I’m noting that important point for later.

Well that was a very deeply technical week and that’s reflected here, not sure anyone even reach the end of this rant but it’s useful to me at least haha

Let’s see where we are at next week.