Singleplayer level design workflow

Introduction

In this article I will show you how I work when designing singleplayer levels. It's a list of the major steps of the design, from initial concept all the way to finished level. During the article, I'll use my level 'Whoopservatory' as an example.

This article is not meant to explain how to actually design a singleplayer level, but more about how to structure your work so that you don't get bogged down in the details and lose track of the big picture.

Let's get started!

1.Ideas

Let's say you want to create a level set in an observatory. Your initial vision of the level consists of impressive architecture and the observatory domes creating cool silhouettes against the sky. Maybe you've seen a picture of such as place that triggered your imagination to want to create this level. Now before you dive into your level editor of choice, you should sit down and write a list of all the cool things you can come up with in such a setting. Don't let the setting limit you in any way, if you have a good idea for a gameplay scenario or cool event it can often be molded to fit whatever environment you are creating. Once you've written an idea down, it's easier to let it evolve and develop.

Collect pictures of the type of environment you want to create, anything which you can find inspiration in. Once you feel that you're well prepared, it's time to move on to the next step.

2.Walkthrough

Sit down and write the walkthrough of the level, from start to finish. This document won't necessarily dictate how the level will play out in its final version, it's more to work on the structure of the level and get a mental image of how it will play out. While working on the walkthrough, revisit the idea document and pick out the ideas you feel strongly about. Write the level so that these pieces fit into the level seamlessly, not just an afterthought thrown in towards the end.

Once you have a complete walkthrough it's finally time to start working on it properly. Again, don't feel restricted by the walkthrough in any way once you build the level. Indeed, not every part of the level needs to be documented, a lot of solutions/stalemates tend to be resolved once you can actually run around in an environment. Also, don't get caught up on this step, let the walkthrough simmer in the back of your head and revisit it whenever you have something you want to add or tweak. Changing something in text is a lot less time-consuming than redoing parts of the level itself.

I like to stick to a written walkthrough, since doing sketches of floorplans and such are so prone to change that it's more or less a waste of time. It might look good on paper, but it more often than not feels completely different once you see it from the view of the player.

3.Prototyping

Finally it's time to start building stuff. Your favorite ideas, those that you chose to commit to and write into the walkthrough, pick these up and try to implement them in test maps. Stick with greybox architecture and content if possible, just get something playable up and see how it feels.

Once you've got something playable, have someone try them out, preferably without any interference from you ("Go left here! No, the other left!"). If any problems arise (a puzzle is hard to understand, a combat encounter is unbalanced etc.), tweak the prototype and have it tested again. Don't think that problems will solve themselves once you add pretty graphics and lighting, if anything the problem will be amplified and you're stuck with something you are unhappy with.

If one of your ideas turn out to be a dud then don't be afraid to discard it. Maybe pick another idea to replace it, and repeat the process of prototyping and testing it. Update your walkthrough to reflect the change, and proceed with the level.

4.Outline

Now we've prototyped and tested our ideas, and we have a more or less complete walkthrough which gives us a great mental image of how the level will play. It's finally time to put it to the ultimate test, which is to create a mockup of the level from start to finish. This will let us run through it and get a feel for how it will actually play. Keep this step as simple as possible, since you will most likely be changing things quite a bit once you see how everything works.

Don't follow the walkthrough blindly. If it only looked good on paper but never in the game world then it's probably a good idea to change it up. For the most part you can skip trying to implement your idea-prototypes into this outline, since they will just complicate the pipeline when you want to make changes to the layout. However, give the ideas the physical space they need, since this is the initial layout and the proper level will have to fit into it once you start building it.

Try to get something playable up in this stage as soon as possible, so that you can run through the level from start to finish. The blockier the better since it will be easier to iterate on. Once you can play it, use your imagination to see how the finished level will be. You can also drop in cannonfodder enemies in the combat areas but don't spend much time scripting them, just use them as roadblocks to give you a feel for the pacing. During this step you can also start to get a sense of possible optimization and performance problems. Try to get these things under control as soon as possible, since time spent at this stage will be saved tenfold once you start putting in the pretty stuff.

5.Playable

Now that we have a layout which feels comfortable, we can start molding it into something more recognizable. Replace the big block architecture with geometry more representative of what we want to achieve in the final version, play around with basic lighting (environment light and simple lightsources to get a feel for the space of the level and help with player guidance), and add basic combat scripting to the encounters.

Now we should also have some pretty well-developed versions of the idea-prototypes ready to be implemented, so move these into the level as well. The goal at the end of this stage is to play a rough but complete version of the level from start to finish. Start laying the foundation of the scripting, although larger purely cosmetic things can still be left as debug-text or other clever placeholder items. Once you've got something that you think is representative of the level, it's once again time to send it out to your playtesters. Again, if at all possible, observe the testers playing the level, since the player should be able to successfully navigate through the level without getting frustrated or lost.

Don't worry if the initial wave of feedback comes back with problems. It's still relatively painless to make changes to the layout and shuffle around events and the turnaround time to do so is short, so you can get quick feedback on your changes. Continue iterating at this stage for a while, until you've got a level that you are happy with. As playtesters seem content with a section of the level it can be okay to go ahead and further develop it, while at the same time fixing and further iterating on other areas of the level.

6.Polish

The Playable stage flows into this stage, since you are often getting feedback on the level. If you've made the right decisions based on the feedback, the feedback you get back should be more and more nitpicky, which means that the level overall plays well.

You can start adding proper graphics and getting proper scripting in, and just generally start polishing the level. I like to create a texture and model palette during this stage, which will be used as a base for the level. Be aware that following this palette too strictly will create a very uniform look which might be potentially disorienting. Don't be afraid to change up areas and break your own art-rules just to create somethign that will stick in the players mind. For many this is the most fun stage, since you finally get cut loose and can give the level the attention it deserves.

Remember to keep your testers in the loop to make sure that the level is developing in the right direction. Also, don't sacrifice gameplay strictly for graphics. If there's something you absolutely can't live without, then atleast make every effort to compromise the gameplay into it so that a whole gameplay scenario isn't completely butchered just to get another vista or landmark in.

7.Tweaking

Now you are sitting on a level which if it were released at this stage would most likely be well received and play quite nicely. However, spending some extra time further tweaking it can make all the difference. What I like to do is to play a fresh version of the level, while sitting with pen and paper and writing down anything which I think should be tweaked. This can vary from script timings to a graphically boring corner. These fix-lists are often quite long, but each item is usually a 10-20 second fix which will make an actual impact. Write up anything you feel should be tweaked, don't be afraid to make mistakes since it's easy to revert back.

You are probably quite sick of the level at this point and you're looking at it with tired eyes. Don't fall for the trap of re-designing whole parts of the level just because you've gotten sick of it. A player will most likely only see the scenario once, whereas you've seen it 100+ times. Try to remember the feeling you had when you played the scenario for the first time, and trust your playtesters.

That about wraps up this article about singleplayer level design workflow. I hope you have enjoyed reading it. If you want to contact me with comments or questions I can be reached at magnar.jenssen@gmail.com

Thanks for reading!

Return home.