(2026-07-28) Godot 3 Final Final Update

Last Godot 3 update time! And because I don’t want to rebuild the old website atm, I’ll just put the various fixes here. Do remember, this is a maintenance update to the old Godot 3 version. And moreover, it’s the last, in theory. The gamejam in april did bring several people together and made all of us do some quick fixes, which are now integrated. I haven’t tested this in depth, just some basic “seems to be in order” checks.

If you did change castagne files during the jam for example, make a backup before updating as it will override the folder. I recommend then merging manually with a tool like meld. You can also do the update from the git repo itself if you have a git tool installed.

If people are adding more fixes, I can integrate them but for me that’s the last I’ll be working on the Godot 3 version, I am more in the process of porting my own projects to the new one. Here’s the list of changes:

Gameplay

• Local Battle now uses the AI by default instead of the dummy.
• Double tap forward and back is now more robust for dashes (thanks Dewiter!)
• Airborne airdashes are now affected by the CantDash flag.
• Timer now freezes during Halt Phase.
• Throw Followups now have no hurtbox by default.
• Death now has a phantom colbox and no hurtbox.
• Can’t kill the opponent in training mode anymore.
• Fix: Blocking while crouching now displays the proper animation.
• Fix: Blocking lows and overheads now updates the blockstun state.
• Fix: Block options in training mode now work properly, independant of standing/crouching.
• Fix: SetMomentumX doesn’t bug anymore (thanks *snuffysam!)

Engine

• Added Armor flag which makes blockstun not happen, and calls the OnArmor state instead and raises the ArmorPunish flag on the next frame.
• Added NoVFX and NoShake attack flags to remove some of the effects.
• Added NoGroundTech attack flag which prevents teching from happening once on the ground.
• CallParent now has a guard to prevent calling it.
• Player distance computation slightly more robust
• Increased default zFar distance for the camera. Not configurable.
• Palletes for 3D sprites are slightly more robust.

Editor

• The mute button now checks its state directly on startup, in case you forced it pressed.

Menus

• Input rebinding works better with controller (thanks GamingWarthog!)
• Palette selection is properly bounded (thanks GamingWarthog!)
• Added music select.
• Default action element script now sets the text of children too, for a bit more flexibility.
• Post battle is slightly more robust.

Additional Notes

• We implemented online rollback for Void Fury, but the code is not polished enough for me to add it to this release. It would only lead to more support questions. Some other systems, similarily, are a bit specific to the game and setup and have not been added. I don’t really want to delay the next version, so I’m just one-shotting this final Godot 3 update for those still working on it.
• I noticed a potential offset during animations during VF. I decided on not importing this “fix” because I don’t know if it’s something that should be fixed, it’s likely project specific? I don’t want to use brainpower on this so for consistency I’m not changing the current behavior.
• If I write “slightly more robust” in this update, it means “I added / fixed a check for specific situations but don’t remember exactly what condition made it happen”. So it’s more likely “advanced use works a bit better” instead of “beginner-proof”.
• There’s a timer fix that I didn’t include because it was too annoying to do. You can make a PR to make a global timer instead of the hacky local one I have.

(2026-06-20) Estival Break - Beginner Vision

Another estival update! If the text before is dry, it’s because you haven’t interacted enough and I don’t have anything to change.

Bit of a delay with the last one but there’s a good reason: i forgor

Beginner Vision

Big subject, and one we actually talked a lot about in the previous update on docs! There’s still a lot to say, and this time I’ll focus more on the beginner focused parts and how they are handled.

Castagne is a software meant for experts, but there’s not many of them and you need a path to become efficient in Castagne. As such, the previous definition of beginner was something simpler: someone who doesn’t know Castagne yet, and might be less technical in general. However, in practice, that’s not the correct definition to use, and the people coming into Castagne have been quite varied. Let’s review some assumptions on beginner’s knowledge:

