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 FROM TIME TO TIME? 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!

Headlines

Here is the TLDR, a quick overview of what's been going on if you're pressed for time.

• Castagne v0.53 is on track, probable release in February / early March.
• There's been a lot of internal changes to make for a better base.
• Quite a few UX improvements, both editor (navigation, custom editors, in-engine tutorials) and on the language itself (constants, entity management, targeting).
• New website! With STATS and helpful pages!
• The project is working on opening up decisions / contributions a bit, as well as improving branding.

Development News

This sections sums up what happened for Castagne's development recently, in 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:

• Presentation: The website now uses the logo as well as a more Castagne-like color scheme. I've made a new layout that is responsive, and organized the pages for easier access.
• Landing Page: There's now a new landing page to show off some of Castagne's features, as well as games using it. It feels a bit "corporate / start-upish" to me with all the generic icons, but we'll replace them with cooler Castagne stuff later on.
• Downloads and Roadmap: The downloads page is now clearer, and answers the main question of Should I start now ?. There's an additional roadmaps page that details the future of the engine.
• Learning: A new learning page has been made that gives links to the three main tutorial sources (in-engine, text guides, videos). I've started a section by profile to help sharpen up further.
• Docs: The documentation now have better formatting and navigation! And in addition to that, the dev branch docs are also available! Should make navigation a lot easier, but I haven't automated the module documentation step yet.
• Games and Community: There's a new community page to help people find the relevant links and contribute, and a games page to list the games using Castagne. These are still nascent at the moment, but I think that's appropriate considering the engine is still young. I've also added articles to get some news out more often!
• Stats: Finally, I've added spying tracking to the website, a simple page counter (doesn't even track ip or anything, just the amount of requests). This will help us understand which parts are most useful to users, as well as get some info on engine usage. Indeed, as the engine checks for updates by default, we can count the number of times this happened to get an estimation of daily users. Stats are given below!

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: ConfigData, Memory, and 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:

• You now have to specify the variable's type between var (regular), def (constants), or internal (internal module values). This ensures better optimization and less errors.
• Variables can now also define type. This isn't strictly enforced at the moment, and you'll be able to do more with it later (like limits), but it has some uses now as well in the custom editors (more on that later).
• You can now declare several variables block per entity. The naming must be Variables or Variables-X, with X as your sub-block name (can be anything you want). This helps to categorize variables more easily.
• The concept of entities is now more enshrined in code, through the state names. If none are specified, this default to 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 or Variables--StateName-X (with X as your sub-block name), for Variables blocks.
  • Init--E for your init blocks. Which brings me to...
• New Init system to go with the entities. Now instead of using any state script as an Init script, they must now be flagged as such by name by following the syntax Init--E with E as your entity's name. The CreateEntity function will now only take the entity name itself, and load the correct init script and variables for you.
• New entity targeting system. The previous one was very flexible, but also very complex, and if I, the person who wrote it, is confused, then I can't expect people to use it in a simple way lol. The new one just takes a Target entity in mind, and has only some clearly flagged functions affecting it. This should make reading simpler, but might require rewriting some aspects.

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:

• Navigation Panel: It got a MASSIVE upgrade! It's now easier than even to find the states you want. See at the end of these news for more detail, as it is this month's feature!
• Casp Docs: You can now document your state scripts! This is shown in the editor when selecting, and you can specify some parts too. You can flag states, especially for overridable ones! All the new base casp files make extensive use of this feature.
• Helpers and Warnings: To help you create clean code with less errors, there are now code warnings, and a new system of Base States and Helpers! To ensure your code still executes the important parts while not limiting flexibility, you're now notified to execute another base state before so that you don't create a script that doesn't handle being hit for instance.
• Custom Editors: Now that is going to be a nice QoL increase for non programmers especially: any variable marked as a constant can now be edited visually. There is a new "Custom Editor" button which will display the constants in a list. This works for any state, including variables, and you can override constants from earlier states. A new option has also been added to restrict edition to only these editors, if you're working in a team with non-programmers and want the additional safety.
• Genre Selection and other special config windows: The config editor got an upgrade to allow some parameters to be edited in a different way. This will be useful for plenty, but the big one now is the Genre Selector, which allows you to change modules and some basic config in a simple way.
• Misc: The state actions are now easier to use, since you can now rename or delete a state without first loading it. There is a new "New Entity" button with templates. You can now display several file's worth of states in the same panel.
• First Time Flow: The First Time Flow has been separated into the FTFlow (project initialization) and FTLaunch (user launches Castagne for the first time). FTFlow will display the genre selector (and others later), while FTLaunch allows you to launch tutorials (and later on, theme and interface config).
• In-Engine Tutorials: Last but certainly not least, we got some tutorials INSIDE THE ACTUAL ENGINE. This is going to be INCREDIBLE to help people start out, and they are easy to make! For the moment I'm making small tutorials for each feature to get a feel for it, but will improve it when we near v0.6's completion.

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!

What's next?

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!

Community News

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!

• Kronian Titans is making progress with models, especially pilots.
• Molten Winds has led to the release of an article on its render pipeline, while a devlog is in progress.

The site also got some profiling at the very end of December, so I can give you a bit of stats for Castagne!

Stat	Value
Downloads	53
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
Articles Read	32
Docs Pages Read	321
Docs-Dev Pages Read	153

Feature: Navigation Panel

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:

• The Attack family of flags allows you to find specific attacks quickly. It can even detect properties like lows and overheads!
• The Airborne and Grounded icons are inherited by their state, and help you zero in a bit faster.
• The Override and Overriden icon are going to be pretty useful in the next part.
• And finally, the Error, Warning, and TODO icons help you with edition!

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!

See you next one!

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!