Gameplay Limits in Bombernauts

(crosspost from Bombernauts Development Blog)

My game design method usually involves making a prototype, then picking an arbitrary or made up "game design philosophy" that fits the prototype I made, then designing the rest of the game with that philosophy in mind. This method helps enforce a bit of consistency in the design, while giving clear guidelines for how to solve certain design problems.

So for Bombernauts, I have been thinking about a concept of gameplay limits. Anyway, limits are cool. If you frame your game design based on what the player CAN'T do, then what they CAN do is nearly infinite (at least that's the thought). It doesn't always work like this in practice, as programming has its own limits, but it helps with design a lot. If someone tries to do X and can't, is X something I explicitly want to limit?

But this is not actually what I chose as a philosophy for Bombernauts. There's a bit more to it, regarding HOW things are limited. I see 2 categories: hard and soft. I am unsure if these terms have been used before for game design, as googling that brings up stuff relating to BDSM which I really don't need in my search history, so if there's a better term for it please let me know.

Let's start by explaining "hard limits", which is what I'm attempting to AVOID in Bombernauts. A hard limit, simply put, makes it extremely clear when the limit is hit, often long before you can hit the limit. The simplest example is game length. Want games to not take longer than 5 minutes? Add a 5 minute timer. You know what the limit is, you know when it's going to be hit, and there's not much you can do to stop it. Another example would be say, health. If a player has 100 health, and attacks to 10 damage, they will die in 10 hits. In a vs. game this makes it clear who's winning or losing at any given time, so statistically the player with less health will lost more often. If it's 10 to 90, the game is basically already decided. There's still a chance for a comeback of course, but at that point it's pretty clear who's going to win, and you can see the end of the match in sight.

A "soft limit", on the other hand, emerges naturally from the game mechanics, and does not have a clear boundary that needs to be hit for the limit to take place. A nice example here is score in everyone's favorite rougelite-like-like-like Spelunky. There is a maximum possible score in Spelunky, but nobody knows exactly what it is (You'd have to check optimal routes for every seed in the game, around 4 billion seeds). If you play Spelunky a lot, you'll edge ever closer to that max score over time, but will never reach it (and if you do, you'll never really know you reached it).

Super Smash Bros is another game with a lot of good examples of soft limits. How many hits do you need to land to kill the other player? Well... it varies. You are never a guaranteed 1 hit away from death in Super Smash Bros, though the chance of a single hit killing you goes up over time as you rack up more damage percent on your character. You can even be killed at a very low percent with a well placed attack and ledge grab from your opponent. As a result the game almost always has a bit of tension over who will win and who will lose, even when one player has a large advantage.

As a programming example, here are 2 ways to do "maximum speed". The hard limit way would be:

    speed += acceleration;
    if(speed > max_speed){
        speed = max_speed;
    }

The soft limit way would be:

    speed += acceleration;
    speed *= friction;

The soft limit way limits velocity because when ((speed+acceleration)*friction == speed), you've hit your cap. You can calculate friction needed to reach a certain max speed by solving that equation for friction, with max_speed in place of speed. It works out to be friction = max_speed/(max_speed+acceleration). See the graphs below for an estimate of how these functions look in game. They both limit speed to the same value, but do so in a different way. The hard limit caps out in finite time, which can be good for games where you want tight timings on things. The soft limit never quite reaches its cap, which can be good if you want a really smooth feeling motion, or want to handle situations where the player can end up moving faster than a max speed cause of an external force.

These two kinds of limits exist on a spectrum though, it's not binary "this is a hard limit" or "this is a soft limit". The example of HP in a fighting game I used earlier, I categorized it as a hard limit because it clearly limits how many hits you can take before dying, but it still manages to be a soft limit on game length, and with healing moves or wombo combos there can be uncertainty on it.

Bombernauts' design is about soft limits. If there is a value or a behavior I need to limit, I will attempt to use a soft limit if possible. For example, game length. A lot of people have suggested to me, "hey you could raise the lava after X time to keep games short!" or "hey there could be a sudden death mode after X time when bombs start raining from the sky!". Both of those are hard limits, and they're not necessary because game length is already limited! Bombs that you throw destroy the level over time, and there is a limited amount of level to destroy. It can vary depending on the number of players, but there should be no stalemate situations (unless all players stop playing... which can happen in a lot of games really).

Explosion forces vary depending on distance from an explosion, and the radius is invisible, so you don't get a clear boundary of if you were hit by an explosion or not. This is another soft limit. Get too close and you will be knocked away, too far away and you wont, but the actual crossover point where it's dangerous is ill-defined.

There is never a current winning player in a single match of Bombernauts, because there is no concept of HP. Even if you die, you can get back into the game for a comeback with a well placed ghost bomb. This degree of uncertainty can make matches really tense, surprising, and fun.

These few mechanics were in from the start of the game... and how I discovered the concept of soft limits. Since then I've used that concept in solving a ton of other design problems in the game. Limiting the effectiveness of bomb jumping (while making the shorter jumps easier) was a mix of soft limits (from how much bombs can effect your speed while already moving, and what degree your own bombs stun you for when they push you vertically). Limiting the ability to spam bombs as fast as possible without adding something like a cooldown also involved a soft limit (the game increases a stat which makes you get stunned for longer when you spam bombs a lot, at a certain point your own bombs start stunning you, which prevents you from continually spamming them, though there are ways around this with clever play).

Anyway hope this was informative, and remember: I'm not saying soft limits are the "right" way to do things. Most games have a mix of both, and its up to you to decide which kind of limit to go for in your own games, it's just something to think about.

- Tyler