Tips for the Working Designer

By Sylvain Dubrofsky [07.26.07]

 Most of us know of design luminaries in the industry, but in a team of 10 designers there are eight or nine non-lead designers whose quality of work is increasingly important. As non-lead designers, we are often given new challenges from project to project, working on games or parts of games we have never worked on before. I love the challenge of constantly delving into the unknown, but having a proper design approach will help give you a huge advantage over designers who go into situations "using their gut".

Articles on design tend to either have a very narrow focus (such as first-person shooter level design) or a very broad one (very general rules and observations) and they're often written by well-known or respected design leads. While these can be a great read, most of us are not in the position where this shared knowledge is useful on a day-to-day basis. The narrow scope is very useful if you happen to be making a first person shooter, but how about if we are making a level in a racing or a third-person stealth game? An article focusing on more general game design may help the lead designer guide the team, but 90 percent of us don't have the level of authority or control for these kinds of articles to be particularly useful!

Often, designers are in situations that are not ideal. We end up working on low profile titles with small budgets and little time. The gameplay may not be a known quantity or can be constantly in-flux. Additionally, we might be working on aspects of the game that are new to us without good guidelines or leadership. It is our responsibility in these situations to persevere and make sure our systems or levels are as good as we can make them, regardless of the situation at hand.

The best way to approach these situations is not to simply cross our fingers and hope for the best, but to do everything we can to research the subject, devise a method that reduces wasted time and effort, and work with a cycle of constant iteration and feedback.

Why should you read an article written by someone who has worked on games you've probably never played? As a working designer who often doesn't have the authority to shape the project I'm working on, my job is primarily responsive to the choices made by others. Most designers out there are in the same situation. Devising a method that is flexible enough to allow designers to create quality work with greater communication is essential for our job.

Three Kinds of Design

There are three basic kinds of design: system, level, and character.

System design involves creation and tuning of particular features of the game such as fighting systems, artificial intelligence (AI), particular game modes, etc. This requires coordinating with programmers, producers, and various other disciplines. Sometimes the designer will be responsible for scripting the system on top of providing the initial design.

Level design involves the specification, construction, and tuning of levels or other physical areas of the game.

Character design is the specification, creation, and tuning of animated creatures.

For this article I will focus on system and level design.

 Research is an Underrated Tool

Many game developers overlook the importance of research in game creation. When you are responsible for creating something that you do not have much experience with, the best first step is to gather research on the subject from as many sources as possible. Talk to friends in the industry - often they have dealt with the task at hand or have heard about how other teams have. The Internet is a great place to find research papers, pictures, or past Game Developer Conference (GDC) talks and there are great websites where you can learn a lot from other developers (such as Dave Johnston and Cliff Bleszinski). Also, there are numerous books, both game related (such as the Game Programming Gems series) and not game related (such as The Design of Everyday Things), that can be very useful. Don't limit yourself to only books on game design!


Finally, it is extremely useful to grab a pen and paper, some relevant games, and reverse engineer what they are doing. Depending on your current design goals, some of the things to pay attention to are timing, determinism, and difficulty ramping. Examples of timing and ramping are: the frequency of AI attacks, distance between placement of enemies, frequency and location of enemy respawns, size and placement of hit-boxes, frequency of setups such as rails in a skating game or hard right turns in a racing game, etc. Determinism is the amount of randomness or lack thereof in a system. This is useful for figuring out AI systems. It can be tedious deconstructing games this way, but it pays dividends when you have to explain why the AI you designed attacks so little at Level 1 or what the thought process was for the last objective in your level.

Researching for System Design

On Shrek: Super Slam, my primary responsibility was to design and tune the game's AI, working directly with one programmer. The mandate was for the AI to be a challenge like a real player. My own personal goal was to have a system that was simple enough to intelligently tune, which was crucial given our schedule and experience. My nightmare scenario was managing a large 3-dimensional array, with one axis representing characters, the second their potential actions, and the third the various levels of difficulty. The complexity of a badly designed system like this would grow a substantial amount every time a character, action, or difficulty level was added. As a result, I had to find a different strategy.

