Published : August 10, 2025
Hey, long time no see! I’ve been making some progress on Castagne, as seen from today’s update, and it’s time to update the roadmap properly! I’ve switched to a new plan over the last few months, now that I’m unemployed self-employed, but I never took the time to explain it fully to everyone. That’s today’s article!
I’ll discuss what next year of Castagne looks like from a production perspective: the general lines of what you can expect, and around when. I’ll start with the current state of Castagne and how the roadmap philosophy changed, then I’ll explain the two big phases: the v0.5x cycle, which is finishing up soon and will be the last Godot 3 version, and the v0.6x cycle which is where Castagne becomes a much more mature project, and finally cashes in all the little opportunities I’ve laid upon the way.
I’ll stay high level here: this focuses just on the global featureset. There are a lot of very interesting details on how each part will contribute to the whole, especially with how there is going to be a new editor and how the UX and productivity will improve. This will be discussed at a later date, in a separate article.
Finally, this article describes my thoughts and intent at a specific time, as such the roadmap will evolve with development. The most up to date version will always be on the roadmap page itself. And with that, let’s get to it!
Right now, Castagne is a promising project that does live up to its promises in many ways, but also presents some flaws, mostly for non-technical users. Castagne handles the core gameplay with no direct issues, but it does requires some wiring on the side to make menus and the like.
This has been planned: unlock the core first, so that gameplay can be iterated on, then do what allows you to access it. One of the reasons that it’s not done yet is that Castagne is not meant for just 2D fighting games, it’s meant for action games (with a focus on FGs of course). As such, my plan has been to expand first with GDScript, so that theories may be tested quickly, and then refine it all together in a compiled language. While this is a sound plan, this is also a slow plan.
So, where are we on that? Well, 2.5D and 2D fighting games work quite well, and support for other types could be added, but we’re still just at those. A lot of the systems are designed but not implemented yet. We’re also at a point where the choice of GDScript is showing more and more performance problems, which while expected are preventing the development of assist-based games properly.
As the main developer, my life situation affects it a lot. The initial plan was for Castagne to stay in expand phase while I was doing my PhD, then refine it after. Unfortunately, the PhD environment was complicated to say the least, which has influenced a lot of the development for the last year and a half: there’s a bunch of features that are janky and non-documented because they were made in a short period between two crunch / burn-out periods. Now, my PhD contract is over (yessss) and I’m out of burn-out (super yesssss), but that’s still a big issue to fix.
As such, now that I know that I’m neither going in academia nor continuing in AAA, I am now going to go full-time on what were previously my hobby projects. This means faster development, but also renewed priorities, and as such a change is in order. Now that we have the current state and problems in mind, let’s see how the engine fares in general to take note of improvement areas.
Castagne’s goal was always efficiency and flexibility. Fighting games are quite complex beasts, and you have to have every advantage you can get. I am pleased to announce, that after surveys and interviews over the years (both Castagne and non-Castagne users, still in progress), it seems to truly live up to that promise. As far as I know, it might even be the current top dog in efficiency from what I heard of both open and closed tools! While this can never truly be known, I think it’s safe to assume the development philosophy works.
Another strong strength is that it’s also quite learnable: I’ve had people telling me it’s easy to learn, the tutorials help quite a bit, and the implicit learning path I designed into the architecture seems to also bring dividends: several users have gone through these steps without them being explicitely laid out and became much more advanced in Castagne use. This is great! At the same time, it’s intimidating: there are many options, and the code-based interfaces scares weaker minds implies higher effort, which might not be worth it and makes the first hours difficult, even with the tutorials.
I don’t think this is a fundamental problem: on one hand, Castagne has shown to be simple even to non-technical beginners once they take the plunge, and the options are a major strength of Castagne. I think it’s a matter of presentation instead, and I’ve got some strong solution ideas for the v0.6x cycle. Castagne has always been experts-first and this won’t change, but many UX improvements can benefit both.
Another weakness is, as expected, missing features, the main two being rollback not really being there, and that you can’t make a playable / publishable build easily. This was already a problem before, but I prioritized core gameplay and UX improvements, as these missing features become paramount later in development.
Not so much a weakness as a non-realized feature, is that Castagne’s efficiency is still limited to the base development. One of the major reasons I made Castagne was to integrate great tools, like the teased combo unit-tests. This is something I want sooner than later, but has been lower on the priority list than “the game works”. As far as I know, these don’t exist or are simple in other engines, so it’s not a weakness compared to others, but is something Castagne needs for its full potential.
There are other strengths (gizmos, VCS support…) and weaknesses (godot 3…), but these are smaller and / or subjective, so I won’t go into them here to not turn this article into a small book.
I’ve listed a lot of problems, but the main conclusion here is that the core system works. Castagne really focuses in on its strengths and it works, while its weaknesses are solved with more development. All good then? Well, yes, it means it’s got the right goal and the right direction, but also that path is long and could be shortened.
Castagne has been mostly expanding by integrating more and more constraints, testing different systems to improve how it delivers its core promise, and reacting to demands (like pure 2D fighters). It has opened many potential strengths, but these are not fully realized yet. While by itself this is not a problem, people are making games with it, and not being fully realized presents issues for them (which are signposted clearly, so it’s something they know beforehand). Additionally, this is also a growth issue: if people are waiting for it to be realized, there are less users, and as such less games, which also means less users as they want to see it in action. Less users means less development effort, so it’s good to keep in mind (in fact, I might define a new v1.0 to encompass only fighting games and leave more genres for later versions, which might be smarter than “v1.0 is when I’m done adding features” lol).
Castagne always had this tipping point in its design, where there was a phase of expansion to test all these features, and a phase of refinement where everything gets more locked down. The more the first phase goes on, the more info there is for the second. With how the systems became more and more stable, I believe it’s a good indicator that we’re reaching a point of diminishing returns, and more data will only make itself clear as more people dive in and make wilder games. There’s also the evolving ecosystem, with several features improving a lot on the Godot end (when Castagne started, Godot 4 was still unstable and in beta, now it’s the main used version for a while). The many evolutions of CASP also start to suffer from technical debt on the Castagne Parser, which is currently more of a compiler than a parser. As such, I believe the best way forward is to switch gears and make this switch ASAP.
As such, Castagne’s new roadmap philosophy is focus on making it fully featured for 2D/2.5D fighters, then expand into other genres. Instead of adding more physics modules and genre skeletons, I say to add menus and tailored tools. This doesn’t change the list of planned features, just the order. This means the rewrite in a compiled language will happen soon, and I’ll be taking all that I’ve learned about how Castagne actually wants to be used, as well as the clearer future direction into account, and try to solve the majority of problems explained here.
This is pharaonic work that will take me several months more likely than not, and as such it would be unreasonable to leave Castagne in its current state that long. Therefore, before going into this, the short term objective is stabilization of the current Godot 3 Castagne version. This is what the v0.5x cycle will do, before switching to the v0.6x cycle. I will now explain what to expect from both.
The v0.5x cycle has now a new goal: make a stable version that allows gamedev to continue while v0.6x is developping, and allow builds. That last point is important, as it will allow users to do playtests. Making presentable menus for final release will still be on them, but the structure will be there. The versions’ tasks will focus on either fixing bugs and stablizing some jank, or on expanding the last features that were planned.
I’ll add a caveat: written document probably won’t be updated, and function reference might only be updated at the end. My website tools are currently broken and I’m jerry-rigging everything so it will take time to fix it enough to have the fucntion reference back. Written documentation is another beast, and instead of adding a long task that will slow down development and need to be redone anyway, I prefer just rewriting the new documentation.
The timeframe for these is intended to be short: I should be done with v0.57 in August-September. After that, I will be on the v0.6x grind.
This is where it gets complex, as this is very much a global improvement on all aspects. Development will by necessity be non-linear and will need to adapt, so I believe it is important to explain the high level components and motivations:
As you can see, this is basically a full project overhaul. It’s also full of linked parts: compiled CASP can’t work without a new compiler, which also means that the editor might have things break… As such, it necessitates a fully realized plan, and is not something that can work well with incremental updates at first. I will therefore only publish on the Unstable branch of updates for a while.
This will take a long time. I expect this to be an ongoing effort until end of Q2, maybe Q3 of next year, but after this Castagne will be a much more mature project and ready to truly achieve its potential. It was planned from the start, although it happens in a bigger batch than I initially expected.
I would recommend to continue your current projects and not wait for it, as CASP has been shown to be stable enough that it most likely won’t fundamentally break your game. More likely than not, what will happen for projects updating from v0.5x to v0.6x will be some functions changing their signature (which likely will be handled by the new version update tool), and some potential gameplay alterations on physics since behavior is undefined (and will be properly defined in v0.6x). Those that played more with the engine internals might have more issues.
The first order of buisiness will be to kickstart the truly linked parts: the trio of the Engine Core, Compiler, and Editor. They are coupled by necessity, although the editor’s dependancy can and will be reduced. There are three goals to achieve here:
This update has few technical difficulties: I am not attacking the hard subjects yet, such as memory storage. The compiled CASP code will still mostly call GDScript functions, so performance should be similar. What the update does is cut the gordian knot, and allow the components to evolve separately. It also adds the structure needed for the following versions: a testing framework, which will allow to test the performance impact of all these changes.
This will all be released as one update, as there is no other natural cutting point before then. This will be v0.60. I will require active testing, as the compiled nature of this update means that windows and linux code will require separate compilation, and thus potential new bugs.
There is however one big prerequisite that you might have noticed: I never specified under which language I planned to write Castagne. This is because this must be tested in depth before I choose. While I have used C++ in the past, my PhD made me understand that I’m a C programmer at heart when I spent 6 months on a C compiler without noticing it, and if I’m not using all those features I might as well go with a newer language. I will thus be testing C++, Rust, and Odin, on their usability for low level code for games, integration with Godot, and abilities in rendering, which will take one or two months.
Once the framework is in place, there will be two parts going on in tandem: I will be translating and improving the modules themselves, and improving the editor at the same time. The reason for this is that both will have to talk a lot to a key part of the engine: the compiler. This is going to be an extremely tricky part as both will exert a lot of pressure on the design of an already complex system: the modules want the code to run really fast, while the editor wants strong analysis tools.
There will be a lot of changes internally on every part, so that means I’ll also need a lot of time on the design board. As such, there’s many unknowns. Still, here are the big parts listed down below:
I’ve got a feel this would be something to expect towards Q2 2026, although I’m promising nothing at the moment.
At this point, Castagne should be in a very good position, with good tools and good performance. That’s the part where I’ll need to focus on improving the quality of the release for a wider release, and then get it to a point where commercial games can be released on it, even if slightly barebones. It also means that’s when rollback gets properly added! Here’s the big items, not necessarily in order:
You might notice that most of these are actually focused on the community: I believe this could be one of Castagne’s great strength moving forward. At the moment it’s mostly me making an open source tool with most of the code contributions, but further on I think the tool has enough potential to foster a healthy community around it, so I want to invest some effort into making it welcoming to start amassing users. Since this phase is when the tool removes its main weaknesses, I think it can start to be carried by its strengths properly.
At this point Castagne will be quite strong! There will be no glaring weaknesses, and the core strengths will be there. The editor improvements should make for a very nice efficiency upgrade, on top of well rollback and performance unlocking new options!
I feel that will be enough to finish this version cycle, but there are still many things to do! Here’s some of the potential directions after:
Of course, this is just a early declaration of intent, and will likely be revised a lot until then. This won’t be even starting until one or two years depending on how things go, but I think it will be a good way to really push fighting game development!
Anyway, I hope this article has cleared up your questions on how I see the development of Castagne over the next year! That’s a pharaonic amount of work, powered by my unemployment stipend and general willingness to have this. I believe this will be a fun (at least, compared to general programming projects) adventure, and I hope the community will be there and grow along with it! As this cycle progresses, there will be a lot more room for contributions so I hope we will find how to harness this aspect.
I’ll leave you with a summary of what I’ve been saying here to conclude this, along with non-contractual dates (they are based on what I expect with how my life is going now, and are very subject to change with external factors):
Enjoy today’s release, don’t hesitate to share what you’re working on! See you around!