• Do they know how to program? Mostly no! There’s various beginner profiles, but for most of them Castagne is the first time they actually encounter programming. This was already in mind, although knowing how to program is always a plus.
• Do they know how to use Godot? Surprisingly, that’s also a mostly no! People come into Castagne from a direct search. The reliance on Godot is both a boon and a curse, as it makes the wall either lower or higher depending on what the other person already knows.
• Do they know fighting games? Very surprisingly, also mostly no! While most have the general concept of a game, game knowledge is very varied. A lot of new users won’t know what frame data is, and some of them haven’t figured out many basic properties of attacks. That’s definitely an issue in game making!
• Do they know how to draw/model/art? Mostly no, but there’s two parts to this. One is that basic ability, on which the surprising part to me was that instead of using the in-engine resources, most people went instead to grab sprites online from existing games. The second part is the workflow: most have no idea of how their art needs to adapt to gameplay constraints, or how to actually integrate it such as how to make spritesheets.
• Do they know how to use computers? Alright this one sounds mean, but I didn’t put it in to dunk on people: surprisingly, some of the beginners are lacking basic computer skills, yet find out about Castagne and try to use the software. I’ve seen several problems on the discord support channel that are vey much caused earlier in the pipeline, but it shows that the software is becomine more and more welcoming.

Sidenote, I use “surprisingly” a lot in these because I haven’t been a beginner in gamedev for a long while, and my journey was different enough that I don’t have proper reference points. I learned programming and 3D modeling through basic curiosity and looking online, before I even learned English. When I started gamedev 5 years later, I already had those core skills available so it wasn’t that big of a climb, and soon after I got a short internship at a gamedev studio so I started using Unity back in 2011 or so. I still have that propensity to not be intimidated by walls of knowledge even outside of my field, so my first reaction is not “give up” but “read more”, which definitely puts me outside of most users afaik, which makes it harder to project. Maybe you already guessed who would use Castagne and the level of beginners, but I did not lol

The question then becomes, how far should Castagne go to support beginners? Each one has their own profile, so different aspects are needed, and some decisions can impair the software for other purposes. So let’s put in a guiding vision: Castagne will always prioritize the expert experience and efficiency over the beginner one and prefer teaching and rising the level to limiting or over-simplifying. This doesn’t mean excluding beginners, but there’s a lot of ways you can make something simple by making most choices for the user, or making the day-to-day workflow worse. That’s a pitfall I wanted to avoid in Castagne: Castagne is not training wheels, it aims to be a supremely strong option on the ways it focuses on.

This means that Castagne’s approach is to teach, which takes time and effort both on Castagne’s side and the user’s side. As such, this brings a fundamental limit to Castagne’s user: the user must be willing to learn. If someone just wants to quickly and casually do a fighting game, Castagne is not the software suited for that, and we shouldn’t use resources to get them. The decisions needed to support that user are going to make the software worse for its target users. Another constraint is going to be you need to know how to use a computer. If you can’t open Castagne, you’re going to be immediately lost as soon as the words “import assets” appear on the screen. This already puts some limits, but it still leaves a lot open. Who should Castagne reach out to?

I believe that Castagne should try to reach out of complete beginners, in part because it’s who it’s attracting already, and because it’s good software that is not a trap. This means that people will be able to learn Castagne and be able to keep using it, which will give us better games, and a more skilled community, so that the discussions can also raise in level. With the new vision realizing that people won’t look outside of Castagne, the realistic option is to have this handled in part by Castagne. Not fully of course, Castagne is not the place to learn about blender or sorting algorithms, but it shouldn’t leave beginners high and dry. Having this in-engine will also mold the basic beginner to someone that can already understand more and is more aligned with Castagne’s workflow. So, how can we do this?

