(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.

(2026-06-11) Estival Break - Communication Pipeline

Hey hey! Another estival update / discussion, this time on communication itself. I’m still enjoying my vacation here but it will be good to be back at big computer (my favorite place)

Communication Pipeline

I guess this is not a question in and of itself, but more something that’s on my mind and I want to talk about it, so I guess it’s a question I ask myself lol. After all, we say in French that an engineer’s job has three parts: le savoir-faire (know-how), le faire (do), et le faire savoir (make known). While I’m pretty solid on the first two, le faire savoir has been a bit of a recurring theme, and might be more important than the others lol

At its core it’s a bit of a balancing act with many parameters: you need to be able to be found, but how much you reach out to people is a slider, which people you are targetting, and how much time you spend on doing that versus the software itself. As you can probably tell by all the previous updates, I am a yapper but very much tend to talk technical. While I can explain parts step by step well enough (I’ve been told I’m quite good at making complex knowledge accessible, such as with my line rendering article on my blog), especially if I take the time to properly write articles, I tend to have a “minimum level” and don’t value the same things as most people, so my updates can be a bit dry. I’m definitely not suited to “shiny thing” type of communications for instance lol (this has been an issue for me in computer graphics academia, but that’s a rant for another day).

There’s a big balance to be kept between the speed of development, keeping people updated on it, and promoting it, along with managing my energy level. There’s a reason why video updates have stopped: it’s a fair bit longer to write these videos and the whole uploading and promotion thingy compared to just stream of thought writing I do with these regular updates that you can fetch from RSS. Still, the promotion part is still quite some mental effort, which is why for instance these updates are not posted on twitter / bluesky / mastodon (that and not being home and I don’t wanna bother with it). It very much feels like posting into the void, except on the discord / forum as people actually react and interact with it, please keep on doing that lol

Unfortunately, this is kind of a chicken and egg problem: while other people can communicate on Castagne, they need to be aware of it first and become invested (which I’ll talk more about in a future update), which means someone’s gotta do it. It’s also tricky, considering I’m the source on most of the advances and will remain that way for a bit more (nobody can really communicate on the private software that only lives on my computer lol), and it also sets the tone of the community (which is in a really nice place I think). That’s the kind of thing that will solve itself as the software become available and more people use it, but there’s still a problem to solve in the short-term.

My answer to that is going to be, like most things, programmation. I actually enjoy writing these updates themselves (although translating is a chore), but the annoying part is all the mechanical steps in posting. I’ve been meaning to find ways to automate that as much as possible, although there’s been some issues on each platform which make it a harder deal than initially expected. I probably need to lock in and do that properly, and that includes thinking more about the workflow and modalities of updates. I’ll be honest, this format right here has been the most fun for me, I just write what’s on my mind or in the update in a longform way (thus allowing more detail into the uses compared to quick “hey look at this” stuff) and it gets pushed to people that care about it directly, while also being quite direct in its usability as I’m just writing from my text editor.

Something I do want to improve, is my video workflow. I don’t enjoy editing video, so I already made a software to do that for me, which I used for the previous updates. However, this still takes time, and thus increased pressure in what is included in these vids. Updating on what I just did feels a natural way to finish a workday, while preparing those updates in depth usually also involved drawing schemas and having to reverify a lot… I think there’s still a lot to do there, so I also need to lock in on that and spend a couple days to make it robust based on that prototype. I do need it for stuff beyond Castagne too, as video tends to be the main format these days.

The mailing list is also one I’ve been meaning to improve, as I am extremely bad at being regular (in general). The mailing list has a bit of a weight, but I need to make people more able to select what they want to hear about. Also, that’s how my parents get updates on what I’m doing (beyond hearing me complain or brag when I see them) so it would be nice to do them again. My current workflow has many moving parts that its very easy for some to slip inbetween the cracks.

There’s a reflexion to be had in general on what to communicate, when, and in what format. I try to not overthink it (I say just after 5 paragraphs on the subject) and post what comes up, so reducing that friction is going to be key for the future.

Time-wise, a progress update takes around 20 minutes to write in general, but the whole workflow tends to be 1h30 long, between losing focus (it’s at the end of the workday!) and all the manual steps. A video is even longer, clocking in at around 4 hours each week. These longer updates I’m doing now are more around 45m-1h but it’s a bit more exceptional.

Anyway this update was a bit more self-indulgent, I’m kinda pushing my thoughts onto you and you’re welcome to tell me I should think less or suggest solutions! Next time, we’re talking about another form of communication: documentation and tutorials!

(2026-06-09) Estival Break - New Direction

Another day, another update. Just kidding, I’m still in the same car as the previous update, so it’s more same day more updates. I’m writing these in advance, with maybe a tweak or two depending on feedback. This one’s another long wall of text, but at this point you expect them.

Please do tell me if you read these or if they are sent into the void lol

Today we got another question, asking more about the new direction of Castagne. Let’s try to clear this up.

How does the new direction act in practice?

So, Castagne has been in development for a long while - 2021 to be exact, we’re in fact nearing the 5th actual anniversary (wtf). A lot has happened in my life and around the software itself, and I have a vision that shifted a bit as the environment became clearer. This does affect dev in quite a few ways, but let’s indulge a bit in Castagne’s origin to understand the context and understand how this new direction will change the engine.

Castagne, at its origin, is the engine layer for Kronian Titans. KT is a passion project, the first I started after burning out on hobby game development. I used to make games for fun, but usually never finished anything. My interest had always been in the systems and architecture, so gameplay itself was less interesting to me. In that sense, I’m not really made for regular indie dev, which has been an important realization at the time. Kronian was made with a longer vision in mind, as a hobby project that would progress over a long period on the side of my main work and doesn’t make too many compromises on its vision. As such, I needed strong tools for gameplay iteration, and after looking around no engine was able to that at a satisfactory level, so I started my own engine layer. The level needed for the tools was too high and expensive to be used for just one project, so I ensured it could be used for several other game genras. After that, since I was scheduled to restart working (I started Kronian during a forced administrative break at work), I figured I could separate that layer and make it available for people online, and who knows it might be helpful for some. This is how Castagne started and released towards the end of 2021.

You can make sense of a lot of Castagne’s decisions using that framework: the focus on experts is because its target user is me. It’s using Godot because it’s my favorite game engine and is open source, so it’s a stable base. It delegates a lot to Godot because I don’t want to redo work for nothing. It’s focused on both flexibility and efficiency because that’s what I value and need for Kronian, and pays for that in design cost and engine complexity, which plays to my strengths. The fact it’s accessible to beginners is basically a fluke in the design: the focus on efficiency means that you have less stuff to keep in mind and get up to speed faster, which helps beginners. I’ve also kept the learning path in mind, because I think that if the software is aimed at experts, there should be a way to become an expert.

In those five years, Castagne has grown tremendously. There’s around 500 downloads every month, and it’s used the world over (not that much in France interestingly enough, I’m too international I guess lol). It’s also software that has had real impact: it’s been an entry gate for many people into the world of programming and game development. I really enjoyed reading the messages telling me it’s been used in a US university to teach programming, how it helped people approach programming from zero, or how it finally gives them a path to their dream. Each improvement in onboarding resulted directly in new profiles coming in, sometimes to the detriment of my mental (not your fault).

Now after five years, I both have a stronger vision of how fighting games are made, and a different life situation. Back then, indie gamedev was just a hobby, now it’s shaping up to be my job for the forseeable future. I’ve been pretty outspoken about how I think that to be stable in the future, Castagne needs to be strong enough to have a pro environment around it, and having it be more accessible is something that would help that goal. Another factor is how, in the end, even though I tried to avoid doing a full engine, I am very much poised to make a full engine as my next big project is a renderer based on my PhD work, so there’s less incentive to keep things super separate. Funny how that works.

Both of these by themselves do not justify a direction change, the current one works well enough and its issues can be fixed with a couple targetted changes. The last factor was seeing how people, for many reasons, are only using 10-15% of what Castagne actually can do, because they don’t see how it integrates inside of a larger vision. That’s not particularity a problem of Castagne’s userbase itself, nor it is Castagne’s issue, it’s something more global: a lot of game development is done in a shortsighted manner, with few resources and visions going further. You can see it go further in bigger studios like AAA ones, but even then I always felt something was lacking.

Usually, I don’t really like imposing a vision, so even though Castagne’s structure is opinionated, it’s justified in many ways and has a lot of room for flexibility. This is not going to change. However, most people don’t just want the tools, they also want to be guided. Realizing that being heavy handed is not rude, but in fact something people want, has been the main trigger of this direction change.

My workflow is not optimal, but I do think it is quite good, especially with regards to Castagne. Therefore here lies the difference: the old Castagne gave you the tools to make your own workflow, the new Castagne says that if you don’t have a strong opinion, you’re using my workflow now. This might sound small, but since I was aiming for quality and usability in many situations, this puts a lot of restrictions on what I can do, while not being able to be communicated to uninitiated users. Under this, I can make much more assumptions about projects, thus enabling many more improvements. Breaking those assumptions requires a higher level of skill than before, but in practice this has already been a high level most users don’t clear, and I still have that core flexibility in mind so it’s not like that ability is gone.

This affects many parts of the project, but one that exemplifies that really well is the sprite workflow. Compared to 3D, sprites are much simpler to make, but also don’t have a standard pipeline (the 3D pipeline still confuses many people, but this one’s beside the point). Therefore, it tends to be the preferred method of many beginners, some that just rip sprites from elsewhere. Castagne handled sprites by relying on Godot’s system: spritesheets. However, this had two issues for beginners: one is that it requires going into Godot and this confuses people a lot, and the other is that spritesheets are not part of common knowledge anymore and some have trouble figuring them out. This leads to people wondering why it’s not something that seems easier for them, such as individual PNGs (very good, potential for optimal), or GIFs (never suggest that again). The back and forth, and needing to tell Castagne about it, and other oddities such as animations and palettes makes this a bit clunky to use at times.

The real answer of how to use the system is one that, as far as I’ve seen, nobody else but me uses: an actual asset pipeline. I never interact directly with the sprite system, it’s done automatically for me. I put my PNGs in, and in a single command all the sprites are now available in Castagne ready to be used. This is the way it’s meant to be used: sprites come from many different places which Castagne can’t know, so you plug both ends yourself. You were supposed to figure out what workflow works for you, but writing this I’m thinking that many didn’t realize this even was an option.

Under the new direction, Castagne’s reach goes further, further enough that you don’t need an additional step in the pipeline for basic use, you can add your sprites individually from within Castagne. This doesn’t stop the previous way, using an asset pipeline is still the optimal way as allows maximum flexibility and adaptation to your workflow. It’s just that now, being non-optimal is not as penalized as before, Castagne now has a default workflow that does cover the case of 90% of users well enough that it doesn’t become a big priority to fix.

This applies to other parts such as the rendering pipeline: it’s always been optimal to make your own that works for the project, and if you don’t follow specific steps I can’t make that work for you, and while I can do that within Castagne pretty naturally, changing how you do assets would be an overreach. The new direction realizes that for most users, this is not seen as going over its scope, but as Castagne being the center of their project, it’s much more justifiable.

I believe all in all, this is a more realistic vision of how people actually use Castagne and massively improves the case of 90% of user while not really affecting that 10%. This does represent a big workload increase (meaning the software will take more time to come out), but it also ensures more Castagne users are ready to use the other parts of my workflow for future projects, and makes the experience more standard.

In a way, this is accepting that for many people Castagne is not just a tool you put inside of your existing project and workflow, but their entry point into the world of game development or programming (or even actual computer use, as I’ve seen, or fighting games themselves). This adds an educative role to Castagne, on top of being a quality tool that is the best at what it does in the ways that matter to me.

Did that make it clearer? Do you believe I’m overthinking things, or overreaching? Don’t hesitate to continue the discussion on the forum! Next estival update is on the communication flow !