A Guide for New GarageGames Customers

Version 1.0
1

GarageGames: Customer Handbook

Welcome to GarageGames
The process of building games, especially games that are more than just entertainment, is difficult and rewarding; this guide will help
you understand our practices. For someone who has never developed a game, its often a humbling experience that helps you to
appreciate the care, coordination, and magic of game development. The information in this document is a guide and no single
approach solves every problem; occasionally, we may deviate from the prescribed best practices.

2013 GarageGames, LLC. All Rights Reserved.

1
Table of Contents

Welcome to GarageGames .................................................................................................................................................................. 1

About this Manual ................................................................................................................................................................................ 4
Introduction - Roles .............................................................................................................................................................................. 5
Introduction Making Fun .................................................................................................................................................................... 7 2
Introduction Software Evolution ......................................................................................................................................................... 9
Introduction Development Lifecycle................................................................................................................................................. 10

Table of Contents
Introduction Synchronizing Teams .................................................................................................................................................. 12
Section: Game Design Document ...................................................................................................................................................... 15
Game Design Document Introduction ............................................................................................................................................. 16
Game Design Document User Experience ...................................................................................................................................... 18
Game Design Document Style Guide .............................................................................................................................................. 19
Game Design Document Script ....................................................................................................................................................... 20
Game Design Document Glossary .................................................................................................................................................. 21
Section: Technical Design Document................................................................................................................................................. 22
Technical Design Document Introduction ........................................................................................................................................ 23
Technical Design Document Hardware/Software Specification ....................................................................................................... 24
Technical Design Document Performance Specifications................................................................................................................ 25
Technical Design Document Architecture........................................................................................................................................ 26

2
Table of Contents

Technical Design Document Interface API/Protocols ...................................................................................................................... 28

Technical Design Document Release Requirements....................................................................................................................... 29
Section: Estimate Sheet ..................................................................................................................................................................... 30
Estimate Sheet................................................................................................................................................................................... 31
3
Estimate Sheet - Goals ...................................................................................................................................................................... 32
Section: Project Schedule .................................................................................................................................................................. 35

Table of Contents
Project Schedule Understanding Constraints .................................................................................................................................. 36
Section: Execution ............................................................................................................................................................................. 39
Execution - Intro ................................................................................................................................................................................. 40
Execution Cadence ......................................................................................................................................................................... 41
Execution Vertical Slices ................................................................................................................................................................. 42
Conclusion ......................................................................................................................................................................................... 43

3
Introduction

About this Manual

In this manual, we will cover the topics below. If this is your first time working with GarageGames, we recommend that you share this
document with everyone in your company. It will save time, money, and it will contribute to a healthy team environment where groups
collaborate better and accomplish more.

Intro 4
The Game Design Document
The Technical Design Document
The Estimate Sheet

Introduction
The Project Schedule
Execution

NOTICE

All team members should read each section. While the technical design document may be the most important document to a
technical person, the other sections are still very important. It takes a team to build a game so understanding the context of the
other groups and individuals will help you do your job.

4
Introduction

Introduction - Roles
Congratulations on your purchase of a custom game. Procuring a game is exciting but it may also be intimidating if you have never
been part of the process before. Making a game is hard because it takes many disciplines. The following roles are required to make
a game:

Designer 5
Designers define the user experience, develop gameplay strategies, and balance competition.

Artist

Introduction
Artists create the digital assets that define game aesthetics.

Programmer
Programmers use scripting or programming languages to add logic and systems to a game.

Manager
Managers coordinate the individuals. Producers, Art Directors, Project Managers, and Technical Directors are all important
managers. A lead is another type of manager who is the best of peers in a given domain (i.e. Programming Lead). Its
important for all managers to be in touch with their project. We suggest that managers spend at least 30% of their time getting
their hands dirty. Leads should only manage 20% or less.

WARNING

After developing a game, teams often do a post-mortem (some call them post-partum). Typically, team communication is the
number one topic cited by team members as the biggest area for improvement.

5
Introduction

WARNING

Its the designers job to define the game characteristics. The designer uses past experience and opinions to set design and its
important to let the designer do their job. Typically, its better to keep the design team size to a minimum, too many opinions water
down a design and reduce the je ne sais quoi. It is, however, useful for a designer to realize that constraints, such as technical,
schedule, resource, force a designer to make decisions and be critical of their design.
6

Introduction
6
Introduction

Introduction Making Fun