The early initial concept was to use fitness functions to determine each proper action for the AI to do, but to me this seemed hard to tune due to its flat structure, where there is no distinction between long-term (chase the enemy) and short term goals (defend incoming attack using reflection). The number of actions can grow very big without additional abstraction and as a result, this structure wasn't suitable.

My initial research in the bookstore proved fruitless. There were plenty of articles on AI, but none specifically on AI for fighting games. The first breakthrough in my research was watching the GDC talk on the Counter-Strike bot AI (a very successful AI system). From this, I found an overall structure that I liked and could emulate. I learned, from talking with friends, that Street Fighter 2 used tables with lists of moves so that their AI wasn't totally deterministic. From Game Programming Gems 3 and the CS-Bot talk, I read about the benefits of using path nodes instead of way point paths. This became the basis for the AI's low level path-finding.

My own game research was valuable as well. I played a lot of similar games, timing the movement and sequences of moves that each AI chose. I then saw if the results differed as I changed characters, changed levels, or by repeatedly re-running the level with the same character. For each game I tried to determine how I could implement similar behavior. Using a Gameshark and Super Smash Bothers: Melee (SSB:M), I was able to see that there was a secret eleventh AI difficulty level below 1. This AI level 0 was not selectable in multi-player but was used for very early single-player tuning where the AI would almost never attack. SSB:M, Kung Fu Chaos, and Power Stone provided some ball-park figures for tuning attack, defense, and movement behavior. At this point I was able to go back to the books in the bookstore and get my terminology straight. What I wanted was a "fuzzy-state machine with multiple layers of hierarchy." This would allow me the flexibility to emulate a lot of the behavior I had seen without too much complexity.

Researching for Level Design

Jonny Moseley: Mad Trix is generally considered a bad game. It was my first experience in 3d level creation and I had around 6 months to create the level in 3ds Max. Still, I was determined to make a great level. The level I was assigned to do was "Tahoe." Because of its proximity, I had actually been to Tahoe recently. I have done on-location research with two other games and I find it very helpful. Early in the level creation process I use this information to separate the level into distinct areas and to come up with a general visual theme. Armed with this knowledge, loads of pictures from any sources, and some useful guidelines (such as the player speed, and draw distance before a turn is needed), I had a good starting point.

Unfortunately not many books cover linear, trick-based level design, so my standard book-based research wasn't helpful.

Next, I spent some time with the competition: SSX and Shaun Palmer: Pro Snowboarder (SP:PS) (and to a lesser extent Cool Boarders) had a lot of useful ideas. With pad and paper in hand and a focus on early levels ("Tahoe" was going to be the second level), I wrote down anything that could be useful. Some examples of the information I recorded were the average time between big jumps in SSX levels 1 and 2, the spacing between rails in SP:PS and drawing simple visual representations of all the areas I liked in all the games. These symbols were very useful as a grab-and-go set of ideas that I could pull from as I made the top-down map for the level.

By studying these games, I generated a philosophy that I applied throughout the creation of my level. I enjoyed trying to get to the really high spots from big jumps in the competition, but was disappointed when my effort to do so went unrewarded. I decided "Tahoe" would generally have 3 levels of height, where the difficulty and potential rewards would be proportional to each other. These areas would cross regularly to allow players at the lower heights multiple opportunities to get back to the higher paths at regular intervals. All this research proved invaluable.

Spending an appropriate amount of time on research, whether by checking out available literature, studying similar games, doing location research, or discussing problems with your peers, will give you the confidence that your work has a strong foundation.

 Develop a Vocabulary

For system design, it is useful to first come up with a vocabulary that helps you talk with leads and people in other disciplines such art or programming. It helps me to think of how I would implement the idea if I were to program it, and what sort of variables I would need exposed when it comes time to tune the system. For Shrek: Super Slam's AI, there were three layers of hierarchy: high-level "Where am I going?", mid-level "Action and Reaction," and low-level "Pathing." For each of these categories I specified the data-structures the system would need. For instance, in the "Action and Reaction" category I needed to be able to group possible attacks by distance to the target, and then from an ordered list with a probability assigned to each. Describing the system in this level of detail and using consistent terminology helped assure that I would get what I needed from the programmer and allowed me to discuss the system with managers using a common vocabulary.

