Game
Development
Presented by Jason Kratzke
What is a Game?
 Many
conflicting definitions
 Set of interesting choices?
 Engaging play?
 Narrative?
 Only one consensus: rules
Game Rules
 Have



many different purposes
Restriction
Freedom
Balance
 Good
rules = fun!
Evolution of Game
Development
 Began
with small teams
 Originally not commercial

First game for consumers: Spacewar (1962)
 Team
sizes grew
 Games became complex

Planning/process necessary
Game Development Cycle
 Preproduction



Concept
Requirements
Implementation Plan
 Production
 Testing
 Postproduction
The Teams
 Art

Visual and audio experience
 Design

Game features and world
 Engineering

Implementation and asset pipeline
 Quality

Assurance
Test plan and balance
Preproduction: Game
Concept
 Often
begins as a simple idea or question
 Must be expanded



Target audience
Genre
Platform
 The
most important decision for a game
Competitive Analysis
 Identify
competition
 Strengths vs. competition
 Weaknesses vs. competition
 Exploit strengths
 Downplay weaknesses
Game Pitch
 Make
publisher(s) excited for the idea
 Create early prototypes


Polish prototypes within their limited scope
A good prototype can create early hype
 Listen
to publisher feedback
 Present competitive analysis
Preproduction: Game
Requirements
 Requirement

Gaming market is competitive
 Prevent

quality is important
function creep
“Wouldn’t it be cool if…” can lead to
severe function creep
Creating Requirements
 Gathering



is different
Customer is entire audience
No designated person to get requirements
from
Entire team helps
 Remember

past games
What has worked and what hasn’t?
Feature Decisions
 Features


should fit game concept
Not the other way around
Even great-sounding features follow this rule
 Example:

futuristic shooter game
Team member visualizes/describes the
greatest turn-based combat feature ever
 The
feature would be completely absurd in
the game; do not include it.
Importance of Features
 Features


must be prioritized
Important (core) features must be done
before “frills”
Cuts down on “function creep”
 Game
must distinguish itself from
competition

Game-specific features impress publishers
Preproduction: Game
Implementation Plan
 High

probability of failure without a plan
Just like any software!
 Game-specific



planning
More art than other software
Balance testing
Extra prototypes
Planning for Art
 Games

require enormous amounts of art
Levels, characters, objects, music, etc.
 Concept
art – introduces visual style
 Assets needed early on

Early builds can use placeholders
 Even
placeholders must be created first
 Scheduling
voice actors
Important Game Milestones
 Alpha


general criteria
50% art done (rest placeholders)
All core features finished
 Code
Complete – no more feature
revisions
 Beta – anticipated by many

When game features (minor and major)
finished
Production
 All
game assets are created and
integrated
 Stage most often associated with
development

Would be difficult without preproduction
 Relies
heavily on good plan & hard work
 Requires strong team skills
Production: Artists’ Work
 Art



Visual and audio work together
Defines the game’s atmosphere
Inspires emotions to involve players
 Art

is extremely important for games
must support the game’s concept
Example: colorful, strange artwork for a
game of absurdity (e.g. Katamari Damacy)
Other Benefits of Good Art
 Draws
in those who do “judge a book by
its cover”
 Makes games feel more realistic or
fantastic
 Minor gameplay complaints can be
overshadowed by powerful art or music
 Great interface art improves menus
Production: Designers’ Work
 Constantly
reviewing features
 Features as implemented must match
“feel” of the game
 Tweaking and improving features
 Occasionally feature must be redesigned


A complete redesign is expensive
Should only be done if the feature does not
fit with game concept as was thought
The Game World
 Designers
expand the game world
 Create all major and minor world details


Most important done in preproduction
Gaps (and gaping holes) filled in during
production
 Story
development draws in players
 Plot must still support game concept
Story Detail
 Level



of story detail depends on game
Games based on reality need little
background
Fantasy requires building entire worlds
Role-Playing Games (RPGs) need rich
worlds, characters, and history
 Well-known
example: Final Fantasy
Level Design
 Level
– the area or context of a player’s
actions
 Traditional “levels” or locations in a larger
