CS/INFO 3152: Introduction to Computer Game Development

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).


Building Blocks

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.

block-chuck

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 examples:

Platformers

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.

Stealth Games

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.

Cover Shooters

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.

Dash

Winner of Most Polished Game in the Spring 2014 Showcase, Dash 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 interesting level.

Black Friday

The audience favorite in the Spring 2014 Showcase, Black Friday 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.

Blush

The winner of the Spring 2011 Showcase, Blush 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 fit together.

Reflexio

The winner of the Winter 2011 Showcase, this document from Reflexio 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.


Submission

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.