(2026-06-06) Estival Break - Release Timeline

Hey everybody! Slow news this time: between the heat wave we had a couple days ago and my schedule for the month, I’m not going to be able to do a lot of work on the project, let alone deep work… which is pretty much the main type of work at this stage.

Therefore, I’m going to be posting more chill updates on the project direction for the time being! This means it’s also a golden time to ask some questions: if you have some, do send them on the forum or on Discord! I’ve already done an early round of questions, which I’ll be answering over the month, as well as some subjects I’ve asked myself. I will be adding some open questions at the end of these updates you’re welcome to answer yourself!

Do note (although that’s gonna be explained more in a future progress), since I’m not always at home and I haven’t automated everything, for these update you’ll need to watch the RSS feed or the automated posts on the discord! I likely won’t be able to post these properly as usual, I’m writing a bunch of these in advance in a car lol. And with that, let’s start with the most common question:

What’s the timeline and features for the project release?

That’s of course the burning question: when will this new version be accessible? “When it’s ready” is a cop out answer, but while I won’t be able to give a proper ETA beyond “before the end of the year most likely”, I will explain my thought process, rollout stages, and planned features. I don’t have everything planned out in detail, I know well enough what big systems are there and how they link together but the exact implementation is decided later in the process, so it’s not going to be exactly as written in advance. I think this is going to be the biggest update.

There are a few things to keep in mind for the project timeline to make full sense. There’s several objectives to balance, just as there as different Castagne users and reasons for using it.

• Core first. Castagne’s main objective is and will always be flexibility and efficiency. This means that I’ll take the time to do things properly, as I still plan on using Castagne in ten years. This means that some features that are basic, such as menus, can be pushed further away to be able to support creating the gameplay in editor.
• Quality. Compared to the current Castagne version, which is in fact a prototype, this version does commit to quality. This doesn’t mean no bugs of course, but this means not having weirdo dangling parts, having automatic tests, having performance metrics… I tend to go towards quality in general even when doing things fast, but here I want to have a strong framework to be used.
• First impressions. These matter a lot, especially to beginners which can come from very different backgrounds and are very sensitive to small changes. That means that a lot of small parts must work together and be tested, as opposed to dev audiences which can figure out stuff more readily (and actually read the docs). The godot 4 version is the one many people are waiting on to start and are going to keep those first hours in mind for a while, so I want the common issues to be solved beforehand.

Personally, I’ve separated the tasks in several internal gates. The first gate is mostly for me: it’s when the engine’s advanced enough to be used for my own projects. It’s mostly core parts such as “attack cancels work properly”. There’s several shortcuts I took, since I want to focus on the internals. There’s a lot of constraints everywhere, such as preparing for rollback in advance, and all the systems made here are going to be interacting with each other and the future ones. This won’t be released, as there’s too many caveats in use that it’s not worth it. ETA unknown, since the heatwave took me out when I had the opportunity to make big progress lol. Here’s the remaining systems to give you an idea, there’s not that many:

• Timeline branch and animation system, which is going to be the main way to make attacks.
• Physics improvements, both in control (physics enveloppes) and base layer (better heuristics, maps, and information). Current version only has entity-map and attack collisions.
• Base gameplay mechmods: Better movement, hitstun and blocking, that kind of stuff. These could theoretically be taken from the current version, but I’m improving them so starting from scratch ends up better.

After that, there’s the second gate. It’s aim is to be for current power users, it’s a functional software that can be used with roughly the same precautions as the Godot 3 version, but not necessarily the same features. It’s to continue development. That’s where a lot of the key work is done, such as removing the shortcuts from the previous gate, implementing some of the less core but still important systems, and start gathering early feedback. Here’s a few of the main stars:

• The new sprite system, which is much more integrated in engine. Graphics pipeline too.
• Editor systems: distribution, tutorials, feedback (more on these in future estival updates)
• General editor workflow improvements, both ui and ux
• More gameplay related mechmods and associated functions, such as training mode or knockdowns
• Documentation of the functions and CASP functions