Making fun separates game development from other forms of software development. To make software, you will need to achieve the
following:

Intuitive User Experience 7

Intuitive Controls
Pleasing Aesthetics
Useful Functionality

Introduction
Stability
Maintainability

In addition to the list, a game also needs the following:

Fun
Replayability
Joy Moments

WARNING

Design changes should be well understood as soon as possible. Changing design during execution without careful consideration is
a recipe for disaster.

7
Introduction

To create fun you should consider one of two paths: cloning or iterative design.

Cloning
Cloning means taking a proven design and copying it.

Iterative Design 8
Iterative design requires developing prototypes (either on paper or with a prototyping application) and usability testing. During
usability testing, we determine if what was built is fun. If its not, you should prototype and try again.

Introduction
WARNING

Design is constrained by technical, schedule, and resource constraints. If the goal of your game is to be persuasive there is yet
another level of challenge. Persuasive games have the challenges of 1) Software development 2) Game development 3)
Instructionally correct. Thats a triple whammy!

8
Introduction

Introduction Software Evolution

Software development isnt just iterative, its evolutionary. The fittest designs and practices survive and the bad ones must be retired.
At a course granularity (i.e. the forest view), we introduce large cycles to help facilitate software evolution. The common phases
include:

Proof of Concept Development

Demonstrates that an idea is possible. Typical development during a software project.

Introduction
Prototype Alpha
Demonstrates that an idea is feasible. Feature complete. Not ready for 3rd party testing.

Working Prototype Beta

Demonstrates that an idea is feasible in a Feature complete. Ready for 3rd party testing.
real world environment.
Release Candidate
Rapid Development A candidate for Gold Master.
Similar to a proof of concept with the
exception that it occurs during development. Gold Master
A shipped version of the software.

9
Introduction

Introduction Development Lifecycle

There are stages a game development project must follow in order to complete a game. All games follow these stages to varying
degrees. If the team isnt able to recite the goals, problems are bound to arise.

Vision 10
The goals of the project. It is extremely important to communicate goals, preferably in priority order, to all team members.

Pre-Production

Introduction
During pre-production we assemble the team and set the standards for goals, design, and schedule. We document them in
order to facilitate sharing.

Production
During production we execute on the game design and react appropriately to inevitable changes.

Release
Release is the end of production. Feature development is complete; final QA and certification commences.

Support
Once live, the game must be supported. In live development models, the base game is released while the other stages, listed
above, occur in parallel with support.

Decommission
The game is retired from play.

10
Introduction

WARNING

The amount of time it takes to complete pre-production can be deceiving.

Typically, the amount of work (a measure of efficiently completed effort) often occurs over a long duration (amount of calendar
time). The reason are the dependencies and iterations. Later decisions, such as technical implementation decisions, are gated by
earlier decisions like design and vision. These dependencies create a development process that is inherently serial.
11
Conversely, later constraints, such as technical implementation and schedule, can affect earlier decisions such as design. These
changes result in another iteration that is still inherently serial.

Introduction
While this process may be slow, it would be significantly more time consuming if these designs were implemented instead of
simply simulating them on paper in a game design document. By setting aside appropriate time for pre-production, we can reduce
dependencies and iteration and increase parallelism during implementation.

Figure 1 Preproduction - Both highly iterative and highly interdependent.

11
Introduction

Introduction Synchronizing Teams

You are now familiar with the roles, you understand the challenge of designing fun, and weve presented the high level stages of the
game development lifecycle. Now its time to get one step closer to execution. But theres still one more important step
synchronizing teams.

Communication across teams is vital and very difficult. The first challenge is to create a common, agreed upon set of guidelines. The 12
second challenge is to actually get people to abide by them. We use several documents to synchronize our teams.

Intent Document

Introduction
Defines the base design in one page. Its the pitch document before you write the Game Design Document.

Game Design Document

Defines the game design in greater detail. The most important role of the game design document is to tell the story of the user
experience. The game design document tells us about game function.

Technical Design Document

The technical design document describes how to implement the functionality of the game design document. Typically, the
technical design document describes runtime requirements, architecture, and development standards.

Estimate Sheet
The estimate sheet decomposes the implementation into smaller units for the purpose of making estimates. The estimate
sheet includes all production stages such as development time, QA, usability, refactoring, and release.

Project Schedule
The project schedule takes the estimates from the estimate sheet and assigns resources to them. The project schedule gives
us our milestone dates.

12
Introduction

WARNING

