The Level Design Document

How much is too much?

4 years ago, when the only thing Unreal to me was how my MP3 player could hold more than 20 songs at a time, I have struggled to understand the concept of a level design document. To this day, after 2 degrees and a handful of industry design documents, I still do not fully understand what a level design document should contain, and whatever information is found between the Red Bull stained pages, how much detail should be included?

Design after design has had either too much or too little information and I'm starting to lose faith that there is a middle ground of hope in this minefield of the term "flow". If there is, please, throw me a metal detector. Now of course there are two sides to this story, isn't there always? So I'll start by dissecting to the two and giving each side a chance to weigh up the pros and cons battle. Firstly, we'll start with what information I think should always be included in a level design document.

Where is the game?

A wise man (A myth from the UCLAN game design studio) nailed this phrase home every time a 'know it all' second year handed him a game design which failed to include a game. We've all fell into this unforgiving trap of thinking a quick top down sketch of a potential level passes as a level design. We are wrong to think this and therefore get snagged in the trap until the wise man comes along with his plastic sword and goatee (are you painting a picture yet?) and rescues you from the zone of 40%. Analogies aside, this is a very dangerous thing for a designer to do when designing a level. First things first we need to establish what happens in the level. What are the epic moments? Does this happen in any other levels? If people say "the level where that badass thing catapults you off the ground into the tower thing where you kill 100 demons before somersaulting into a bed of straw", will people know that was your level? Start by compiling a list of key events, things that are unique and awesome to your level. This will give you a good foundation to start your design. So where is the game? If you do not know what happens in your level then find out before you start putting portholes to hell into Spyro the Dragon.

Pace yourself

Pacing is important, even your girlfriend will vouch for that. Once you have the 'key events' list sorted your now ready to tackle the design. I would still suggest laying off the graphics tablet, mouse or indeed pencil if anyone can remember what those led based instruments are until you have thought about the pacing of your level. Too many designers brush over this as if it was an insignificant crack on the windscreen with the mentality "no one will notice". We will notice, and your level will transform into a sponge for fun, soaking up gameplay left right and centre. A way around this can be one of two ways, two of two for all you eager game designers. A time pacing chart, such as the one shown below, can give instant visual feedback about exactly what is happening in your level and the intensity these events are going to provide. Now, for all you mathematicians out there, this is not an exact formula, but it works. It allows you to think "oh, there's too much jumping in this section, if I save it for a later part of my level it will break up repetitious game play and add variation " in which case you can pat yourself on the back and grab a cold beer, preferably not in the workplace, of course. Pacing is everything and using a core set of mechanics multiple times but in varied ways is the secret to good level design.

Dad jokes can only get you so far

Another way to pace a level was, as far as I'm aware, invented by Wise Man number 2 (not in hierarchy for disclaimer reasons) . This method works in second year games design at the University of Central Lancashire, and continues to work once you've thrown your cap into the air never to be seen again. Games can become complex pretty quickly and if you don't keep tabs on what the player is doing in each section, pacing can pick up momentum and before you know it pass GO picking up £200 for the trouble and turning your title from 'Game of the year' into another Dynasty Warriors. A way to avoid this is to create a list of your core mechanics. This, for most genres of games will include jumping, running, walking, triple back flip into a plie whilst counting backwards from 100, you get the idea. You then create a list of secondary mechanics, these are things that may be specific to your level, say you have an underwater section where the player is pulling triggers, that would be included here. And thirdly, you include Events. These are things that we have mentioned previously, if something badass happens, write it in this column, if not, then rethink your design.

Once you've compiled your lists, hopefully not leaving the chubby kid until last, you can then start to turn it into some kind of flow. Number your core mechanics 1-50,000 or however many you have, and give your secondary mechanics A, B, C values and use mandarin when out of the English language, game designers dig that.

Now comes the tricky part, you need to walk through your level in your head thinking about what the player is going to be doing in the different areas of your level. This is more of a visual tool so I've decided to paint a picture with a 1000words, see the badly drawn image below. Adding a time scale value for how long you think each section is going to take is a good indicator for how many minutes of gameplay your level will consist of.

