Published : January 12, 2024
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.
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.
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:
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:
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.
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:
Here are the changes still in implementation for v0.54:
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:
See you later for the Castagne Survey and Anniversary post!