Kalia and the Move to Alpha

Hello everyone! It's been a while since I last made a long-form devlog about the development process of Kalia and the Fire Staff. With the pre-alpha demo for the game reaching its final state, it has been time to give the project a throughout revision before moving onto an "alpha" stage. While a Postmortem post (or should I say a "Pre-natal"?) is warranted, that's not what I will be talking about just yet. Today I wanted to focus on the tech behind the game's systems and mechanics and how they will be upgraded for the alpha stage. So buckle up, let's go on a deep dive into KatFS's game systems!

First, a brief introduction to the matter at hand and reasoning. The Kalia demo has been initially developed as a prototype, and while I have made an effort to always be looking two steps ahead, for the most part its game systems have been built on-demand and in an improvised fashion. Get it working first, then get it working well. The advantage for this method is that it is a lot easier to just pick up the next feature and start developing it rather than getting stuck at the overwhelming task of planning a whole structure for a game you have yet to figure out the full requirements for. Just figure out what is needed next, code it and plug it in! However, as you can imagine, doing so will accrue you a lot of "tech debt" - that is, the quick and dirty solutions you come up with will eventually pile up until at some point it starts getting on the way of development. Sure, I might have got the AI, sound effects and animation systems working, but each was developed as their own thing and getting everything to work together has gotten awkward.

If a project is simple enough, this won't become a serious problem. But for the scope I see for KatFS, a bit of housekeeping is in order. In the previous paragraph I pointed out how planning the whole structure for a game you don't know the full scope of can be daunting, but now that I have a demo with 3 chapters and implementations for pretty much all the core game systems I'd ever need, the scope couldn't be any clearer. Not only that, but I have a blueprint to build off from, even if it's not perfect. Therefore, I've taken to revise the existing implementations and iterate on how they could be made better. This doesn't mean starting out from scratch though, no! It's important to settle for "good enough" instead of chasing perfection forever after all. Instead, my plans involve mostly modifying the existing systems so that they work better together, merge different implementations into a common one where it's possible, and separating some bloated components that try to do too much into multiple specialized instances.

With that out of the way, saddle up! Be warned, this devlog will be a big wall of text with not a lot in the way of images, so allow me to insert a funny bit of Kalia art to make this interesting before getting into it:

ENTITIES

Alright, let's get into some practical examples! Starting with a major one, the Entity system of KatFS. Entity is a component used by almost everything that can be attacked, burnt or destroyed in the game, from the crates and explosive barrels to wooden debris and trees to all the enemies Kalia fights. This component does a lot of things, from handling damage intake and health points to managing progression towards burning objects, and it also contains references for a lot of other components such as the AI script for NPCs, serving as a sort of "hub" for every dynamic world object in the game. Here's an example of the Entity component on a zombie prefab, and bear in mind these are only the inspector-facing properties of this component:

So, what are the issues with it? Well, first of all, the Entity component has to cover for a lot of kinds of objects - static props, dynamic props, NPCs, bosses - and it leads to it having some sort of identity crisis. Is entity #576 an NPC or a static prop? For example, in order to define whether a particular entity is an NPC or not, the way it's done right now is to check whether it has an attached AI script. Strike a pile of crates with a zombie inside, everything will be checked for an AI script. So one of my main goals for the KatFS alpha is to separate Entity into several sub-categories, such as PropEntity, MobEntity, and PlayerEntity (more about that last in a bit). All of these will still fall under the same common Entity umbrella, but will have specializations based on the needs of every type of object.

There's another issue around the Entity component, or rather a lack of it in places. For about 80% of game cases, the presence of an Entity component is used as an indicator that a specific object should react to damage or other in-game stimuli. It's a great way to filter for valid objects for a lot of operations. However, there are some exceptions to this. The player character, Kalia herself, for all intents and purposes should be an Entity - she can take damage, be detected by AI and has many in common with other entities - yet that's all handled by a PlayerController component instead, meaning that a lot of Entity operations require a special clause for the player: 

• Something exploded? Checking for all entities hit by the explosion isn't enough, we must check for all entities AND the player;
• NPC looking for a target? Checking for all valid entities in range isn't enough, we must check for all entities AND the player;
• So on and so forth...