It is completely up to you which method you use to pace your level, you may even have your own way of achieving similar results. But in all cases you must think about the pacing of your level otherwise players will get board very quickly and instead load up Call of Duty in their vertical disk trays when they have 5 minutes to spare.

In a similar way to a beginners attempt at a level pacing, my word count got pulled out from underneath my caffeine fuelled fingers and I lost track of time. I will use this eagerness as a badly placed cliff-hanger and write about the 'detailed'  side to a level design document in Part II, hopefully being posted in the near future.

 I hope that people find this interesting as I feel there are a lot of useful tips in there that I use when creating level designs and hope you feel the same.

Identifying game play

As all of my blogs seem to have only included the contextual side of the course i thought I'd add some of my own research about identifying game play and what tools can be used in describing the patterns that emerge.


Patterns in Game Design

A formal definition to describe a pattern would be a reoccurring part(s) that directly affect game play.

Game design is more difficult to define than most other design subjects because of the simple reason that games are artificial objects rather than natural ones. They are also entirely designed by humans which makes the process of creating a game with immersive and exciting game play difficult to understand. Designing interaction is they key to creating game play. No other medium provides interaction like videogames. If people are able to interact with a game successfully then game play is born. Most aspects of creating games are predictable, using the same engines along with the same formalized modeling and textures techniques. However, that is just the surface of game design and we explore the subject more it becomes clear that there are a lot of elements to a game that are impossible to anticipate.

As a core rule, if you think of game design as interaction design, the process becomes much clearer, the interaction being the usability between humans and computers. The three main areas to identify when looking at patterns in game design are the creation of patterns from problems, following on patterns and editing patterns. When creating a pattern from a problem the designer can identify a core issue that is wrong with the design, however this technique used on its own only removes the unwanted effect and does not tackle what the design is trying to achieve. Using following on patterns can be applied to multiple patterns when a certain pattern does not work when confined on its own. Editing Patterns can be useful when a designer wishes to introduce, remove or modifying existing game play however the designer has to be careful when using this tool because if a pattern is edited too much then it may completely alter the feel of the game play.

If so many potential problems can be caused by the three main areas of pattern design why do designers still use these techniques? The reason we use these tools is because patterns in design do offer a good model for how to structure knowledge about game play that can be used in the design and analysis stages. The key is not to isolate elements but bring together many different techniques in order to get the desired effect.

Semi-Formal descriptions are what patterns rely on for a general description of a specific area of game play without using quantitative measures. This could include anything from open doors, jumping, navigating levels, anything that is directly affecting the game play of the game is given a semi-formal description. The reason why designers do not use quantitative measures is because they are too precise for solving ill-defined problems of design. The presence or effect of design cannot be measured and for this reason it is an impossible technique to implement. However patterns do have a structure and relationships that can be identified. This therefore leads to patterns a semi-formalised concept to be applied to their intended use.

After looking at semi-formal descriptions the designers then move onto interrelated descriptions which means that all the patterns can somehow all be related in someway. Although it is common that some relationships are more popular than others depending on the game type. The 5 main relationship types that emerge, the first one being instantiates which applies to a scenario has an existing pattern and then causes the next to be present after that. The second are modulate patterns which is when the first pattern affects aspects of the second pattern but does not have to affect the entire pattern. The third relationship type is ‘instantiated by’ which is when the pattern can be instantiated by ensuring the presence of the related pattern. The fourth type is ‘modulated by’ which applies when an additional pattern can tune a patterns affect on game play. And finally, the fifth relationship type is a ‘potentially conflicting with pattern’ which can make presence of other patterns impossible. Although there are 5 different relationship types this does not mean that it has to be an either or situation in which only one relationship can apply to a certain type of game, sometimes multiple relationships can exist in games because of how the game is intended to be played is not necessarily the way a player plays the game and other unintended relationships may form through this type of play.

Which leads us on to intentional or emergent presence. This is when a game design pattern may be found in game play that was either intended by the designer or an unplanned consequence of the configuration of the game. The unintentional patterns in games are often classed in a hierarchy at the highest level meaning that the patterns are harder to design. This is common sense if the player has unintentionally found a pattern as the designer did not plan this design whereas a lower level would include a core set of rules the designer has laid down.