(2026-03-24) Physics engine okay!

Big milestone! I’ve advanced the whole engine flow enough so that we now have both physics and attacks working! They kind of go together.

First off: Physics. The new engine is more advanced than the previous one, as it’s made to handle more colliders and both 2D and 3D at the same time. 2D colliders are compatible with 3D and vice-versa, although it’s not what I would recommend to use lmao

At the current moment, it’s at mostly parity with the previous engine. While I could finish it right this week, I know people will want to use the new Castagne for the upcoming Indie FG jam this april, so I’ll be postponning it for a bit to focus on the editor.

Something that is of note here is the interface: the collider functions have changed. While I know this adds additional work for the porting of projects, after tests I’ve seen that this way is a bit better.

• Colbox and Hurtbox now work with an horizontal center, and a base and height. This is a better way to adjust colliders that are close to the character imo. Colbox(0,100,0,500) (equivalent to Colbox(100, 500)) will produce a box going from -100 to 100 horizontally, and 0 to 500 vertically, so it’s a simple way to add one to characters.
• Hitbox now works with width and height from the lower back corner. Hitbox(0, 100, 0, 500) (equivalent to Hitbox(100, 500)) will produce a box going from 0 to 100 horizontally, and 0 to 500 vertically. It reflects the more forward-facing nature of hitboxes, and thus allow faster set up.

I’ve set it up this way because it also becomes easier to move colliders around from code, as instead of being coordinates it’s now origin and dimension. This makes operations easier, except shrinking a collider forward which is the same difficulty as before. Do note that the order of parameters stays coherent: it’s dimension by dimension, and the shortcuts are (width, height) and (width, base, height) for each function, covering most cases.

This is not fixed in stone yet, so you can discuss it on the forum. Something to note is that I’m planning on adding drag-and-drop in the editor for these, so it should be easier to set up once the editor is more featured.

Some changes on the Attack module front too, although this one is quite tamer. It’s just a slight rework of the attack events, which work as such:

• At the start, OnAttacked is called on the defender. This is the first event, where most attack overrides will happen. This is before the blocking computation, so you can potentially decide to get hit or not, which is a new ability.
• After that, either OnAttackHit or OnAttackBlocked is called on the attacker depending on the result. The rest of the overrides happen here, and that’s where the attacker gets his meter and whatnot.
• Finally, OnGetHit or OnBlocking is called on the defender. This is where you apply the changes to HP and the like.
• In the case of a clash, only OnAttackClashed is called on both clashers.

All attack events share two properties: the target is the opponent for the attack, and Attack. allows you access to the current attack instead of preparation. This is intended to allow more flexibility in case of multiattacks and to enable more behaviors. Do note however, that the engine doesn’t store recieved/inflicted attacks anymore so you can’t refer to them outside of these events.

There’s more upcoming changes, although this post is long enough and I’m deciding on the details. Something to note, in this whole rework, is that the engine now makes more assumptions about your game, one of the key ones being the ground. The previous Castagne didn’t really care, but this one assumes that being grounded or airborne is a fundamental caracteristic of the game. I like that because you can ignore it if you don’t care, but it allows better integration, which really helps many cases. This is a throughline of the updates.

My next step is to advance the flow module, and to advance the editor workflow. I want the engine to be ready for the jam, although if you want to use it you’ll need strong basics with the previous one. Please get in touch, as this will probably be a closed beta, as it has enough caveats that I don’t want it available without supervision, and instead focus on a polished release. See you next update!

(2026-03-21) Forum Launched!

Hey hey! So up until now, the Castagne community was a bit spread around, but especially on Discord. This isn’t always the best for storing information long-term and having transparent discussion, but it was good enough for a while. However, now that Castagne has grown, it’s time to migrate to a proper forum!

You can find a couple things on the forum already:

• You can ask for help! There’s a support category where people can help each other, and answered questions are marked!
• You can post and read tutorials! Share your own knowledge there!
• Share your games!: Create a thread for your own game so that progress doesn’t get lost! You can also find likeminded people to work with!
• Castagne Development!: You can discuss all these progress updates I’m doing there! Threads are created quickly after publication, and you can also talk about improvements to Castagne.
• Real-Time Chat: You can still do lightweight discussions there! There’s also more general categories on the forum.

GO TO THE FORUM

The Discord will still exist, but I’m going to focus more and more on the forum as time goes on. The forum is going to be the one pushed forward on the website from now on, and there are integrations from the forum to discord.

Little extra info: at the moment the forum is using DiscourseID, since my mail is blocked by gmail (probably previous owner of the IP doing weirdo stuff with it), but I’m hosting it on my own server. When I have the time to properly investigate and fix this, I’ll add the option for local accounts.

(2026-03-20) Host Engine Structures

Remember that Castagne can be run independantly? It handles all the gameplay on its own, but needs to be hosted by another engine to actually poll input or display anything, which in most cases is Godot. This also means that some data has to be shared, which is the subject of today’s update!

Introducing two new types of data structure to Castagne: ModStructs and HostStructs. ModStructs are an extension of the structures that already exist, they store another Memory Stack and thus can be rolled back if needed. They are separate from the main memory, and live inside of the engine itself, which allows additional abilities where needed.

Currently, this covers the AttackData structure, and you can guess what it’s used for based on the name. The interesting part of ModStructs is that they are also accessible from CASP directly. As such, AttackParam is a thing of the past, you can now directly use Set(Attack.Damage, 1000) for example. It’s also much more flexible than before, as you will be able to declare any type of attack parameter using the declare variable syntax: declare Attack.MyCoolParameter vec() = [0,0,0] creates a new MyCoolParameter attack parameter of type vector. This will still be compatible with the Attack Overrides system, so it’s quite strong!

HostStructs are an extension of ModStructs, as they are one ModStruct plus an additional data structure on the host side. The most direct application is the ModelData structure, which holds the parameters for the model. This is stronger than before on the Castagne side, as you can do Model.Position for example instead of having the whole ModelMove functions. On the host engine side, HostStructs recieve callbacks at key points in the process, such as the graphics update step for models, which are used to handle data while keeping rollback in mind. Since HostStructs have access to this managed memory stack, they can read the correct values and update accordingly, which works better if you use an immediate update structure (meaning, you are not dependant on previous state). The responsability of data lifecycle during rollback will mostly be handled by Castagne, while the responsability of acting on the data is on the HostStruct. This effectively replaces the InstanceData system, which worked in a similar way but was less structured.

Anyway, that’s mostly internal stuff which is going to be useful for engine devs or those that go really far. On your end, it’s most likely buisiness as usual, as you just make your Godot scene and it gets loaded as expected. Or, you use Sprites which are handled for you.

One change that will be coming however as a result is the fusion of the 2.5D fighter and 2D fighter genre into one. This was a big mark of using Godot specifically, and it brought a lot of issues because Godot’s pure 2D engine doesn’t handle 3D models (duh), and as such a lot of default behavior couldn’t be used. Using Godot’s 2D engine won’t be off the table however, as it will become a config option, that way if you want to use pure 2D sprites and background you will be able to set it up.

This change will make the beginner experience much less brittle, and will cause less confusion around some features of the engine which are not available when using the pure 2D renderer as it will be opt-in AFTER the initial approach and ensure you actually know what you’re getting into. Many people think “2D Fighter” refered only to the characters, which is not the case but it’s not something you can “fix”, especially in the first 3 minutes someone has with Castagne. It also prevented the default characters from being used, so the choice most beginners made would cut them off from learning! Won’t happen as much now.