And then there’s the third gate, which aims for a potential wider release. This one focuses on what beginners will expect, but balances it with a faster release. The aim’s less technical here but emotional, the idea is to avoid the uninitiated feel like there’s a huge part missing. This does delay the stronger tools that make Castagne worth it, but beginner pandering enables potentially more people moving up the pipeline and helping out. Here’s a couple of the main systems planned out:

• More varied mechmods, such as burst or armor. Mostly chasing the “out of the box” feel and making it not just a softer curve, but a lower floor for most projects.
• Audio system, for which I’m still deciding on a lot of stuff. Decisions decisions, I actually studied sound and signal processing as well as sound design for games back in the day, but Castagne’s current implem aims a bit too much at pro implementations.
• AI system, the degree of advancement remains to be determined. I have ideas for a very strong system but it might be too strong and long to develop for this.
• Menus / UI, and round flow. Long and annoying to make, and one of the features that the uninitiated don’t realize the complexity of.
• Tutorials upon tutorials, to make the easy learning path longer.

That’s of course not the end of development, or even the first proper version. Beyond the fact there’s always going to be improvements to be made, there’s still some core features missing: 3D fighters and platform fighters, the tools interface, the command line interface, other engine integrations… The aim here is to be a solid enough open beta to bring in more people, but not wait until everything is perfect (which couldn’t happen anyway without user feedback).

You might notice that there is a shift in development between those gates: it’s aimed at pros first, then starts focusing more on the uninitiated before going back to pros. For better and worse, Castagne’s userbase is mostly beginners, and even within the more experienced people, I can’t help but notice many lacking huge parts of the picture. This is probably because I tend to have high standards and a philosophy of knowing what’s going on in the other fields, and a lack of clear visions and learning paths for gamedev. While having to adapt to that is also a personal journey for me (which doesn’t stop just at just Castagne but also many other fields including research), the need to define what is the aim of the software and adapt to the reality of the field is present and answered by this order: we first ensure everything will work for its purpose and not limit the user, then we aim at onboarding users and making the main operations smoother, then we expand towards the actual target level of the software. I’ll discuss that more in a next estival update.

One feature I haven’t mentioned is online: while rollback is a strong constraint that stays in the code always, a friend is going to help me with the implementation of the online services part. Ideally, I’ld also be able to get help on menus because it’s not that hard design wise or implementation wise but it’s very long, might have to see if anyone from the community wants to help.

All in all, that gives you a better idea of the release steps. The first gate is a priority, and a closed beta will happen towards the second gate. The aim is to expand more and more until we get to the public release itself as an open beta, then after a while get to a fuller feature set. Time wise, I can’t really say, there’s many different ways it can go and since it’s still going to be a one man show for a bit (I want to make sure all systems structures are set up properly), it’s very dependant on whatever else is going on in my life at that moment, including parts that are still Castagne dev but not directly technical. Still, I hope to finish the first gate in July, and the second sometime before the end of the year. Non contractual, can’t say more since I haven’t expanded all the tasks yet. Castagne is a huge project that did take more time than I hoped for when I started this rewrite in december, so it’s starting to overlap with other projects and commitments I have, although they are ultimately linked. This month being a good example since I can’t really do deep work, and therefore can’t make significant technical progress (although I might be able to advance some other parts).

That’s it for today! More estival updates to come, the next one is on the new engine direction and what it means in practice, which is going to be another philosophical subject. I think a lot. After reading this update, what do you think of that timeline? Where would you ideally hop on the new version? Go to the forum or discord to discuss this, and ask more questions! This is the time where I’ll be actually putting a lot of the vision behind Castagne into words.

(2026-05-24) Hitstop / Freeze / Halt

Quick update: hitstop is back in the engine. Here’s how you currently set it:

Set(Attack.Stop, 6)

In fact, at the moment that’s how you set all attack parameters. I’ll be adding functions over time for easier use, but this is the generic way. Some parameters that used to have different names depending on hit / block, namely hitstun / blockstun and hitstop / blockstop now are unified under their single banner of Stun and Stop respectively.

