KatFS Alpha Devlog #8 (February 2025)

Hello all! This is February's monthly Alpha Devlog, delivered in the fifth of March... Bear with me, the Brazilian carnaval holiday happened right on the turn of the month this year and I sorta forgot about the devlog... :') Speaking of carnaval, here's a little art for it featuring Kalia and Callie, a character to be featured in a future game (get hype, but don't hold your breath, it's still very far away!)

With that out of the way, what did February bring us?

ANCIENT FACILITY ASSETS

Work on the new facility chapter has been progressing, with many new assets being conceptualized and produced at this early stage. The ancient facility is an industrial structure that operates on magical technologies whose secrets have been lost to time. While it may be ancient, its machinery is still functional, simply dormant for centuries and waiting for someone to come along and start them back up. The facility chapter is heavily inspired by the classic Half Life games, a massive underground industrial complex where Kalia has to fight enemies and operate the machines to move forward.

Big buttons and levers that can be interacted with are an important staple for many games, and that definitely applies to KatFS! The player will also encounter ancient panels and displays that Kalia is definitely not qualified to operate... Sorry Kalia, you'd need a PhD on a defunct subject to make sense out of those!

The heat sensors that can be found in the Pre-Alpha Demo have gotten a redesign, and a rename to "heat converter". These devices can convert incoming heat into magical power which can then activate other devices. Simply tossing fire magic at them won't work, however, they need an active fire nearby that provides sustained heat!

Battery blocks are a new experimental gameplay mechanic that is meant to replace most use cases of the "box and pressure plate" puzzle element (albeit these shouldn't be going completely away!). Batteries can be charged up at designated charging stations, and then moved to a battery slot to power up a device. They will be distinguishable by their unusual blue glow instead of the typical orange one.

Status lights can be off, red or green, and their purpose is to serve as an auxiliary visual element in puzzles, specially when it comes to devices whose state may be hard to discern immediately.

The ancient facility has pipes running all over it, from the thinnest to absolutely massive ones. These elements are mostly for ambience. The "staff vault" however is an important set-piece in Kalia's adventure, as it is where she will find the Fire Staff in! As Kalia comes closer to get a better look, the machine suddenly activates, the staff seemingly powering it as it beckons Kalia. There's a big button just in front of the machine, surely nothing bad could happen if she were to press it?

(In-game scenario subject to changes. Also do ignore the duplicate Fire Staff by Kalia, she really shouldn't have it at this point :B)

In order to advance deeper into the facility Kalia will have to operate its machines, but there's not much she can do without power... Fortunately, this facility also houses the energy generators that not only power itself, but the whole ancient city! Getting them to work might be easier said than done, however...

This one was a doozy to model in Blender, being the game's single most massive asset yet:

ANIMATED DISPLAYS!

A way to bring some life to these otherwise static objects. Just look at it:

 Achieving this effect was a bit tricky. These props all have a secondary "emissive" texture that the shader uses to light its appropriate bits up. By tweaking the shader variables, it's possible to have these devices light up, power down, flicker and do anything you'd expect a light source to do. And by "animating" this secondary texture flipbook style, the lights can move and form blinking lights and moving displays naturally.

A picture is worth a thousand words, so allow me to show an example, the four frames for the secondary emissive texture on the control panel object (the big rectangular dashboard on the right side of the above image). White areas get lit up, while black means no light.

LOGIC IS BACK!

With the new facility chapter, comes a chance to revise the interaction and logic systems in the game. "Logic" in this case refers to the system I've got set up in order to create scripted behaviors in the game, such as "open this door when the player presses a button", "play music when Kalia enters this area" or "start a cutscene when a group of enemies is defeated". It's already gotten a facelift during the transition to alpha, and seems to hold up well.

What's really new is a new paradigm and systems in planning for the "interact" button. In the Pre-Alpha Demo, this button had only one use: to make Kalia grab onto objects that could be moved around. It was always my plan to have this button serve as a contextual input for interacting with world objects in ways other than attacks. For example, interacting with the buttons and levers shown previously.

The challenge that comes with this is determining "context". The approach I've opted for is to have interaction scripts require a "trigger zone" where should the player enter, the object will assign itself to a global variable, informing that the player is within its interaction range. When the input function is called, the script can then go through each category of interactable and check if one has been assigned, and then run the activation code on it. This even allows for a priority system where certain interactions will take priority over others (albeit the best practice would be to avoid situations where interactables could overlap as much as possible).

Interactable items will also display a visual prompt when they're in range, to indicate that they can be interacted with. I'll also be adding a button prompt to match.

What about the grab and move function I mentioned? The feature is staying, but will be changed from the demo: objects that can be interacted with to be moved will be much more uncommon and specific, like the battery blocks or boxes with handles. They will get interaction prompts as well, and the underlying code to handle them will be changed to the new paradigm. The majority of objects in the game will no longer be moveable that way, however they'll still be able to be moved by attacks and other physical interactions. The idea is to restrict this interaction to specific puzzle sequences and incentivize other avenues of interacting with the environment in the moment to moment gameplay.

Oh yeah, and perhaps now I could finally have a way for the player to open chests rather than smashing them! Well, for unlocked chests, at least...

That is all for this devlog! Appreciate your interest, and let's see what March brings us! I expect the facility to be looking slick come next update!