This is the first entry in a series called “What I know about game design”. It is an attempt of writing a collection of articles where I summarize some of the game design experience I have gathered during a decade in the games industry. If you haven’t already, read the introduction.
Before you start reading, know that depending on who you are you might find some of it rather basic, and that is as it should – I want the series to become a solid foundation to stand on for aspiring designers.
#1: Always communicate
The importance of communication
It might not seem like it when putting that latest AAA blockbuster disc into your console, but games really are chaotic collections of systems, sounds, 3d models, animations, text, stories and ideas. What people see as a game is a million moving pieces orchestrated by a team of game development professionals. They are webs of countless artificial rules. An unbeliavable amount of work has gone into making it seem like a life like experience rather than the incredibly complicated piece of software that it actually is.
It is your job, as a game designer, to make sense out of that complexity. Without you carefully chiseling out the contact surface between game and player, the experience will be one of confusion and frustration. You need to make sure that the player understands what’s going on, what he’s meant to do and how it can be done. And here’s the catch – you need to do so without encumbering the player with information and without ever breaking her suspension of disbelief.
It’s not a simple task. In fact, one of the most common questions I ask of my coworkers is “how do you communicate that?”. So often when we designers have an idea, or sometimes even when we have already implemented it, we’ve not thought of how to communicate the idea to the player. And our failure to communicate the new cool idea will mean that it will either go past the player unnoticed, or it will blow up in her face and frustrate her. And then it is either a waste of production time or actively hurting the game experience.
“How do you communicate that?” Ask yourself that question often.
Even worse is the notion that certain things doesn’t need to be communicated. That the players should find those concepts out on their own, as if complex rules that aren’t expressed in an understandable way somehow enter the player’s conciousness through osmosis. No. Trying to create a gameplay challenge by being obscure is not entertainment nor gameplay. You’ll only confuse the player.
“Challenge through obscurity is not gameplay.”. Make that your mantra.
The fidelity of the information that must be conveyed to players is staggering. Just to show to what level of detail you must consider it, let’s look at something as simple, mundane and obvious as doors in a typical first person shooter. What must an FPS communicate to the player about its doors?
Can doors be opened? How do I open a door? Can all doors be opened? If not, how do I determine which doors that can be opened and which are not? Are some doors locked and can be unlocked? If so, how do I differentiate between doors that are locked and doors that cannot be opened? How do I unlock locked doors? If I have unlocked a door, will it remain unlocked? What is the difference between a locked door that can be unlocked and a door that can never be opened? When I open a door, will it close automatically? Can I close doors manually? If so, how do I close a door? Can the NPCs of the game open doors? Can the NPCs of the game unlock doors? Can the NPCs of the game close doors?
All these questions represent aspects of your game that the player must understand. And this is simply identifying potential questions. The next step is to find out how to give the answers.
How to communicate information
During the 80´s and early 90´s games often came with thick manuals explaining the intricate details of the games. With sufficiently complicated titles you started off by doing research; you got home and sat down in front of the computer, but instead of turning it on you opened the manual at page one. And you studied it to understand how the game worked and how you controlled it. If you played a game and didn’t get it, that was your own fault.
Boy have things changed.
But we didn’t go directly from there to where we are today. There was a long transition process where studios relied less and less on manuals and more on tutorials. More and more games had entire training levels that would teach the player the fundamental mechanics. These were often outside the game’s campaign, not worrying too much about trying to integrate them into the story, not caring about breaking the fourth wall or making much sense from a narrative perspective. But step by step they reduced the need for manuals, and each step also reduced the players’ tolerance for having to study before enjoying their newly purchased game.
Suddenly the cardboard boxed game disappeared alltogether from store shelves, replaced by today’s thin plastic boxes, and there were no longer room for thick, information crammed manuals. Tutorials became a necessity.
Tutorial doesn’t mean the same thing today as it did then. A slow process of increasingly sophisticated design work has integrated it into the normal gameplay creating a singular game experience. A modern tutorial is not a training level separate from the main campaign. If done right, it is unnoticable. Learning how to play comes naturally, effortlessly, by simply playing the game.
Players today expect to get the game while playing it – they just want to hit “new game” and get going without ever worrying about how to play. They don’t care for long or suspension-of-belief-breaking tutorials anymore; the game world and all it’s functionality should ideally explain itself without ever drawing attention to the fact that it is being explained. The designer’s hand should remain invisible. Occasionally informing players that there are hints on how to do certain things whenever a new concept is introduced is still considered acceptable, as long as the hints are not forced on the players.
The modern way of teaching an audience how to play a game is usually a two step approach.
- Start out with very low complexity, and then slowly introduce new concepts in a deliberate and careful pace. The goal is to increase the complexity at a pace the player can follow without being overwhelmed or confused – but make sure that the game’s complexity does not stay low for too long or the audience will grow bored.
- When a new concept is introduced, give the player the chance to test it out. Do not linger – allow the player to use the new concept before he have forgotten the little he has already learned about it, before he has forgotten about the concept alltogether and before additional concepts have been introduced making the player overwhelmed. Make the scenario in which he can test out the newfound concept simple enough – the goal is not to challenge him here but to teach him and make him appreciate the feature. If the testing ground is difficult well before he has even learned the basics of the concept, he is likely to become frustrated and might actually fail to absorb the lesson you are trying to give him.
What kind of information needs to be conveyed? To better understand how to communicate different aspects of a game we need to unravel its web of complexity.
Understanding the verbs, or the things the player can do – her abilities – is the foundation of a playable game, because they are the interface into the gameworld. Teaching the player the verbs starts the second the game begins. The most basic ones – looking around, moving around, jumping and crouching in the case of an FPS – needs to be taught immediately so that the player can begin to interact with the game space.
Here are the things you need to consider when communicating the verbs.
How do I use each verb? In very concrete terms, how is a specific verb activated? How do I jump? How do I equip a specific weapon? How will I repair the broken machine? How do I get my plane in the air?
It is not simply about informing the player how these things are accomplished (which is tutorial territory). If you think systematically about player interaction you can create mental models in the player’s mind about how interaction works. If verbs A, B, C and D are accessed according to a system, and the player knows how to access A, B and C, he should be able to figure out how to use D as well.
If I know that a specific weapon can be equipped by pressing 1 and another one by pressing 2, it is intuitive to try pressing 3 when I get a third weapon. After having fixed several broken down generators that all emitted specific smoke and spark effects, I’ll probably try the same button when I encounter a broken down car that emits the very same effects.
What are the functions of the available verbs, and what are the possible consequences of using them? Make sure that you give the player clear feedback when using a verb, both to communicate that the game recognized the action and to inform the player of the action’s consequences. Even if the real results of a verb is long term, ensure that there is some immediate feedback so that it’s understood that the input was registered.
Sound, effects, text, animation, AI and other systematic responses are all good methods for displaying the effects of a used verb.
Sometimes there are verbs that are quite similar but have some important differences. In these cases, make sure that the feedback differs enough to make the verbs feel unique – and see to it that the feedback is designed in ways helping the player understand where the difference lies.
When is a verb available and when it is not? Certain verbs are only available in certain contexts or locations, and you need to make sure that the player understands when they’re available or unavailable, and preferably the contextual difference enabling or disabling them.
Your best tool is again a systematic approach to create mental models. If If I have learned that all doors with a yellow frame can be opened, the first time I encounter a window framed by a yellow list I am likely to try to open it. I am also likely to ignore windows lacking that yellow list.
So the player knows the verbs, but to realize when there is good use for a specific verb you need to be clear about the gameplay challenge ahead. If the challenge is especially responsive to certain verbs, make sure it communicates that in an effective way. Discovering or figuring out how to solve a gameplay challenge with the available verbs is a common and often entertaining challenge, but there are some guidelines how you should communicate the challenge.
Firstly, make sure there’s a “hook” or a “tell”, something that informs the player that there is something here to connect a verb to. Think of the blinking weak points of the classic shoot-em-up boss battles or the empty space that breaks the horizontal lines in Tetris. Something that stands out from the noise, shouting “hey, I’m interesting somehow”.
Secondly, make sure it’s consistent with the title’s internal logic (the one the verbs should already follow) and that its logical nature is signposted, so that the challenge is something the player can grasp through reason based on the information he has learned from the game.
Thirdly, think “systems” when creating gameplay challenges. A game is a player mastering a number of systems over time, and if you base your challenge on a system the player has been exposed to numerous times, she has a better chance of understanding it because she has created a mental model in which to place the challenge.
Whatever you do, don’t make it arbitrary or random. Challenge through obscurity is not gameplay.
Communication player choice
The truth is that most games do not have a lot of player choice beyond the basic, immediate and physical gameplay (with simple, short term choices like what weapon you use, if you use cover, if you try to strafe away from rockets, etc.). If you work on one of those games, and you have a mere handful of instances where the player have deeper, meaningful choices – make sure the player is fully aware of the choice whenever it appears. Don’t let it go to waste by drowning in an inferno of information. Make them realize that the choice is there, and that it has serious consequences.
How to best tell a story in a game is well beyond this text. What I do want to say is that when it comes to story resulting in player objectives, clarity is key. Don’t be vague. Do what you can to get the player to understand the following:
- What his current objectives are. Whenever a new objective is recieved or an old one is resolved, pull no stops to be certain that the player got it, that he knows that a change occured and what it means.
- What is necessary to solve them. Is it necessary to do or acquire X and Y before attempting to solve Z, then the player should be informed of these requirements and what they consist of.
- How to reach them. Help the player navigate to the solution of the objective.
Helping the player reach her objectives in a 3D environment is one of our biggest challenges. This is because each area is unique, and because balancing between the two terrible worlds of confusion and linearity is a continous walk on a razor’s edge. You don’t want the player to be frustrated because he is lost, and you don’t want the player to be frustrated because he’s being hand held.
You need to guide the player towards her current goal effectively, preferably with an invisible hand. If you’re leading with waypoints, voice messages, lighting, hint coloring or content breadcrumbs is up to your taste, the target audience and the tone of the game – but whatever you do, do not underestimate how difficult and important this is. It is easy to believe that your level is easy to navigate, but you’re wrong. You’re just wrong. Players will get lost and frustrated, and you will only realize this when you see players testing your content for the first time.
Even very experienced designers are continuosly surprised over how players manage to get lost in their “perfectly” tuned levels. Don’t mistake the players’ confusion for exploration. Challenge through obscurity is not gameplay indeed.
A common notion is that if you provide too much information to the player she will end up feeling like you’re holding her hand. We’ve all played games where we have felt this and grown frustrated by it – it is a serious problem and a matter to be handled delicately. But the truth is that it’s not the the amount of information communicated but how it is communicated. You can be clear but subtle. A steady hand that cannot be felt.
You must become the player’s invisible guide.