Fighting games have a lot of names for stuff that is player facing, and players also give it their own name, so I’m making up less ambiguous, less overlapping, technical terminology as I go. That’s why the default button names are LMHU, as it doesn’t overlap any common button name on controllers, that’s why “teching” out of a combo is “recovery” and “teching” out of a throw is “breaking” the throw. I try to link concepts that are conceptually similar. There’s no unified fighting game lexicon that all games use, so players tend to come with different names, and some names reappear like “high” attacks meaning different things for 2D and 3D fighters for example, or “stun” which could also refer to the “dizzy” mechanics of some games. I need to give names to concepts in the engine that speak both to the technical reality and face the user, so it’s a big matter of taste. I’m making the engine so we’re using my taste, which is also the correct one (obviously).

Anyway, Freeze phase and Halt phase work just as they worked previously, mostly. I have yet to implement collider coherence over several frames, so for now I took the shortcut of just removing frozen entities from the physics computation. I worry a bit about the more state I keep outside of the CASP memory stack as its additional rollback headaches. There’s a bit of play with the Before and After events: Frozen or Halted entities only execute their respective phase without the Before and After events, and they are executed at the same point as the Main phase, meaning you can use active entities’ After event to access data from the frozen / halted entities.

Cool bonus of the compiler being an actual compiler instead of a spaghetti parser is that phases / events are properly handled now, and hit animation now plays as expected without needing fancy tricks.

Summer heat is starting here and it’s frying me so I’ll probably be less efficient. I should probably either figure out blocking or physics enveloppes next, hopefully I’m out of those big core features by the end of the week.

(2026-05-23) Attack Cancels

Alright, new system is still in development, but it already works at the level of the previous one so let me share some early info!

The old AttackCancel system was just syntaxic sugar over an InputTransition. Works well enough, but there’s many cases where you need to do some extra work, namely for when an attack has prerequisites. Not really an issue, but still something you had to keep in mind often.

The new AttackCancel system has two major differences. The main one is that an AttackCancel now holds much more information inside, such as its motion or potential conditions for the cancel, which allows much simpler use. The second is the interface through metadata (which in fact shaped a lot of that system).

The base function is now just AttackCancel(State), with the state holding all the relevant info inside. That means you don’t need to specify an additional motion or check for meter cost and the like, that’s all inside of that little call. As I’m expanding the system, I’ll add more options to override the default values, such as adding an alternative motion for cases like a followup you can also do from neutral. These are not really new capacities, just a new simpler interface for that.

The way you actually use the system is simple: just put some metadata at the top and most of it happens automatically. A lot of the attack system now goes through that. Let’s take a look at a simple attack using an F branch:

+AttackType Light
+AttackDuration 60

F12-15:
	Hitbox(10000, 5000)
endif

Let’s break down some of the parts:

• +AttackType is a metadata line, and is the equivalent of AttackRegister from the previous version. It mostly works the same, but the new compiler features allow some extra conveniences, such as easier specification of attack types and the compiler warnings guiding you in the proper direction to make new ones. It will call AttackState and AttackType-[TYPE] (hook) for you.
• +AttackDuration is another metadata line. This time, instead of waiting until runtime to see the duration of the attack, it now will get it from the metadata, which is going to be relevant for frame advantage computations. The upcoming T branches will set this automatically.
• +AttackMotion can be used to add as many motions as you want. It is not present here, so it defaults to the state name if it is a motion.
• Then it’s buisiness as usual. I’m assuming you already used Castagne if you follow these updates lol

Planned upcoming metadata elements are +AttackCost and +AttackRequires, which make the cancel unavailable if the conditions are not met.

Next up here is going to be blocking, and how the attack cancel system will interact with this hitconfirming system. The remaining tasks for this gate are mostly related to the attack system, improving physics, or improving the editor.

Also, forum is back online. If it goes down again I’ll cry. I’ve improved the server config to host additional services in the future (in fact, I’ve already added one two months ago but it’s not ready for public use yet).