THE GAME DEVELOPMENT

PROCESS

Game Programming
OUTLINE

o Teams and Processes

o Select Languages

o Debugging

o Misc (as time allows)

o AI
o Multiplayer
 INTRODUCTION

o Used to be programmers created games

o But many great programmers not great game
makers

o With budget shift, emphasis has shifted

o Game content creators are artist and designers

o Programmers can be thought of as providing

services for content
o But fate of entire game rests in their hands
 PROGRAMMING AREAS – GAME
CODE

o Everything directly related to game itself

o How camera behaves, score is kept, AI for bots, etc.

o Often in scripting language (rest is in C++, more on languages next)

o Produce faster iterations
o Allow technical designers/artists to change behaviors
o More appropriate language for domain (ex: AI probably not easiest
in C++)
PROGRAMMING AREAS – GAME ENGINE

o Support code that is not game specific

o More than just drawing pretty 3d graphics (that is
actually the graphics engine, part of the game
engine)
o Isolate game code from hardware
o ex: controller, graphics, sound
o Allows designers to concentrate on game
o Common functionality needed across game
o Serialization, network communication, pathfinding, collision
detection
 PROGRAMMING AREAS – TOOLS
o Most involve content creation
o Level editors, particle effect editors, sound editors

o Some to automate repetitive tasks (ex: convert content to game

format)
o These usually have no GUI

o Sometimes written as plug-ins for off-the-shelf tools

o Ex: extensions to Maya or 3dStudio or Photoshop

o If no such extension available, build from scratch

 PROGRAMMING TEAM
ORGANIZATION
o Programmers often specialize
o Graphics, networking, AI
o May be generalists, know something about everything
o Often critical for “glue” to hold specialists together
o Make great lead programmers
o More than 3 or 4, need some organization
o Often lead programmer, much time devoted to management
o More than 10 programmers, several leads (graphics lead, AI
lead, etc.)
SOFTWARE METHODOLOGIES

o Code and Fix

o Waterfall

o Iterative

o Agile

o (Take cs3733, Software Engineering)

 METHODOLOGIES – CODE AND
FIX
o Really, lack of a methodology
o And all too common

o Little or no planning, diving straight into implementation

o Reactive, no proactive

o End with bugs. If bugs faster than can fix, “death spiral” and may be cancelled

o Even those that make it, must have “crunch time”

o viewed after as badge of honor, but results in burnout
 METHODOLOGIES - WATERFALL

o Plan ahead
o Proceed through various planning steps before
implementation
o requirements analysis, design, implementation, testing (validation),
integration, and maintenance
o The waterfall loops back as fixes required
o Can be brittle to changing functionality,
unexpected problems in implementation
o Going back to beginning
METHODOLOGIES - ITERATIVE

o Develop for a period of time (1-2 months), get

working game, add features
o Periods can coincide with publisher milestones
o Allows for some planning
o Time period can have design before implementation
o Allows for some flexibility
o Can adjust (to new technical challenges or producer demands)
METHODOLOGIES - AGILE

o Admit things will change, avoid looking too far in the

future
o Value simplicity and the ability to change

o Can scale, add new features, adjust

o Relatively new for game development

o Big challenge is hard to convince publishers

 COMMON PRACTICES – VERSION
CONTROL

o Database containing files and past history of them

o Central location for all code

o Allows team to work on related files without overwriting

each other’s work
o History preserved to track down errors

o Branching and merging for platform specific parts

COMMON PRACTICES – QUALITY
(1 OF 2)
o Code reviews – walk through code by other
programmer(s)
o Formal or informal
o “Two eyes are better than one”
o Value is programmer aware others read
o Asserts
o Force program to crash to help debugging
o Ex: Check condition is true at top of code, say pointer not NULL
before following
o Removed during release
 COMMON PRACTICES – QUALITY (2
OF 2)
o Unit tests
o Low level test of part of game (Ex: see if physics computations correct)
o Tough to wait until very end and see if bug
o Often automated, computer runs through combinations
o Verify before assembling
o Acceptance tests
o Verify high-level functionality working correctly (Ex: see if levels load
correctly)
o Note, above are programming tests (ie- code, technical). Still turned over to
testers that track bugs, do gameplay testing.
o Bug database
o Document and track bugs
o Can be from programmers, publishers, customers
o Classify by severity
o Keeps bugs from falling through cracks
o Helps see how game is progressing

Based on Chapter 3.1, Introduction to Game Development

OUTLINE

o Teams and Processes (done)

o Select Languages (next)
o Debugging

o Misc (as time allows)

