(2026-05-17) Two Characters

NO FELIX LOOK BEHIND YOU!!!!

Update is what it says on the tin, you could already do several entities but I’ve properly implemented the Battle Init Data support for variable overrides, which allows them to start on opposing sides.

A lot of updates these days are not super interesting to show in my opinion. From experience people tend to prefer stuff that is relevant to them, so “I fixed the editor having issues with helper states” when you never used the editor is kinda whatever. This has been the bulk of progress these days, small stuff like “input events now delay their consumption so that branches are more coherent in niche cases” that will save a headache to a few people in the future. That’s just programmer life.

Doing stuff properly takes time with very little visibility. The next big step is handling hitstun for example, and while the concept is simple, doing a proper hitstun state that is robust enough to handle various animations and states is much trickier than it seems. Most of the choices will sound like ramblings unless you have a dozen examples on hand lol

Anyway see you soon!

(2026-05-13) New Error System

I’ve spent two days to make this, but hopefully it’s worth it. Remember when I talked about making the compiler more robust and the engine more learnable? Take a look at the new errors:

As you can see, errors now are much more verbose. They have categories, and since there’s no space limit anymore they tell you a lot more detail on how it happened. This is already more advanced and useful than the previous version, and the display is nice.

A new thing however, that I added just now, is the ability to ask for a deeper explanation by clicking on the error itself. This adds the little blurb below that can be as verbose as it wants to that you can understand better why the errors happens, and how you can fix it.

This system is not just for compiler errors: it also handles compiler warnings, runtime errors, and the runtime logs. That also means all those can have more information given to them. One such information is the context, which you can see on the compiler error. This helps trace each of these back to the exact line it happened. This is definitely not something that will come up in a later update.

For the record, I have not written error codes for each error yet: there’s a lot and I got annoyed halfway through. Some are a bit context-specific and would require a bigger refactoring to work, and if I’m honest this has been already pretty long and I want to focus on other things. There are currently 38 error codes in the engine for compiler errors specifically, and I’ve written a message and explanation for each one, but there’s probably about as many of them to write on top of it. Now that the system is in place however it will be usable for new errors.

There’s a lot of work still to be done before a release. My tracker says 56 tasks before the first gate, which is not even the beta release. Not all of them are two days mind-numbing endeavors however. This biggest one still remaining is the attack system, including cancels and hitstun and the like. This is a core engine concept now so you have a lot of moving parts to design and handle, but bit by bit it’s going to be done.

There’s also all the surrounding parts I need to get back to: you might have noticed update videos have dried up, because they are pretty long to make even with the tools. Just communicating is taking quite a while, and even a casual update like this one takes 40 minutes to write, and another 20 to post. The forum is also still down, and I’m going to make the config a bit more robust because the website is hosing more and more features now. Anyway, that’s going to be it for today, see you next update!

(2026-05-10) Animation System, Graphics philosophy change

Alright, back on actual updates! This time, I want to show the new animation system, and a big direction change. Before we start, there’s now a display of the entity’s state and animation in the corner. Take a look:

Yep, Baston is going to be retired for a while now as its anims didn’t import properly for some reason. I haven’t made a Bagar model yet but Felix’s anims are quite complete and fresh in my mind, so he’s going in.

While that might look like the usual affair, the internal structure couldn’t be more different. This also shows a new departure in Castagne philosophy: graphics are now going to be more intertwined… in a way. Let’s talk about this direction change.

Castagne was always made to be very confined, and not go further out than needed. It’s part of its expert focus: you ain’t getting more advanced than bare metal engine integration. This has made Castagne very able to do advanced graphics, as you might expect from my profile. This has also polarized the engine a lot in that area, as it scales very well on a skill that is extremely rare in the gamedev space, and has left pretty much everybody else against a wall when they start pushing a bit more. That alone is not cause for too much concern, apart maybe from putting in a default godot-side, but as I’m making more and more fighting games, I am seeing that there’s a lot of cases where I want more direct coupling of the graphics as most attacks and state are extremely timing and animation dependant. Fighting games are after all one of the more kinesthetic genres, and as such you can’t treat graphics (specifically, animation and VFX) as an afterthought. This is why, Castagne will now handle a larger part of the graphics.

This is a huge philosophical departure, and makes a lot of design decisions very subtle. One big difficulty is that a lot of options are extremely dependant on your graphical pipeline. A beginner-focused engine would just make that choice for you, but Castagne aims for high potential and flexibility: I spent 3 years researching line rendering as a PhD, I’m going to use it in my games. I however don’t wish to force people in a janktastic pipeline that’s turbo bleeding edge, but at the same time vanillia godot rendering won’t cut it simply because the FG needs are a bit too different. As such, Castagne will now ship with a custom graphical pipeline focused on tasteful defaults, ease of use, and interesting options. That means you’ll be able to use a fraction of my power out of the box, without having to go meditate under waterfalls. Most users are not going to take advantage of the inherent flexibility of Castagne, and that’s okay. Most games have around the same needs, and the support of some abstractions will stay useful for advanced games too, while not making it mandatory. I’ll speak more about it when it becomes more relevant.

Back on animations. Now that you understand the new direction, how does the Animation system, which has been by design always very barebones, change? Well, Animations are now rich structures. That means that not only they will keep more of their data inside, including semantics, they will also be able to have gameplay impact in the future. What are some of the implications?

• First off, that means that an animation can have some of its internal logic inside, for example: loops. No need to call AnimLoop anymore where you needed it. The in-engine name can differ from the Castagne name too.
• There can be more manipulation of the animation. One of the big advantages of using Sprite was being able to alter the visuals associated to the frame data easily, but to do the same in 3D would require a lot of finnicky work. Since 3D has one more D than 2D and is therefore objectively superior, this won’t do. This, combined with some upcoming systems, will bring that flexibility to the better graphics option.
• Some people like attaching colliders to the models to automate hitboxes. My opinion is that’s an overall mistake for game feel, and the previous philosophy reflected that. Under this new direction, associating hitboxes and hurtboxes to specific parts of the animation is natural, and will be supported. This means that you could also bake your hitboxes in advance for 3D fighters, but also allow your team members to adjust colliders on a general animation while you program moves. I know most people are not using collab features but I do from time to time.
• Ease of use is kept by having implicit animations: if an animation is only refered to by a name, it’s set up with default parameters. This allows you to keep working as usual without going back and forth with animation definitions.

This will also be supported by a new branch: the Timeline branch. This is going to be the new star of the show, as after making hundreds of Castagne moves (geez) I have found that they have a lot of similarities. The Timeline branch aims to cover like 95% of usecases in a strong and extremely efficient way, and is going to be a joy to work with (for me at least). The design is still being refined, but it will allow Castagne to have its cake and eat it too at the cost of my sanity, as is usual with the engine. The animation system’s full potential will be shown only within that context.

Since it’s already long enough of an update, I’ll say that I’ve reorganized some tasks internally in three gates, a first one that makes the engine usable for everyday dev (= I start using it on my games), a second that can lead to a limited beta (= for the power users), and a third for general release. No ETA, and feature parity isn’t a concern anymore for the nicher functions for release (ie, freecam tool can wait lol, as well as systems that get their meaning when going away from 2D fighters). I still have to mentally process some of the feedback from the jam, don’t hesitate to send me your experiences!