Yo! Another update to a structure you know (and love?): BattleInitData, which as the name implies, holds the data needed to initialize a Castagne fight! Most probably didn’t use it much, but it’s been a cornerstone internally.

There is not much to talk about to be quite honest with you, as the ideas work the exact same, the interface is just better. It used to be an unwieldy JSON dictionary with a weirdo format, now it’s a properly reified object with a functional interface. Here’s an example where I create two players and their character, both have a 100 meter but the second one only has 1 HP.

// Assume we got config, player_1_scripts, and player_2_scripts properly handled before
let mut bid = BattleInitData::new(config);
let character_1 = bid.player().entity(player_1_scripts);
let mut character_2 = bid.player().entity(player_2_scripts);
character_2.entity_override("HP", MemoryEntry::Int(1));
bid.entity_override("Meter", MemoryEntry::Int(100));

As you’ve seen, it is simpler to build, and the previously available functions are there. Overrides allow you to change a variable from the character at creation, and you can set them up to be inherited. As such, the Meter override here was set at the root, so it applied to all entities defined in this BID, while the HP one was only done to a single entity. You can override global, player, and entity variables, as well as create entities with no player parent.

This is still a work in progress, as I’m focusing first on key functionality there. The new idea is that known data can be set more easily in general when the engine knows about it, with simple functions. Here’s an example of a new functionality: instancing subentities directly:

bid.player().entity(scripts).subscript(fireball_subscript_id)

This is honestly fairly low priority compared to other tasks once that the basic functionality is there (some overrides don’t currently work because there’s no player memory yet for instance). It’s needed to set up fights in the editor and game, but at the moment only the first is needed to get started with the engine (as you remember with my priority list). Still, are some planned / potential functionalities:

• First of all, there is going to be a host engine interface. That example was in Rust, but you’ll be able to have a very similar interface from within Godot.
• The flow module will be able to handle “standard” variations of this. An example you already know is the fighting variation, which just gives you a 1v1 with potentially multiple characters.
• An idea I’m evaluating, is the ability to save a state to a BattleInitData, which would allow to store state on disk. This could be REALLY strong for editor tools.
• Another idea in a similar way, is the ability to add BattleInitData DURING a fight. With proper management (keyword: proper), this could allow complex worlds and situations, which would be quite interesting for the more platforming focused cases.
• Another one that’s linked to both, is the ability to reference existing HostStructs or similar from within. I’m not sure yet of what this would imply, but the idea is to be able to integrate Castagne into game flows better, like starting a fight from an RPG overworld seamlessly. We’ll see when I need it I guess lol, that’s real low prio compared to actually making stuff work.

Next up is multiple file loading for CASP files, as well as Editor control there. It’s time for the Base CASP to get a tune up, and that would already cover most of the prerequisites for the engine!