Get the latest Education e-news
 
  • Tips for the Working Designer

    [07.26.07]
    - Sylvain Dubrofsky


  •  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!

    Summary

    • As working non-lead designers we often work on projects in non-optimal conditions without high-level authority. In these cases we should strive for quality work through methodology.
    • Research is underrated as a tool for design.
    • Use research and communication to come up with metrics and guidelines to maximize efficiency.
    • When designing systems, come up with a plan that you could implement if you were to program the system and a vocabulary that allows you to discuss the system with programmers and management.
    • Design levels using a top down approach. Get the whole level blocked out in 3d as fast as you can, using pre-existing pieces for size reference when available.
    • For levels, get your end-level and boundary conditions (objective, exits, etc...) in first, and then start play testing as soon as you can.
    • Make sure to play others designer's work and share knowledge to make the game better as a whole.

     

    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.

Comments

comments powered by Disqus