Remember you are awake

I have decided to keep track of my personal approach to game design by maintaining a document for each year of my career. This was the approach I wrote in 2009. There are already several things I have learned since writing this that will make it into the 2010 update. I hope this can be a good jumping off point for people interested in becoming a game designer. I would love to hear any of your opinions or personal insights into the game development process.

Game Design Process:
Personal Observations and Approach 2009

Overview

I have been educated as a game designer, and I have been engaged in video game design for over 10 years. During my education and work as game designer, I have been exposed to various processes, methods and tools. As a result, I have developed certain opinions about the computer game design process and the individuals who create and produce these games. I have prepared the following summary of my observations and my personal approach to developing successful, fun video games.

Green light Process

Determine what games your publishers have slotted into their production schedules. Understanding what they are currently developing and what their marketing department currently wants to add to their release schedule is crucial.

Once a dialogue with the publishers has been initiated, the developer can begin to create game design concepts that match their development strengths, while also fitting within the type of game desired by the publisher.

One-Page Pitch document

The developer should create several one page documents for potential titles that cover the high level design direction. Each document should contain a brief overview of the game design written to excite the reader and provide an understanding of the type of game and the intended game play style. The document should also touch on the demographic, unique selling points and game design pillars. The pitch document is a good way to gauge the team’s interest in the concept and see if it should move further into the design process.

Design Pillars

The pillars should be limited to around five core goals that the game aims to achieve. If you are creating a survival horror game for example, these pillars would be used to further refine and explain what is intended by survival horror. To further illustrate game pillars, here are some examples within the survival horror genre:

Emphasis on realism, no elements of supernatural
This pillar helps refine the scope of the game immediately. The team and designers can use this as a base when evaluating any possible game content. The pillars may seem restrictive however they actually operate to facilitate creative design choices throughout the development process. It is the difference between staring at a blank page, and knowing that you are going to draw a chicken robot.

Ensemble cast with a focus on gameplay interactions
We now know that the game will put an emphasis on other characters within the game world and that these characters will be used for gameplay rather than just to add story flavor. Since this has been deemed a pillar of the game, it also tells the team that a large part of development time and resources are required to achieve this pillar.

Focus on suspense and terror over action
This pillar helps shed light on the overall pace of the game. We can now see that it might play like the movie “The Shining” or “Misery”. This pillar poses a challenge to the design team to construct compelling gameplay that involves more psychological challenges than reflex based challenges.

Player vulnerability and a new take on death
Ooooh! This one compels the reader to say “tell me more”. In a horror game the concept of self preservation and death could be thoroughly explored. This pillar gives the team a chance to innovate on the game concept of death and life. What if the player assumed the role of another character if they died?

The design pillar process should include as many team members as possible. This is the least expensive stage of game development and should be used to bring the team together and create “buy in” for the potential title. You never know where brilliant ideas will come from and limiting them at this stage can only take away from a game’s potential. If the team feels included they will work that much harder on the title if it goes into production since they have a vested interest and some ownership in the overall direction. The team will also help determine whether the concept is sound and commercially viable.

Once the pillars are identified, the document should explain each pillar in a couple sentences.
Unique Selling Points

The unique selling points (USP) area is a high level marketing way of distilling your game pillars. The USPs should be short exciting sentences of what would be written on the back of the game package.

Once the USP section of the document is finished it is important that the lead designer along with as many team members as possible start to see the game in their heads. If you can not play the game in your mind and start to get a feel for the moment to moment –to-moment gameplay, the game concept needs to be scrapped or refined until it is possible to envision it clearly and articulate it to others. The team and the game leads will be the biggest champions of the title, and if they cannot inspire the publisher when discussing the game, it will be a short meeting.

Support materials should be created to help sell each pitch. Concept art and visual materials pulled from other media can be used to great affect in sharing the vision for the game. If the horror game design example was one of the pitch documents, the team could create a short movie cutting together short scenes from films that are influences on the title. The visual materials can later be used in PowerPoint presentations that flesh out the one-page pitch document further.

