Transcript 09/06/12 - Computer Science & Engineering

Computer Game Development
By Jijun Tang
Contents for the Presentation









Group members, group name, logo
Description, specification, goals, game play
System requirement, audience, rating
Interface, input/output, interactions, cameras
Premise/limitations/choices/resources
Content designs/3D/2D/animation, audio
Level designs, flexibility/scripting language?
Version control/testing strategy/documentation
Brief timeline (demo date is early Dec)
Homework





Game treatment document
Each group to turn in one
Due: Sept 17th, before class
Print and bring it in class
Expected page lengths 4-5 pages,
11pt font, single space.
Example of Treatment

http://www.csc.kth.se/utbildning/kth/kur
ser/DH2650/spel08/The%20Game%20
Treatment.doc
Requirement
Requirement
Requirement
Highlights
Production Details
Production Details
Game World
Game World
Examples

http://pyrrha.csisdmz.ul.ie/4075/treatment.html
Premise

Story is the typical example of premise






Time
Place
Characters
Relationships
Motivations
Etc.
Choice and Outcome

Well-designed choice



Often desirable and undesirable effects
Should relate to player goals
Balanced against neighboring choices


Too much weight to every choice is
melodrama
Orthogonal choices – distinct from others

Not just “shades of grey”
Resources/Economies

Resources


Things used by agents to reach goals
To be meaningful, they must be…



Useful – provide some value
Limited – in total or rate of supply
Economies


Systems of supply, distribution, consumption
Questions regarding game economies:




What resources exist?
How and when will resources be used?
How and when will resources be supplied?
What are their limits?
Interface

Typical perspectives:





First-person
Over-the-shoulder (OTS)
Overhead (top-down)
Side
Isometric
First person
OTS
Overhead and Side
Isometric
Audio Interface

General categories of audio

Music


Powerful tool for establishing mood and
theme
Pay attention to license issues



The campus is cited 960 times last year
Sound effects
Dialog
Example
Huds
System Design

Two general approaches to design

Special case




Experiences built one scene/level at a time
Anticipate states while pre-scripting events
Solved by discovering the intentions of the designer
Systemic




General behaviors are designed
Scenes/Levels are specific configurations
Some events may still be pre-scripted
Solved by understanding the system
Cybernetics


Study of communication, control, and
regulation
Model
Cybernetic System

A basic cybernetic system has:

Sensor – detects a condition


Comparator – evaluates the information


Thermometer
Switch
Activator – alters the environment when
triggered by the comparator
Example System
Activator
Comparator
Sensor
Feedback

Feedback:



information about the internal or external changes of system that
make the system adjust its output
The portion of a system’s output that is returned into the system
Feedback Loop

The path taken by the feedback
Goal
Rate
Action
Information
Level
Positive Feedback



Amplify changes
Leads to runaway behavior
Difficult to make use of
From Bob
Craig
Negative feedback



Counteracts changes
Leads to goal seeking behaviors
Most common form in systems
From Bob
Craig
Feedbacks in a Game

Negative feedback




Stabilizes the game
Forgives the loser
Prolongs the game
Magnifies late
successes

Positive feedback




Destabilizes the game
Rewards the winner
Can end the game
Magnifies early
successes
Platforms

Platform: General description of hardware and
software






Personal computer – PC, Mac, etc.
Console – Wii, PlayStation, Xbox, etc.
Handheld – DS, Game Boy Advance, PSP, etc.
Mobile device – Cell Phones, NGage, PDA, etc.
Arcade – custom vending games (e.g. Time Crisis)
PC Games compared to other platforms:


PC Games are developed and used in the same platform,
other platforms may require proprietary development kits.
Console games are popular because consoles are used in
a “lean-back” position, while PC is used in a “sit-forward
Game Saves

Save triggers:



Save-anywhere





Allow the player to save the state at any point in the game
Disadvantage: System needs to save many different
variables, also may make it too easy for the player
Save points:


automatically saved at certain points
Disadvantage: Player has little control
Save only the accumulated points
Disadvantage: Rather limited
Coded text saves to save a bit space
Do you really want user to save?
Genres

Genre – a category describing
generalities of conventions, style, and
content
Major Genres








Action
Adventure
Arcade
Casual
Education
Fighting
First-person
shooter
Platform








Racing
Rhythm
Role-Playing (RPG)
Simulation
Sports
Strategy
Puzzle
Traditional
Audiences

Target audience





Demographics


Group of expected consumers
Age, gender income …
What does your audience know?
What does your audience demand?
Study of relevant economic and social statistics
about a given population
Demographic variables

The relevant factors
Audiences

Market


Demographic segmentation of
consumers
Market segments: Smaller sub-segment of the
market; more tightly defined

Demographic profile
 Typical consumer attributes in a market
 Age, Social class, gender etc.
Audiences

Heavy Users



Hardcore gamer


Those of the numeric minority of potential users
responsible for majority of sales of any product
80/20 rule: in anything a few (20 percent) are vital and
many(80 percent) are trivial.
Game industry term for heavy video game users
Casual gamer

Game industry term for all other gamers
Hardcore Players







Play games over long sessions
Discuss games frequently and at length
Knowledgeable about the industry
Higher threshold for frustration
Desire to modify or extend games creatively
Have the latest game systems
Engage in competition with themselves, the game,
and others
Design Procedure

Waterfall method



Development methodology
Design and production are broken into phases
Iterative development



