KatFS Alpha Devlog #1 (July 2024)


Hello everyone! Starting with this post, I want to experiment with monthly update devlogs on the KatFS project. The reason for it is two-fold: First, I want to keep whoever has been following the project better updated on its status and development, without having to rely on loose Twitter posts. When the demo version was actively developed, there was always something new to write about, but as the game's foundation consolidated and the project transitioned to an alpha stage, less and less of these big interesting topics have came up, leading to devlogs becoming very infrequent. Therefore, it might be the case of rounding up the small little things and writing more informative blog posts, to keep the metaphorical blood pumping. 

The other reason is one of motivation - sometimes it's good to get your head down and work, but it gets lonely if you're not communicating about it for a long time. My intention with this new schedule is to bring some much needed rigidity as the project enters the great valley of alpha development. If the prototype was an era of being overwhelmed at all the tasks that needed doing, the alpha is about looking for tasks in a dark abyss. So the plan goes as follows - every month I'll start a draft for the monthly blog post, and at least once a week I'll bring it up to date. Then, at the end of the month, it will get revised and published! This gives every week some closure, and a big moment for every month too. 

(And also it's way easier to write in weekly chunks while the mind is still fresh than doing it all at once at the end of the month and having to recall notes from several weeks prior!)

SORTING SOME SPRITES OUT

A very early issue that came up in the project was how to create the impression of a 3D environment using only 2D assets, given the game's top-down view. This is by no means a novel issue, any game where objects can move in front of other objects has had to deal with it. See below, Kalia appears behind the tree but in front of the ground elevation.

By default, Unity sorts sprites based on their Z position, meaning those closer to the camera appear over those further out. However, in KatFS everything resides in the same Z plane, meaning there's no sorting at all happening and chaos ensues as everything renders in a random order. Here's the same scene left at the whims of the renderer without any sorting: the tree happened to be rendered correctly over Kalia, but so did the ground elevation. You can also see the roots of the larger tree creep up in front of the central one.

Unity also allows you to manually sort sprites by layers and a numerical order, and if you look up older tutorials on this issue, they will likely point out the same solution: create a script that sets your sort order to a value based on its Y position! Since objects that are at higher positions should appear behind those that are lower, we reverse the orders (higher Y = lower sort order). While it works, it also presented some issues:

  • Every sprite or sprite group that needed to be sorted had to have this script attached
  • Movement and positioning are more granular than integers, so the translation from Y to sort order required a magnitude shift to account for at least a decimal
  • Related to the previous, since sort order is a signed short, it caps out at around 32k (positive and negative), which meant a scene couldn't stretch further than 3200 units in either Y direction or it would break beyond that
  • Keeps sort order from being usable for other purposes
  • Doesn't seem very well-optimized, but that could be just my coder brain talking
Despite all these downsides, I've kept this system throughout the entirety of the project's prototype phase. But now that alpha development has started, and with it a refactoring and rethinking of old, ineffective methods. See, for the alpha I intend to start using tilemaps for all parts of the level structure (ground, pits, walls and other "structured" elements such as rivers) since they're a lot easier to build with. But there was a problem - tilemaps get assigned one sort order value for the whole thing, but the individual pieces can have varying Y positions. I couldn't use sort order for Y-sorting. So I had to look up solutions. And I found out a beautiful solution that made me facepalm at not having discovered it earlier - like as early as when this issue first came up:

Remember how sprites get sorted by their Z-position. Yeah, turns out that you've been able to customize that axis for a while now. If you have a top-down game, you can have your sprites sorted by their Y-position automatically. Heck, if you have an isometric game you could even set up a wacky tilted axis and have transparency sorting deal with everything for you! Transparency sorting, where were you when I started this project?

Now this didn't come for free. A lot of tech debt has been accrued due to the previous method, meaning it wasn't as simple as just flicking a switch and tearing out all that sprite sorting bloat. A lot of sprites have weird pivot points that don't match their intended geometry (I had developed a different solution for pivots), all sprite renderers were set to sort based on center since it's the out-of-the-box default and the hundreds of static structural objects in the demo levels have had their sort order set at the editor level via sorting script (transparency sort requires all sprites to be on the same layer and order). 

While I could spend some time wiping out that debt, there are several other changes coming with the alpha that have made me decide it was best to default on it and start over with new and improved assets and methods. That was always the plan anyway, as I never intended for the demo scenes to be directly carried over to the main game. And it's not like I'd be starting from scratch - a lot of assets can still be utilized, and the old ones can be used as references for the new ones.

A TOUCH OF GREEN (AND SOME OTHER COLORS)

With the game opening to a forest setting, it felt appropriate to work on some nature assets. And what better reference than local Brazilian flora? It's a great way to introduce some variety to the game's wilderness settings while also sneaking in some representation. Some of these species are even at risk of extinction unfortunately, and while a digital sprite isn't much, at least it's a way to preserve their image and bring attention to what we ought to protect. (And there's a bit more on that in the next section)

However I couldn't pass on drawing some fruit-bearing plants in all of their glory. These will work nicely with a feature I've planned that will allow Kalia to "harvest" health pickups from specific plants... By giving them a gentle knock so that their fruit drops, that is!


Beautiful things. But you may think, isn't it a bit inappropriate to feature such notable plants (some of which risk extinction) in a game about using fire to deal with every problem? I would never hear the end of the "of course a Brazilian would make a game where you can burn the rainforest" jokes. Well, that's what the next section is about.

WITH GREAT FIRES COME GREAT... RESPONSIBILITIES?

While Kalia's earliest concepts had her act like a pyromaniac, her character eventually matured into a "wildfire druid" archetype, of a demon that has not only learned how to live in harmony with nature, but has taken the responsibility of protecting it, with fire magic being her main tool. A sort of "turning their worst weapon against them" kinda deal.

KatFS has had a mechanic to represent this aspect of Kalia's character ever since its earliest drafts - a "nature energy" meter that would fill up whenever Kalia was surrounded by natural elements, giving her benefits such as passive healing, boosted magic regeneration and damage reduction. It was present in this early screenshot concept, and is there in the pre-alpha demo (even if it never gets explained in-game)!



The catch? Burning down, destroying or otherwise scaring away plants and animals ceases them from boosting your nature energy, meaning the player misses out on these buffs if they're careless in the game's nature settings. It's quite a potent carrot to dangle in front of the player, but after having spent so much attention in the game's future depiction of flora, it feels like it also needs a stick - something that will actively punish players that burn down forests for the heck of it. >:]

I've discussed it with some Brazilian dev friends, and an idea was formed. Kalia can still gain nature energy like she always did, however burnt down or destroyed plants not only stop giving out nature energy, they'll drain it instead. This will allow the nature meter to go into negative levels, which will be indicated by the meter turning red, bestowing Kalia with the opposite effects: she will take extra damage from all damage sources, and her magic regeneration will be slowed down, completely stopping at maximum effect. If you burn down a whole forest, there will be nothing but misery in it.

But that's not enough. If Kalia truly goes rogue and starts destroying huge amounts of nature at once, the same spirits of the woods that have blessed her with protection will apply the ultimate punishment - the player will find themselves chased by a fast, strong and unbeatable unique enemy, sent from the depths of the woods to put Kalia in her place and send you back to the last checkpoint. Better be more careful next time!

Get Kalia and The Fire Staff Pre-Alpha

Download NowName your own price

Leave a comment

Log in with itch.io to leave a comment.