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

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