Level Design Document
Due: Saturday, April 15th at 11:59 pm
The level design document is one of the more controversial documents in this class.
It can be a lot of work for the designers, at a time when art asset generation is
incredibly important. Furthermore, this document has historically been very long --
longer than any of the other documents. So it became a document that people did
because they had to, not because it helped them design levels. This is not unlike the
problem the architecture specification used to have (particularly when we required
UML or full class documentation).
In recognition of this problem, we have tried to make this document more focused than
in previous years. In particular, we will only be concentrating on what was called
the intermediate level. Tutorial design is important, but we will leave
that to your in-class demonstrations. We want you to be thinking ahead, to the time
where your game gets really interesting.
In designing this document, you may wish to refer to the slides on
from class. If you have never done storyboarding for games or software
before, you also might want to review the storyboarding
in the introductory course.
Before you start, the very first thing we want in this document is a restatement of the team’s
design philosophy. What are you trying to accomplish with your levels? Do you want this
to feel like an action game or more like a puzzle game? Should there be a feeling of
tension or should the player be relaxed. Is exploration encouraged, or do you want to
reward optimal behavior?
You have plenty of experience with design philosophies by now. This is just more of the
same, except that it should be focused on your desires for level design instead of just
game mechanics. Just give us 2-3 paragraphs. The purpose of this initial section is to
give us criteria that we can use to judge the rest of the document.
After the initial design philosophy, we are looking for three things:
It is acceptable to make each one of these its own high level section. However, if the team thinks
it has a better way of organizing the document, we will take that into consideration.
Maybe your team will define the format for future semesters!
A basic pattern is what Walker called a "building block" in
lecture. It is a
single mechanic/challenge pairing that represents a something that the player must
overcome to solve the level. It is not the entire level, but only part of the level.
Most levels are a sequence of basic patterns (and composite patterns).
But either way, the key to level design is understanding the game’s building blocks.
For example, consider the following storyboard from the
2014 game Beck & Chuck.
In this picture, the player has to make it past a missile launcher. The missile launcher
is placed at a choke point, restricting the player's maneuverability. So the player must
either destroy the launcher or time any actions very carefully.
In this section list several basic patterns for the game (at least three).
For each pattern, provide a single storyboard illustrating the challenge and
an an accompanying paragraph describing the pattern.
We have some examples of basic patterns in the examples below.
Think about level
design in games that you have played and take inspiration from that, rather than looking at a document for a game you
have never seen before. Many of your favorite genres have well-established patterns.
Here are a few examples, to help your team think of design possibilities.
High-Precision Jump: In a high-precision jump, the gap between two platforms is
so large that you must make a running jump just as you reach the end of the first platform.
If you jump too early, or stop running before you make the jump, you will not clear the
distance. If you jump too late, you will fall off the first platform.
Moving Platforms: The moving platform is a variation on the high-precision jump.
The platform you need to read is moving back-and-forth (or up-and-down). You need to
time your jump so that the platform is close enough to your current platform in order to
clear the distance.
Mobile Hazards: Monsters and platforms rarely chase you. The just go back-and-forth
and block your way. Furthermore, Goomba-stomping aside, most monsters in platformers are
to be avoided. The challenge is to time your jump to make it over the moving monster
Cover: In a stealth game, guards typically cannot see you while you are behind
walls, crates or other obstructions. You therefore need to move quickly from cover
to cover, so that you are never seen by the guards.
Patrol Patterns: A patrol pattern loop that the guards make about the level (or
part of the level). To move about the level, you learn this pattern, and take advantage
of it to keep your player actively out of the line of sight of the guards.
Campers: A camper is a guard that never moves, and is blocking a location that
you need to reach. You must either disable or distract this guard using an appropriate
Cover: As the name implies, cover shooters also use cover as a design pattern.
While enemies can see you behind cover, they cannot hit you with weapons. Of course, you
cannot hit them while in cover either. The challenge in these game is to come out of
cover at just the right time to hit another enemy.
Covering Fire: As we said above, you have to come out of cover to hit an enemy.
Covering fire is a constant stream of fire from the enemy that forces you to remain in
cover. If you are out of cover for too long, you will be hit and die.
Cover Busters: A cover buster is an enemy whose whole purpose is to get you out
of cover. A classic technique is to throw a grenade at your current location. The grenade
can circumvent cover, and you are given limited time to move away from cover before the
As we said above, a level is often a sequence of patterns. However, the most interesting
levels are those in which the player has to overcome challenges in parallel instead
of just in sequence. This is the definition of a composite pattern: two or more basic
patterns combined together so that the player must overcome them simultaneously.
A good composite pattern should be more than the sum of its parts. Just as we like to
see emergent gameplay when we combine player mechanics, we would like for their to be
an emergent challenge that can only occur when the challenges are combined
In this section, teams should come up with at least one composite pattern. Once
again storyboard the challenge. In addition, include a paragraph or more describing
the pattern. This paragraph should clearly indicate the basic patterns that make up
the composite pattern. In addition, explain the emergent challenge, bringing attention to what is
new about this challenge, created by combining the basic patterns together.
This might seem a little abstract, and it is hard to fully describe without seeing it
in a document with the appropriate basic patterns. See the first few
examples below, most notably Aphelion and
Squeak & Swipe. However, what we want is very straightforward if you think
about how this works in other games.
Forced Jump: In a forced jump, the player must overcome one of the jump challenges.
This can be either a moving platform or a high-precision jump. However, the current
platform also has a mobile hazard on it. The mobile hazard forces you to jump to avoid it.
The emergent challenge is that this forced jump causes you to lose the momentum that you
need to jump to the next platform. Therefore, the jump to avoid must be to the next
platform, or you will never make it.
Phased Hazards: Many times there are more than mobile hazard at the same time.
These are simple if they are all moving at the same speed; you just need to time your
jump over each one. In a phased hazard, one of the mobile hazards is moving at a faster
speed than the other. The emergent challenge here is that timing your jump for each
hazard becomes much harder; there are two different time intervals that you must keep
track of and this can break your rhythm.
Buddy System: Stealth games typically have more than one guard in a level. The
AI for these guards may even expect to see one another, and get suspicious when they don't.
They definitely get suspicious when they see the body of another guard. The emergent
challenge here is that this can make disabling or distracting a camper that much harder.
It has to be done out of sight of any guard whose patrol pattern takes it past a camper.
Cover Peeking: While a guard cannot see through cover, it might look behind cover,
or even destroy cover that it passes by as part of its patrol pattern. The emergent
challenge here is that this puts a time limit on how long you can stay in cover. You
have to get out of poor cover before a peeking guard patrols by.
Arenas: Cover shooters often have an arena layout as part of their level design.
There is more than one cover location, and they are not all facing the same direction.
The emergent challenge is that this cover allows the enemy to safely get around to
your side and flank you behind cover. Like cover busters, this is a design pattern
to keep the player from "turtling.”
Covering the Busters: Covering fire makes it hazardous to move away from cover.
Cover busters through grenades (or other weapons) that make staying behind cover dangerous.
Putting the two together is obvious. The emergent challenge is to stay behind cover enough
to be safe, without staying too long that the enemy forces you out before you are ready.
Now that you have the basic patterns, create some levels. We want three levels: an
easy level, an intermediate level, and a hard level. You do not have to have all of
your design patterns in each level. The design patterns also do not have to be tuned to
exactly the same difficulty in each level. For example, in a platformer, the hard level
is often the result of taking a standard high precision jump and making it more precise.
In creating each level, the team should should storyboard it clearly. In addition,
annotate which parts of the level correspond to which design patterns. As an example
of what we are looking for, consider this annotated level from the
2014 game Dash.
If you have described your design patterns well
enough, we should be able to understand the entire level just by looking at this storyboard.
We do want some text accompanying the storyboard for each level. In this text we
want you to argue why you believe this level is easy, intermediate, or hard. But we do
not need much description of the level beyond that.
As we have said before, this version of the document is very new. We have only asked
for this level detail once, in the previous year.
But in contrast, in previous years we asked for a lot of things that we are no longer
interested in. We do not need detailed tutorial descriptions anymore. And while player
progression is important, we would rather focus on getting the intermediate levels right
before we add them back to the document.
With that said, there there were three standout documents from last year. In addition,
there were several documents from previous years that gave hints about how to create
and intermediate level. Take a look at these examples to give you an idea of how you
might design your levels.
Winner of Most Innovative (Mobile) Game in the Spring 2016 Showcase,
Squeak & Swipe does a good job at identify a large number of basic patterns.
They also clearly identify the patterns in each of their levels.
Another popular game from the Spring 2016 Showcase, Aphelion was a puzzle game
that consisted of a large number of challenging levels. They do an excellent job of
identifying complex patterns and incorporating them into their game.
Winner of Most Polished (Mobile) Game in the Spring 2016 Showcase,
Inari also does a good job at identifying basic and composite patterns. However,
we are not a fan of their sparse description for each level. Please do not use this
A mobile game from the Spring 2015 Showcase, Stack and Smash had the problem that
it was a multiplayer game with no single player content. However, they were able to
identify basic strategies and showed how to mix and match them. This is a great way to
use this document for multiplayer games.
Winner of Most Polished Game in the Spring 2014 Showcase,
does an excellent job of designing a complex level from design patterns. While you can
ignore the tutorial section, the intermediate level section is exactly what you should
be emulating. Indeed, this document was the early prototype of the current version.
Also Winner of Most Polished Game in the Spring 2014 Showcase (this time in the mobile division),
was a puzzle game with very strong level design. They clearly spend a lot of time
thinking about their design patterns, as you can tell from this document.
Winner of Most Innovative Game in the Spring 2014 Showcase (mobile division),
Over the Arctic Hills
was a puzzle game with a lot of real-time components. While they do not go into as much
detail about their building blocks, they do an excellent job of putting them together in
a single level.
The winner of the Spring 2011 Showcase,
presents its level design as a sequence of frames, with each frame focusing on a single
platform. Hence this document is one of the earliest examples of building-block design
in this class. While we never see the entire level all at once, we get an idea of how they
The audience favorite in the Spring 2014 Showcase,
has a very different level design that the other games. Instead of static obstacles, its
level design is about controlling crowd density. Once again, this is a complete design
document, but you should only focus on the intermediate level.
Strategy games are always a hard sell at Showcase, and the game
was a dark horse favorite among the TAs when we were grading afterwards. The design document
for this game is another example of how to identify design patterns when your gameplay is
unpredictable or depends on computer AI.
Due: Saturday, April 15th at 11:59 pm
You should submit a PDF file called leveldesign.pdf
containing all of the information above. We ask that the file be a PDF so that we can
annotate it in order to return it to you with feedback for possible revision. It is fine if
you create the document in a program like Microsoft Word, but you should convert it to PDF
As the prospect of revision implies, this is not the final draft of your specification.
You will have later opportunities to revise your concept. However, as with previous
revisable documents, you should take this assignment seriously.