Thoughts on level design
Part 1: From the idea to the blueprint.
Introduction
I designed my first level on my good old Commodore Plus/4 around 1993. I was trying to give myself more lives in Scramble, when I accidentally found the memory address where the first level was stored. I started messing around with it and randomly changed the layout. Then I made a list of what graphical element a byte meant, and I planned my first map on a grid sheet. In practice the map was unplayable, and eventually I got bored of typing bytes into the memory, but this experience started me on the road of game development. Since then I've learned much and now I'd like to share my current (ever evolving) level design workflow.
I.) First steps
Before the planning could be started a few things should be clarified:
- What is the role of the map? How does it fit to the flow of the whole game?
Although level designers work on a small, well defined part of the game, they must see the big picture: the story, the dramatic curve, and most importantly the level's relation to neighbouring levels (assigned to other LDs). With a few exceptions, levels can not be created as independent and isolated systems. A good design document is very important, but even that is not a subsitute for an in depth discussion with the game designer. Proper communication between fellow LDs helps to keep the levels more or less consistent.
- What game elements should and should not be used?
The story and the game progression chart probably gives you a definite answer. (If in doubt, always ask the game designer. They love the attention. :) I usually make a list of the game elements I can use, so I can focus on the building blocks I have.
- How long should it take for an average player to finish the map?
In the past on several occasion I ended up creating maps way bigger than it was necessary. They had to be cut, so I wasted time and effort. But that taught me to pay attention to the length of the map. Although it is hard to define how an "average player" would perform, but with a few educated guesses, you can't be off that much. A good starting point might be looking at the classics of the relevant genre. How long did it take to beat a map or mission in Super Mario 64 or Deus Ex? Are there check points or does the game use quicksaves? I think generally a shorter session with substance is better than a longer but attenuated one.
- What is the theme of the map? What mood and look should be archieved?
Usually when the level design work starts there are only a few if any art assets available. Yet the general look of the map should be defined early on, so when the LD builds the map using gray boxes and other standin assets, she/he can see a much richer environment with the mind's eye. Having a (shared!) vision of the final look will subconsiously affect the whole map building process.
- What is the deadline for the job?
I'm a devotee of progressive level design. It makes the task very scalable, therefore life easier even with close deadlines. The basic idea is that the map should always be in a state that it's playable from start to finish. Even if it has no enemies and only empty box rooms. It's all about refining stuff, and when you run out of time then you automatically have a working map for submission. No need to hack stuff in a hurry during the night before the deadline, just to make it work somehow. Knowing how long one have for the job helps prioratizing the tasks, so with some common sense the job can be done very efficiently.
Of course many more questions can be (and should be) asked, but these are the most important ones I think. The game designer/project manager should be able to answer them. These initial parameters are the cornerstones of the map, we build the map around them.
II.) The first sketch
After we read the design documentation many times, we're familiar with the game mechanics involved. I use to make the list of gameplay elements mentioned above, sit down with pen and paper, trying to figure out interesting ways to combine them together. One way or another, the first version is in our minds. It is time for the first sketch. For that I usually use a 2D vector drawing program (like Inkscape), but if visibility, Z axis fight or 3d map topology is especially important, I use a 3D package (like SketchUp) to quickly sculpt a version. Now let's see the former case, using a map from MetaBall2 as an example.
The first version is a quick, clean overview of the area. Reference photos and concept drawings are provided to give the feel of the environment. A short explanation is useful to help the viewer understand the somewhat minimalist artistic
design:
"The gray areas show surface height. Lighter is higher.
The lake is blue, the cyan part is shallow water." ...and so on.
Then comes the real stuff. Things can get crowded easily, so don't try to push all relevant information into one view. Use multiple layers to separate different aspects of the gameplay, so you can easily turn off unnecessary info. The letters and numbers mark special places, which are described in the walkthrough document, accompanying the blueprint. Here is an excerpt: (Spoiler warning! :)
"To enter the closed cavern (3.) the player must be in an IronBall and use the C8 cannon to launch herself and destroy the barricade at the entrance. The Balltar with the Ironball (B:I) is located near the C7 cannon. That cannon can not fire the player up to the plateau directly, but if the cliff is targeted (4.) the player's ball will bounce back of it, thus accessing that area."
After this first version comes the hammering part where a fellow LD or a game designer is asked to find as many problems as she/he could in the map. Pointless areas, dodgy solutions, boring encounters, everything should be pointed out. More (and fresh) eyes see more. Potential weaknesses must be addressed, even if it hurts. For many it's a difficult process, as they count these critics as attacks toward their personal and/or professional skills. Forget ego, it's not about you, it's about the map. A bad idea is a bad idea, even if your best friend came up with it. (Similarly, a good idea is good even if it comes from an arrogant idiot.)
It is very important to communicate clearly your reasons for doing things. The devil's advocate sitting at the other side of the table will understand them, as her/his goal is the same as yours: to make the game fun, solutions logical, systems rock solid.
Give only constructive critics, and consider constructive critics only.
In the next iteration we deal with the issues, incorporate good advices and check things again, until everyone is confident that it will work.
Experimentation is important, especially if you have an unorthodox idea. With todays advanced editor framworks, many new gameplay ideas can be prototyped without involving coders or artists. If you can show a more or less working version of your great yo-yo based fruit catcher minigame to the others, you have a better chance to convince them that is fun. (If it is fun. You'll realize if not, and save time for everyone involved.)
Companies are often reluctant to give you time to experiment with new stuff, they rather go on the tried and proven path. But don't be discouraged by that. Take the initiative and put a few extra hours from your free time to discover new possibilities. On the long run, it will be beneficial for the game, and therefore for you.
This concludes part one. In part two we'll look at the challenges of the implementation of the plans.
Zoltan Erdôkövy, 2007-04-14