Communication Lab 9
Level Design (Building Blocks)
Due: Saturday, April 1st at 11:59 pm
The focus of today's lab is to start thinking about your level design. In the past, we
had students make a level design document in order to make their level ideas concrete.
However, you already have a lot of work to do in this class, and this document was heavy
on the designer just when you need art assets for your game. Therefore, we have demoted
the level design to (two) communication labs this semester.
The main thing you are to do in this lab is to brainstorm building-blocks
for your level design. We ask that someone take notes or sketch these ideas while the
lab is ongoing. At the end of the lab please scan the notes, or take a phone picture,
and submit them to CMS.
While this is going on, the TAs will be circling the room and occassionally giving their
own feedback on your discussion. If anything is unclear about this assignment, or the
document in general, please ask them. They have been through this process before (some
of the TAs have done this multiple times).
A building block is a mechanic/challenge pairing that represents a single
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 building blocks. Sometimes,
building blocks are put on top of each other so the player must overcome them simultaneously.
But either way, the key to level design is understanding your building blocks.
To give you an idea of what we mean, 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 players maneuverability. So the player must
either destroy the launcher or time his/her actions very carefully.
When building blocks appear in a lot of games, they get called a design pattern.
Many of your favorite genres are defined by their design patterns. Here are a few
The classic design pattern for a platformer is the 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. Jump to early (or stop running before you make the jump) and you
will not clear the distance. Jump to late and you fall off the first platformer.
Another design pattern are monsters and mobile hazards. 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.
When you combine these design patterns together, you get a particularly insidious
challenge. You have to jump just at the right time to make it across, but avoiding
the monster may cause you to jump to early or break your timing.
The basic design pattern in a stealth game is cover. Guards 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.
Stealth games also have patrol patterns. This is a loop that the guards make 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.
Good stealth games combine these two patterns together in a single level. You move to
cover to keep from being seen. It is only safe to come out of cover when the guard moves
away from the open space between you and the next cover position.
As the name implied, cover shooters also use cover as a design pattern. While enemies can
see you behind cover, they cannot hit you with weapons either. Of course you cannot hit them
while in cover either. So the challenge is to come out of cover at just the right time
to hit another enemy.
Cover shooters often have an arena layout as part of their level design. This is a design
pattern to keep the player from "turtling". Cover only protects you from one side, and in
an arena, and enemy can flank you behind the cover. So these two design patterns combine
to force the player to move about the arena.
Creating your own Building Blocks
We want you to spend this lab time coming up with building blocks for your own game. We
do not want complete levels; we want simple challenges (or pairing of challenges) that
you will later use to build your levels. A good indication of whether a challenge is a
building block is if you can sketch it in a single storyboard frame.
To give you some idea of what we are looking for, here are some building-blocks from
semesters past, when we still had the level design document.
Winner of Most Polished Game in the Spring 2014 Showcase,
does an excellent job of designing a complex level from building blocks. While this is
a complete design document, including tutorial levels, you should focus on the intermediate
level. Notice how they isolate each challenge and then chain them together to make an
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.
The winner of the Spring 2011 Showcase,
presents its level design as a sequence of frames, with each frame focusing on a single
platform. While we never see the entire level all at once, we get an idea of how they
The winner of the Winter 2011 Showcase, this document from
is a sketch of several short level ideas. While there is no single level that puts all of
them togehther, this document does a good job of illustrating the design style.
Due: Saturday, April 1st at 11:59 pm
Level design is an iterative process, and we would like to give you some feedback
early on in the process. There is no official document for level design, so this is
the only time you will get any feedback from us outside of your milestone demonstrations.
As with all communication labs, limit yourself to the work that you do in the lab.
We do not want you working on this lab outside of class; you have too much other work
to do, particularly with your alpha release. Someone should take notes during lab.
Scan these notes or take a phone picture. Submit these notes as
design (it can be any format) in CMS.
You only need to submit this file once for the entire group.
You will notice that the deadline for submission is later in the week. That is because
we want one submission for both this communication lab and the next.