Sometimes the goal of the system you're designing is not well developed. When working on an unreleased game "Skills," I was responsible for designing and scripting one of the main modes called MC Mode. The high-level design of the mode was originally done in a committee and as a result, the design was not very clear.

With limited time and resources, but a large knowledge of similar games, I was able to identify features of similar modes in other games and realized that what they were describing was like the mini-game "Pazaak" from Star Wars: Knights of the Old Republic. Using Pazaak as the basis for MC Mode made building and describing the system a lot easier. We had a language to discuss how MC Mode related to Pazaak, how it differed, and it soon became a lot easier to see what the end result could be. The final design did not end up too similar to Pazaak in the end. However, the similarity of acquiring pieces in the larger game that you then use in the MC Mode became a great starting point. I could then start work on this new system from a proven design and it was a design that I could start scripting right away.

Develop Metrics and Guidelines from Research

When working on a level in a new genre, it is desirable to get quick feedback on the level as often and as early as possible. Gathering research and then building using top-down design allows me to get to that goal quickly. Sometimes designers are forced to start designing the level layout before the engine and mechanics are done. In this case you will have to rely on paper sketches or other prototyping tools such as Google Sketchup until the engine and tools are ready.

When it is possible to build and play your level in-game, begin with large 3-dimensional pieces to block out space. Next put in the last boundary condition in the level (for objective based games this is the last objective to beat the level, for racing games it would be the finish line). Now the level is "playable", albeit in rough form, from beginning to end. These first steps should not take much time - a couple days at most with mature tools. This process allows others to play test and give meaningful feedback right away.

With this initial feedback, you can get a good rough guide for the entire level, and adjust for any positive and negative reactions. The rest of the project becomes a cycle of playtesting and iterative editing. I like to divide the level into discrete sections and then build up all sections at the same time, but not all projects allow this. For some projects it's necessary or desirable to build and polish a single section of the level at a time.

Tony Hawk's Underground 2 Remix was an exciting project for me. I had always enjoyed the series, and the game was a launch title for a new hardware platform. The short development cycle and a changing hardware spec, forced us to build the game with vague guesses on the concessions we would have to make for the small screen and the available memory.

My research consisted of going to Santa Cruz, where I got a tour of the area from local skaters, and then playing every previous Tony Hawk game to get a feel for what worked (especially early levels - this time mine was the first in the game). I now had some things to work with such as the overall size in square feet of the level, number of distinct areas that I found in Santa Cruz, and a variety of other general design guidelines. I observed that early levels in previous Tony Hawk games tended to be flatter and wider, and that it seemed a good idea to have multiple ways from any location to any other, except for small self-contained skate parks.

Once I had a quick paper map with all of the sections roughly blocked out, I built each section using very simple 3D boxes with a placeholder texture that consisted of a picture of the large buildings. One thing that helped in this stage was that we had access to all of the old Tony Hawk maps. Being able to grab pieces from old levels for size reference is extremely useful at early stages of level design. Using simple building blocks, I was able to layout an entire level in extremely rough form in a day. Doing this pointed out some important problems, like the fact we had too many areas (two had to be cut), that parts of the level were too linear, and that some spots had visibility that would probably exceed our polygon budgets. All of this could be dealt with early on and people on the team could play the game to get a feel for the size and scope of the level quickly.

Play Early and Often

It is extremely useful to play and give feedback on other people's levels or systems and encourage them to do the same on yours. Sharing and spreading mechanics or setups that work well throughout the game, helps make sure the really fun elements are not just one-offs and give the game a more consistent feel. In turn, this leads to less wasted asset creation time and a better product.

Finally, keep playing games and learning. I'm always dismayed when I talk to designers who don't play games. As designers who are "in the trenches" there are always new things to learn. After all, I can't imagine there are too many movie directors who don't watch movies, or musicians who don't listen to music!



Sylvain Dubrofsky has a degree in computer science and started his career as a programmer, but quickly switched to a designer role. From his start in late 1999, he has been at four companies and on worked nine game titles in five genres. His roles have included levels, AI, level scripting, core gameplay scripting, and much documentation.

Return to the web version of this article
Copyright © UBM TechWeb