System Fault Devlog 3
I’m sure some non-English language has a word for the concept of progress, even if it seems like you’ve taken 8 steps backwards. If so, that word would describe this week’s development rather nicely.
This week saw the introduction of the first powerup. Shields add an additional non-healable hit point, and will likely be incredibly useful as robots get smarter and harder to defeat. But before I added powerups, I restructured how robots spawned in order to make levels more difficult to charge through.
Initially, robots spawned randomly throughout each level, with a bit of logic to lessen the likelihood that multiple robots appeared in the same room. Now, a happy path from the player’s spawn point to the level exit is calculated. The level’s more difficult robots spawn along this path. Powerups spawn off the path, incentivizing avoiding tougher robots and searching for advantages before charging toward the level exit.
I also tweaked robots' investigative behavior. Previously, explosions within a large radius would trigger robots to move toward the originating coordinates and investigate, even if the path to reach those coordinates was long and traversed much of the level. My thinking was that robots could hear and localize the sound quite accurately, knew the levels better than the player did, and that swarms would be an effective challenge. But this proved to be messy for a number of reasons:
- A single robot defeat would trigger a massive swarm, which made the challenges very lopsided.
- While swarms aren’t to be avoided at all cost, they do muddy the soundscape and probably shouldn’t happen regularly.
- With robots positioned along the happy path, swarms would drain the path early. Instead of progressing through rooms one-by-one, a few early battles could completely clear the path, leaving the way to the exit clear.
Robots now only investigate explosions based on their path’s distance, making progressing through levels feel like a series of individual smaller battles.
And, of course, I fixed more foundational bugs. Speaking of which…
Many of my bugs involve collision and visibility indices. I built these systems for a roguelike concept demo I ultimately shelved, and roguelike physics is much more forgiving. I’ve found many corner cases where indices aren’t cleaned up, aren’t updated correctly, and aren’t terribly helpful even when they are accurate and up-to-date. Further, even if I worked around these deficiencies, the underlying physics wouldn’t let me do much of what I want.
Fortunately I had a plan, and last week the missing piece fell into place. The physics engine I’ve been eyeing had a major update, including a much improved integration with my engine. I’ve since ripped out much of my crappy physics code, replacing it with motion and collision detection written by folks who know what they’re doing. Working through this non-visually is challenging, to put it very mildly and with much less profanity than I’d prefer to use. When I was very young, I remember playing inside some cabinets in a house my parents were renovating, giggling at the light and open space where sides and backs would have been. I’m much less amused now that I’m older, and the house is replaced by my game that doesn’t work. Even so, this paves the way for a number of improvements:
- Existing code should run much more efficiently, paving the way for mobile and other small form factor support.
- I can perform spatial queries against the world, answering questions like “Is the player trying to aim at a robot?” and letting that robot respond in more or less intelligent ways.
- With someone else maintaining the physics code, I can concentrate more attention on actually making games rather than fixing indexing issues.
Needless to say, I don’t have a gameplay recording this week. With any luck, next week I can show off powerups and moderately more intelligent robots.