Condition Effects

The Problem

A number of power-ups and environmental factors acted upon numerous player physics variables creating math errors and race conditions when combined.

How I solved it

My solution was to divert the math to a linked list of special effect holders that are attached to the player. Each special effect has individualized effects that are summated each time an effect is added or removed. Numerous physics variables can be handled, as well as elemental and damage-over-time effects and more as-of-yet unimplemented uses.

What I learned

While fixing the bug was the instigating event, re-factoring how the game handled these effects allowed me to extend the system to improve other existing and future aspects. From slowing to burn damage to freezing players in an ice block, all these effects and more are trivial to implement (even for modders).

Ball-istics

The Problem

A ball-scoring gamemode suffered from problematic hard-coding in multiple areas and a lack of modding variety.

How I solved it

This gamemode's code was in need of a refactor to eliminate a number of hard-coded code-duplicated limits and variables. While I refactored, it became apparent that the new variables allowed for untapped modding potential. By connecting several of the gamemode's events to special handler functions, I was able to run the code through the mutator chain (a special linked list for modifying game rules) and create a UI for expanding the selection of ball types usable in this rugby-like mode. Now devs and modders alike can make their own balls that fly faster, bounce harder, cloak, explode, teleport, converse, and even seek.

What I learned

You don't have to make huge changes to durastically affect how a game is played. Allowing players to optionally turn a few dials can completely change a game for the better. Now, any time I see arbitrary hard-coded limits I ask myself: Could players have more fun if this thing could be tweaked a little?

Sound Ideas

The Problem

Over a dozen in-game interactions were either lacking unique sounds or missing sounds altogether creating a strange lack of immersion.

How I solved it

One thing studying game design doesn't prepare you for is the joy of being a foley artist.When I was tasked with filling in various missing in-game sounds I needed to replicate everything from various footsteps the sounds of elements to the spring-powered "ka-chunk" of weaponry. I quickly realized a number of household objects could provide pieces of the sound profiles I wanted, then edited them together to create punchy and satifying sounds to fill in those silent interactions. When it came to existing sounds that were used for multiple purposes, the negative effects were clear once they had been updated. You may wonder, for instance, why it's a big deal to have differing sounds for swimming through various fluids like water, lava, slime, and more. Why not just use a universal swimming sound? Immersion stems from a game's ability to communicate with the player, and there's no better way to communicate you've entered a fluid than through the sounds you make as you wade through it. In an instant you get a feel for how dangerously viscous it is; just knowing this isn't your normal everyday water puts players in a heightened state. That sonic feedback feels good, and it becomes noticable when it is absent even from small interactions.

What I learned

I've come to learn that sound is one of the most important tools for immersion, yet is often an overlooked aspect of most games. While players may not consciously notice every missing or inappropriate sound I encountered, they will take note of it on a subconscious level. Over time, your sound design will be one of the factors that either makes your game feel good, or makes it feel unsatisfying, uncanny and strange.

Checks and Balances

The Problem

A number of weapons, powerups, and environmental factors lacked code to account for interactions, often creating bugs and bad visual communication.

How I solved it

When I first found the bug-causing interaction between the powerup that temporarily increases your running speed and the weapon that is capable of leaving behind a sticky glue-like trap, I figured the fix would be quick and simple. It was at first, but it didn't feel right. Players would be zooming about the map then stumble into the trap and freeze dead on the spot until the trap was eventually destroyed. The code had not accounted for a corner-case in this interaction, but it was more than just a bug; it was sloppy design. To rob players of all their movement with or without this powerup felt unfair and unbalanced. Not to mention, it would happen so quickly that players would become confused momentarily. My solution was to have the glue trap strip away the powerup, but not stick the player. In this way, speedy players are punished for hitting the trap but in a way that feels justified and allows them the chance to react to the situation.

There were a number of these interactions that felt unfinished and offered the opportunity to create balancing factors.

• Problem: Sniping weapons are disproportionately strong in certain maps.

Solution: Add a powerup to block a single headshot in sniper-dominated maps.

• Problem: A projectile with the severe disadvantage of detonating if shot by an enemy isn't worth the risk.

Solution: Players can now steer the projectile with a laser-pointer, allowing them to dodge enemy fire whilst simultaneously visually alerting enemies to the impending danger.

• Problem: While scoped in, sniper weapons create a lack of awareness of your teammates.

Solution: Scope elements change to friendly colors and identify teammates when pointing at them to prevent wasted shots and create opportunities for team recon.

• Problem: A camera-guided projectile creates a total lack of situational awareness for players that fire it leaving them completely vulnerable.

Solution: Special camera effects and alarm sounds are made when the guiding player takes damage allowing them to quickly react and possibly abort their current shot. Friendly players (including themselves) are also identified through the projectile's camera so the firing player can quickly identify enemies near them in self-defense.

• Problem: A rocket-based projectile hits too hard when landing easy ground shots on enemies, but reducing damage will punish skill-based direct hits too much.

Solution: Damage is tweaked based on the area hit. When a rocket impacts a player in the leg area, damage is reduced and momentum imparted is increased. This not only creates new strategies for knocking enemies back when direct hits are not an option, but also creates new skill expression by letting players rocket-jump using the increased momentum with less worry of self-damage.

What I learned

Game balance doesn't have to just be a matter of tweaking numbers. One can add a unique interaction between elements and create a totally new power dynamic that offers a new vector for balance. Sometimes it's not possible to balance a game with just numbers. These new vectors provide a way to create balance through interactions that feel clever and polished; making new strategies for players that feel justified without increasing complexity tenfold.