Using a document as an authoritative source can be a great way to synchronize your team, but simply making the document will
not achieve the goal of a synchronized team. There are several guidelines you should follow:

Single Owner 13
While many people will contribute to the documents, there should be one owner of the document. Its everyones
responsibility to understand and contribute to the document, but a single owner should merge together everyones
comments and notify the group when a new revision of the document is ready for review.

Introduction
Assumptions
The team should recognize that the design document is the authoritative source. If something isnt specified, it should be
considered ambiguous. If something is really important to you and the documents dont include the information you need to
represent your important topic, ask the document owner to update it.

Updating
You wont get the design 100% correct during pre-production. That means things are going to change. When they do, the
document owner should update it and share it with the team. Typically, the document owner will update the document
immediately and share a new version of the document on a weekly basis, typically in a project meeting or once a week
during the sprint.

13
Introduction

PRO TIP

These documents are for collaboration and communication. You should always include page numbers and sections using a
numbering system. Its much quicker to refer to a spec if its numbered appropriately (i.e. John, did you take a look at the design
specification in section 2.3.4?).
14

PRO TIP

Introduction
Have you gained a new team member? Its no big deal. Ask the new team member to read the GDD and TDD and come back with
questions. Consider giving them a test. Even if you dont grade it, the very process of testing someone increases the likelihood that
they will retain the information.

14
Game Design Document

Section: Game Design Document

Setting the Course for Your New Game
15

Game Design Document

The GDD
The game design document (GDD) is a document designed for failing. No, really. By iterating in a document, one of our goals is to
fail early. Failing on paper is much cheaper than failing in implementation, QA, or worse -with the end user.

15
Game Design Document

Game Design Document Introduction

The GDD defines what you are building. It doesnt, and shouldnt, concern itself with the how and when of a project. At a minimum,
the design document will define user experiences, style guidelines, and script/story.
16

WARNING

Game Design Document

The design document is more like an initial rendering of a home, not the blue print. By focusing only on the end-result you are
removing constraints that may overly limit your creativity. But there is a balance. Its not helpful to design a game that would take
three years to build when you know you only have six months. Good designers understand that some things that seem difficult to
implement can actually be very easy and some things that seem easy to implement can be very hard. Keep an open mind and talk
with your technical resources often. Dont negotiate against yourself and assume that something is hard when it may be simple.
Conversely, dont make assumptions about something you perceive as simple it may not be.

16
Game Design Document

PRO TIP

Move the rock! The most difficult part of a new idea is getting started. Dont be afraid to be wrong. Move the rock by putting down
the first proposal and sharing it with someone else or the team. Dont get worried about formatting at this stage; you should
assume that you will be removing or refining a lot of your ideas. Even if you share something thats 95% wrong, you are sill 5%
right and your next step will be clearer.

17

Game Design Document

17
Game Design Document

Game Design Document User Experience

The user experience provides the basis for development of the entire game. The user experience uses wireframes, sketches, and
descriptions to define the users inputs and the games outputs. We typically use a format similar to the following:

18
The user is in the shuttle. She pulls the yoke towards her stomach.

Game Design Document

The ship rotates along the y-axis

End Of Experience

18
Game Design Document

Game Design Document Style Guide

The style guide defines the look and feel of the application or game. If the customer doesnt know what look-and-feel they want, we
will provide them with a series of choices based on popular designs. Once we determine a reference from existing samples, we will
develop custom concept samples using initial designs.

In addition to the style guide, we may build common art during the pre-production phase. Developing common art early in
19
development helps us maintain a consistent look across all experiences and increases parallel development.

Game Design Document

Figure 2 Typical steps of moving from reference examples to custom developed concept pieces.

19
Game Design Document

Game Design Document Script

The script may exist in several forms. For a class, the script may define the content you intend to teach. In an MMO, the script may
include a list of all quests available by player level. The script defines all of the content the user may encounter. To save
development cost, game developers may only generate one user experience that defines the template for a user experience. Once
that is defined, the designer can define multiple implementations of the user experience in the script. 20

Game Design Document

Figure 3 Potential layout of levels, users experiences, and scripts.

20
Game Design Document

Game Design Document Glossary

Terminology seems like a trivial issue, but when it comes to communication, its very helpful to get everyone on the same page.
There are many different disciplines in the game world and each group already has a set of vocabulary within their given domain.
When you hear dissenting terms, pick one and add it to the glossary.
21

Game Design Document

