Heyo, happy new year! This is gonna be a more serious update, more on the project's framework than actual development itself. If you've been on the Discord, you know that it's been coming for a long time, but I only now found the time to sit down and write this update. This will all go into effect from the next release onwards. I'll give you the TLDR, and then go into each point in more detail.

Also, it's Castagne's second birthday! Well, a couple months ago. We'll celebrate in time.

TLDR

• License Change to MPL 2.0 (weak copyleft). For most people, this won't change anything: you can still do commercial games for free. It's just that with the situation and environment changing, I felt it was important to ensure Castagne stays for the community. I'm also adding a CLA in order to be able to enforce these protections and be able to efficiently react to challenges like console publishing.
• New release cycle / options. At the moment, updates flow a bit at random, and take quite some time to pack, which limits frequency. I'm making a new release flow, and specifying what to wait for in each of the three branches, which should allow for more updates and less bad surprises.
• Roadmap update / Next Events. They happen all the time, but since it's been a while I have more visibility on what exactly is going to happen in the next 3 main versions. I'll also talk about some events coming up in the next months.

License Change to MPL

This is the big one, and it's always a big potential pain point in open source projects. Fortunately, we're still early in Castagne's dev cycle and the new license is even more "free software" than the previous, so I think it won't really affect your plans, and instead reinforce Castagne's future.

So, at the beginning of the project, Castagne was just Kronian Titans' engine layer. It had a lot of the design you (probably) love, but I honestly didn't know what would happen to it in the future. I just figured that, since it was getting bigger and more generic, it would probably be useful to people. Worst case scenario, nobody but me uses it, but since I needed it anyway that's no loss. So with my PhD somewhat scheduled (administrative delays amirite) soon, I released it as MIT and called it a day, as this was the same as Godot and with the possibility of altering it later.

Fast-forward two years and a bit, and now it's growing up quite nicely, if I say so myself. I'm really glad to see it approaching the originally envisioned form. I'm also really glad it's been adopted by a few developers, with more keeping an eye on it. I still don't know what I'll do after my final PhD year, but I see I enjoy and rely on Castagne, as do others, therefore I want to cement it so it stays healthy in the future. The landscape is also changing a bit around, with more predatory scraping of assets and code for instance, and I also learned more about open source and its ramifications (as it is my first FOSS project).

This is what motivated the license change. I just wanted to ensure it's more protected against bad faith actors, stays healthy in the future, while still allowing people the freedom to make commercial games. Indie dev is hard enough as is, I want Castagne to be an enabler more than a limit. Please understand that I've researched the subject for a couple months already, and consulted with several people including experts before making this decision.

Thankfully, MPL 2.0 is still pretty permissive. The two main things it changes for most users are simple: you must say that the game was made with Castagne, and if you change Castagne's files, you must redistribute them under MPL 2.0 (that is simplified ofc, please refer to the full text for the exact points). What I'm aiming for through these changes, is that some of the improvements and benefits flow back to Castagne. Knowing the engine exists and what games are made with it helps the community grow (which gets us more cool games, and better quality software), and potential bugfixes (or more rarely features) are also spread to the community (which beyond being good practice, is also fair for the software your game is built upon). I believe for most users, this change will be almost invisible.

This will also be implemented for the assets, which are currently under an unclear license. I'm still debating the exact one, but as I mentionned before, I also want the assets to be as permissive as possible.

The second change, which might be more controversial, is the addition of a CLA (contributor licensing agreement). Again refer to the full text for the exact effect, but the idea is to allow me to act as if I own the whole Castagne code. This allows me to act as a single entity on behalf of the project and thus gives me the flexibility needed to act in case of an issue, for instance console publishing.

This means that contributors must trust me, as I could take their work and do what I wanted with it. However, I think this is limited, considering their contribution is immediately available under MPL, and with how I see things going, I'm still going to be the main contributor for quite a while. Since the code is available under MPL, that also gives you a very easy exit door if I ever become mad with power in your eyes.