The final step is to create a rough control scheme. It may seem like it is too early to start thinking about this issue; however, it is an extremely valuable tool to the reader. When the reader sees a preliminary control scheme, it is something they can keep in the back of their mind while reading how wonderful and fun your game will be. They can start to use their imagination to play your game in their head. Hopefully, your document inspires some really fun thoughts!

After the team has created a number of the one-page pitch documents that address various publisher interests, then it is time to resume the dialogue with the publishers.

Love. Love, as cheesy as it sounds, is an absolute requirement for any game or piece of art. It is blatantly apparent when you are playing a game that was created with love. Games created with love demonstrate appreciation for the player’s time and intellect in the quality of the work. All of the timeless classics have this one thing in common. Even if the game is slow to catch on commercially, it is the defining factor that keeps a game in the gaming community’s consciousness and will lead to slow but steady sales. If the creators of a game do not love it, who will?

As an added note, competitive analysis and research should coincide with the pitch document preparation. Knowing what is already on the market and what will be coming out will help in validating the proposed game design. Research into other media will help in the creative process, reading, watching films and even listening to music helps facilitate the design process and create original ideas.

Pre-production

Pre-production of the game is essential to start answering the questions raised in the game design concept phase.

Define the core gameplay and systems

This is absolutely necessary since the entire design team relies on this plan. A level designer cannot do their job if they do not know what the player is capable of doing. Designers typically use what they know they can count on. If all they know they can rely on is that the player can jump, you will get a game all about jumping.
Create a plan for systems design

Now that you have defined the core game mechanics it is time to start planning how to implement each system. The systems should be prioritized to help support the level design team, starting with the systems that affect the greatest amount of play time.
Plan the pacing and progression of the game

Most, if not all, games have a progression. It can be as simple as creating a plan for teaching mechanics in a puzzle game over the course of a set of levels to planning the arc of an RPG with complex plot twists and character development.

The game “Super Metroid” is a great example of how to setup pacing. The designers limit the move set and weapons that the player can use and steadily add onto the move set and weapons throughout the game. Each weapon or item acts as a gating mechanic to reach the next area where the player will find another one. You need the rockets to open a door that then leads to an ice ray that you need to use to freeze enemies to jump on to reach the item that allows the player to roll to get to….The lure of what lies beyond the next corridor is a strong and compelling hook and the inclusion of new play mechanics accentuate the experience.

Metroid’s design is a successful ramp for action games since if timed well, it gives the player an opportunity to learn each new mechanic just in time to get another one, always building on the player skills while keeping the game feeling fresh. Pacing of mechanics and rewards is crucial to any type of game regardless of genre.

Companies such as Sony do play tests on all of their titles. They keep track of player interest level and play times. The more positive feedback loops that a game contains the longer it will keep a player’s interest. These feedback loops can be looked at as rewards. Designers should be conscious to include rewards or varying worth and specific time intervals. The worth of each reward to the gameplay is key and should be proportional to the investment required to gain the reward.

Tetris rewards the player every time a line is cleared but excites the player and encourages them to get better by clearing multiple lines if they are skilled and patient. The pacing phase should account for the moment to moment reward system. Some examples of rewards can include the following:

• New items weapons or abilities
• Story progression (Cut scenes or plot points)
• A nice vista within the level
• Discovering a new area of the game
• Reaching a check point or completing a level
• Alternate content or “Easter eggs”
Development risks

Identifying development risks is important since it allows the team to create a series of back-up plans and designs. Designers should plan for multiple ways to implement their systems in the event that the schedule or technology does not work for their ideal choice.

For example the design team may decide that they want a really dynamic cinematic camera system for the game. In the event that the tools are taking too long to implement or the camera system is not working well for gameplay it is good to have a “B” and “C” option to fall back on, each progressively less ambitious and time intensive to implement. Any system deemed risky by the leads should adhere to this philosophy.
Proof of Concept

The developer and publisher have remained in contact and have piqued interest in one of the game concepts. The publisher is now interested in pursuing one of the game developer’s titles and would like to see a proof of concept demo.