I propose looking at it through a framework of three skills: Programming, Art, and Design. Each beginner can either have a basic level in that skill, or not have it, and measures can be taken. That’s on top of well, teaching Castagne, it’s more a sort of soft prerequisites that can be accomodated for, especially in the first tutorials. We’re going to assume that once you’re out of the beginner / advanced beginner stage, you’re able to figure stuff out on your own because you have that anchored basis, and can look up tutorials. They are pretty independant, so while that means there’s 8 beginner profiles, we only need to think about those axises independantly.

• Programming: A user that can already program would rather focus on an efficient language specification and examples. This works well with Castagne’s flow as it is easy to see how efficient it is once you read code, although some programmers are easily intimidated (there’s still many profiles).
• No Programming: Code tends to be a major mental block, and it’s likely the single most polarizing thing in the engine for beginners: those that read will say the engine is nice, those that get turned away will say it’s super obtuse. This is the core so it’s not an easy fix, which is why there’s a visual programming interface coming up. A big difference, is that this one respects the user. Many visual programming interfaces are condescending and unsuable above intermediate level. We’re not doing that here, we’re using Castagne Script’s idiosyncraties to make a real interface that I myself would also use and doesn’t have any limits compared to code, that’s how we actually respect the user’s intelligence and not trap them.
• Art: A user that knows art usually doesn’t know how to integrate it, and also won’t read godot’s docs apparently. There’s two subcategories: sprites, which are favored by beginners and have no standard workflow and low technical knowledge, and 3D which have more standard workflows but are also much more complex (and still misunderstood by most, as it’s quite a tricky part to be honest). The solution here is to have sprites handled more directly by the engine, as the 3D people will naturally have more tolerance to the technical and we can rely on that standard workflow, while also being hard enough that it’s not realist to have it in the engine. This will likely cover most cases.
• No Art: While it might seem it’s less common, there’s many users that don’t have art skills coming into Castagne. Some are programmers, some are designers or general beginners. Some want to rip sprites online and that’s their problem, I’m not going to add tutorials on how to steal assets. The existing solution in engine is to use the example characters and their animation library, which I think is a good idea, however the current implementation is lacking. The animations are too static, they are hard to visualize, and the UX of example characters is bad, as modification is prevented by default. I believe this will be solved with just a few key changes: the new animation system allows in-engine alternation of both 2D and 3D animations, and some visualisation tools will help the rest. Making the example characters more dynamic and able to be added after the start will allow experimentation, and with that I expect many more people will be getting their start with this library.
• Design: Users that already know about fighting game design tend to already have an idea in their heads. I don’t think anything needs to be directly done for them at the very early stage, what they are looking for are specific mechanics and their adjustments. This is naturally covered by the mechmods and the more granular tutorials and help me button.
• No Design: This is tricky, because there’s also no coherent terminology. Infil’s dictionary does help, but the concepts don’t always have the same names from game to game, and don’t necessarily link up the concepts. I believe there’s two parts to this: one the one hand, you need to define terminology for everyone, so that should be part of the general curriculum. On the other hand, there’s how to use that information, as people might not know how a move being positive will affect the game. This is tricky to teach, as it’s much more art than science, and a young art specifically. I believe this can be filled out enough through a very quick explanation when the concept is introduced, while more advanced used can either be relegated to a “how to design fighting games” section (low priority) or community tutorials.

Adding some branches to the onboarding tutorial specifically could help direct users, and some categories focused on different lengths and how much they are guiding you through things. This is definitely a part that will need iteration. A risk with that is having so much information that the tutorials themselves become intimidating, but at some point you gotta cut people off: these would not be able to figure out the software without them, and I would much prefer a userbase that is able to find how to do things properly to having the forum be a collection of quick hacks.

Another point to keep in mind in beginners that skip tutorials. Those that skip tutorials are handled by the natural documentation and design of Castagne, as well as the Help Me button if they don’t ignore it. No additional effort is going to be made for them: they want to discover things by themselves, so they will be on their own beyond showing them where the tutorials are on first startup. As mentioned earlier, users that don’t want to spend the effort to learn Castagne are not targetted by the software.