The only other code contributor is mrgoodtimehaver, and they have already given me their okay with this, so this change will also be effective from the next update onwards. I hope this will bring the intended effect in the future, and the flexibility will allow me to course correct. Considering the vibe and state of the community, going that much in-depth is most likely overkill, but I feel serious topics need serious handling.

New Release Cycle

Now onto a lighter subject, the release cycle, updater, and packaging. Basically, how you are getting the software.

At the current moment, it's a bit cowboy style, I just update when I feel it's good enough, and dev / main are not that different. But, this process takes time, still leaves bugs, and is becoming limited with additional contributors. It also makes update take more time, therefore, a new, more defined system will be put into place.

The first change is that we will now have 2 code branches you can choose from, when updating your Castagne, each one suiting a specific need:

• Main Branch: This one is for those that value stability more, and want something that "works out of the box". Keep in mind, we're too early to have LTS, that stability is relative. Since this is the one most people will get, we'll strive to ensure a higher level of quality through more standardized testing, more specifically ensuring tutorials work and the like. Since this will be some people's first try with the engine, some not even in the discord, it will ensure a smoother experience.
• Unstable Branch: This is the equivalent of the dev branch, where updates that at least kinda work get pushed. The aim here is to allow a mostly automatic packing and uploading of a Castagne version, so that people that are more tuned into the updates can test stuff quickly, even if it is rough. This one aims to fix the delay issue, so that publishing is a quick step instead of one hour plus.
• I've thought about including a "dev / code" branch to this, but if you're pushing code to the repo, you can pull it too.

I'm also working on the updater to allow it to install the update immediately, so that it's easy for people to stay on the latest version. Together, this should allow changes to flow quite nicely into everyone's hands.

Additional alterations are as follows:

• The Castagne Starter will be phased out little by little, as its function has been replaced by the Castagne editor. It will now only serve to launch the game or editor based on how you launch it.
• I'll add a new "Castagne Project" option to the downloads, and rename the "Castagne only" option to just "Castagne lib", that way more advanced people don't get confused, and you can get an installation without the Godot executable.
• I'll try to see how I can add some startup scripts for Godot, so that first time flow is better. Previous design tries to make you start inside of Castagne and its tutorials ASAP, but then getting to Godot is complex and trips up most users. Having two icons, one for the Castagne editor, and one for Godot should make it easier.
• As an aside, the MacOS build will be de-emphasized, as I can't really test it, don't know MacOS, and to be frank, don't really want to learn lol. If anyone in the community wants to ensure first time flow works correctly, we'll work together :)

Since this is a change to the updater that will mess everything if I do it by parts, both branches will update at the same time for the next release.

Roadmap Update / What's next ?

Finally, the more interesting part for most users, what's getting added and how. Last update was mid-August, and it's now January. So what happened in those five months? Well quite a bit, so much that in fact, I would need a good hour to list all the changes I forgot. So the actual final list is going to be in the changelog, but here is a selection (read: what comes to mind right now) of some features coming into the next version that are already implemented:

