The experienced designer and Lara Croft creator here outlines a process for designing action/adventure gameplay that will satisfy the needs of both your player and your game's story, in the first installment of a multi-part series.
[In this Gamasutra design feature, original Lara Croft/Tomb Raider creator Toby Gard here outlines a process for designing action/adventure gameplay that will satisfy the needs of both your player and your game's story, in the first installment of a multi-part series. To read Part 2 of this feature, click here.]
Different people have different approaches to delegating design responsibilities.
I have seen creative directors who seem to have no vision of their own but merely act as filters through which their team's ideas are strained.
I have also seen creative directors who form a rough image of what they want in their heads and then delegate the design to their team after loosely describing it to them. Inevitably the team then repeatedly fail to deliver his expected "right" solution.
A better approach than searching for mind-reading designers, is for the creative leads to express clearly both what they want and where the flexibility is, so that their team can know how to take ownership without getting lost in the creative wilds.
I believe that balance is achieved when an unwavering core vision is delivered to the team (based on the whole team's input and feedback) and then responsibilities are delegated with clearly defined parameters for success.
This first article describes stage 1 of a process that does just that, based on the methods that I have found the most successful.
The process attempts to balance to a healthy amount of creative freedom and ownership for a level team, while keeping a structured vision in place by defining what details are essential to work out first and communicate to the team and what parts are better to be delegated with success criteria.
The steps that the entire process describes can be just as useful for an individual designer regardless of the level of delegation expected to occur.
Since every project has its own needs and team structure, this process is unlikely to translate exactly for you. However, many of the concepts can be adapted for just about any story-centric game.
The first step in the clear communication of vision for level design is delivering the Level Flow Diagram.
There are four sources from which the high level design plan should be drawn:
Like any good scene or chapter from a book, the conflict and resolution of a level should be born from the main character's motivations. This is why the character's motivations should always be clear to the player or they will feel lost and directionless.
These motivations translate into game objectives such as "find the man who killed your lover" or more simply, "kill Boss 5 of 10". The strongest objectives are ones where character and player motivations are in alignment.
It is not enough to simply state the objective or motivation of a character if you want to create alignment. You also need to make it matter to the player if you want them to become invested in it.
For instance, showing through cutscenes that the main character hates a boss enemy, while letting the player know they must kill that boss to progress, results in a much weaker alignment than giving the player reason to hate that boss enemy.
If that boss enemy betrays the player after the player has come to trust him or if he takes something from the player (for instance by killing an NPC that the player has come to care about) then the player and the character will both have a real reason to hate him.
The time it takes to setup player motivation is why it is so hard to align player motivation and character motivation in an opening cutscene.
Often you have no choice but to state the character motivations right at the beginning, in which case the player will only have an intellectual rather than emotional alignment with him or her.
To strengthen that alignment through the game, the motivation "I want to bring my girlfriend back to life" must be completely linked to the player objective "Kill the Colossus."
If the objectives are not directly related to the motivation (for example, if you spend most of your time being waylaid by endless rat killing quests) then the player will lose sight of the meaning behind their experience and their alignment with the main character's motivation will erode along with their interest in continuing to play.
It is during this first phase of the level design that you must choose which of the powerful and interesting set pieces and emotional events that came from the whole team during preproduction brainstorms will make it into the game.
These are the high points around which you will fill in the rest of the level design. They are the moments that will define your game in the player's mind and it is crucial that they support or drive your story.
The set pieces are high-concept action-oriented ideas such as "escape the burning building" or "find and defuse the four bombs." Set pieces are the basic building blocks for an action heavy game, just as they are for action movies. The challenge is in creating set pieces that haven't been done a dozen times before.
The emotionally charged events are the heart of your game -- i.e. looking for survivors of a deserted village, only to find a shocking and disturbing answer to their fates as you enter the town hall.
Emotional events have the potential to be more memorable than a set pieces if handled well, but they too require the building of player and character alignment, which makes them harder to pull off.
The game pillars define the basic things the player can do, so to integrate the cool set pieces and emotional scenes into the level, they must be compatible with the player abilities or they will feel anachronous.
The most flexibility will come if the game pillars aren't considered final until all the Level Flow Diagrams have been completed. It is only during the process of picking the things that will actually happen to the player, that you will learn what the player abilities really ought to be and how flexibly you will need to implement them.
For instance, if the game is about a jet skiing hacker, then it would be inappropriate to build a set piece around horseback crocheting. Doing so would have to rely heavily either on cutscenes and (shudder) quicktime events or would require specific controls, interface elements and abilities.
Apart from being inefficient from a development standpoint to create new abilities for each set piece, they would be also be un-ramped for the player unless you included several such horse riding and crocheting sections, in which case those abilities should have been in the pillars in the first place.
Regardless what sort of game you are making there is a story that is almost as important to consider as the main character's; that of the level itself. Whether the player is experiencing an alien invasion, or trying to solve a murder mystery, their level of immersion is almost entirely dependent on your commitment to preserving fiction.
The most common mistake made in level design is defining a set of challenges loosely based on a manufactured set of parameters and then trying to set dress them to look like something. This inevitably results in unconvincing, bland and forgettable levels.
Despite many protestations from designers who feel shackled by a fiction-heavy approach, the reality is that when you resolve to respect the fiction of a level you inevitably find yourself designing spaces and events that surprise not just the player, but often yourself as well.
I will go into this in detail in the second stage of level development called "Building Through Fiction" but for now, all we need is the commitment to ensure that our overall level flow is being defined in a context that can be made fictionally consistent.
So no windsurfing on the moon -- however much fun that may sound.
Some people make full flow charts of their levels, but I tend to think that's excessively restrictive and not informative at all regarding basic spacial layout.
I prefer a level flow that resembles hybrid between a schematic diagram and a simple beat sheet.
The goal is not to be exhaustive, but to define the skeleton of the level; the core of it.
On average I find that at least half of the final level goals will actually be added by the team during the next stage, so it's important to keep these simple because the level will at least double in complexity from here. If you can't fit the flow on one page, then it is probably too long.
The types of elements that you would include will be different depending on the type of game you are making, but the goal is always the same; keep it simple.
In this example I used the following:
Level Stimulus
I use these to call out the player's arrival at an area. They serve as the locations on my schematic but also the critical information pieces given to player, during scripted events etc.
Player Response
The things the player does. These are generally objectives that have been clearly communicated to the player.
Locks
Locks are the "hard gates" that restrict forward progress in the level until a certain set of criteria are met. (I'm lumping "soft gates" into Player Response for the purposes of this.)
Keys
These are status changes either of the world or of the player character that will lead to opening a 'lock' somewhere.
This single page schematic actually describes two levels (one campaign) that takes about an hour to complete.
Along with this diagram you would include notes that describe the intention behind each element and directly references the four sources from which they were derived. (This is how you define the success criteria for the level team.)
Motivation
Kill the Covenant. Seeing the human fleet and the Pillar of Autumn being shredded in Campaign 1 gives the player enough animosity to last for a game's worth of Covenant killing.
Pillars
This would include the focus on introducing the player their first experience with the three-man driving / gunning Warthog gameplay, and the cooperation with AI troops.
Themes
Referencing films and other games is a good way to quickly communicate theme. Starship Troopers might be a good example to evoke the feeling of soldiers being overwhelmed by an alien enemy on an alien world.
Fiction
The level is teaming with touches that infer a great deal about both the larger story and the smaller scale individual stories of the ongoing war:
Destroyed escape pods and the bodies of those that did not survive the landing litter the landscape, while debris from the space battle overhead fall through the sky. Each of the pod crash sites suggests the short desperate survival stories of the soldiers Master Chief meets there.
Once a Level Flow Diagram is done, you are still a long way from moving onto the next stage, the handoff to the team.
To evaluate a Level Flow Diagram you need to have done the whole game's worth. Only when they are all side by side can you can see how well they fit with each other and how the ebb and flow of gameplay will move from the start to the end of the game.
Put them all up on a wall, and you will see where the player is being sidetracked, where a different order of events would make for a better rhythm and where emotional events are happening too early in a game for player and character alignment to have occurred.
The secret to making a great story based game is to make the actions of the player be the engine that drives the story, not the other way around.
Ico and Shadow of the Colossus are among the most successful stories in video games, yet many say the story elements were minimal. That's not true. The story was everywhere, because the player lives it.
Ico was about escape and protection. Every time you managed to coax Yorda closer to escaping from the castle, the story of your struggle for freedom progressed. In Shadow of the Colossus, throughout the game the hero slowly sacrifices not just his own life but the lives of each colossi, in his mad quest to resurrect his love.
Protecting a girl and Killing Colossi. The player actions are shaping the story taking the burden off the cutscenes and making the story matter to the player.
Level Flow Diagrams are the first key communication of Level Design intent to the team.
Build Level Flow Diagrams from:
Character motivations
Emotional and experiential set pieces
Player actions as defined in the game pillars
The environment's own fiction
Use minimal elements to draw the diagram, and represent only the main events.
Keep it to one page.
Ensure you are driving story through player action.
Note:
I am in no way suggesting that Halo levels were developed using a method that bears any resemblance to this process.
I have no idea how Bungie goes about its level building process. I used this Halo level as an example because it was both well-designed and well-known.
[To read Part 2 of this three-part feature, click here.]
Read more about:
FeaturesYou May Also Like