o AI
o Multiplayer
C++ (1 OF 3)
o Mid-late 1990’s, C was language of choice
o Since then, C++ language of choice for games
o First commercial release in 1985 (AT&T)
o List pros (+) and cons (-)
o (Take cs2102 OO Design Concepts or cs4233 OOAD)
+ C Heritage
o Learning curve easier
o Compilers wicked fast
+ Performance
o Used to be most important, but less so (but still for core parts)
o Maps closely to hardware (can “guess” what assembly instructions
will be)
o Can not use features to avoid cost, if want (ie- virtual function
have extra step but don’t have to use)
o Memory management controlled by user
 C++ (2 OF 3)

+ High-level
o Classes (objects), polymorphism, templates, exceptions
o Especially important as code-bases enlarge
o Strongly-typed (helps reduce errors)
o ex: declare before use, and const

+ Libraries
o C++ middleware readily available
o OpenGL, DirectX, Standard Template Library (containers,
like “vectors”, and algorithms, like “sort”)
 C++ (3 OF 3)

- Too Low-level
o Still force programmer to deal with low-level issues
o ex: memory management, pointers
- Too complicated
o Years of expertise required to master (other languages seek to
overcome, like Java and C#)
- Lacking features
o No built-in way to look at object instances
o No built-in way to serialize
o Forces programmer to build such functionality (or learn custom or
3rd party library)
- Slow iteration
o Brittle, hard to try new things
o Code change can take a looong time as can compile
C++ (SUMMARY)

o When to use?
o Any code where performance is crucial
o Used to be all, now game engine such as graphics and AI
o Game-specific code often not C++
o Legacy code base, expertise
o When also use middle-ware libraries in C++
o When not to use?
o Tool building (GUI’s tough)
o High-level game tasks (technical designers)
JAVA (1 OF 3)

o Java popular, but only recently so for games

o Invented in 1990 by Sun Microsystems
+ Concepts from C++ (objects, classes)
o Powerful abstractions
+ Cleaner language
o Memory management built-in
o Templates not as messy
o Object functions, such as virtualization
+ Code portability (JVM)
(Hey, draw picture)
+ Libraries with full-functionality built-in
 JAVA (2 OF 3)

- Performance
o Interpreted, garbage collection, security
o So take 4x to 10x hit
+ Can overcome with JIT compiler, Java Native Interface (not
interpreted)

- Platforms
o JVM, yeah, but not all games (most PC games not, nor consoles)
+ Strong for browser-games, mobile
 JAVA (3 OF 3)

o Used in:
o Downloadable/Casual games
o PopCap games
o Mummy Maze, Seven Seas, Diamond Mine
o Yahoo online games (WorldWinner)
o Poker, Blackjack
o PC
o Star Wars Galaxies uses Java (and simplified Java for scripting
language)
o You Don’t Know Jack and Who Wants to be a Millionaire all Java
SCRIPTING LANGUAGES (1 OF 3)
o Not compiled, rather specify (script) sequence of actions

o Most games rely upon some

o Trigger a few events, control cinematic

o Others games may use it lots more

o Control game logic and behavior (Game Maker has GML)

+ Ease of development
o Low-level things taken care of
o Fewer errors by programmer
- But script errors tougher, often debuggers worse
o Less technical programming required
o Still, most scripting done by programmers
o Iteration time faster (don’t need to re-compile all code)
o Can be customized for game (ex: just AI tasks)
 SCRIPTING LANGUAGES (2 OF 3)
+ Code as an asset
o Ex: consider Peon in C++, with behavior in C++, maybe art as an asset.
Script would allow for behavior to be an asset also
o Can be easily modified, even by end-user in “mod”
- Performance
o Parsed and executed “on the fly”
o Hit could be 10x or more over C++
o Less efficient use of instructions, memory management
-Tool support
o Not as many debuggers, IDEs
o Errors harder to catch
- Interface with rest of game
o Core in C++, must “export” interface
o Can be limiting way interact
o (Hey, draw picture)

Based on Chapter 3.2, Introduction to Game Development

 SCRIPTING LANGUAGES (3 OF 3)
o Python
o Interpreted, OO, many libraries, many tools
o Quite large (bad when memory constrained)
o Ex: Blade of Darkness, Earth and Beyond, Eve Online, Civilization 4 (Table
3.2.1 full list)
o Lua (pronounced: Loo-ah)
o Not OO, but small (memory). Embed in other programs. Doesn’t scale
well.
o Ex: Grim Fandango, Baldur’s Gate, Far Cry (Table 3.2.2 full list)
o Others:
o Ruby, Perl, JavaScript
o Custom: GML, QuakeC, UnrealScript
o Implementing own tough, often performs poorly so careful!
 MACROMEDIA FLASH (1 OF 2)
o More of a platform and IDE (ala Game Maker) than a language (still,
has ActionScript)
o “Flash” refers authoring environment, the player, or the application
files
o Released 1997, popular with Browser bundles by 2000
o Advantages
o Wide audience (nearly all platforms have Flash player)
o Easy deployment (embed in Web page)
o Rapid development (small learning curve, for both artists and
programmers)
o Disadvantages
o 3D games
o Performance (interpreted, etc.)

Based on Chapter 3.3, Introduction to Game Development

 MACROMEDIA FLASH (2 OF 2)

o Timeline Based
o Frames and Frame rate (like animations)
o Programmers indicate when (time) event occurs (can occur
across many frames)
o Vector Engine
o Lines, vertices, circles
o Can be scaled to any size, still looks crisp
o Scripting
o ActionScript similar to JavaScript
o Classes (as of Flash v2.0)
o Backend connectivity (load other Movies, URLs)

Based on Chapter 3.3, Introduction to Game Development

OUTLINE

o Teams and Processes (done)

o Select Languages (done)
o Debugging (next)
o Misc (as time allows)
o AI
o Multiplayer
DEBUGGING INTRODUCTION
o New Integrated Development Environments (IDEs) have
debugging tools
o Trace code, print values, profile
o But debugging frustrating
o Beginners not know how to proceed
o Even advanced can get “stuck”
o Don’t know how long takes to find
o Variance can be high
o Mini-outline
o 5-step debugging process
o Debugging tips
o Touch scenarios and patterns
o Prevention
 STEP 1: REPRODUCE THE
PROBLEM CONSISTENTLY

o Find case where always occurs

o “Sometimes game crashes after kill boss” doesn’t
help much

o Identify steps to get to bug

o Ex: start single player, skirmish map 44, find enemy
camp, use projectile weapon …
o Produces systematic way to reproduce
 STEP 2: COLLECT CLUES

o Collect clues as to bug

o But beware that some clues are false
o Ex: if bug follows explosion may think they are related, but may be from
something else
o Ex: if crash using projectile, what about that code that makes it
possible to crash?

o Don’t spend too long, get in and observe

o Ex: see reference pointer from arrow to unit that shot arrow should
get experience points, but it is may be NULL
o That’s the bug, but why is it NULL?
STEP 3: PINPOINT ERROR
o Propose a hypothesis and prove or disprove
o Ex: suppose arrow pointer corrupted during flight. Add code to
print out values of arrow in air. But equals same value that
crashes. Wrong.
o Ex: suppose unit deleted before experience point. Print out values
of all in camp before fire and all deleted. Yep, that’s it.
o Or, divide-and-conquer method (note, can use in
conjunction with hypo-test above, too)
o Sherlock Holmes “when you have eliminated the impossible,
whatever remains, however improbably, must be the truth”
o Setting breakpoints, look at all values, until discover bug
o The “divide” part means break it into smaller sections
o Ex: if crash, put breakpoint ½ way. Is it before or after? Repeat
o Look for anomalies, NULL or NAN values
 STEP 4: REPAIR THE PROBLEM

o Propose solution. Exact solution depends upon stage of

problem.
o Ex: late in code cannot change data structures. Too many
other parts use.
o Worry about “ripple” effects.

o Ideally, want original coder to fix. At least, talk with

original coder for insights.
o Consider other similar cases, even if not yet reported
o Ex: other projectiles may cause same problem as arrows did
 STEP 5: TEST SOLUTION

o Obvious, but can be overlooked if programmer is sure they

have fix (but programmer can be wrong!)
o So, test that fix repairs bug
o Best by independent tester

o Test if other bugs introduced (beware “ripple” effect)

DEBUGGING TIPS (1 OF 3)

o Question your assumptions – don’t even assume

simple stuff works, or “mature” products
o Ex: libraries can have bugs
o Minimize interactions – systems can interfere, make
slower so isolate the bug to avoid complications
o Minimize randomness – ex, can be caused by random
seed or player input. Fix input (script player) so
reproducible
 DEBUGGING TIPS (2 OF 3)

o Break complex calculations into steps – may be equation

that is fault or “cast” badly
o Check boundary conditions – classic “off by one” for
loops, etc.
o Disrupt parallel computations – “race conditions” if
happen at same time (cs3013)
o Use debugger – breakpoints, memory watches, stack …
o Check code recently changed – if bug appears, may be in
latest code (not even yours!)
DEBUGGING TIPS (3 OF 3)

o Take a break – too close, can’t see it. Remove to provide fresh
prospective
o Explain bug to someone else – helps retrace steps, and others
provide alternate hypotheses
o Debug with partner – provides new techniques

o Get outside help – tech support for consoles, libraries, …

 TOUGH DEBUGGING SCENARIOS AND
PATTERNS (1 OF 2)
o Bug in Release but not in Debug
o Often in initialized code
o Or in optimized code
o Turn on optimizations one-by-one
o Bug in Hardware but not in Dev Kit
o Usually dev kit has extra memory (for tracing, etc.). Suggest
memory problem (pointers), stack overflow, not checking
memory allocation
o Bug Disappears when Changing Something
Innocuous
o Likely timing problem (race condition) or memory problem
o Even if looks like gone, probably just moved. So keep
looking
TOUGH DEBUGGING SCENARIOS AND
PATTERNS (2 OF 2)
o Truly Intermittent Problems
o Maybe best you can do is grab all data values (and stack,
etc) and look at (“Send Error Report”)
o Unexplainable Behavior
o Ex: values change without touching. Usually memory
problem. Could be from supporting system. Retry, rebuild,
reboot, re-install.
o Bug in Someone Else’s Code
o “No it is not”. Be persistent with own code first.
o It’s not in hardware. (Ok, very, very rarely, but expect it not
to be) Download latest firmware, drivers
o If really is, best bet is to help isolate to speed them in fixing
it.
DEBUGGING PREVENTION (1 OF 2)
o Understand underlying system
o Knowing language not enough
o Must understand underlying system
o At least one level down
o Engine for scripters
o OS for engine
o Maybe two layers down (hardware, assembly)
o Add infrastructure, tools to assist
o Make general
o Alter game variables on fly (speed up)
o Visual diagnostics (maybe on avatars)
o Log data (events, units, code, time stamps)
o Record and playback capability
 DEBUGGING PREVENTION (2 OF 2)
o Set compiler on highest level warnings
o Don’t ignore warnings
o Compile with multiple compilers
o See if platform specific
o Write own memory manager (for console games,
especially, since tools worse)
o Use asserts
o Always initialize when declared
o Indent code, use comments
o Use consistent style, variable names
o Avoid identical code – harder to fix if bug
o Avoid hard-coded (magic numbers) – makes brittle
o Verify coverage (test all code) when testing
OUTLINE

o Teams and Processes (done)

o Select Languages (done)
o Debugging (done)
o Misc (as time allows)
o AI (next)
o Multiplayer
 INTRODUCTION TO AI

o Opponents that are challenging, or allies that are helpful

o Unit that is credited with acting on own

o Human-level intelligence too hard

o But under narrow circumstances can do pretty well (ex: chess and Deep
Blue)

o Artificial Intelligence (around in CS for some time)

AI FOR CS DIFFERENT THAN AI FOR
GAMES
o Must be smart, but purposely flawed
o Loose in a fun, challenging way
o No unintended weaknesses
o No “golden path” to defeat
o Must not look dumb
o Must perform in real time (CPU)
o Configurable by designers
o Not hard coded by programmer
o “Amount” and type of AI for game can vary
o RTS needs global strategy, FPS needs modeling of individual
units at “footstep” level
o RTS most demanding: 3 full-time AI programmers
o Puzzle, street fighting: 1 part-time AI programmer
AI FOR GAMES – MINI OUTLINE

o Introduction (done)
o Agents (next)
o Finite State Machines

o Common AI Techniques

o Promising AI Techniques
GAME AGENTS (1 OF 2)

o Most AI focuses around game agent

o think of agent as NPC, enemy, ally or neutral
o Loops through: sense-think-act cycle
o Acting is event specific, so talk about sense+think
o Sensing
o Gather current world state: barriers, opponents, objects
o Needs limitations : avoid “cheating” by looking at game data
o Typically, same constraints as player (vision, hearing range)
o Often done simply by distance direction (not computed as per
actual vision)
o Model communication (data to other agents) and reaction
times (can build in delay)
GAME AGENTS (2 OF 2)

o Thinking
o Evaluate information and make decision
o As simple or elaborate as required
o Two ways:
o Precoded expert knowledge, typically hand-crafted if-then rules
+ randomness to make unpredictable
o Search algorithm for best (optimal) solution
 GAME AGENTS – THINKING (1 OF 3)

o Expert Knowledge
o finite state machines, decision trees, … (FSM most popular, details
next)
o Appealing since simple, natural, embodies common sense
o Ex: if you see enemy weaker than you, attack. If you see enemy
stronger, then go get help
o Often quite adequate for many AI tasks
o Trouble is, often does not scale
o Complex situations have many factors
o Add more rules, becomes brittle
GAME AGENTS – THINKING (2 OF 3)

o Search
o Look ahead and see what move to do next
o Ex: piece on game board, pathfinding (ch 5.4)

o Machine learning
o Evaluate past actions, use for future
o Techniques show promise, but typically too slow
o Need to learn and remember
GAME AGENTS – THINKING (3 OF 3)

o Making agents stupid

o Many cases, easy to make agents dominate
o Ex: bot always gets head-shot
o Dumb down by giving “human” conditions, longer reaction
times, make unnecessarily vulnerable

o Agent cheating
o Ideally, don’t have unfair advantage (such as more attributes
or more knowledge)
o But sometimes might to make a challenge
o Remember, that’s the goal, AI lose in challenging way
o Best to let player know
AI FOR GAMES – MINI OUTLINE

o Introduction (done)

o Agents (done)

o Finite State Machines (next)

o Common AI Techniques

o Promising AI Techniques
 FINITE STATE MACHINES (1 OF 2)

o Abstract model of computation

o Formally:
o Set of states
o A starting state
o An input vocabulary
o A transition function that maps inputs and the current state
to a next state
FINITE STATE MACHINES (2 OF 2)

o Most common game AI software pattern

o Natural correspondence between states and behaviors
o Easy to diagram
o Easy to program
o Easy to debug
o Completely general to any problem

o Problems
o Explosion of states
o Often created with ad hoc structure
 FINITE-STATE MACHINE:
APPROACHES

o Three approaches
o Hardcoded (switch statement)
o Scripted
o Hybrid Approach
FINITE-STATE MACHINE:
HARDCODED FSM
void RunLogic( int * state ) {
switch( state )
{
case 0: //Wander
Wander();
if( SeeEnemy() ) { *state = 1; }
break;

case 1: //Attack
Attack();
if( LowOnHealth() ) { *state = 2; }
if( NoEnemy() ) { *state = 0; }
break;

case 2: //Flee
Flee();
if( NoEnemy() ) { *state = 0; }
break;
}
}
FINITE-STATE MACHINE:
PROBLEMS WITH SWITCH FSM
1. Code is ad hoc
o Language doesn’t enforce structure
2. Transitions result from polling
o Inefficient – event-driven sometimes better
3. Can’t determine 1st time state is entered
4. Can’t be edited or specified by game designers or players
 FINITE-STATE MACHINE:
SCRIPTED WITH ALTERNATIVE LANGUAGE

AgentFSM
{
State( STATE_Wander )
OnUpdate
Execute( Wander )
if( SeeEnemy ) SetState( STATE_Attack )
OnEvent( AttackedByEnemy )
SetState( Attack )
State( STATE_Attack )
OnEnter
Execute( PrepareWeapon )
OnUpdate
Execute( Attack )
if( LowOnHealth ) SetState( STATE_Flee )
if( NoEnemy ) SetState( STATE_Wander )
OnExit
Execute( StoreWeapon )
State( STATE_Flee )
OnUpdate
Execute( Flee )
if( NoEnemy ) SetState( STATE_Wander )
}
FINITE-STATE MACHINE:
SCRIPTING ADVANTAGES

1. Structure enforced

2. Events can be handed as well as polling

3. OnEnter and OnExit concept exists

4. Can be authored by game designers

o Easier learning curve than straight C/C++
 FINITE-STATE MACHINE:
SCRIPTING DISADVANTAGES

o Not trivial to implement

o Several months of development

o Custom compiler
o With good compile-time error feedback
o Bytecode interpreter
o With good debugging hooks and support

o Scripting languages often disliked by users

o Can never approach polish and robustness of commercial
compilers/debuggers
FINITE-STATE MACHINE:
HYBRID APPROACH
o Use a class and C-style macros to approximate a scripting
language
o Allows FSM to be written completely in C++ leveraging
existing compiler/debugger
o Capture important features/extensions
o OnEnter, OnExit
o Timers
o Handle events
o Consistent regulated structure
o Ability to log history
o Modular, flexible, stack-based
o Multiple FSMs, Concurrent FSMs
o Can’t be edited by designers or players
FINITE-STATE MACHINE:
EXTENSIONS

o Many possible extensions to basic FSM

o OnEnter, OnExit
o Timers
o Global state, substates
o Stack-Based (states or entire FSMs)
o Multiple concurrent FSMs
o Messaging
AI FOR GAMES – MINI OUTLINE

o Introduction (done)
o Agents (done)
o Finite State Machines (done)
o Common AI Techniques (next)
o Promising AI Techniques
COMMON GAME AI TECHNIQUES

o Whirlwind tour of common techniques

o (See book chapters)