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