System Fault Devlog 7

Consolidation was this week’s theme. Existing systems were combined, new systems were introduced, and groundwork was laid for lots of fun emergent complexity!

That enough buzzwords for you?

I began by changing how damage was handled. Previously, players and robots handled this slightly differently. Since I’d like to add robots that require more than a single shot to kill, though, I decided to unify everything under a single set of systems. Now, all player and character damage is handled the same way.

This paved the way for a new set of systems for handling explosions. I thought it might be neat if, say, a mine detonated and took out the cover behind which you were hiding. Since explosions are a key aspect of System Fault gameplay, they now have their own dedicated systems. Robot kills now cause explosions, as do mines. The previous delayed kill/shockwave mechanic is now handled by the explosion system, which also wipes out server room tiles. Actually, explosions themselves are managed by an even more generic Area of Effect (AoE) system which, among other things, will eventually manage smoke clouds for the upcoming stealth mechanics.

Handling this was somewhat interesting. System Fault uses a shadowcast-based visibility system, where walls and other objects can block line of sight. It wasn’t too much effort to repurpose this mechanic for explosions. Now, instead of radiating outward indiscriminately based on distance, explosion shockwaves are blocked by obstructions. If the obstruction is destroyed–a robot or server blows up, for example–the shockwave can reach other tiles and cause more damage.

I also gave the AI a boost. Previously, robots would investigate player actions by identifying when they first saw a bullet, then approaching to within a few units of that position and stopping. My hope was that this wouldn’t cause them to trot gleefully into the player’s gunsights, but that’s often what they did. The new algorithm identifies a point parallel to the bullet’s line of flight and moves toward it. In practice, this seems to result in robots safely investigating shots, backtracking along their path, and finding the player more often and safely.

Finally, I seem to have cracked environmental audio, at least in part. Code to filter sounds based on rooms and distance has been in place for a while, but it never quite worked. Yesterday I dove in, reread the relevant specs, and managed to create different effect chains for occluded and unobstructed sounds. I’m not completely happy with the result, but where the game world previously sounded like an open space with lots of sounds scattered around, now it resembles an enclosed building with separate rooms and a tangible distance. More tuning sure to come.

Speaking of audio changes, check them out for yourself in the below gameplay recording of me taking down a server room. I spawn in, take out a couple robots in the opening room, then find a server room off the main path. First I collect a shield, then I shoot out enough tiles to see how many exits I’ll need to defend. Then I plant a mine in each. Finally, I spin and spray, taking out the server room, and defending successfully against the swarm. Admittedly it’s a bit easy, and I put a few simplifying measures in place mostly due to how muddy the soundscapes used to be. Those will likely be removed next week. On the other hand, this is just level 1, and the enemies are the simplest you’ll encounter in the game. Dumbasses have half your visibility range and speed. Level 2 introduces robots that can see as far and move as fast as you can, both of which should make server room takedowns much more difficult.

My goal next week is to implement the grenade-tossing mechanic, which clears the way for implementing two new powerups. After that, all that stands between us and an early access demo is a few new robot types and slightly more complex server rooms. With any luck, I’ll have a demo out by the end of the month.