(2026-06-27) Estival Break - Metrics and Feedback

We love walls of text here! Compared to the previous ones, this one is written after my vacation, and just after torturing myself by reading research papers for two hours. I’ll decompress by writing a bit about Castagne and one of the subsystems of the editor to allow continuous improvement of the engine!

Metrics and Feedback

That’s right, I’m making spyware now. I’m going to gather every keystroke and network packet on your computer to sell it back to LLMs. Just need to find a way to add blockchain in there and raise a gorillion dollars in venture capital. Of course it’s a joke (although I do remember someone asking in the Castagne discord if it was a virus lol, as if I was gonna say “oh yeah dude you got me”), but after talking about communication from me to you and how to handle beginners, this update’s subject is about the communication from you to me!

A big part in improving software is feedback. I love getting multi-page google docs telling me how the software can improve (thanks to those that send them to me!), bringing in new ideas and refining existing ones. What you do with said feedback is another question, but to do that you need to actually have some, which is fairly rare in practice. So, how do we currently get feedback from users? (not counting bugs and the like, which while these are feedback it’s more of a technical kind)

• One way is the spontaneous feedback: someone having an idea, or trying out the engine, and giving their opinion and experience. Happens fairly rarely, it’s usually either after the first couple hours or a month or two of use. It’s a snapshot in time, fairly rare but gives some qualitative insights.
• Another way is the surveys, which I did twice now. That’s where I get most of my data, as the questions help people formulate thoughts and I can get answers from people already using the engine daily or following closely. They represent a fair bit of effort to push through and happen infrequently.
• Quick informal feedback when I announce something or ask a simple question in an update, usually helps correct shots before they go live. The number of interactions on my posts on social media and Discord also give a quick view into how liked something is.
• Indirect feedback by observing what people have trouble with and if patterns emerge. This is a very honest form of feedback, but also very imprecise and disorganized.
• Website stats. I’ve got no cookies or tracking on the website, but I can gather how many times a page is accessed. Mostly relevant is the number of downloads, and the number of checks for updates, which give me a quick idea on the pulse of the community.

As you can see, getting feedback is not an easy task. There’s a lot of filters, and it requires a constant pulse on the community. There’s also a few MAJOR flaws in these methods:

• Feedback is infrequent, and has no structure over time. It’s hard to see the evolution of a question.
• Feedback is filtered through the lens of the questions I ask, which will color what people talk about and their answers. They also answer from memory and thus can be somewhat inaccurate.
• And as a major point: no information on the users that fall through. Giving feedback requires going through downloading the engine, trying it out, joining the discord, and giving their opinion to me. Understandable, very few people will go through that whole process, and it might not even cross their mind.

A lot of this can be traced back to not having an actual plan on this lol, which is honestly very okay. The main aim of the software is to be functional first and foremost. Still, having more data, both objective and subjective, in a more structured way, and at higher frequency would be great, and allow finding out a lot of hidden pain points and paper cuts of the software, or seeing how tutorials help people, etc. An integrated system will also help understand where the silent users or the ones that drop out early go. From what I remember of the stats, there’s like 10-15 new users on the Discord each month (vibes only) while the software is downloaded like 500 times a month (varies but it’s around that part).

Therefore, with that in mind, I want to add software usage metrics inside of Castagne. Stuff like seeing which help rubrics are most used, heatmaps of the interface, what tutorials and genres are used… All of that should give a stronger view into the actual use of the software and its potential improvements, and thus give a third layer after me dogfooding the engine and invested users giving their opinion. However, I don’t want this to be predatory, as it goes against my whole worldview. Data is not going to be shared automatically: this is purely opt-in and respects the user.

This does limit the amount of users that get caught in it, but I hope the more respectful approach will lead to people being more willing. The actual mechanism of sharing leans into this through the upcoming Pulse Survey: as opposed to doing one survey every whenever that takes a long time to answer, a small survey is kept and updated in the engine and prompted for every X weeks. The idea is that the survey takes very little time to answer but also allows space for open ended questions. Answering the form also optionally shares your metrics, putting you in control and allowing both quantitative and qualitative data. Questions are cycled in or out over time depending on what I want to know.

One of the aims here is transparency and privacy: I don’t want to get too much information, the idea is not to be able to track actual games through it. Beyond the fact that some are under NDA, this would be disrespectful and I would not like that to be done to me. I also want to avoid a lot of that personal data management by anonymizing it, I just want to know some details on how the engine is used and can be made better, not see what anyone specifically is doing. Exact details on what metrics to gather in a respectful way and how much information can be had on a user will have to be determined and discussed. One major aspect is going to decide if a user should be able to be tracked from one submission to the next to see their evolution: very interesting data, but might go a bit too far even if anonymous.

Under this system, that means that metrics are going to be gathered in a few key ways:

• First off, basic website statistics to get the number of downloads or daily users. This is not personal data, it’s a classic phone call home you can already disable and is gathered through basic server administration. Some little changes on the software itself such as only checking for updates once a day are going to allow this first layer to get an idea of base traffic and usage.
• After the first few moments of use, a special early prompt allows early onboarding feedback and asks for automatically sending metrics. This is a first check to catch a lot of casual users who might not use the forms and/or drop early. Finding a balance of not making this too obnoxious and not happen too early will allow for a good source of information and quick catches of people who might drop out.
• Then you have the Pulse Survey coming into action, for invested users to keep giving feedback quickly and regularly. This is the community step: people who answer are likely to be regular users of the engine, even if not always talking in the community. This is the core of the system: how to make the software better for its main users.
• Finally, some extra tracking of the indirect help requests. Having an actual strategy there can get data outside of the normal channels by catching what people are actually struggling with. One of these is the “Help Me!” button in Castagne itself, which is going to be a recurring theme.
• This doesn’t preclude the previous forms: big survey from time to time, quick informal questions, people sending feedback spontaneously… The whole system just helps put that top of mind and engages more users into that loop.

While just like the tutorials this is very much not a core system for the engine, it’s something I want to implement early to get the best insights and integration with the rest of the engine. Bugs also get caught earlier, and considering how it affects early users, this is important.

What do you think? Does this seem like a proper strategy? What data would you not want to share specifically? Next time we’re talking about the Community itself!

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