Most Recent Episode
Hey, everyone. I recently launched the Kickstarter for my upcoming Spaghetti Western Action-RPG Bandits and Bounties.
I just finished playing through Super Metroid, and a thought occurred to me. Something that is both a strength and weakness of the “Metroidvania” style of game is that sometimes you see an object out of reach, and don’t know if you can actually get to it with the items you currently have, or if you need to come back later. In many cases it’s obvious: there’s a colored door or marked block that you don’t have the weapon to open, but many times it’s not as obvious, and you have to solve some sort of navigation puzzle to reach the item.
Why I think this is ultimately a strength is it creates the possibility, but not a certainty, of an unsolvable (for now) problem, which is a rarity in games. Games are designed around the player, and thus every problem is made to be solved. There’s no reason to give up on a puzzle because you know there’s a solution. But with this, you get ambiguous situations where there is a chance that the problem is insoluble for the time being. Giving up could be the correct option, and because of that, it means more when you figure out that a problem can be solved and you don’t give up.
It’s Halloween and that means Emo Mcgothington has more candy to fight than ever! When they made a deal with the devil, the people of the candy kingdom asked for treats, but instead they got tricked! Help our maudlin mercenary save the Candy Kingdom with this 65% off sale~
Today I want to talk about the relationship between specific and general elements of games. It’s something that I’ve been thinking a lot about recently. But first I should define what I mean by specific and general.
The key, I think, to understanding games as an expressive medium lies in the following:
Claude Shannon once famously estimated the number of potential chess games as being at least 10 to the 120th power, which, as the cliché goes, is more than the estimated number of atoms in the observable universe. However, in all of these games of chess, there is not a single one in which the two sides come to a peaceful solution to their conflict, or in which the pawns rise up and overthrow their own king, or in one of the bishops converts the opposing pawns to switch sides. There is not even a scenario in which one side grows their ranks; the best they can do is maintain their numbers, and the likely outcome is a steady reduction in pieces over the course of the game for both sides.
In addition to this, there are many themes which reoccur, perhaps not in every single game, but in most well-played games. Using your pawns to shield your more valuable pieces, sacrificing pieces in order to pull your opponent into a disadvantaged position, using multiple pieces in tandem to push the opposing king into a corner. None of these things are explicitly stated in the rules, but they are behaviors that are implied by the rules. The rules make these behaviors beneficial to winning the game.
The crux of all of this is that, despite the often near-infinite numbers of permutations games can have, they still make a statement through what the player can do, what the player can’t do, what the player should do, and what the player shouldn’t do.
Many people talk about designing using “verbs”. In other words, thinking about the actions the player can perform in a game. Run, Jump, Talk, Shoot, Trade, Swim, and so on. But it’s as important to think about what the player can’t do, and it’s also important to consider which of the actions that are available to the player are incentivized and disincentivised.
As a developer, it is important to understand how the cans, can’ts, shoulds and shouldnt’s form the core of the narrative of the game. To go back to the chess example, the narrative of chess could be said to involve class hierarchy, strength in numbers, sacrifice for the greater good (or, one might argue, sacrifice of the lower class for the benefit of the upper class), zero-sum warfare, the importance of thinking ahead, setting and avoiding traps, and so on.
Take, as another example, Amnesia: The Dark Descent, and how so much of the core experience comes from the fact that the player can’t fight back against the monsters. In addition to that, they are incentivized against looking at the monsters for too long, which helps make them more frightening. Also, players are incentivized towards scouring the level for items such as lamp oil which causes them to keep themselves in an uncomfortable position for longer. All of this combines to create the atmosphere of fear and helplessness that is at the core of the game’s experience.
Or, to take the example in another direction, think about how, in Megaman, the fact that you can’t shoot in any direction other than horizontally is such a core part of the challenge of that game. Think about the way you’re incentivized to complete the levels in more-or-less a certain order because of how the boss weakness system works.
Remember as a developer how much control you have over the overall experience. Anything the player can do is something you’ve (either intentionally or unintentionally), allowed them to do, and sometimes what you don’t allow them to do speaks as loudly as what you do. And within the bounds of that experience you’ve created, the way they play will be informed by what you have decided is beneficial and detrimental. In this way a game can have a consistent theme or narrative or meaning or whatever you want to call it, even if the events change from playthrough to playthrough.
We’ve talked so far about goals mostly in terms of specific objectives which you’ve placed in specific places for the character to reach. But what if the systems in your game interact in such a way that the player ends up needing to do something which you did not specifically design or anticipate.
First of all, something I want to address. As the designer, even if something emerges from the system rather than being explicitly put there, you still can have some awareness of it and anticipate common (and uncommon) emergent events that are possible from your system. You can have an overall awareness of the possibility space defined by your ruleset, and thus most emergent objectives can be prepared for. You might not know exactly when they will emerge, but you can have a good idea of what they’ll be when they do.
For instance, if you put an ammo system in your game, you can expect that a potential situation that might emerge is the player running out of ammo. At this point, their goal is to find more ammo.
Knowing this, you can create challenges around goals which the player may or may not need depending on the circumstances. The way these differ from optional challenges is that, in certain situations, they cease to be optional, and become necessary for the player to make progress.
Early on in Super Metroid, there’s a series of rooms where the goal is a device that will refill your missiles. Blocking the player’s progress is a door which must be opened with missiles. If you are at full missiles, this side-challenge is basically useless to you. If you aren’t at full missiles, it gives you a small reward but is all-together optional. If you don’t have enough missiles to open the door, this challenge becomes a necessity.
One of the largest examples of this sort of design is the curse mechanic in Dark Souls (before they patched an easier solution into the game). Some enemies inflict a “cursed” status ailment. If they manage to completely curse you, you are at half-health until you can become uncursed. There were only a couple of ways to do this and they both involved massive treks through dangerous areas with only half health. The player had been given an goal through a system in the game, and the designers put that goal behind obstacles. The designer doesn’t know that the player is necessarily going to be cursed, but they know that if the player does get cursed, they’re going to have a challenge ahead of them.
The moral of this story is that, as the designer, you should be aware of the needs the player might be given by the system you’ve designed. You can use this awareness both to insure that the player never gets completely stuck by making what they might need available to them, and also allows you to create challenges around those needs.
As a final note, this also accounts for the level-design feature of the “boss fountain”. This means either putting a lot of items up right before a boss, or putting an object that spawns a constant stream of low-teir enemies which drop items, so that the player can replenish their stocks before a major fight. Remember, you might not know what exactly the player needs at any given time, but you know the sorts of things the player will need in general.
The idea of tension and release is a common one among many art forms. In music, ascending scales and dominant chords can build tension, while descending scales and returning to the tonic chord can give a sense of release. Dissonance resolves to consonance. A story will build tension through conflict before finally resolving the conflict, creating release. It’s something which is core to our experience of art and entertainment. We want the catharsis that comes with building and releasing tension.
So how do we apply that to level design?
The people of the Candy Kingdom made a deal with the devil. They asked for infinite candy, and what they got was an infinite candy army. And so they must turn to exiled hermit and all-around downer Emo McGothington, to save the day with his penchant for violence and negativity.
As Emo McGothington, you will run ‘n’ gun your way through 30 levels spread over 4 worlds using a variety of weapons to dispatch your saccharine foes.
I worked on this game with Jared Cohen, who did the art, and Phillip Lanzbom, who did the music.
You can get the game here: http://emomcgothington.com/
There’s also a launch trailer: