DEVLOG 2023-08-19

This week we resumed the livestream and we started working on using the messages (actions and events) coming from the C++ model and interpreting them. Well… at least the events.

Before, when the C++ model sent events, listing what happened since last player turn, to the GDScript side of the game (implementing the “view”) that side was ignoring these changes and instead just rebuilt the whole scene from scratch, so each turn appeared immediately because rebuilding the scene is fast, but it was also immediate, not allowing animations. With the actual interpretation of events, we have an animation for each event that can be interepreted with an animation. Right now only the Moved event have an animation, the other ones basically dont mean there is anything to animate except maybe FailedToMove that could be represented as a bump into a wall or another character. But for prototyping just haveing the movement of characters animated is already working well.

It might look simple and obvious, but doing it the way I did means the model can add new stuffs without having to worry about the interpretation in the view and the view cannot change the model, which avoids a whole class of issues.

Now the missing part is pushing actions when the player decide to do something at their turn. I didnt implement it yet by lack of time and because I need to see if I actually can do the generic and automatic handling of the serialization-then-passing of a value coming from GDSCript towards a C++ type. The issue, you see, is that going from GDSCript to C++ means I need to have a way to map the type name in the GDSCript action, which is a dictionary with at least one field “type_name”, to a C++ type, so that information MUST be existing somewhere and right now it doesnt. It’s part of the unpleasant situation where you have to pass values from one language to another, in particular with the lack of C++ reflection. Anyway as part of this prototyping I will still do it of course, and then when starting the actual game I will decide if it was worth it.

By the way, about the actual game, my initial plan was to finish all the prototypes by September then start the real game development. But looking at how much I still need to experiment with, to me we are late. I really need to make sure the view/model separation layer is at the right level so this Prototype 2 we are doing right now is crucial. To make the scope of the prototyping more viable (and because I havbe been thinking about the subject very hard), I decided to cancel Prototype 3 where we wanted to check if hexagonal base space would work. I’m a bit tired of thinking about this and it’s probably a complication. Maybe for another game. So that’s decided: we’ll go with a square-based game. But in a 3D grid. There is still the granularity of such grid to decide. The basics of the issue is this: does a character takes a whole position? Or multiple? Does a position is a cube (uniform) or more like a column, so that a character standing up is in one position? Remember: we want verticallity, not in the way Dwarf Fortress or Brogue or traditional rogulikes way of doing it, but really in a way where the player can be attacked by a sniper. There is still plenty of challenge and decisions to make because of the necessity (or will) to have a 3D grid. And Prototype 3 instead of being about hexagons, will be about that.

Then prototype 4 is about the action-turn granularity mechanism. For this one I actually have already a good idea of how to do it so we might skip it.

We’ll see I guess. For now my focus is Prototype 2 and we are not that far from finishing it.

Next Stream: Caves Of Qud playthrough

Next week the stream will not be about development but about playing Caves Of Qud and discussing some of it’s ideas, as it’s one of the inspiration of the game. Caves of Qud will be released v1.0 next year so I guess it’ss fine to not wait and play the current version together. I’m extremely bad at it so feel free to join to give me some clues hahaha