I think that’s a good framework to think about that, and a good general plan. Castagne onboarding, albeit flawed, has managed to bring quite a few users up to speed. It’s part of what allowed Castagne to push beyond its target audience already, so an expansion in that early net should help much more people find their first foothold in the engine. After that, the additional tutorials mentioned in the other updates should help raise the level, now that the initial funnel will properly bring people to the level needed to use it. This will ensure the userbase is more advanced and numerous, which will enable development to go further and better.

Also, I’m planning on using the Castagne characters during tutorials to make them more palatable. I guess this makes it less corpo (which is not a bad thing), but I guess I’m in the zeitgeist of the new generation of open source mascots. Just need to add an anime girl somewhere instead of my puns on francophone BD.

Do you think I missed a part of the beginner experience, or that there is a better way to handle them? Next time, I’m going to speak about communication again, but in the other direction: from users to me!

(2026-06-14) Estival Break - Docs and Tutorials

Wow, another estival update! Still got plenty of those until the end of the month.

Docs and Tutorials

Documentation is always a big subject in open-source projects, and according to feedback, Castagne’s docs is one of the best, really complete for a project at this stage, and very lacking and obtuse. What gives?

The reality is that, not everybody needs the same docs, and thus they will have very different experiences of it. People that think Castagne’s doc is great is mostly technical people: Castagne functions are all explained, and most of the internal states in CASP have documentation, meaning you don’t need to experiment to understand Castagne. On the other end, someone not as technical will be lost more easily, as the getting started part of the docs is fairly minimal and split. Furthermore, small syntax drift makes docs not always up to date. Let’s talk about how I intend on taking these challenges!

First off, it’s good to know what kind of docs are present in Castagne and what they are needed for and their specific challenges. It’s a complex environment, so this multimodality reflects that.

• First off is the function reference, which is how to use each function provided. This is what most programmers mean when they say docs, as its the actual core of them.
• Then, specific to Castagne is CASP docs. All the gameplay is written in CASP, including stuff like walking or hitstun, and all of that is contained in CASP files and therefore outside of usual doc pathways.
• Module Docs is all the other parts of modules, describing how they work, what variables are available and what they do, etc.
• Text Docs, standalone pages. There’s a few of them covering parts of the engine such as the main loop or the language specification.
• Text Tutorials, which is exactly what it says, more oriented towards technical users.
• Video Tutorials, which cover some basics as well as some of the asset workflows as they go beyond the software. These are oriented towards less technical users. These are also the most annoying to update.
• In-Engine Tutorials, which guide you step by step in the engine.
• Example Characters, which show how its done and allow illustration of the concepts.

Access to the tutorials is currently done either from the website (which easily drifts away) and from the engine (which has a janky interface). Drift from reality is a concern, with in-engine tutorials being the easiest to keep in sync since they can be tested, and video being the hardest as they can’t and remaking them is a chore. Keeping docs up to date is a huge issue in programming and takes a lot of time, so it needs to be properly supported in the dev workflow.

That’s why docs have been a concern of the new version from the start. The best way to have docs up to date, is to make it easy to keep them so. As such, here’s a few of the key ways this happens:

• Stronger Release Script: Castagne’s release flow has a few manual steps, this is about removing some of them from that whole thing. Specifically, automating the docs rebuilding and upload, as well as making the tests automatic (I currently manually test that all the in-engine tutorials are working before each release). I’ll also add fetching from CASP files to have the state docs in the docs too.
• In-Engine Tutorial Focus: Tutorials are very finnicky, small changes can one-shot non-technical beginners even though all the logic is still there. It’s also the one that needs more entry points and polish. That’s why I want to make in-engine tutorials the central point: their programmatic nature makes them much easier to test against interface drift, they are the only mandatory access point (can’t guarantee you’ll go on the website) and they can be interactive to make information stronger to retain. This nature also means they can be automatically converted to text tutorials easily, and video tutorials albeit with some caveats. Being able to put the full focus on them will allow more coherence and going further, but it loses targetting of audiences through the medium, although other additional solutions can mitigate that issue.
• Testing: Already mentioned before, but the only way to ensure such a big amount of documentation in a complex software stays up to date is automatic tests. Testing the in-engine tutorials is already one thing I mentioned twice, but another idea (stolen from rust) is automatic testing of the functions themselves through examples. Every function will now have an example code with it (if applicable) that will be tested before release. That is quite an increase in workflow, but I’m already doing that one internally.