Figure 4 The GDD calls this a zebra, the TDD calls it a stripy horse. In the meeting, everyone is confused.

21
Technical Design Document

Section: Technical Design Document

How getting done is done 22

Technical Design Document

The TDD
The technical design document defines how we will implement your game design.

22
Technical Design Document

Technical Design Document Introduction

The TDD defines how we are building what the GDD defines. It doesnt, and shouldnt, concern itself with game design and schedule
other than to reference the game design document or project schedule. At a minimum, the technical design document will cover
hardware/software specifications, performance specifications, define architecture, implement interface/API specifications, and 23
release requirements.

Technical Design Document

WARNING

The technical design document is more like the blueprints of a home, not the rendering. It should be specific and detailed enough
that developers will be able to reference it to implement the project.

23
Technical Design Document

Technical Design Document Hardware/Software Specification

The technical design document will tell developers and QA what platforms and hardware systems the software will work with. At a
minimum, this specification should cover the runtime environment, but it may also be important to define the specifications of the
software you will be using to develop the product.

The following is a list of possible software modules you may need to formally define.
24

Domain Module
End-User Configuration Min System Ram

Technical Design Document

Available Mass Storage
Graphics Card Shader Model
CPU Benchmark Performance
Form Factor (Laptop, iPad, Galaxy, etc.)
Min Network Bandwidth
Min Network Latency

Operating System Type (Windows, Mac, iOS, Android, etc.)

Version Release, Update, Service Pack, etc.

Browser Support Brand (Chrome, IE, Firefox, etc.)

Version

Standard Protocol (HTML5, 0MQ, XML, SCORM, DIS, MP4, etc.)

Version

Tools/Framework Product (Torque, Flash, Zend, 3D Studio Max, etc.)

Version

24
Technical Design Document

Technical Design Document Performance Specifications

Scale can have considerable impact on the development practices and, therefore, the cost of software development. Both parties
should not make assumptions regarding the load that the system will be able to handle. This is especially true for servers or services.

At a minimum, you should consider the following measures:

25
Max Concurrent Users
Average User Throughput
Max User Throughput

Technical Design Document

Max Payload (bandwidth)
Max User Wait Time (download, processing, etc.)

25
Technical Design Document

Technical Design Document Architecture

Architecture may start with some concept of a design paradigm like MVC, MVVM, etc. You could use this paradigm to define the
architecture. Finer granularity in architecture may be defined using design patterns such as those defined by the gang of four Design
Patterns book (http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612).

One way to start defining your architecture is to simply decompose the product into anticipated modules. Similar to a Work 26
Breakdown Structure (WBS), you can use the 100% rule to decompose the product into smaller pieces. After decomposing the
product, you can then look for opportunities for shared systems such as managers and utilities.

Technical Design Document

26
Technical Design Document

WARNING

Architecture is very difficult. Trying to design too much up front can lead to disastrous results. Instead, let your architecture evolve
by building your product in steps based on what the product should do. For example, if you have never seen a car before, it would
be too difficult to sit down and design a car. Instead, it would be better to evolve your architecture over time in phases.
27
Dont design a car; instead, break your project into phases:
-A rolly thing
-A rolly thing that can slow down.

Technical Design Document

-A rolly thing that can slow down, steer, and is controlled by a person.
-A rolly thing that can slow down, steer, accelerate, and is controlled by a person.
-A car.

WARNING

Building a system that is too rigid is bad. Things will need to evolve over time so your system needs to be flexible enough to adapt.
Surprisingly, making your system too flexible can also be bad. When systems are engineered to be too flexible, doing very simple
things can become very complex due to all the systems required to couple systems together (if your system is too complex, a
solution is to build a tool that makes the process easier). And if those systems couple together at runtime, debugging can become
very difficult. Balance is important. The best architectures are both flexible and simple.

27
Technical Design Document

Technical Design Document Interface API/Protocols

Most applications have GUIs. Its a lot of work to define user interfaces that are intuitive and well organized. Applications also
interface with other applications; when they do, they use interfaces such as Application Programming Interfaces (APIs) and network
protocols.
28
Its possible and, in many ways, beneficial to design your interfaces prior to developing them. Too often, APIs are a result of the
underlying foundation only, a development practice that tends to result in non-intuitive APIs.

Technical Design Document

At a minimum, API specifications should have the following definitions:

Startup
Shutdown
Disconnect (if applicable)
Reconnect (if applicable)
Functions
Parameters
Data structures and data alignment
Examples
Error Handling