Practice of producing things incrementally
Refining and re-refining the product
May iterate many cycles before get it right
Waterfall vs. Iterative
testing
Prototypes

Prototypes



Physical prototypes


Early working models of the product
Used to test ideas and techniques
Non-electronic models; physical materials
Software prototypes

Used regularly during iterative development
Other Document Types







Preliminary design document
Initial Design Document
Revised Design Document
General Design Document
Expanded Design Document
Technical Design Document
Final Design Document
Communication-Flowcharts

Flowcharts


A typical technique for diagramming steps in a
process
Most developers are familiar
Start/End
Process/
Action
Decision
Y/N
Delay
Example Flowcharts
W andering
City
Start
Quest
No
Search for
Quest
No
Ye s
City
Quest Details
Ac cept
Recruit
Yes
Gather PC Allie s
Em bark/Split
Gather
Wilderness
Go to
Equip
Recruits
Seek Aid
Gear
Regroup
Artifacts
Assistance
Encounter
Communication-Diagrams

Associative diagram


Drawing that helps manage and organize information visually
Mind Map


A style of associative diagram
Key words and figures are placed on branches
weapon
fighting
range
Psychology

Working Memory



Holds roughly 7 ± 2 items at one time while
other cognitive operations on them
Each slide should not have more than 6 items
Attention



Method of enhancing perceptions relative to
other stimuli in the same environment
How we focus on important things
Limited capacity
Psychology

Classical conditioning

Reaction to stimulus is conditioned by pairing with another
stimulus that elicits the desired response naturally
Before conditioning
Conditioning
After conditioning
Psychology




Unconditioned stimulus – Meat
Unconditioned response – Salivation over meat
Conditioned stimulus – Tone
Conditioned response – Salivation over tone
Before conditioning
Conditioning
After conditioning
Psychology

Operant conditioning


Learning by encouraging or discouraging
Operant

A response; the action in question


Example: pressing a button
Reinforcement contingency

Consistent relationship between the
operant and a result in the environment
Psychology

Reinforcers


Increase the probability an action will be repeated
Positive reinforcement

Positive stimulus that reinforces the behavior


Negative reinforcement

The removal or prevention of a negative stimulus


Ex. Use umbrella and be dry
Ex. Use umbrella and keep from getting wet
Punishment

Reduces the likelihood of a behavior with a stimulus

Ex. Being burned by a hot stove
Programming Teams


In the 1980s programmers developed the
whole game (and did the art and sounds
too!)
Now programmers write code to support
designers and artists (content creators)
A Team Picture
Different Programs

Game code
Anything related directly to the game

Game engine
Any code that can be reused between
different games

Tools
In house tools
Plug-ins for off-the-shelf tools
Team Organization




Programmers often have a background
in Computer Science or sciences
They usually specialize in some area (AI,
graphics, networking) but know about all
other areas
Teams usually have a lead programmer
They sometimes have a lead for each of
the major areas
Skills and Personalities

Successful teams have a mix of
personalities and skills:
Experience vs. new ideas
 Methodical vs. visionary


But hard-working is always the key
Methodologies


A methodology describes the procedures
followed during development to create a
game
Every company has a methodology (way of
doing things), even if they don't explicitly
think about it
Methodologies: Code and Fix





Unfortunately very common
Little or no planning
Always reacting to events
Poor quality and unreliability of finished
product
“Crunch” time normal
Methodologies: Waterfall





Very well-defined steps in development
Lots of planning ahead of time
Great for creating a detailed milestone
schedule
Doesn't react well to changes
Game development is too unpredictable
for this approach
Methodologies: Iterative

Multiple development cycles during a
single project
Each delivering a new set of functionality
 Refinements are needed



The game could ship at any moment
Allows for planning but also for changes
Methodologies: Agile Methods





Deal with the unexpected
Very short iterations: 2-3 weeks
Iterate based on feedback of what was
learned so far
Very good visibility of state of game
Difficult for publishers or even
developers to adopt because it's
relatively new
Make Coding Easier





Version control
Coding standards
Automated build
Code review
Unit testing and acceptance testing
Version Control


Recommended to use for team project
Version control is





Database with all the files and history.
Only way to work properly with a team.
Branching and merging can be very useful
Used for source code as well as game assets (text
and binary)
Tools:



CVS is one of the most popular tool
Source anywhere
SVN
Coding standards

Coding standards are




Set of coding rules for the whole team to follow
Improves readability and maintainability of the code
Easier to work with other people's code
They vary a lot from place to place



Some simple, some complex
Get used to different styles
Sample standards can be found at: http://www.chrislott.org/resources/cstyle/CppCodingStandard.html
Automated builds




Dedicated build server builds the game
from scratch
Takes the source code and creates an
executable
Also takes assets and builds them into
game-specific format
Build must never break
Quality Control

Code reviews





Knowing others will read the code will make coding
more carefully
Another programmer reads over some code and tries
to find problems
Sometimes done before code is committed to version
control
Can be beneficial if done correctly
Follow coding standards, and put comments
Avoid Run-time Errors


Run-time errors are hardest to trace and have the biggest
damage
Initialize variables, use tools (Visual .Net is good at this), check
boundaries, etc.



purify on Windows
valgrind on Linux
Asserts and crashes





Use asserts anytime the game could crash or something could go
very wrong
An assert is a controlled crash in the debug version
Much easier to debug and fix
Happens right where the problem occurred
Don't use them for things that a user could do


Open a non-existing file
Press the wrong button