Hey hey, small post once again to tell you how development is going on my end! This bulletin talks about the work done, in progress, and in the future.

Community / Smaller subjects

Little section to start out with some subjects that were open:

• Unity news have brought a lot of people here, please know I'm always available if you need more info on some parts or how to port your game.
• Similarily, 2DFM02 conversion prototype has been a success, still far from publication ready however.
• I've started updating the video tutorials here. It takes a lot of time to keep the learning accessible so it's tricky to keep up, but I think it's worth it. Still, it's a commitment lol
• Haven't been able to open easy first issues due to lack of time, will try to do so when possible.
• Concerning the license change to a more open source one, I'm very probably going with MPL 2.0 (which will roughly amount to "if you fix a bug in Castagne please share the fix" most likely). I'm waiting on confirmation from knowledgeable friends that this won't affect publishing on Steam or other platforms. Castagne is FOSS and will always be. As I mentioned before, I wish to figure out this licensing situation before resuming updates.

New Specblocks system (coming next update)

Prolly should find a better name if you have an idea, previous one was Castagne Data lol.

The system took a nice form in the end and is integrated into the editor. Here are the capacities:

• It can define constants that can be then used in the code as usual
• It can provide a graphical interface in a few ways:
  • Replacing the code panel with a list of variables inside of categories (default, easy)
  • Replacing the code panel with a custom UI panel
  • Replacing the main window with a custom UI panel
  • Adding gizmos on top of the game
• Its data may be extracted and transformed easily, with the ability to do so even outside of the engine running

This is a really nice addition! It fills up a use that was only able to be filled in a complex way before, and by enshrining it like this it becomes a lot easier to edit was were already present engine features. I've noticed users can miss some of the features pretty easily (and have trouble extending variables blocks), and sometimes editing can be a lot of trial and error.

Let's take movement as an example: before you had to do plenty of small adjustments and feel out the ideas. You had to look for variables and edit them across a few variables blocks. Now:

You got all the variables exposed in categories logically, and see what editing them does before recompiling the engine. Nothing changed on the backend, for this it's just a lot easier to use and no variables are lost.

Sound System (currently worked on)

This is a simple implementation, since Godot 4 had made some improvements on it. It's mostly going to be a flexible base that will be built upon in future updates. It's in two parts, plus some UX.

Music will be set through a Castagne config menu. It will include support for intros and looping. In the (nearish) future, you will be able to use those same settings for menus and the like. Playback methods may be overwritten for more dynamic music, but considering the needs there it probably won't be expanded upon until v0.7 (godot 4).

SFX will instead be set through specblocks. While this implementation will be simple, the idea is to keep the callbacks flexible once again so that you may include all the fancy sound manipulation you need. This is accompanied by the SoundParam function that can, well, set arbitrary parameters to be passed to the callbacks.

As you can see it's mostly a base. Sound is one of the domains that's really important in fighting games, but it also needs special attention in rollback. Because Godot 3's version is pretty simple afaik, I prefer keeping a generic interface until we go to Godot 4 and figure out a more featured and stable version. This base should be able to stand until then (and most likely after, since I'm keeping standard middlewares in mind) and be built upon if you need functionality faster.

Updater / Packaging (next update)

The current update cycle is a bit hard to keep up with on my end, with releasing a build taking around an hour or more. Plus, it's annoying for you to update by going on the website.

If I want to open up contributions, this needs to be reflected upon to go faster, so that means I have to finally figure out the updater proper. This is a good opportunity to also store some of the "packaging" of Castagne, to avoid some easy pitfalls. This may need a few iterations since it's OS dependent.

There are also a lot of pitfalls, like a recurring bug that can happen every time we add a new asset to the engine that will just make it bug when launched directly (cause is known, solution is known but prone to human error). There's also version numbers everywhere that don't get updated. All in all, this means a fair bit of tedious work that I want to automate as much as possible so that people don't get dumb surprises when they try out the engine for the first time and I can focus more on Castagne itself.

Since I'm waiting on that license change to release the next version this seems like a good opportunity to do all of that and then clarify the main/dev update cycle (since we are getting more stable and featured). I'm thinking of slowing down the main branch a bit sometime between now and v0.6 when I feel it's not missing key features anymore, keep dev builds on a somewhat regular release schedule, but especially use the new code branch for fast bleeding edge releases.

What remains for v0.54

Since I grouped updates by functionality and not length, this one is also shaping up to be a multi-month affair. It takes a bit more time than initially expected because some usability and performance concerns have been brought up through the use of the engine, and fixing them as soon as possible is something I want to do to ensure future work goes by more smoothly.

The big thing to note here is scaling the engine for multiple entities. This is a core concern on several levels, and affects modules across the board. Some changes have been made already through v0.53, but more are needed. Here is a high level list of the actions to take:

