csce 590e spring 2007 game programming by jijun tang
Post on 18-Dec-2015
221 views
TRANSCRIPT
CSCE 590E Spring 2007
Game Programming
By Jijun Tang
Announcements
We will meet in 2A21 on Wednesday Please bring laptops (with mouse) on
Wednesday Please install 3D Canvas Pro Flash Game due this Wednesday Small game due Friday, March 9th,
5:00pm
Game Design Presentation
Two presentations, on March 5th and March 7th.
March 5th: group A, Cheeze Puffs!, Team Swampus
March 7th: Group D, Group E, Psychosoft
Each has 20 minutes to present, 5 minutes to answer questions
Contents for the Presentation
Description, specification, goals, game play System requirement, audience, rating Interface, input/output, interactions, cameras Premise/limitations/choices/resources Content designs, audio Level designs, flexibility Use case/UML (rough) Engines to use Version control/testing strategy Brief timeline (demo date is May 2nd-9th)
Logos-so-far
3D Canvas Pro
http://www.amabilis.com/ Requires XP/2000, DirectX 9 Requires license code Installation package is available for
download After installation, enter the code under
the help menu
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)
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
Methodologies
Code and Fix Waterfall Iterative Agile
Make Coding Easier
Version control Coding standards Automated build Code review Unit testing and acceptance testing
Languages
C/C++ Java Script: Flash, Python, LISP, etc. C# XNA for PC and Xbox
Programming Fundamentals
Data Structures: Array
Elements are adjacent in memory (great cache consistency) Requires continuous memory space
They never grow or get reallocated Use dynamic incremental array concept GCC has a remalloc function
In C++ there's no check for going out of bounds Use vector if possible Keep in mind of checking boundaries
Inserting and deleting elements in the middle is expensive
List
Very cheap to add/remove elements. Available in the STL (std::list) Every element is allocated separately,
not placed contiguously in memory Lots of little allocations Bad cache awareness, but can use arrays
to hold pre-allocated items Single/Double linked list
Lists
Dictionaries
Maps a set of keys to some data. std::map, std::hash, etc Very fast access to data Perfect for mapping IDs to pointers, or
resource handles to objects May waste space, need to design
comparison operators
Hash Table
Others
Stacks First in, last out std::stack adaptor in STL
Queues First in, first out std::deque Priority queue is useful in game to schedule
events
Stack/Queue/Priority Queue
Bit packing
Fold all necessary data into a smaller number of bits
Bool in C++ may use up to 4 bytes, thus is very expensive
Very useful for storing boolean flags: pack 32 in an integer
Possible to apply to numerical values if we can give up range or accuracy
Very low level trick Use shifts to handle the operation or use assembly Only use when absolutely necessary
Bits
OO Design and Patterns
Object Oriented Design
Concepts Class
Abstract specification of a data type Instance
A region of memory with associated semantics to store all the data members of a class
Object Another name for an instance of a class
Inheritance
Models “is-a” relationship Extends behavior of existing classes by
making minor changes Do not overuse, if possible, use component
systerm UML diagram representing inheritance
E ne m y B o s s Supe rD upe rB o s s
Polymorphism
The ability to refer to an object through a reference (or pointer) of the type of a parent class
Key concept of object oriented design C++ implements it using virtual functions
Multiple Inheritance
Allows a class to have more than one base class
Derived class adopts characteristics of all parent classes
Huge potential for problems (clashes, casting, dreaded diamond, etc)
Multiple inheritance of abstract interfaces is much less error prone (virtual inheritance)
Java has no multiple inheritance
The Dreaded Diamond
Limitations of inheritance
Tight coupling Unclear flow of control Not flexible enough
A person is an employee, and a father What if the person is also an employer
Static hierarchy The inheritance hierarchy is fixed at instantiation The object's type does not change with time.
Component Systems
Use aggregation (composition) instead of inheritance
A game entity can “own” multiple components that determine its behaviour
Each component can execute whenever the entity is updated
Messages can be passed between components and to other entities
Component Systems
Component system organization
G am e E nti ty
N am e = s w o r d
R e nde rC o m p C o ll is io nC o m p D am age C o m p P ic kupC o m p W ie ldC o m p
Benefits of Component Systems
Data-Driven Composition The structure of the game entities can be
specified in data Components are created and loaded at
runtime Very easy to change (which is very
important in game development)
Analysis of Component System
Very hard to debug Performance can be a bottleneck Keeping code and data synchronized can be
a challenge Extremely flexible
Great for experimentation and varied gameplay Not very useful if problem/game is very well
known ahead of time
Design Patterns
Design pattern is a general repeatable solution to a commonly occurring problem in software design
Design patterns can speed up the development process by providing tested, proven development paradigms
Algorithm (for computation problem) is not pattern (for design)
Object Factory
Creates objects by name Pluggable factory allows for new object
types to be registered at runtime Extremely useful in game development
for passing messages, creating new objects, loading games, or instantiating new content after game ships
UML for Factory
O bje c tFac to ryP r o d u c t * C r ea teO b jec t( P r o d u c tT y p e ty p e) ;
C re ate P ro duc t
P ro duc t
Singleton
Implements a single instance of a class with global point of creation and access
For example, GUI Don't overuse it!!!
Single to ns ta tic S in g le to n & G etI n s tan c e ( ) ;/ / R eg u lar m em b er f u n c tio n s . . .
s ta t ic S in g le to n u n iq u eI n s tan c e ;
Observer
Allows objects to be notified of specific events with minimal coupling to the source of the event
Two parts subject and observer
UML for Observer
Composite
Allow a group of objects to be treated as a single object
Very useful for GUI elements, hierarchical objects, inventory systems, etc
UML for Composite
C o m po s i teO p er a tio n ( ) ;
lis t< C o m p o n en t* > c h ild r en
Spe c if ic C o m po ne ntO p er a tio n ( ) ;
C o m po ne ntO p er a tio n ( ) ;
Debugging
The Five StepDebugging Process
1. Reproduce the problem consistently
2. Collect clues
3. Pinpoint the error
4. Repair the problem
5. Test the solution
Step 1: Reproduce the Problem Consistently
Sample reproduce steps:1. Start a single player game
2. Choose Skirmish on map 44
3. Find the enemy camp
4. From a distance, use projectile weapons to attack the enemies at the camp
5. Result: 90 percent of the time the game crashes
Step 2:Collect Clues
Each clue a chance to rule out a cause Each clue a chance to narrow down
the list of suspects Realize that some clues can be
misleading and should be ignored
Step 3:Pinpoint the Error
Two main methods:1. Propose a Hypothesis
You have an idea what is causing the bug Design tests to prove or disprove your
hypothesis
2. Divide and Conquer Narrow down what could be causing the bug
Eliminate possibilities from the top down or Backtrack from the point of failure upward
Step 4:Repair the Problem
Propose solution Consider implications at point in project Programmer who wrote the code should
ideally fix the problem (or at least be consulted)
Explore other ways the bug could occur Ensure underlying problem fixed and not just a
symptom of the problem Bug trace database
Step 5:Test the Solution
Verify the bug was fixed Check original repro steps Ideally have someone else
independently verify the fix Make sure no new bugs were
introduced At the very end of the project, have
other programmers review the fix
Expert Debugging Tips
Question assumptions Minimize interactions and interference Minimize randomness Break complex calculations into steps Check boundary conditions, use assertions Disrupt parallel computations Exploit tools in the debugger (VC is good) Check code that has recently changed Explain the bug to someone else Debug with a partner (A second pair of eyes) Take a break from the problem Get outside help (call people)
Tough Debugging Scenarios
Bug exists in Release but not Debug Uninitialized data or optimization issue
Bug exists on final hardware, not dev-kit Find out how they differ – usually memory size or disc emulation
Bug disappears when changing something innocuous (e.g., add a print) Timing or memory overwrite problem
Intermittent problems Record as much info when it does happen
Unexplainable behavior Retry, Rebuild, Reboot, Reinstall
Internal compiler errors Full rebuild, divide and conquer, try other machines
Suspect it’s not your code Check for patches, updates, or reported bugs Contact console maker, library maker, or compiler maker
Understanding theUnderlying System
Knowing C or C++ not enough Know how the compiler implements code, and
optimize code Know the details of your hardware
Especially important for console development
Know some assembly and be able to read it Read memories will help Helps with optimization bugs or compiler issues
Adding Infrastructureto Assist in Debugging
Alter game variables during gameplay Visual AI diagnostics Logging capability Recording and playback capability Track memory allocation Print as much information as possible on a
crash Educate your entire team
testers, artists, designers, producers
Prevention of Bugs
Set compiler to highest warning level Set compiler warnings to be errors Compiler on multiple compilers Write your own memory manager Use asserts to verify assumptions Initialize variables when they are declared Bracket loops and if statements Use cognitively different variable names Avoid identical code in multiple places Avoid magic (hardcoded) numbers Verify code coverage when testing
Game Architecture
Overall Architecture
The code for modern games is highly complex
With code bases exceeding a million lines of code, a well-defined architecture is essential
Overall Architecture
Main structure Game-specific code Game-engine code Both types of code are often split into modules,
which can be static libraries, DLLs, or just subdirectories
Architecture types Ad-hoc (everything accesses everything) Modular DAG (directed acyclic graph) Layered
Overall Architecture
Options for integrating tools into the architecture Separate code bases (if there's no need to
share functionality) Partial use of game-engine functionality Full integration
Overview: Initialization/Shutdown
The initialization step prepares everything that is necessary to start a part of the game
The shutdown step undoes everything the initialization step did, but in reverse order
Overview: Initialization/Shutdown
Resource Acquisition Is Initialization A useful rule to minimalize mismatch errors in the
initialization and shutdown steps Means that creating an object acquires and
initializes all the necessary resources, and destroying it destroys and shuts down all those resources
Optimizations Fast shutdown Warm reboot
Overview:Main Game Loop
Games are driven by a game loop that performs a series of tasks every frame
Some games have separate loops for the front and and the game itself
Other games have a unified main loop
Overview:Main Game Loop
Tasks Handling time Gathering player input Networking Simulation Collision detection and response Object updates Rendering Other miscellaneous tasks
Overview:Main Game Loop
Structure Hard-coded loops Multiple game loops
For each major game state Consider steps as tasks to be iterated
through
Overview:Main Game Loop
Coupling Can decouple the rendering step from
simulation and update steps Results in higher frame rate, smoother
animation, and greater responsiveness Implementation is tricky and can be error-
prone
Overview:Main Game Loop
Execution order Most of the time it doesn't matter In some situations, execution order is
important Can help keep player interaction seamless Can maximize parallelism Exact ordering depends on hardware
Game Entities
What are game entities? Basically anything in a game world that can be interacted
with More precisely, a self-contained piece of logical interactive
content Only things we will interact with should become game entities
Organization Simple list Multiple databases Logical tree Spatial database
Game Entities
Updating Updating each entity once per frame can be
too expensive Can use a tree structure to impose a
hierarchy for updating Can use a priority queue to decide which
entities to update every frame
Game Entities
Object creation Basic object factories Extensible object factories Using automatic registration Using explicit registration
Game Entities
Level instantiation Loading a level involves loading both
assets and the game state It is necessary to create the game entities
and set the correct state for them Using instance data vs. template data
Game Entities
Identification Strings Pointers Unique IDs or handles
Game Entities
Communication Simplest method is function calls Many games use a full messaging system Need to be careful about passing and
allocating messages