• Visual Editing: I've added a new system called specblocks, which are a more advanced system to precise data in Castagne. It allows me to put a graphical interface to a set of variables, which means that you can now visualize your jump arc when editing it and more! It's also used by the sprites and sounds now.
• Entities: The entity and targetting system have been vastly simplified and empowered in some ways. Now your file only describes one entity, the main one, and its sub-entities (projectiles, puppets, etc). These subentities are easier to communicate with and lighter on the engine. The editor now also offers a lot of support for them, but we're evolving so far past the initial requirements that it's stressing the internals a lot, so there is some jank in it, please bear with it for a while. Yup we got technical debt, but repayment is for v0.7.
• Audio: You were a lot to want it, it's finally here! In a simple way. You have music with custom loop points, and a simple implementation of sound playing. As I'll explain more below, I don't have basic assets yet for that, so its having limited support.
• Flow: Got some improvements on flow that will become more important later. The engine now theoretically supports more than one character per player, and more players (I wouldn't try either at the moment), and you can override variables for all your crazy gamemodes. For now, it won't really change what you do, except that you can now choose your map and song!
• Sprite Improvements: While not the full extent of what is coming, sprites are now easier to work with and specify. A lot of non-technical users tend to go to this, so having it easier to access is nice.
• Internal Improvements: Honestly I lost track a bit of which was in the previous version or not, but systems are better. I'm optimizing some stuff even more, the parser is showing its limits lol. Won't rework it until v0.7 though, so some jank inbetween might be there.
• Quality of life improvements: better search, several types of TODOs now have icons, good stuff. New S branch (sequential) allows easier writing of attacks, depending on how you go about it.

Here are the changes still in implementation for v0.54:

• Attack Module: This one is mostly implemented and is the last large system. The attack module is now more flexible and features, mostly thanks to the Override system, which allows altering attacks based on the situation. As an example, you can make attacks do more damage on an air-to-air counterhit in like two lines. There are additional changes, like more flexibility everywhere is CASP, conditional cancels, proration is back, etc. I'm guessing this will be to everyone's taste!
• Graphical Effects: We had a small system before for VFX, it's now improved to support sprites. This is a bit temporary before we get to v0.55, will do for now.
• New Updater: I wrote about it just above.
• Freeze and Halt phases: I'm reworking the freeze phase to be individual, since that's what actually works for hitstop with projectiles and the like. A new Halt phase will be added, and allows an entity to take ownership of the simulation of sorts, being the only one able to move, for superflashes and the like.
• Tutorials update: Systems have changed enough that I have to rewrite a lot of those, I'll try to make smaller ones. I'll see if I can update the video ones, although mine will be minimal.
• General bug fixes / improvements: I'm getting on a few bugs cases that are a bit subtle, often related to frame perfect landings. I'll be also adding some of the "easy first issues" myself since I'm seeing I can't really find the time to create a learning workflow to onboard new contributors, and they were on features people complain about when finding the engine for the first time.

That's quite a full program. The core of the update itself is almost done, but the rest will need some focused work. This will most likely break some stuff in your games depending on what you were doing, but its not that hard to fix. Release should not be too far out.

What's cool here, is that we're getting really close to finding out Castagne's true potential! Indeed, this update will have almost realized the core of Castagne, meaning you'll be able to program a lot of varied mechanics like I envisioned in the beginning. This will need to be linked to the next update, v0.55, which will add the missing elements, namely menus and graphics. While some of the more advanced features will be out of reach for a bit longer, this strong base will already make a ton of games possible, but maybe technical.

That's where the next updates of the v0.6 cycle come in. I believe we'll see some explosive feature growth for Castagne, as I'll be able to chain features and gamemodes using the framework put in place. This may also be the point where you'll be able to start using Castagne a lot more seriously!

I think it will be appropriate to make a better body of Castagne assets. I'll probably bring it back to the table later, but if you're interested and reading this, give me a ping!

I've updated the roadmap accordingly, mostly moving stuff around. As always, this can and will get reworked. Here's the recap with some random guesses for release date:

• v0.54 (Q1 2024): Core gameplay features are in. You can make your gameplay with no issues.
• v0.55 (Q2 2024? fair chance): Graphics and menus. You can play / release your game in a barebones state. Simple training and fight modes, can start making 3D fighters.
• v0.56 (Q3-Q4 2024? maybe?): Mechanics update, allowing fuller support for 2D and 3D fighters. Can play versus AI.
• v0.57: Gamemodes update. Training mode, replays, combo trials, that kind of stuff.
• v0.58: Associated genres, making the engine more suited for beat them alls or platformers.
• v0.59: Polish, bugfixes, tutorials, etc.
• v0.6: Whatever comes up in the meantime, before we're truly ready to move to the v0.7 cycle.

See you later for the Castagne Survey and Anniversary post!