Thus the reason for the creation of a PlayerEntity sub-category, to finally bring Kalia down to earth with all the other peasants. A similar issue arose in that certain objects may require baseline Entity functionality while not warranting the full breadth of systems that a dynamic prop or NPC would - one example being the ice mage's shield, which breaks after a few attacks. Currently it's not under the Entity umbrella, meaning that attacks now have to check if they're hitting an entity OR the player OR this very specific shield component. You can see how this could get out of hand quickly. My new plan is for the basic Entity component to be a simple "this object reacts to attacks" component, with the specialized categories coming with extra functionality while also serving as an identifier for the categories they represent.

FIRE AND HEAT

Fire is obviously a very important part of Kalia and the Fire Staff. After all, the main draw of the game is being able to set a plethora of things on fire and watch as it spreads from object to object and affects enemies in battle. Therefore, the systems that handle fire and heat in KatFS need to be on point. Currently, almost everything regarding the fire system is handled by one component, BurnController:

This component handles the object's burn state, the particle and lighting effects, and the spreading of "heat" to other objects. If you're wondering, yes it requires an Entity to function since it has no metadata on flammability and other fire stats by itself (yet another example of tech debt from improvised implementation). A big issue that I have discovered with the fire system, however, is that the mechanics that depend on heat spread are inconsistent - in some cases the burning object itself will "broadcast" the presence of heat, such as BurnController broadcasting heat towards all entities in range, but in other cases scripts will attempt to detect heat the other way around by checking for proximity to any BurnController that is actively emitting heat (the heat-sensitive crystals work like that), which has led to bugs that happen one way but not the other and that are hard to fix in a way that's compatible for both cases. This issue also exists at the other end, where any sources of heat that are not a burning object have to be jury-rigged and may fail to interact properly with other objects (such as Kalia's fiery aspect, which gives her a "heat aura").

The plan here? Decouple heat spread and heat sensitivity from BurnController into two new components:  HeatEmitter and HeatReceiver. While these two components will be often used and managed by a BurnController, they can also be used in any other context that requires the heat functionality, such as a non-entity object that radiates enough heat to burn nearby objects, or the previously mentioned heat-sensitive crystals. Since all objects interacting with the heat system will be using the same underlying components, this behavior can be made more consistent across the whole game, and any heat-related issues can be fixed more easily.

LOGIC SYSTEM

KatFS features a logic system inspired by the microchips in LittleBigPlanet 2's level editor (albeit I'm certain this design language is pretty universal in game development). This is what allows scripted interactions and sequences to work in the game, such as a pressure plate detonating a bomb when activated. For the most part, I'm happy with how it works, but I've found that the way its components are named, organized and used leaves a lot to be desired. A base LogicObject component represents anything that produces logical inputs, having several implementations such as PlayerSensor, HeatSensor, LogicGate and LogicKeyhole. I won't go into detail for each of them, but know that they ouput logical signals based on certain conditions. These signals are then taken by a LogicReceiver component, which activates events based on the current logical state or when it changes. It's straightforward, but these names can be unclear and setting it up can easily become a tangled mess. For example, many objects have both a LogicObject and a LogicReceiver since the former is unable to run any events based on its own state, requiring the latter.

Here we have a matter of just cleaning up the components a bit. LogicObject will be renamed to LogicOutput, and LogicReceiver will get the matching title of LogicInput. Logical gates will be their own thing rather than an implementation of LogicOutput, since they're in an unique position where they have both inputs and outputs. All LogicOutput components will also be able to activate events based on their own internal state, no longer requiring an additional component for operations contained to a single object.

CONCLUSIONS

As you can see, these are changes that don't affect the game's presentation all that much, but are a big deal under the hood. Implementing these changes is sort of a one-way street, since it's akin to taking out a lot of what makes the game work and changing it before plugging everything back in (albeit thanks to online repositories and version control, nothing is truly a one-way street in gamedev!). My intentions with these and other changes is to leave the KatFS codebase in a position where core systems are robust, adjacent features can be easily added in, and building the game itself has as little friction as possible (no setting up 5 different components for every prop when you can get it done with 1 automatically). While I don't expect reinventing the wheel to be exciting work (both for the dev and the audience), it is rather necessary when the current wheel keeps squeaking and giving a bumpy ride.

Plus, all that gamedev experience gained from the pre-alpha needs to go somewhere, right? That is all for today, until next time!