Gamasutra: The Art & Business of Making Gamesspacer
Action Adventure Level Design: Kung Fu Zombie Killer
View All     RSS
August 22, 2017
arrowPress Releases
August 22, 2017
Games Press
View All     RSS






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Action Adventure Level Design: Kung Fu Zombie Killer

May 7, 2010 Article Start Page 1 of 5 Next
 

[This is the second part of a three-part series of articles by veteran designer and Lara Croft/Tomb Raider creator Toby Gard, dealing with level design in action adventure games. Part 1 described Level Flow Diagrams, which act as the core of the level brief provided to a team by the leads. Part 2 describes a process of expanding that brief into a detailed level plan of the awesomely named Kung Fu Zombie Killer.]

This stage of the process is most often carried out by a cross-discipline team of designers, artists and coders, who will expand the level brief into a detailed level plan, but this process can equally be the next step that an individual designer takes when designing a level solo.

A Note on Collaboration

Delegation and teamwork are vital given the scale of modern console development. Without them, leads become bottlenecks that slow development and sap motivation.

The current trend is towards agile development whereby scrums are given ownership of individual problems. This has many advantages over the old waterfall methodology, but there is one pitfall to watch out for with peer-only teams.

If a group of peers go into a room with the goal of making design decisions, the tendency won't be towards a design that everyone loves, but rather towards the design that everyone least hates.

The psychology goes this way:

1. Person X suggests a new idea that he thinks might be mint. It's not a complete idea yet, but he believes it has a kernel of goodness that could make for a unique piece of gameplay.

2. Persons Y and Z who have not seen anything like this idea before quickly point out all the flaws in the idea.

3. Person X, whose idea still needs nurturing, responds defensively, firing off hastily-thought out solutions that people also don't like.

4. The idea is shut down and the group moves on. If person X brings it up again, people are going to think he is beating a dead horse.

5. Next, Person Y suggests something that he has seen in a game before.

6. Person X and Z both remember that being pretty mint in that other game, and they know it can be done, which means low risk.

7. Everyone feels good as they write the tired, overused mechanic/scenario up on the whiteboard.

8. Repeat.

There is little to no way to get vision from a peer-only group unless they have worked together long enough that they are all on the same wavelength.

There are two potential solves to this:

1. Separate brainstorm and decision meetings.

2. Employ a group design method I tested at Crystal Dynamics called a "The Thunderdome" (as coined by Mr. Ron Rosenburg.)

Thunderdome!

A "Thunderdome" gives each member of the level team the same deadline to propose a complete, individual solution to the entire design problem (in this case a paper map.) Once that (tight) deadline is up, the whole level team comes together and shows their individual solutions to their teammates, and everyone discusses the pros and cons of each one in a respectful way.

Then the team (and the lead) cherry picks the best ideas from all the proposals and merges them into a unified team plan.

This is the equivalent of forcing lateral thinking techniques in an individual. Humans naturally solve problems by brainstorming solutions until they find one that works, at which point they generally stop thinking about the problem. Lateral thinking techniques push us to go beyond that first working answer and try to find three to five more, to see if there is a better solution out there before moving on.

When each individual in a "Thunderdome" creates their own solution, I guarantee that none of them will be the same, and the group will have multiple working solutions to pick from instead of one compromise solution. Of course this is not in the agile way -- which probably makes me a heretic who must be burned or something.

Stage 2, Building Through Fiction

With the Level Flow Diagram in hand, the next stage is to fill in the details.

Architecting the level through stories

This is the time to explore the level's stories because from them, the juiciest parts of the level's design will emerge.

Regardless of the narrative of the game, each level has the potential to tell many layers of its own background story. Even an empty office has the potential to tell little stories that transform it from a dull set of plain rooms into a real place through artfully placed builder's tools, scrounged furniture, used cups, and discarded rubbish.

But the real power of level stories has nothing to do with set dressing; it is in their ability to provide you with context-relevant gameplay scenarios that the story-based method really shines.

To make the level real to the player though, first it must be real to you.

A Cautionary Aside: Gather and Study Reference

I would argue that the power to immerse the player, to absorb his attention completely, is the common attribute of the greatest and most successful games.

Gathering and studying reference is critical to creating immersion for the player. It is something that the entire team should do, not just the artists.

Everyone stores simplified constructions of reality in their mind; schemata that codify the critical features of the world around us. We use our schemata to recognize and interpret everything we experience.

We also use those same simplified representations of reality to recreate it through art. Because no two people use precisely the same critical features to build their schemata, every person's art has a unique look, filtered through the lens of their uniquely simplified representations of reality.

While schemata allow us to rapidly process the deluge of information we receive each day, they come with the cost of a blindness to data that does not fit with them. That data gets stripped away and left unprocessed. Because we rely on them constantly, we tend to trust them implicitly.

But the fact that no two people have precisely the same schemata is all the clue we should need to realize that they cannot be trusted at all.

When we are creating worlds in games, immersion is only possible for the player if we can convince the players that the space is authentic (whether stylized or not.) If the critical features on screen don't match up with the critical features of the player's schemata, then he or she will not be fooled by it.

So as game makers we must have really precise schemata to convince the widest selection of players.

When designers or artists rely on their standard schemata to judge their own creations, they are mistakenly assuming that others will judge their work using similar standards as they do. This can be particularly egregious when people from one country try to reproduce locations from another.

American dumpsters sitting in the back streets of Paris or French road signs on the streets of Chicago might seem acceptable to the developers because they do not mismatch with their very simple schemata of those distant locations, but these contextually inappropriate placements will be laughably inaccurate to people really familiar with those places.

Given that games are released worldwide, it is difficult to overestimate the damage to audience immersion and perception done by poorly researched levels for a large percentage of your audience. Remember, it's your worldwide reputation on the line.


Article Start Page 1 of 5 Next

Related Jobs

Wargaming America, Inc.
Wargaming America, Inc. — Emeryville, California, United States
[08.21.17]

Community Manager
Respawn Entertainment
Respawn Entertainment — Los Angeles, California, United States
[08.17.17]

Executive Producer
NBCUniversal
NBCUniversal — Glendale, California, United States
[08.17.17]

Coordinator, Games & Digital Platforms
NBCUniversal
NBCUniversal — Glendale, California, United States
[08.17.17]

Production Coordinator





Loading Comments

loader image