(2026-06-09) Estival Break - New Direction

Another day, another update. Just kidding, I’m still in the same car as the previous update, so it’s more same day more updates. I’m writing these in advance, with maybe a tweak or two depending on feedback. This one’s another long wall of text, but at this point you expect them.

Please do tell me if you read these or if they are sent into the void lol

Today we got another question, asking more about the new direction of Castagne. Let’s try to clear this up.

How does the new direction act in practice?

So, Castagne has been in development for a long while - 2021 to be exact, we’re in fact nearing the 5th actual anniversary (wtf). A lot has happened in my life and around the software itself, and I have a vision that shifted a bit as the environment became clearer. This does affect dev in quite a few ways, but let’s indulge a bit in Castagne’s origin to understand the context and understand how this new direction will change the engine.

Castagne, at its origin, is the engine layer for Kronian Titans. KT is a passion project, the first I started after burning out on hobby game development. I used to make games for fun, but usually never finished anything. My interest had always been in the systems and architecture, so gameplay itself was less interesting to me. In that sense, I’m not really made for regular indie dev, which has been an important realization at the time. Kronian was made with a longer vision in mind, as a hobby project that would progress over a long period on the side of my main work and doesn’t make too many compromises on its vision. As such, I needed strong tools for gameplay iteration, and after looking around no engine was able to that at a satisfactory level, so I started my own engine layer. The level needed for the tools was too high and expensive to be used for just one project, so I ensured it could be used for several other game genras. After that, since I was scheduled to restart working (I started Kronian during a forced administrative break at work), I figured I could separate that layer and make it available for people online, and who knows it might be helpful for some. This is how Castagne started and released towards the end of 2021.

You can make sense of a lot of Castagne’s decisions using that framework: the focus on experts is because its target user is me. It’s using Godot because it’s my favorite game engine and is open source, so it’s a stable base. It delegates a lot to Godot because I don’t want to redo work for nothing. It’s focused on both flexibility and efficiency because that’s what I value and need for Kronian, and pays for that in design cost and engine complexity, which plays to my strengths. The fact it’s accessible to beginners is basically a fluke in the design: the focus on efficiency means that you have less stuff to keep in mind and get up to speed faster, which helps beginners. I’ve also kept the learning path in mind, because I think that if the software is aimed at experts, there should be a way to become an expert.

In those five years, Castagne has grown tremendously. There’s around 500 downloads every month, and it’s used the world over (not that much in France interestingly enough, I’m too international I guess lol). It’s also software that has had real impact: it’s been an entry gate for many people into the world of programming and game development. I really enjoyed reading the messages telling me it’s been used in a US university to teach programming, how it helped people approach programming from zero, or how it finally gives them a path to their dream. Each improvement in onboarding resulted directly in new profiles coming in, sometimes to the detriment of my mental (not your fault).

Now after five years, I both have a stronger vision of how fighting games are made, and a different life situation. Back then, indie gamedev was just a hobby, now it’s shaping up to be my job for the forseeable future. I’ve been pretty outspoken about how I think that to be stable in the future, Castagne needs to be strong enough to have a pro environment around it, and having it be more accessible is something that would help that goal. Another factor is how, in the end, even though I tried to avoid doing a full engine, I am very much poised to make a full engine as my next big project is a renderer based on my PhD work, so there’s less incentive to keep things super separate. Funny how that works.

Both of these by themselves do not justify a direction change, the current one works well enough and its issues can be fixed with a couple targetted changes. The last factor was seeing how people, for many reasons, are only using 10-15% of what Castagne actually can do, because they don’t see how it integrates inside of a larger vision. That’s not particularity a problem of Castagne’s userbase itself, nor it is Castagne’s issue, it’s something more global: a lot of game development is done in a shortsighted manner, with few resources and visions going further. You can see it go further in bigger studios like AAA ones, but even then I always felt something was lacking.

Usually, I don’t really like imposing a vision, so even though Castagne’s structure is opinionated, it’s justified in many ways and has a lot of room for flexibility. This is not going to change. However, most people don’t just want the tools, they also want to be guided. Realizing that being heavy handed is not rude, but in fact something people want, has been the main trigger of this direction change.

My workflow is not optimal, but I do think it is quite good, especially with regards to Castagne. Therefore here lies the difference: the old Castagne gave you the tools to make your own workflow, the new Castagne says that if you don’t have a strong opinion, you’re using my workflow now. This might sound small, but since I was aiming for quality and usability in many situations, this puts a lot of restrictions on what I can do, while not being able to be communicated to uninitiated users. Under this, I can make much more assumptions about projects, thus enabling many more improvements. Breaking those assumptions requires a higher level of skill than before, but in practice this has already been a high level most users don’t clear, and I still have that core flexibility in mind so it’s not like that ability is gone.

This affects many parts of the project, but one that exemplifies that really well is the sprite workflow. Compared to 3D, sprites are much simpler to make, but also don’t have a standard pipeline (the 3D pipeline still confuses many people, but this one’s beside the point). Therefore, it tends to be the preferred method of many beginners, some that just rip sprites from elsewhere. Castagne handled sprites by relying on Godot’s system: spritesheets. However, this had two issues for beginners: one is that it requires going into Godot and this confuses people a lot, and the other is that spritesheets are not part of common knowledge anymore and some have trouble figuring them out. This leads to people wondering why it’s not something that seems easier for them, such as individual PNGs (very good, potential for optimal), or GIFs (never suggest that again). The back and forth, and needing to tell Castagne about it, and other oddities such as animations and palettes makes this a bit clunky to use at times.

The real answer of how to use the system is one that, as far as I’ve seen, nobody else but me uses: an actual asset pipeline. I never interact directly with the sprite system, it’s done automatically for me. I put my PNGs in, and in a single command all the sprites are now available in Castagne ready to be used. This is the way it’s meant to be used: sprites come from many different places which Castagne can’t know, so you plug both ends yourself. You were supposed to figure out what workflow works for you, but writing this I’m thinking that many didn’t realize this even was an option.

Under the new direction, Castagne’s reach goes further, further enough that you don’t need an additional step in the pipeline for basic use, you can add your sprites individually from within Castagne. This doesn’t stop the previous way, using an asset pipeline is still the optimal way as allows maximum flexibility and adaptation to your workflow. It’s just that now, being non-optimal is not as penalized as before, Castagne now has a default workflow that does cover the case of 90% of users well enough that it doesn’t become a big priority to fix.

This applies to other parts such as the rendering pipeline: it’s always been optimal to make your own that works for the project, and if you don’t follow specific steps I can’t make that work for you, and while I can do that within Castagne pretty naturally, changing how you do assets would be an overreach. The new direction realizes that for most users, this is not seen as going over its scope, but as Castagne being the center of their project, it’s much more justifiable.

I believe all in all, this is a more realistic vision of how people actually use Castagne and massively improves the case of 90% of user while not really affecting that 10%. This does represent a big workload increase (meaning the software will take more time to come out), but it also ensures more Castagne users are ready to use the other parts of my workflow for future projects, and makes the experience more standard.

In a way, this is accepting that for many people Castagne is not just a tool you put inside of your existing project and workflow, but their entry point into the world of game development or programming (or even actual computer use, as I’ve seen, or fighting games themselves). This adds an educative role to Castagne, on top of being a quality tool that is the best at what it does in the ways that matter to me.

Did that make it clearer? Do you believe I’m overthinking things, or overreaching? Don’t hesitate to continue the discussion on the forum! Next estival update is on the communication flow !

(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.