Published : February 04, 2023
Hello Castagne community! This news series aims to provide context on what happened around Castagne in a short-ish format. Hopefully every month or so? Don't hesitate to suggest what you think should be in it!
Since it's the first one, I'll be covering the last 2 months of Castagne and explain the format a bit!
Here is the TLDR, a quick overview of what's been going on if you're pressed for time.
This sections sums up what happened for Castagne's development recently, in a more detail.
These last two months covered a lot of deeper changes to the engine, as well as changes in presentation. This section is going to be quite long.
Most visibly, we got a new site (you're on it!) with a lot of neat parts! Compared to the previous single page website with some link on it to access the docs, we went a long way. I think the project is a lot more accessible now! Here are some of the features:
On top of that, the main part of v0.53 is the memory system rework. Before that, I left access to the internal dict to modules, which works, but won't be sustainable in the longer run since it's a bit tricky, and will cause problems when we get to v0.7. Now that the engine is more in place, we are able to enshrine the relationships more through new interfaces:
StateHandle. It was a bit tricky to ensure all the systems work well with it, but it will make the subsequent versions easier. See the changelog when the version will be out for all details, considering it's a lot of technical points.
In general, the module interface was also propped up a bit, in time for the big v0.6 marathon where we will iterate on all the modules themselves. One addition was the separation of
Base.casp into several files, which can be added dynamically by modules. This is very good for flexibility, but I'll have to either surgically change the files, or rebuild them. I think the second option is better considering the modules are changing, but that also means we're gonna wait for v0.54 for the next stable version.
The Castagne Script language was updated! This added a few things like constants and a new entity management system. The bases are still there as expected, but I've added some additional safeties. In any case, the language will stabilize more in v0.7. Here are the main changes:
internal(internal module values). This ensures better optimization and less errors.
Variables-X, with X as your sub-block name (can be anything you want). This helps to categorize variables more easily.
Main, which is your main entity. The syntax is as follows, with E as your entity name:
E--StateName: For any generic states
Variables--StateName-X(with X as your sub-block name), for Variables blocks.
Init--Efor your init blocks. Which brings me to...
Init--Ewith E as your entity's name. The
CreateEntityfunction will now only take the entity name itself, and load the correct init script and variables for you.
One thing this allowed was an update to the editor UX! I wanted to try some things ASAP as we need to experiment often and find some of the most useful points, before v0.9's big editor UX rework. Here are the main highlights:
Finally, the Flow Module is on the way! This is the one that handles spawning the players and characters. It's almost done, and it's already pretty flexible as you can spawn as many players as you want, with as many entities each, and override values in each of them! It's also asymmetrical if needed, and you can alter a lot through the new BattleInitData. To make this easier, I added an additional module,
FlowFighting, which is focused on making fighting games easily.
The user interface for the module is still in progress, as you have two: the advanced one, and the custom one that may be changed by the specific flow module. It's the later one that is well in place, with the advanced one requiring code to be done.
Something interesting is that it was the first module I wrote a public design proposal for, which was neat. I think I'll continue for the others, so please give your feedback on them!
This section covers what are the subjects coming up, so you can come and give your ideas!
The main subject is finishing up Castagne v0.53. The flow module is pretty much done, with only some interface concerns for advanced flow. Therefore, the only thing remaining is the Input module.
You may find the proposal in the documentation. It's a bit less complete than the flow proposal, but I think it gets the idea across. I would appreciate if you can take a look!
Overall, considering my current burn rate, I think the version will release in February, although considering travel and potential holidays, it could be delayed to March. The documentation to make might push it towards the later though.
The other subject, in a more long term approach, is opening up the project to contributions. At the moment, the project is mostly centralized on me, which I think is optimal for the current phase as the engine is stabilizing, and thus the cost of coordinating with others might not be currently worth it. However, to prepare that move, I am opening up the decision process a bit, as for now its just "I think of something -> I implement it on my own -> released", which isn't the best to catch potential mistakes. That's one of the reasons I started the feature proposals, and I think there can be other parts we may add slowly.
Linked to that, is branding and licensing. The engine is getting a bit of traction, and according to the surveys the next few versions are going to bring a fair amount of users in, therefore cleaning up the message will be important. I think it will be good to push the Castagne characters more, but I won't overcharge this newsletter with idle thoughts, albeit I'll mention that I have started to make an additional Castagne character. This brings me to licensing, since at the moment code and assets are under the same license, which might not be the best. I'm thinking of moving the assets to a second repo with a CC license, probably CC-By "The Castagne Project", as the aim is to still keep it open as much as possible. If you have experience with that, I'll be glad to hear it!
Here is what's happening in the community these days. Don't hesitate to ping me to keep me in the loop!
Considering this is the first news article, I don't want to put too much pressure on projects that might still be young and didn't ask around a lot, therefore I'm including mostly my own this time (as I have the excuse of working on Castagne for the slow progress lol). If you are working on a Castagne project, please let me know!
The site also got some profiling at the very end of December, so I can give you a bit of stats for Castagne!
|Times Castagne Opened||184|
|Main Page Accessed||347|
|Downloads Page Accessed||113|
|Learn Page Accessed||84|
|Individual Games Page Accessed||75|
|Community Page Accessed||27|
|Getting Started Guide opened||77|
|Roamap page accessed||37|
|Docs Pages Read||321|
|Docs-Dev Pages Read||153|
I think having a small "article" of sorts every news should be neat! Don't hesitate to suggest subjects, or maybe even a guest article!
So this time, the big innovation you can see is going to be the new Navigation Panel! With the engine complexity going up, effective usage was going to be harder, so I wanted a robust way to handle the engine! In today's feature, we're gonna have a more in-depth look at it and its design.
There's a lot to unpack, so before that I think it's wise to go back to what it's supposed to do and what it looked like. The navigation's panel role is to select the correct state in the current file's list of states. Easy right?
The issue is that, there's a LOT of states over several files. Even with the addition of tags to group states together, it was still a lot to go through.
On top of that, a lot of the flexibility of Castagne comes from the fact that you can program a lot of behavior through its scripts, which also means I wrote a big
Base.casp with default behavior that you can overwrite. However, the issue here is that if you want to know what to overwrite, you kinda have to read the whole file, which is less than ideal.
This is quite a problem for the UX here, as it is one of the most common parts the user will have to use. This is also quite a contrast to the other clearly documented parts of the engines, as this one is technically in user-space, and thus was left to the user.
This stumbling block is also getting worse: as the engine grows, the complexity does too, and in particular the
Base.casp got separated into many (7 or more!) files, which is going to make it even more difficult! This requires a rework, and fast.
So there's a fair problem: how to make selecting states efficient? You need to be able to find them quickly and visually. But that's not the only one problem here.
The deeper issue at play, is that users don't have intrinsic knowledge of Castagne when starting out, and thus need to be guided to their answers. I could write guide upon guide for each feature, but that'll still leave blind spots and might be outdated, while being intimidating and with another degree of separation. This makes it clear: the interface itself needs to teach users.
So of course, that's easy to say, but harder to put into practice. What I think is a good way here, is to allow users to discover the states they might need and to allow them to understand what they do. I think I achieved this in some capacity, but there's very probable improvements to be made.
The first change I made was to have each state get its own lil' panel to call home. It's not much, but it helps each one stand out, and we can add more stuff to it over time, as we'll see soon.
The first improvement I made, was to replace the tag system with categories. It's still pretty much the same thing, but with nesting, and the ability to collapse them, which makes navigation easier. On top of that, some categories are made automatically.
Sometimes however, states call on other states, sometimes from other files. To ensure they could be found more easily, I added a toggle to show states from the previous files, as well as to show helper scripts next to the state that calls them! This allows you to skip the step to find them, although you could somewhat do that earlier through the CalledStates button. We're starting to get a bit crowded however, yeah?
This means we need to get some filtering in! To do that, I added State Flags: little icons that can either be added and inherited manually (like the Grounded or Airborne icons), or added automatically by the parser (like the Attack family). The default flags cover a few niches:
Each of those icons is visible with a clear color code, which helps you find states at a glance. On top of that, you can filter them, by showing only the states that have one of these flags! I think we got our selection efficiency question covered, so lets get to the others.
At the moment, you still need to get inside the state to get what it does. This is what this next change aims to fix: State Documentation!
All comments that start with
## get added to the state's documentation. This is then shown on the window below, as well as a tooltip. Additionally, the first line is shown next to the state when selecting it, and the
TODO keyword is detected and raises a State Flag.
These help us understand, but we also need to discover the abilities of the engine. We already have some of that through the called states and helpers, but since most interaction is going to be through overridable states, they have a specific behavior added.
Any state may be marked as overridable, along with a comment. This comment is then shown together with the state when selecting it, as well as raising a state flag. This flag may then also be filtered for, but I've also added a toggle to show all the overridable states at once for convenience.
This helps quite a bit! To help keep track of that, the overriding states have their own state flags, and it is not possible anymore to create one by accident through the "New State" button, as you can now only make them by selecting it and then clicking on "Override State".
All in all, I think this will allow for more organic discovery of the engine, which will help users mature. I don't think it will remove the need for guides or anything, but it quite complementary to them. I hope you'll enjoy using it to make your games!
Overall, the project is in good health! Castagne v0.53 is quite big -- it would have been the equivalent of a full version and more earlier in the cycle. It is understandable, after all v0.6 has to go over all the modules, and this update is about setting the stage!
We'll see a lot of evolution this year! I think the project is starting to mature, and I hope you'll be there when that happens!