KatFS Alpha Devlog #4 (October 2024)

Hello all! This is the fourth alpha devlog for KatFS.

SOCIAL MEDIA WOES

In the last devlog, I mentioned the Twitter blockade in Brazil and how I've been moving my operations to BlueSky. Since then, Twitter has been reinstated in my country and I've been able to post again... Only for the site to then announce highly questionable AI and block feature policies which has sunk goodwill in the platform to an all-time low. And personally, browsing that site does not spark joy anymore. Yeah I love the community I've gathered there, and all the cool projects I follow, but I've had to wade through so much garbage to maybe see what they're up to.

So uuh. Follow me on BlueSky still: https://bsky.app/profile/kaliagame.bsky.social

It's where all the cool peeps are, and if you're a cool peep you should be there! Plug done, onto the actual game stuff...

CAVE STORY

Originally, the cave chapter was supposed to be an extension of the prologue, with Kalia tracking down the source of the zombies into the cave and eventually falling down to a deeper layer where she gets trapped in the underground world. Narratively, it is an essential set-piece as it marks the proper beginning of Kalia's journey, but mechanically... It felt like more of the same from the previous forest area. The player would still be fighting zombies with only Kalia's quarterstaff, with the only difference being larger combat encounters and no nature buffs to keep your health up.

Pacing is important in any game, but even more in a narrative-based one. The best games are the ones that change things up often enough to not bore the player with too much of the same, but also not so often that it feels that nothing matters. We've all played that game that just kept throwing curveballs at the right times and had your interest secured from beginning to end, right?

The beginning of a game is very important in catching the player's interest, so we can't have them grinding the same zombies for too long before getting to the interesting parts. The cave chapter needed to bring something more to the table. And then I thought: what if the cave chapter were also an early preview and tutorial on the fire mechanics?

My mind immediately raced to a game that's masterfully executed the "disguised tutorial" style of game design: Portal. The game is all about placing and using portals with the portal gun, but you start off without it and must first learn the basics of gameplay before getting into the portal stuff - kind of like how in KatFS you begin without the Fire Staff and first come to grips with the basics. However, Portal doesn't hide its portals from you until you have the gun; much to the contrary, the first thing you do in the game is walk through one. Even once you get the gun, at first you can only fire one color of portal, with the full gun being a later unlock.

So, what's the KatFS equivalent? It would be introducing the fire mechanics before the player has the Fire Staff, letting them at least experience it in a limited capacity before getting full access to fire magic! The question now is how?

FIRE HAZARD

We need a source of fire that's not Kalia's fire magic, since she doesn't have it yet, so it has to be something from the environment. However it has to be something the player can interact with and have some agency over, otherwise it might as well just be a scripted set-piece. And it needs to be something that makes sense as a fire hazard and therefore can easily be identified as such.

These standing torches have been placed throughout the cave, lighting the main path. While that's handy, they're also quite flimsy and all it takes is a single misplaced strike for the thing to topple and possibly spread fire to nearby objects. Of course, knowing players, these strikes might not necessarily be misplaced...

The standing torch is a new category of specialized entity in the game, which I've named "fire hazard". These are objects that are safe initially, but can cause open flames once struck, even if the attack did not have a fire component. It makes for a good way to introduce fires to the player at the start of the game, but I've also been thinking of other ways such objects can be used later in game... Say, those that played the demo, do you remember coming across a courtyard packed with explosives?

THE (NOT SO) LOST EXPEDITION

The torches are neat, but why are they there to begin with? I thought this was a wild cavern? Well I'd thought that too, but with the change in direction for this chapter, the narrative also changed slightly. Kalia not only finds more zombies, but also an entire campsite set up inside, like an expedition of sort was there. It must have been recent too, for their torches to be still alight.

The actual campers are nowhere to be found however. Only lots and lots of zombies. Maybe the adventurers discovered something they shouldn't have and ended up zombified?

Deeper into the caves, Kalia will find passages that have been clearly opened with the recent use of explosives. Whatever was sealed deeper into this cave has been freed by their carelessness, and they ended up paying the ultimate price.

However, Kalia is too curious to not explore deeper. And with some clever use of these torches, maybe she can even burn all these zombies to a crisp! This fire stuff is so awesome, if only she had some sort of artifact that could produce flames using magic...

Speaking of fires...

NEW AND IMPROVED FIRE SPREAD FILTERING

Let's talk how fire spreads in KatFS. Every object that is a potential source of flames has a "heat spreading zone" element, composed of a trigger collider that covers the range in which it can spread fire. Objects that receive this heat can then perform collision checks against these heat spreading zones, and detect how much heat it is currently receiving. The following image shows how this looks like:

In this example, object 1 has a huge heat spreading zone which overlaps with object 2's collider, meaning 1 could spread fire to 2. The inverse does not apply, since 2's heat zone is much smaller and does not reach 1.

However, the blue obstacle in that example is deliberate. So far, I've explained how the range is detected, but what about the fire actually being able to reach other objects? Can't have them spread through walls! So we need a "heat projection" check, to see if the heat from 1 could actually reach 2. In the pre-alpha demo, this is done by tracing a line between the center of the two objects, and checking if this line intercepts an obstacle.

This prevents fires from spreading through obstacles, but it can also block fire spread in situations where it seems like there should be enough contact for an open flame to spread, specially when it comes to larger objects. Next example:

Both objects' heat zones reach each other. Both objects almost physically touch each other. In fact, object 2 has almost all of its top face touching object 1, so by all means you'd expect fire to spread between these two objects despite the obstacle, right? Let's test:

Oops, the red line between the two centers just about hits the corner of the obstacle. Sorry, no fire spreading between these two objects I guess!

Obviously this is not what I would consider a satisfying outcome, so a better heuristic has been needed to solve this issue of fire spreading. And recently I suddenly had an eureka moment! Behold, the new method:

Allow me to explain. Rather than checking for obstacles by drawing a line from center to center, this new method checks corner to corner. As long as at least one of these lines connects without intersecting an obstacle, fire spreading will be allowed between the two objects. In this example, two of the lines do intersect the obstacle, but the two others do not, meaning fire can spread between the two objects!

This new solution should mean that larger objects can better "project" their heat around corners and small obstacles, without too much of a performance hit. Since only one line has to be unobstructed, the objects don't even have to perform all four checks every time - once a check passes, the others can be skipped!

Also, it makes for an interesting debug view (which might be hard to see in this sub 3MB GIF!)

That is all for this month! While chapter 1 isn't "fully playable" yet, it's pretty much 90% done, with only the very tail end missing, since this chapter will do something new to the project's development and feature a small cutscene that will take the player to a different area of the level past a point of no return. This is the story of Kalia getting lost after all!

However, in the next month I plan on taking a break from direct development to work on something else for the project... An official website! I'll admit, web development is kind of new ground for me, but fortunately I have friends who can help guide me. Perhaps soon you'll be reading devlogs on an actual Kalia.com website?

See you for next month's devlog!