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!