This should already fix a lot of the issues, and allows the standalong pages to focus on parts that don’t move much, such as the language specification or engine loop. But this would only improve the content of the docs, which is just one part. The second part is access, and that is just as important for a good tool. So, here’s the way you can access the docs:

• In-Engine: The docs already are accessible there, but they are not really usable. Improving their display, as well as making them an actual system that other tools can reference will help tremendously.
• Web: Already there, but having them as a separate website that is updated automatically will make them much stronger to read through. Having them start from the engine first will also allow different presentation online.
• Tooltips: Already exists, but expanding on having the docs always visible is a big concern. Function names appear faster, and how to use a function or CASP state is meant to be always close at hand.
• Help Me! Button: If you have a keen eye, you might have noticed the “Help Me!” button at the top of the interface. This is an additional system based on the tutorials that focuses on practical docs, namely to answer quick questions such as how to do armored moves. Compared to the tutorials, this is more of a cliff notes version, with usable snippets: the system can actually put some common blocks inside of your code! This also has a link to the community with guidelines so that we don’t have to say as often to people to include details.
• Programmatically: Not a priority at the moment, but you will be able to access the Castagne docs from an API. This will make it possible to create integrations such as bots and the like.

As you can imagine, that’s a huge amount of docs to make, and they won’t come in all at once. There’s also still an issue of what should the docs cover, and while I’ll talk more about this in the beginner estival post, at some point you stop being just technical and start going into the more artistic side. Some people have asked questions such as “how to make a move feel good?” and my answer of “add forward momentum to make it feel more powerful” tends to lead to mashslop games and is thus not universal. This is just one of the issues that can rise from the mission of the official tutorials, along with coverage / speed. That’s why in a second phase, a strong focus is going to be put in community tutorials, where you can interface with those tutorials system easily, and be referenced in various ways by the official software. As such, you can now explain to people how your custom proration algorithm works and why it’s good!

There’s other concerns, such as translation of said docs (can you feel the pain already?), but they are not as critical in this stage of the project. There’s also a bit of question over LLMs, which while I don’t like them or intend to shove them in the software for no reason, are often used by people instead of searching or asking, and their use in programming is more widespread than in art. They’ve already scrapped the Castagne docs and can produce CASP code from the tests I’ve done, and the programmatic interface could help local models be aware of what’s going on and thus reduce slop questions. I’m personally not convinced of their use here since Castagne is quite simple in practice, and I think the tutorial will be enough to put users in conscious control which will work faster, but hey if they are already taking my bandwidth they might as well be useful. I’ll take this time to note that I’m refusing the use of AI to write the docs, even though it’s a common use these days, as I want the docs to be quality and accurate. I’ve also got plans in the further future to make smaller vids myself and dev interviews, a bit outside of the general tutorials to make the results more complete.

Finally, a point I’m not going to expand on this time is the example characters. That’s because there’s a lot to say about them, especially at a beginner level, and how they tie into the engine itself. I think the ideas that were tied to them were good, but the execution could be better, which some of the new systems will definitely help with. An early note I’ll do is that there’s going to be several characters, and that they will be integrated into the tutorials both as characters and as examples.

As you can see, there’s a lot to say on docs, and it’s probably more complex than you’ve expected! And I’ve not even covered everything. In truth, such systems are central to software, and Castagne being complex AND a beginner-magnet, its docs need to grow in a way to support that. What would you make tutorials on? Next time, we’ll talk about beginners.