28
Technical Design Document

Technical Design Document Release Requirements

Finally, the Technical Design Document should define how software is released, updated, and if applicable, decommissioned. There
are many ways to update an application. Some, like the distribution of a new installer, are simple; others, like a live update of a
product while users are still using the application, are much more difficult and require special consideration. A common update
system resembles the following diagram. Under this system, product owners are able to deploy releases with reasonable assurance 29
that a bug or similar artifact isnt created by the versioning system itself.

Technical Design Document

29
Estimate Sheet

Section: Estimate Sheet

How much work will this take?
30

Estimate Sheet
Estimate Sheet
You understand the goals, the intended design, and the likely implementation its now time to determine the work effort of tasks.

30
Estimate Sheet

Estimate Sheet
Armed with our goals, design, and technical design document, we are ready to start thinking from a production perspective (as
opposed to simply thinking of decomposition of the product modules) and develop tasking.
31
Lets first take a look at what a section of our estimate sheet might look like:

Estimate Sheet
31
Estimate Sheet

Estimate Sheet - Goals

There are several goals of the estimate sheet:

Provides estimate 32
The obvious reason for estimating is to provide estimates for the project schedule.

Additional Decomposition

Estimate Sheet
Drives finer-grained decomposition of the architecture. This is why we tend to estimate in hours instead of days. Estimates
over two days are reviewed as candidates for further decomposition.

Shifts thinking from what to how

After spending so much time thinking about what you are building, its important to add the production side of the process to
your mindset.

Defines production overhead

Management, QA, usability, review, and refactor are all very important parts of development that can often be missed.

Estimates help define a given implementation

Often, the estimate can provide a level of certainty for a given definition where there may be ambiguity.

Quantifies risk through confidence

Confidence helps us understand risk to some degree. A two week job estimate that Ive done before (high confidence) is very
different than a two week job Ive never done before (low confidence).

32
Estimate Sheet

PRO TIP

Dont be surprised when the estimate process forces revisions of design or implementation. Track the changes in the TDD and
GDD so that the new approach can be shared with the remaining team members. 33

Estimate Sheet
WARNING

Warning, estimates change when you switch from one developer to another. Add the assumed resource to add validity to the
estimate.

WARNING

Estimates should be in work effort, not duration. Work effort defines how many hours the work takes to complete, not how long it
takes on a calendar. Consider a two hour job that starts at the end of the day Friday and finishes early Monday morning. The work
effort is two hours, but the duration is forty-one hours.

33
Estimate Sheet

PRO TIP

GarageGames Confidence Scale:

34
1. No clue -- don't make decisions on this. We need to talk more.
2. Hardly a clue -- don't make decisions on this. We need to talk more.
3. Someone else has done this and I read about it; job not well defined -- don't make decisions on this. We need to talk more.

Estimate Sheet
4. Someone else has done this and I understand this; job might not be well-defined -- don't make decisions on this. We need to talk more.
5. Done something similar to this before and this relates to that work -- this estimate has a variance of +/- 50 percent of estimate.
6. I think I understand this fairly well and I understand the goal.
7. The average case for programming when the requirements are understood.
8. A confident case for programming; average case for a lot of art work.
9. I've done this before and it's very similar.
10. I'm probably not working on software... or... no matter what, I'm only going to work on this for a period of time (i.e. 1 week of QA).

PRO TIP

It isnt a perfect science, but at GarageGames we use the following formula to calculate risk adjusted time:

Risk Adjusted Estimate = Estimate + (Estimate*(10-Confidence)/9)

34
Project Schedule

Section: Project Schedule

When will this Game be done?

35

Project Schedule
Project Schedule
You have a solid estimate sheet and you feel confident about your numbers. Next, its time to let the schedule dictate when the
project will be done.

35
Project Schedule

Project Schedule Understanding Constraints

Moving from the estimate sheet to the project schedule is fairly straightforward. To build the schedule we copy and paste directly
from excel to Microsoft Project. In Project, we consider the following constraints in order to calculate milestone and project end dates:

Dependencies
A dependency prevents a job from starting because it is dependent on another job. A classic example is that QA cant begin 36
its review until the software is feature complete (unless you are OK with the inefficiency of doing it again).

Critical Path

Project Schedule
A critical path exists when the date of a given milestone or release date is wholly dependent on a single resource. We can
reduce critical paths by balancing workload across multiple resources. Critical paths that arent resolved need to be managed
closely since their impact on a release date can be profound.

