Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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

    - Sylvain Dubrofsky

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


comments powered by Disqus