world
 Levels define the gameplay experience
 Often what makes or breaks a game
Artificial Intelligence
 Comes
in many levels of complexity
 Desired effect determines
implementation

Examples: A guard patrolling around a
building needs simple AI, but a tough
computer opponent in a strategy game
requires complex AI
 Can
add to immersion
Player Rewards
 Important
for motivation
 Types of rewards vary




Meeting the challenge
Gaining power
Changing the game world
Many others
 Must
be meaningful
Game Balance
 Balance:
remaining between extremes
 Extremely important in games
 More important in multiplayer games
 Most important: risk vs. reward and power
balance


Risk vs. Reward: make no choice clearly
superior or inferior
Power: maintain challenge without creating
frustration
Multiplayer Considerations
 Multiplayer
rewarding


balance: difficult yet
All players must have equal opportunities
for success
Imbalance = boring for overly powerful,
frustrating for less powerful
 Communities

form
Decide how to support game’s
communities
Production: Engineers’ Work
 Implement


Software
Hardware
 Ensure


features according to plan
hardware can handle features
Features may require redesign if hardware is
inadequate
Worst case: feature goes unimplemented
due to hardware/software constraints
Asset Pipeline
 Pipeline
allows assets (art, music, etc.) to
be added to games
 Sometimes simply involves converting files
 Require specific organization
 Must be kept as simple as possible

Short pipelines avoid human error
Production: Quality Assurance
 Create
test plan for all features
 Test features as soon as they are available
 Game-specific test areas




Fun
Immersion
Pacing
None of these are quantifiable!
More Balance
 QA

is also concerned with balance
Some game aspects are quantifiable
 Balancing
on these can be achieved through
mathematics

How does one balance those that aren’t?
 1.
Testing!
 2. Modification!
 3. Back to step 1!

Total balance – almost impossible
 Must
decide what is close enough
Testing
 Generally
starts during production
 When production ends, testing continues
 Important testing deadlines:



Alpha: ensure features fit the game
Code freeze: no new features to be added
Beta: Remove most of the elusive bugs
 Second
 Final
purpose: increase game visibility
goal of testing: ready game to be
shipped
Alpha Testing
 Purpose:
ensure all features fit game
concept & work together
 Starting point varies

Normally when 50% of art assets finished, all
core features implemented
 Primary
question: Do the features make
the game feel like a fun, cohesive whole?
 Generally done by in-house testers
Code Freeze
 Also
known as code complete
 No new features to be added
 Generally occurs after alpha finishes
 Does not mean the game is done

Only means functionality is set
 Interactions
between functionality must
be verified
 Balance is generally not complete
Beta Testing
 Final
thorough testing effort
 For games, usually done by players
 Useful for finding obscure defects
 Great way to test game balance
 Adding new features during beta: danger

Easily leads to function creep
 Need
clear system for reporting issues
Finishing Testing
 End-of-testing

Remove remaining defects
 Except




goals
those deemed “will not fix”
Create release candidate
Check release candidate against entire
test plan
Console manufacturer/licensor approval
Finally, create gold master
Postproduction
 Plenty
of work left
 New features, fixes added in patches

Defects left behind in games are exploited
 This

can destroy balance!
Most online games are expected to be
patched
 Review
development process
Postmortem
 Important





questions
Did we achieve our goals for the game?
Were the project’s expectations realistic?
What went right?
What went wrong?
What lessons did we learn?
 Player
feedback answers many of these
 Continually improve development
process
Conclusion
 Games

Usually more than other software
 Games




require planning
are different
Art and music
Balance
Emotional appeal
Most importantly: Fun!
References




Chandler, Heather Maxwell and Rafael. (2011).
Fundamentals of Game Development.
Sudbury, MA: Jones and Bartlett Learning.
Flynt, John P. (2005). Software Engineering for
Game Designers. Boston, MA: Thomson
Course Technology PTR.
Kremers, Rudolf. (2009). Level Design: Concept,
theory, & practice. Natick, MA: A K Peters, Ltd.
Schell, Jesse. (2008). The Art of Game Design: A
book of lenses. Burlington, MA: Morgan
Kaufmann Publishers.