The team should set about creating a small chunk of gameplay that demonstrates one of the core elements of the game while creating interest to see further systems and sections of the game. The demo should typically be 10 minutes of gameplay that showing the unique selling points in action.

The demo process can divided into multiple demos that illustrate each pillar or selling point individually. This can be an effective strategy since it allows the team to focus resources on each pillar and use a scrum development process.

The lessons learned from each demo will also allow the team quickly transition to a vertical slice demo which creates a fuller view of the game as a whole. The demos should help the developer to see what worked with the initial game design was and what failed. This is the time to make hard decisions on what should remain in the game, what should be cut and what sections of the game deserves higher priority and additional resources.

Producers should track the development time closely during the demo creation period to create a metric for how much the team can accomplish during the full development cycle. If it was determined that a polished level takes a month and a half to reach a shippable quality level, it should be factored into the schedule and necessary design adjustments should be made. As painful as it can be cutting early and cutting big can save the project. The player will never know what was taken out but they will judge the game on the level of quality of what was left in.

Vertical Slice

The publisher is pleased with the smaller demos of the game and would like to see an actual chunk of the complete title. It is important to choose a section of the game that will remain in the finished product as well as give excellent examples of each design pillar and show that there is sufficient gameplay and substance to entertain players for the duration of the full title. Art and design should be polished to as close to a shippable state as possible since it is setting the expectations if the game moves onto production.

The vertical slice can be a risky step in development depending on your budget, schedule and position in the project approval process. It is important that the vertical slice does not take too long. You can get valuable time metrics from the process but also get your game canceled. Staggering what each discipline is doing during the process is a good way to make sure progress is still being made on the overall game production.
Production

The game is in full production and the team is excited to finally get going and actually make the game. If the pre-production process was smooth and risks and problems have been identified early in the process, this should be a matter of generating and polishing content. The main issue during production is to maintain clear communication with all disciplines.

When issues arise they need to be addressed immediately and if new questions are asked they need to answered to keep people on track and working. If the leads do not have an answer the team members faced with the issue should be empowered to resolve the issue. The view from the trenches can be quite different to someone focusing on their own section of the game.

It is important to never underestimate the influence and impact that sound has on the perception of fun. The design team should work closely with the sound team to make sure that the in-game events have sounds that reinforce the action on screen. Just as visual language is important to making an understandable and enjoyable experience audio plays a large role helping the player immerse themselves in the game. Adding sounds early and planning the design needs of sound will help round out the total experience of the game.

Level design should be as agile as possible. Levels should develop from paper maps and written plans to in-game geometry as quickly as possible. The designer can create vignette drawings of sections of the level or area with self-contained gameplay. An example would be to draw a map of a room with a puzzle in it with notes on how to solve the puzzle or platforming challenge. By creating a batch of smaller good ideas, the designer can then worry about the order in which they should be played in, and the fine tuning of how the sections of gameplay connect and relate to each other.

Assets required for a level should be generated and reviewed as early as possible to allow early blocking geometry to be created. If the game is linear in nature, the designer should think through the level flow and create a simple list of resources needed before touching the computer to save time. They should also refer to the pacing document, time with a pencil and paper is faster and cheaper than jumping right into the computer for most designers.

Level overview documents may sound fun the way they are written; however, until the level is playable, it is still a mystery whether the gameplay works. Minimal effort should be spent during this period on superfluous tasks that are place holder or do not lead to actionable tasks.

Systems design should be just as agile as level design. The design team should work quickly to get to a point of functionality and then address polish. New needs always present themselves once the system has been implemented, so reaching a playable state will allow the design team to prioritize what is needed to bring the system to a functional and shippable state.

Beta should act as a hard Beta. No new content should be added to the title, as tempting as it may be. Any new content is capable in resulting in more bugs than anticipated and new content requires new testing plans for the test department.
Conclusions

This process is ever-evolving with each title that I personally work on as well as knowledge shared from colleagues. The main goal of my game development philosophy is to continue to explore unique game concepts and development techniques that empower the team and lead to artistic and hopefully, commercial success.

We must love our games, our teams and the player to make the process work.