Transcript 09/17/12 - Computer Science & Engineering

Computer Game Development
By Jijun Tang
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.
Choice and Outcome

Choice


Outcome


A question asked of the player
The end result of a given choice
Possibility space


Represents the set of possible events
A “landscape” of choice and outcome
Choice and Outcome

Consequence or Weight

The significance of an outcome


Greater consequences alter the course of the
game more significantly
Choices are balanced first by
consequence
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”
Qualities of Choice

Terms in which to discuss choices








Hollow – lacking consequence
Obvious – leaves no choice to be made
Uninformed – arbitrary decision
Dramatic – strongly connects to feelings
Weighted – good and bad in every choice
Immediate – effects are immediate
Long-term – effects over extended period
Orthogonal – choices distinct from each other
Goals and Objectives

Objectives

Designed tasks players must perform


Rigid requirements – formal
Goals

An intentional outcome


Notions that direct player action
Scales all levels of motivation


From selecting particular strategies…
…to basic motor actions (e.g. pressing a button)
Goals and Objectives
Find sword
Rescue dragon
Kill princess
Find sword
Kill dragon
Rescue princess
Designer

System
User
Objectives and goals can differ


Players goals reflect their understanding of the game
Designers must consider how the game communicates with
players

Affordances – the apparent ways something can be used
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?
Player Strategy
Situation

Result
People usually reason with commonsense


Action
A view of linear causation – cause and effect
Complex systems do not behave linearly

Players need information to support linear
strategy
Game Theory

Game Theory



Utility


A measure of desire associated with an outcome
Payoffs


Branch of economics
Studies decision making
The utility value for a given outcome
Preference

The bias of players towards utility
Game Theory

Rational Players

Abstract model players – not real people



Always try to maximize their potential utility
Solve problems using pure logic
Always fully aware of the state of the game
Game Theory

Games of skill



Games of Chance



One-player games
Outcomes determined solely by choices
One-player games
Outcomes determined in whole or part by nature (chance)
Games of Strategy

Competitions between two or more players
Game Theory

Decision under certainty


Risky decisions


Players know the outcome of any
decision
Probabilities of nature are known
Decision under uncertainty

Probabilities of nature are unknown
Testing

Software testing: Process of verifying performance
and reliability of a software product

Tester: Person trained in methods of evaluation, may be
the first job in the industry for a fresh graduate

Bug: Discrepancy between expected and actual behavior

Problem/Bug report: Description of the behavior of the
discrepancy
Testing Types

Unit test



Focus test





written from the developer's perspective
focus on particular methods of the class under test
Testing session using play-testers
Testers represent the target audience
Lots of feedback at one time
Data can be compromised by group think
Acceptance test
Unit Testing





With very large codebases, it's difficult to
make changes without breaking features
Unit tests make sure nothing changes
Test very small bits of functionality in
isolation
Build them and run them frequently
Good test harness is essential
Unit Test
Acceptance Testing




Also called functional tests
High level tests that exercise lots of
functionality
They usually run the whole game checking
for specific features
Having them automated means they can
run very frequently (with every build)
Bug Report and Trace





Bug database
Keep a list of all bugs, a description, their
status, and priority
Team uses it to know what to fix next
Gives an idea of how far the game is from
shipping
Doesn't prevent bugs, just helps fix them
more efficiently
Bug Report
Balancing

Tuning




Developing solutions by adjusting systems
Iterations are faster
Changes are less dramatic
Balance:


Equilibrium in a relationship
Player relationships, mechanics, systems, etc.
Balancing

Intransitive relationships



Multiple elements offer weaknesses and strengths relative
to each other as a whole
Balanced as a group
Example: Rock-Paper-Scissors (RPS)
Heavy
Infantry
Archers
Cavalry
Creativity


Ability to create
Ability to produce an idea, action, or
object considered new and valuable
Classic Approach to Creativity





Preparation: Background research and
comprehension
Incubation: Mulling things over
Insight: Sudden illumination – Eureka!
Evaluation: Validating revealed insights
Elaboration: Transforming the idea into substance
Brainstorming


Generating ideas without discrimination
Evaluation after elaboration, can be
unfocused
Inspiration

Board games






Team competition
Temporal systems
Martial arts


Serialized stories
Music


Continuity techniques
Television

Fantasy and agency
Sports


Dynamic narratives
Books
Film

Resource management
Paper RPGs


Spatial relationships
Card games


Discipline in action
Children

Invention
Communication

Documentation


Methods vary widely
Written, descriptive model of the game


Depth varies according to the needs of the game
Development documentation
 Docgen

Wikidot
Communication

Treatment: A brief, general description of the

game and the fundamental concepts
Used to sell and show off your idea
May include:









Concept statement
Goals and objectives
Core mechanics and systems
Competitive analysis
Licensing and IP information
Target platform and audience
Scope
Key features
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