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.