• Currently, the target system is a bit barebones. The previous simplification was a really solid step, but it needs additional support to reach better usability. At the moment, it is mostly only used to access the main character of the opponent in general, and instancing projectiles. I want to make it a bit more explicit, and ensure some better data access in general (as at the current moment, it is dangerous to use).
• Somewhat implemented, is handling multiple hits and similar. We got some callbacks sent per collision (which works well), but I'm not convinced this will be enough in some cases, so I want to investigate the limits of this method, and open up additional options if needed.
• Freeze phase, as of now, is a global setting, which is not suitable for hitstun. At the same time, if several entities enter freeze at the same time, they can affect each other in probably unintended ways. As such, a partial rework is needed. I'm thinking of separating freeze into two distinct features. The first is individual freeze, which is going to be used for hitstun and affects single entities. This will require a few adjustments especially on hurtboxes, but it will allow better management of hitstop and similar things. The second is a global freeze, that may only be entered by a single entity at a time, which will be the most useful for superfreeze, as gameplay will truly halt. Better names to come
• At the moment, all entities are "full entities", that are completely independent and have access to everything. This represents a missed opportunity for both performance (full entity is overkill for a graphical effect) and usability (order safety limits what we can do). To solve this, I'll implement one idea that was here for some time, and implement additional entity types: Sub-Entities (for projectiles and the like) and Light Entities (for effects and non-gameplay affecting stuff). They will have access to less things, but at the same time will allow implementation of complex behavior a lot more easily (get projectile position, get number of projectiles currently out, etc). More details to be ironed out.
• Finally, actual support for multiple characters per player, or multiple players, so that we can do assists properly. A lot of the previous improvements given here are to make this possible and practical.

The Attack Module would also benefit from having a lot of love put into it, since it's one of the core parts. Some of the mentioned entity work also improves it, but some focused features would help make its current abilities more generic and applicable:

• Blocking logic is currently hardcoded and not super documented, so a rework that allows more flexibility would be really nice.
• Something that is only somewhat implemented here is altering attack values depending on opponent state. This is somewhat present with block or air variations, but I'm thinking of an override system that is more flexible and thus allow for counter hits or other specific situations.
• Attributes somewhat exist now, but I want to expand them more instead of being a dumb simple copy of what I saw elsewhere. To complement the alteration system above, I want to make this system hitbox-hurtbox specific and allow more specific uses (OTG, air only attacks, etc).
• Combo resources ("meters" or "counters" that are reset at the end of a combo) are also somewhat implemented for groundbounce, but I want again to make it generic.
• While not attack module specific and more on the CASP end, Proration has been a bit on the sideline for a bit. I want to implement some more control over it, both for damage and hitstun, as well as progressive gravity.
• Default values for various attack types. Current system uses Castagne Config and is no longer sufficient, so it will be moved to CASP and exposed.

Finally, Battle Flow is getting moved to now since its prerequisites have been moved earlier, as well as being a feature that most people expect (even if not a current core priority). System is of course going to be flexible enough to allow custom behavior between rounds. If you are wondering why it wasn't here before, it's because it was but its design didn't survive collision with rollback back towards v0.2 (in early 2022! Kronian uses the old system in the april 2023 demo since it's alright in a solo environment).

Rest of the roadmap

As usual, I'm going over what's on the menu for Castagne and it's been a while I haven't gone over the roadmap, so I've refreshed the page a bit.

Here are the main changes:

• Removed the funny names for updates. I am serious man now. >:(
• New character model is scheduled for whenever I have time now and not a requirement for next version
• Added battle flow to v0.54 as mentionned
• Attack module rework pass 2 moved from v0.57 to v0.54, since it's pretty much what is being done
• v0.55 is still focusing on graphics, exact contents have changed but not the high level map
• v0.56 is focusing more on game mechanics to implement. Doesn't change the high level map again.
• Removed "basefiles improvement" from v0.57 since its being done every update and most of it is now in v0.56
• Removed "Standard Custom Editors" from v0.57 also since they need a bigger rework and the urgent need has been filled by specblocks. This is scheduled for the v0.7 or v0.9 cycle instead (TBD)
• AI is still scheduled for v0.57 at the moment, but may be moved earlier. Similar for the second menu pass of v0.58.
• In general the roadmap from v0.57 onwards is less set in stone, while for the next few versions its a lot more defined.
• Removed the "mystery boxes" since some info has been revealed already and I'm not sure when to include them.
• Moveset jam is still in the works, gonna wait until we have a good set of animations to jam with.

Wrapping up

Anyway, that's it from me! I'll keep posting short updates regularly and adding features as needed. I'm really glad for how the community has grown and is helping each other in the channels. I hope we can keep the momentum going, and I can't wait to see your games!

I took the opportunity to take a quick look, and we are at about 1239 downloads of Castagne. Neato! I'll do a more complete stats roundup later.

The last few updates have been pretty heavy, and they'll probably still be for a bit. While all the versions up to v0.52 were the "prototype" phase, this one is the "growing" phase, where it slowly builds on the lessons learned. "Stabilization" will most likely come from v0.7 onwards.

It's always a pleasure working on the engine and the games, and I'm happy to see the decision to make it open has helped people. Considering the amount of work, I'll try to pace myself to achieve all that I want to do in due time.

I'll most likely be back writing a long article with the yearly Castagne survey, coming towards october-november!