Over-allocations
Workers time should not be allocated greater than 40 hours. If you find that you need more than 40 hours from any single
employee, you project has systemic issues that need to be resolved with more money, more time, or a reduction in features.

Work Calendar & Vacations

Holidays and vacations can have a profound effect on release dates. They should be added to the project schedule.

Work Balancing
Balancing work across employees increases velocity. Conversely, working in parallel increases management overhead.

Hiring Needs
Your project schedule is a great tool to help you assess your hiring needs. Its not unusual to spend two or three months
trying to find the right hire. If you dont know well in advance, you will end up compromising your needs and make a bad hire.

36
Project Schedule

WARNING

Remember, estimates are estimates and many things will change over time. Its important to update your project schedule weekly
if you want it to be useful for the entire life of your project.
37

Project Schedule
WARNING

Dont get too granular or expect too much fidelity from your project schedule. Its a tool to use for guidance but its not perfect.
Dont be upset if someone is doing a task on Monday that is scheduled for Friday (or vice versa). We estimate in hours but we look
at the project schedule in granularities of weeks not days.

WARNING

The milestone and release dates are a function of feature count, complexity/risk, and parallel development and typical
development constraints. Until the project schedule is built, milestone dates and releases are guesses. After the project schedule
is built, milestone and release dates are educated guesses.

37
Project Schedule

WARNING

Its important to get team buy-in on the estimates. Your estimates arent nearly as important as the people who will live up to the
commitment. If you want your developers to truly commit to their work load, you need to get their buy in. 38

Project Schedule
WARNING

Generally, you should place higher risk tasks earlier in the project schedule. By doing this, you will have more time to react to
changes discovered when you actually implement the task in question.

38
Execution

Section: Execution
Now we discuss the hard part
39

Execution
Execution
Congratulations, now comes the hard part. Execution.

39
Execution

Execution - Intro
Executing your project, commonly called production, is an extremely complex process that requires highly-talented and seasoned
professionals. This document will scratch the surface of execution by discussing some of our best practices.

40
PRO TIP

At GarageGames we use a ticket tracking system to task those who are doing the work. Sharing a project schedule is not granular

Execution
enough. We use this same ticket system for tracking bugs. Customers who want to put their finger on the pulse of the project are
welcome to review the tickets at any time.

40
Execution

Execution Cadence
So far, weve not discussed agile methods. We use the aforementioned process to help us determine our path for a reasonable
horizon. We use agile methods to implement that path. The agile methods we use include:

Weekly Sprints 41
Once a week, we use the project schedule and backlog (a place to put discovered and incomplete work) to build a project
sprint. At the beginning of a sprint we commit to the work we will perform. The goal is to complete your work by the end of the
sprint.

Execution
Daily Standups
Every day we meet as a team to discuss what we did yesterday and we are doing today. The goal of this meeting is to meet
no longer than you need to in order to get your work done.

WARNING

Dont nag developers during the sprint. If youve done it right, they are committed to deliver on their promises. Measure their performance at the
end of the sprint but dont make the sprint so long that your developers fall victim to procrastination.

WARNING

Be considerate during the daily standup. You goal is to inform others so that you can work out interdependencies between the team. Its not a
time to argue implementation. Handle those discussions after the meeting.

41
Execution

Execution Vertical Slices

In order to work iteratively and reduce risk, we like to begin development by building a vertical slice. A vertical slice is a
representative set of work done at final quality. This will help discover issues early in a project when there is still time to make
adjustments.
42

PRO TIP

Execution
After developing a vertical slice, usability testing is advised. To test usability, we put new users in front of the product and ask them
to use it. If they cant use it without additional information, your product will not thrive in the real market. As game developers, we
are too experienced to represent a typical user; therefore, we must find testers that are more representative of the games
audience.

42
Conclusion

Conclusion
Thank You!
43

In closing, wed like to thank you again for choosing GarageGames for your game development service needs. The success of our
project together will hinge on our ability to collaborate effectively.

Conclusion
We hope that this guide will provide you with insight into the challenges of game development and the methods weve developed to
manage the challenge. We encourage you to share this document with everyone who we might be working with.

We would like to thank NASA for the use of the images. http://history.nasa.gov/diagrams/mercury.html

If you have any questions, please feel free to reach out directly to your point of contact or our CEO. He can be reached at
ericp@garagegames.com.

43