p art 3.1: t eams and p rocesses p age 67 s everal software engineering methods are commonly used to...
TRANSCRIPT
PART 3.1: TEAMS AND PROCESSES
PAGE 1
SEVERAL SOFTWARE ENGINEERING METHODS ARE COMMONLY USED TO CREATE VIDEO GAMES.
METHOD 1: EXTREME GAME PROGRAMMING(AKA: “CODE LIKE HELL, FIX LIKE HELL”)
DESIGN
CODE
TEST
DELIVER
ARGUMENTS FOR…• CODING WITH TOO MUCH PLANNING
CAN BE AS BAD AS CODING WITH NO PLANNING AT ALL
• TENDS TO MAKE PROGRAMMERS TACKLE THE BIG PROBLEMS EARLIER RATHER THAN COMING UP WITH (POSSIBLY FAULTY) SOLUTIONS TO THE SMALLER PROBLEMS THAT ARE DISCARDED LATER
ARGUMENTS AGAINST…• THE FRANTIC PACE OF THE PROCESS IS
TOO STRESSFUL FOR MOST DEVELOPERS
• ERRORS ARE NOT SYSTEMATICALLY ELIMINATED AND SOMETIMES ARE NOT DETECTED AT ALL
• ONLY SUITED FOR SMALL PROJECTS WITH SIMPLE REQUIREMENTS (I.E., NOT GAMES)
TEAMS AND PROCESSES
PART 3.1: TEAMS AND PROCESSES
PAGE 2
METHOD 2: CLEANROOM SOFTWARE ENGINEERING(AKA: “INCREMENT-TO-COMPLETION”)
ARGUMENTS FOR…• PROMOTES PARALLEL DEVELOPMENT
OF INDEPENDENT FEATURES• RELIES HEAVILY ON SYSTEM
INTEGRATION, SO A PLAYABLE VERSION OF THE GAME IS AVAILABLE EARLY IN THE PROCESS
ARGUMENTS AGAINST…• PARALLEL EFFORTS REQUIRE HIGH
DEGREE OF COORDINATION TO BE SUCCESSFUL
• LOWER LEVEL DESIGN IS ALWAYS IN FLUX, WITH SPECIFICATIONS THAT ARE HARD TO DOCUMENT UNTIL AFTER FULL IMPLEMENTATION
GAME DESIGN –
HIGH LEVEL REQUIREME
NTS
TEST
INTEGRATE WITH
FULL GAME
INITIAL LOWE
R LEVEL DESIG
NS
KEY SYSTEM DESIGN A
(E.G., RENDERING)
KEY SYSTEM DESIGN B
(E.G., GAME LOGIC)
CODE
PRE-INTEGRATION SYSTEM TEST
TEST
INTEGRATE WITH
FULL GAME
CODE
PRE-INTEGRATION SYSTEM TEST
PART 3.1: TEAMS AND PROCESSES
PAGE 3
METHOD 3: CASCADE DEVELOPMENT(AKA: “THE WATERFALL METHOD”)
ARGUMENTS FOR…• ELIMINATES COMMON UNCERTAINTIES
BY REQUIRING EXTENSIVE UP-FRONT PLANNING
• YIELDS ACCURATE SCHEDULE AND COMPLETION ESTIMATION
ARGUMENTS AGAINST…• RELIES HEAVILY ON CORRECT DECISIONS
AT THE BEGINNING OF THE DEVELOPMENT PROCESS
• DOES NOT ACCOMMODATE SIGNIFICANT ALTERATIONS TO GAME FEATURES
HIGH LEVEL GAME DESIGN LOWER
LEVEL FEATURES DESIGN CODING &
MODULE TESTING
INTEGRATION & SYSTEM TESTING DELIVERY
& MAINTENANCE
PART 3.1: TEAMS AND PROCESSES
PAGE 4
METHOD 4: ITERATIVE DEVELOPMENT(AKA: “THE SPIRAL METHOD”)
ARGUMENTS FOR…• FLEXIBLY ALLOWS THE
DEFINITION, DESIGN, AND DEVELOPMENT TO BE ADJUSTED THROUGHOUT THE ENTIRE PROCESS
• PERMITS DYNAMIC REACTION TO COMPETITIVE MARKET DEMANDSARGUMENTS AGAINST…
• FREQUENTLY RESULTS IN “FEATURE CREEP”, WITH CONSTANT CHANGES TO BOTH BUDGET AND TIMELINE
• TEMPTS DEVELOPERS TO SHORT-CHANGE HIGH-LEVEL DESIGN IN FAVOR OF AD HOC ADJUSTMENTS
PART 3.1: TEAMS AND PROCESSES
PAGE 5
METHOD 5: AGILE PROJECT MANAGEMENT(AKA: “ADAPTIVE SOFTWARE DEVELOPMENT”)
ARGUMENTS FOR…• SIMPLIFIES THE DEVELOPMENT
PROCESS TO A MINIMAL SET OF PRACTICES THAT MAY BE ADAPTED FOR EACH PROJECT AND EACH DEVELOPMENT ENVIRONMENT
• WELL SUITED TO PROJECT MOBILITY AND SPEED
ARGUMENTS AGAINST…• DOES NOT PRESCRIBE SPECIFIC
PRACTICES, SO GETTING STARTED CAN SEEM PROBLEMATIC
• GAME PUBLISHERS MAY HAVE DIFFICULTY ACCEPTING THIS APPROACH UNLESS THEY VIEW THEMSELVES AS CUSTOMERS WHO CONTROL THE LIST OF PRIORITIES
PART 3.1: TEAMS AND PROCESSES
PAGE 6
PRODUCER• DAY-TO DAY SUPERVISION OF DIRECT REPORTS• REVIEW OF WEEKLY TASK LISTS• EVALUATION OF RESOURCE ALLOCATION• ASSIGNMENT OF PERSONNEL TO SPECIFIC GAME
FEATURES• MAINTAINING COHESIVE AND CONSISTENT TEAM
VISION• MANAGEMENT OF OUTSIDE CONTRACTORS• FACILITATING COMMUNICATION AND DECISION-
MAKING• PROACTIVE IDENTIFICATION OF POTENTIAL
PROBLEMS• ENSURING THAT THE TEAM IS FULLY STAFFED AND
SUPPLIED• PROVIDING FEEDBACK AND PERFORMANCE
REVIEWS FOR TEAM
PRODUCTION TEAM MEMBERS
PART 3.1: TEAMS AND PROCESSES
PAGE 7
ASSISTANT PRODUCER• PROJECT MANAGEMENT AND GAME DESIGN
EVALUATION• INTERFACING WITH AND SUPPORTING
DEVELOPERS, LICENSORS, AND MARKETING• DESIGN DOCUMENTATION REVIEW• TRACKING TEAM MEMBERS’ PROGRESS
ACCORDING TO SCHEDULE• INTERACTING WITH QUALITY ASSURANCE TEAM• COORDINATING INFORMATION RELEASED TO
GAME FANS• ASSISTING IN THE FULFILLMENT OF THE
PRODUCER’S RESPONSIBILITIES
PART 3.1: TEAMS AND PROCESSES
PAGE 8
EXECUTIVE PRODUCER• OFFERING CREATIVE INPUT AND DIRECTION
TO GUIDE THE BRAND TO A SUCCESSFUL PLACE WITHIN THE MARKET
• LEADING THE GLOBAL BUSINESS EFFORT AND VISION FOR A BRAND
• CLARIFYING THE VISION FOR THE BRAND, CONVEYING IT TO OTHER DEPARTMENT EXECUTIVES AND INTERNAL LEADERS
• RECEIVING REPORTS FROM PRODUCERS AND ASSISTANT PRODUCERS, AS WELL AS VARIOUS TEAM LEADS (LEAD PROGRAMMER, LEAD DESIGNER, LEAD ARTIST, ETC.)
PART 3.1: TEAMS AND PROCESSES
PAGE 9
PRODUCT PLANNER• DEVELOPING AND DEFINING THE FUTURE
OF A GAME, A FRANCHISE, OR EVEN A PRODUCT PERIPHERAL
• PLANNING FOR NEW CONSOLES, CONTROLLERS, HEADSETS, NETWORKING CAPABILITIES, ETC.
PROGRAM MANAGER• COMMUNICATING AS THE VOICE OF THE GAME
TEAM TO OTHER DEPARTMENTS, INCLUDING MARKETING
• CONTRIBUTING TO SPECIFICATION WRITING AND MANAGING DEPENDENCIES BETWEEN SOFTWARE GROUPS
DEVELOPMENT DIRECTOR• MENTORING, TRAINING, AND COACHING
DEVELOPERS• DEFINING INITIAL PROJECT SCOPES AND DELIVERY
SCHEDULES• IDENTIFYING RISKS AND PRIORITIZING OBJECTIVES
PART 3.1: TEAMS AND PROCESSES
PAGE 10
PRODUCTION ASSISTANTS• INTERNING AT THE GROUND LEVEL, DOING
MUNDANE TASKS IN ADMINISTRATIVE WORK, SOFTWARE TESTING, MEETING PREPARATION, NOTE TAKING, ETC.
• LEARNING THE ROPES TO GAIN THE EXPERIENCE NEEDED TO BECOME ASSISTANT PRODUCER, PRODUCER, ETC.
PART 3.1: TEAMS AND PROCESSES
PAGE 11
PROGRAMMING PLATFORMSWITH DIFFERENT OPERATING SYSTEMS, VIDEO AND AUDIO CAPABILITIES, AND COMMUNICATION FUNCTIONALITIES, SELECTING A GAME PLATFORM IS A CHALLENGE AND DEVELOPING CROSS-PLATFORM GAMES IS PARTICULARLY DIFFICULT.
PART 3.1: TEAMS AND PROCESSES
PAGE 12
CROSS-PLATFORM PROGRAMMING
TWO COMMON APPROACHES TO DEVELOPING A GAME FOR MULTIPLE PLATFORMS:• PLATFORM AGNOSTIC – DEPEND ON PRE-EXISTING SOFTWARE
THAT HIDES PLATFORM DIFFERENCES (E.G., JAVA VIRTUAL MACHINE).• SOURCE TREES - DEVELOP MULTIPLE VERSIONS OF THE SAME
GAME FOR THE VARIOUS DESIRED PLATFORMS.AMONG THE PROBLEMS WITH CROSS-PLATFORM DEVELOPMENT:• EACH PLATFORM MUST BE TESTED SEPARATELY DUE TO SUBTLY
DIFFERENT BEHAVIOR.• THE TENDENCY IS FOR DEVELOPERS TO “DUMB DOWN” THE GAME
TO THE PLATFORM WITH THE LEAST ADVANCED FEATURES.• WITH SOURCE TREES, SEPARATE TEAMS OFTEN DEVELOP FOR
SEPARATE PLATFORMS, YIELDING INCONSISTENT VERSIONS OF THE GAME, INCLUDING DIFFERENT SETS OF DEFECTS.
PART 3.2: C++, JAVA, ANDSCRIPTING LANGUAGES
PAGE 13
C++, JAVA, AND SCRIPTING LANGUAGESPROGRAMMING GAME CODE FOR A PARTICULAR GAME, INCLUDING AI FOR CHARACTERS, CAMERA POSITIONING AT VARIOUS STAGES OF THE GAME, AND OTHER GAME-SPECIFIC FEATURES, OFTEN EMPLOYS SCRIPTING LANGUAGES.
PART 3.2: C++, JAVA, ANDSCRIPTING LANGUAGES
PAGE 14
THE PROS OF SCRIPTING LANGUAGES
• ALLOW FOR COMPLEX ENTITY CREATION WITHOUT RECOMPILING THE ENTIRE GAME ENGINE
• COMPLETELY PORTABLE TO OTHER PLATFORMS• AFFORD LESS OPPORTUNITY TO CRASH A
SYSTEM, YIELDING A MESSAGE INSTEAD OF LOCKING UP
• USUALLY PERMIT LOAD-ON-DEMAND, WITH ONLY SECTIONS CURRENTLY IN USE IN THE GAME LOADED
• PERMIT COMPLEX USER-MODIFICATION OF GAMES
PART 3.2: C++, JAVA, ANDSCRIPTING LANGUAGES
PAGE 15
THE CONS OF SCRIPTING LANGUAGES• USUALLY LACK SYMBOLIC DEBUGGERS, MAKING
DEBUGGING MUCH MORE COMPLICATED• SCRIPTS ARE USUALLY COMPILED AT RUN-TIME,
CAUSING SIGNIFICANT SLOWDOWNS COMPARED TO HIGH-LEVEL LANGUAGES LIKE C++
• IF THEY’RE POWERFUL ENOUGH TO DO ANYTHING SOPHISTICATED (E.G., AI), THEN THEY’RE COMPLEX ENOUGH TO NEED ADVANCED PROGRAMMING SKILLS
PART 3.2: C++, JAVA, ANDSCRIPTING LANGUAGES
PAGE 16
C++ VS. JAVA
C++ STRENGTHS• HIGH PERFORMANCE• OOP FEATURES (E.G.,
POLYMORPHISM)• EXTENSIVE LIBRARIES• BACKWARDS
COMPATIBLE WITH C
JAVA STRENGTHS• IMPROVED
PERFORMANCE• MODERN FEATURES
(E.G., OBJECT SERIALIZATION)• EXTENSIVE LIBRARIES• LESS COMPLICATED,
WITH SHORT LEARNING CURVE
C++ GAMES• PC GAMES• CONSOLE GAMES• ONLINE MULTIPLAYER
GAMES
JAVA GAMES• CASUAL GAMES• BROWSER GAMES• MOBILE GAMES
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 17
PROGRAMMING FUNDAMENTALSSEVERAL STANDARD DATA STRUCTURES FIGURE PROMINENTLY IN GAME PROGRAMMING…
VECTORS & MATRICESFACILITATE THE IMPLEMENTATION OF LINEAR ALGEBRA FORMULAS IN GRAPHICS AND ANIMATION
DICTIONARIES & HASH TABLESFACILITATE THE IMPLEMENTATION OF MASSIVE LOOK-UP TABLES FOR AUDIO AND VISUAL ASSOCIATIONS
STACKS & QUEUESMANAGE THE APPLICATION OF AFFINE TRANSFORMATIONS (TRANSLATIONS, ROTATIONS, SCALING) AND ENTITY INTERACTIONS (COLLISIONS, MULTIPLAYER COMMANDS, ETC.)
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 18
DATA STRUCTURE:LAYERED ISOMETRIC GRID
ONE COMMON GAME DATA STRUCTURE IS THE MAP, WHICH IS BASED ON AN ARRAY OF CELLS, EACH OF WHICH HAS AN ASSOCIATED TERRAIN TYPE, STRUCTURE TYPE, AND POINTERS TO MOBILE GAME UNITS (TROOPS, CREATURES, ETC.).
Direction Adjacency Location
North (x, y-1)
Northeast (x, y-1) if y is even(x+1, y – 1) if y is odd
East (x+1, y)
Southeast (x, y+1) if y is even(x+1, y+1) if y is odd
South (x, y+2)
Southwest (x-1, y+1) if y is even(x, y+1) if y is odd
West (x-1, y)
Northwest (x-1, y-1) if y is even(x, y-1) if y is odd
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 19
DATA STRUCTURE: PARTICLE SYSTEMTO MODEL CERTAIN NON-POLYGONAL OBJECTS (E.G., SPLASHING WATER, EXPLOSIONS, SMOKE), A SYSTEM OF HUNDREDS OR THOUSANDS OF SMALL PARTICLES MAY BE USED, WITH EACH PARTICLE HAVING ITS OWN ATTRIBUTES.
FIELD TYPE
Position Vector
Velocity Vector
Color Vector
Energy Integer
Size Float
Transparency Float
TimeToLive Integer
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 20
DATA STRUCTURE: SUBDIVISION SURFACEWHEN 3D OBJECTS ARE DISTANT FROM THE VIEWER, THEIR LEVEL OF DETAIL CAN BE LOW, WHILE WHEN THEY’RE NEAR THE VIEWER, THE LEVEL OF DETAIL MUST BE HIGH.SUBDIVISION SURFACES ARE USED TO EXPAND A 3D MODEL LACKING DETAILS INTO A MORE ELABORATE MODEL.
DATA STRUCTURE
DESCRIPTION
Vertex (x,y,z) coordinate info
Triangle Three vertex objects
Triangular Mesh Array of triangles
Adjacency Matrix 2D table of vertex adjacencies
Triangle Subdivider
Drives triangular mesh subdivision
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 21
DATA STRUCTURE:INTERACTIVE MUSIC SEQUENCERAN INTERACTIVE MUSIC SEQUENCER PROVIDES THE INTERACTION OF COMPUTER GAMES WITH THE IMMERSIVE QUALITIES OF MUSIC.// Note: The red fields are the
// interactive features.
typedef list< Sequence * > SequencePtrList_t;typedef list< Track * > TrackPtrList_t;typedef list< Voice * > VoicePtrList_t;
class MusicSequencer_t{ MusicSequencerState_t State; SequencePtrList_t ActiveSequencePtrList; SequencePtrList_t FreeSequencePtrList; TrackPtrList_t ActiveTrackPtrList; TrackPtrList_t FreeTrackPtrList; VoicePtrList_t ActiveVoicePtrList; VoicePtrList_t FreeVoicePtrList;};
class SequenceState_t { Tempo_t Tempo; Volume_t Volume;};
class Sequence_t{ SequenceState_t State; SequenceState_t BeginState; SequenceState_t EndState; SequenceInterpolator_t Interpolator; TimeUnit_t TimeElapsed; TimeUnit_t TimeStep; CallbackFunc_t *pCallback; TrackPtrList_t TrackPtrList;};
class TrackState_t{ Volume_t Volume; PitchBend_t PitchBend; Pan_t Pan; Effect_t Effect;};
class Track_t{ TrackState_t State; TrackState_t BeginState; TrackState_t EndState; TrackInterpolator_t Interpolator; Sequence *pOwner; char *pEvent; Instrument_t *pInstrument; VoicePtrList_t VoicePtrList;};
class VoiceState_t{ SynthVolume_t Volume; SynthPitch_t Pitch; SynthPan_t Pan; SynthEffect_t Effect;};
class Voice_t{ VoiceState_t CurrentState; VoiceState_t BeginState; VoiceState_t EndState; VoiceInterpolator_t Interpolator; Track_t *pOwner; char nKey;};
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 22
DATA STRUCTURE: SPRING NODEONE METHOD FOR IMPLEMENTING ANIMATED CLOTH IS TO PLACE INVISIBLE SPRING NODES AT VERTEX LOCATIONS WITHIN THE CLOTH.
FIELD TYPE
Position Vector
Velocity Vector
Force Vector
Mass Float
Neighbor List Linked list of other spring nodes
Distance List Parallel list of neighbor distances
Neighbor Count IntegerONE REASONABLE MODEL HAS EACH NODE CONNECTED TO…• ITS NEAREST
NEIGHBORS (VERTICAL AND HORIZONTAL) BY STRONG STRETCH SPRINGS
• ITS DIAGONAL NEIGHBORS BY WEAKER SHEAR SPRINGS
• ALL OF ITS NEIGHBORS BY WEAK BEND SPRINGS
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 23
DATA STRUCTURE: BSP TREETO EFFICIENTLY DETERMINE THE ORDER IN WHICH POLYGONS SHOULD BE RENDERED, BINARY SPACE PARTITIONING TREES ARE USED.IN THIS DOOM-LIKE LAYOUT, THE GAME DEVELOPER WANTS THE PLAYER TO SEE INTO ADJACENT ROOMS (AND SOMETIMES THROUGH THOSE ROOMS INTO ADDITIONAL ROOMS), BUT THE 80-ROOM LAYOUT MAKES DETERMINING WHAT’S VISIBLE SOMEWHAT PROBLEMATIC.
THE LAYOUT SURFACES ARE USED TO PERFORM A BINARY SPACE PARTITIONING (UP TO A CERTAIN DEPTH).
IN ADDITION, THE OPTICAL CONNECTIVITY IS DETERMINED BETWEEN THE VARIOUS ROOMS AND CORRIDORS, USING DOORS AND WINDOWS TO DETERMINE VIABLE ADJACENCIES.
THIS INFORMATION IS THEN COMBINED TO QUICKLY DETERMINE OVERALL VISIBILITY BETWEEN ROOMS.
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 24
BIT PACKING FORNETWORK COMPRESSION
NETWORK GAMES NEED
TO SEND GAME STATE
INFORMATION SUCH AS
POSITION, VELOCITY,
ACCELERATION, AND STATUS
FLAGS, BUT STORAGE
BYTES ARE OFTEN
PADDED WITH BITS
CONTAINING NO REAL
INFORMATION.
struct NetData{ unsigned char MsgType; // 0 - 28 1 byte unsigned long Time; // 0 - 0xFFFFFFFF 4 bytes unsigned short Element; // 148 - 1153 4 bytes int XPosition; // -100,000 – 100,000 4 bytes int YPosition; // -100,000 – 100,000 4 bytes};
struct NetData : public BitPackCodec<5>{ PkUint<unsigned char, 5> MsgType; // 5 bits PkUint<unsigned long> Time; // 32 bits PkUint<unsigned short, 148, 1153> Element; // 10 bits PkUint<int, -100000, 100000> XPosition; // 18 bits PkUint<int, -100000, 100000> YPosition; // 18 bits};
BASIC STRUCTURE WITHOUT BIT PACKING: 136 BITS
BASIC STRUCTURE WITH BIT PACKING: 83 BITS
WHILE THE USE OF BIT PACKING GREATLY REDUCES THE BANDWIDTH REQUIREMENTS FOR NETWORK GAMING, IT COMPLICATES DEBUGGING AND SLOWS DOWN PERFORMANCE (DUE TO THE LINEAR TIME COMPLEXITY OF THE PACKING AND UNPACKING OPERATIONS).
PART 3.3: PROGRAMMING FUNDAMENTALS
PAGE 25
OBJECT-ORIENTED VS.COMPONENT-BASEDTRADITIONAL OBJECT ORIENTATION USES AN INHERITANCE HIERARCHY TO DEFINE THE CHARACTERISTICS OF GAME ELEMENTS.
Object
Renderable Object Logical Object
Spawn Point Trigger BoxParticle System Physics Object
Animatable Object Collectable Object
Weapon HealthpackActor Door Gem
HOW CAN WEAPONS BE MADE
ANIMATABLE?HOW CAN DOORS
AND GEMS BE MADE
DESTRUCTIBLE, BUT NOT ACTORS
AND WEAPONS?Entity:
Weapon
Rendering Component
Animating Component
Collecting Component
Entity: Door
Rendering Component
Animating Component
Destroying Component
COMPONENT-BASED PROGRAMMING RELIES ON AGGREGATE BEHAVIOR, I.E., ASSIGNING EACH GAME ENTITY A SET OF BEHAVIORS AND FUNCTIONALITIES.
THE FLEXIBILITY
OF COMPONENTS
AND THEIR RELIANCE ON
RUN-TIME MESSAGE PASSING
COMPLICATES DEBUGGING
AND PERFORMANC
E.
PART 3.4: GAME ARCHITECTUREPAGE 26
GAME ARCHITECTURECERTAIN ASPECTS OF CODE ARE UNIQUE TO GAME PROGRAMS. INITIALIZATION CODE TO SET
UP THE WINDOWS AND INTERFACES, AND TO LOAD
DATA FROM EXTERNAL FILES
UPDATE INPUT FROM DEVICES LIKE THE KEYBOARD OR
JOYSTICK, AND UPDATE THE MUSIC
STATE TABLEINTERPRET CURRENT
USER INPUT, UPDATE
ONSCREEN CHARACTERS, DRAW MAP,
PERFORM CURRENTLY
LOADED EFFECTS
LOAD GAMES, GENERATE
CHARACTERS, PURCHASE ITEMS, SET EQUIPMENT, PLOT TEXTBOXES
(HEALTH, WEAPONS, ETC.)
HANDLE TURNS,
ACTIVATING THE AI
FOR ENEMIES
AND ACTIVATIN
G THE MENU
SYSTEM FOR
CHARACTERS
RUN CURRENTLY
LOADED SCRIPTS
RELEASE ALL
CREATED OBJECTS,
DEALLOCATE MEMORY,
SHUT DOWN THE PROGRAM
PART 3.4: GAME ARCHITECTUREPAGE 27
GAME TIMINGWHILE COMPUTERS RUN AT DIFFERENT SPEEDS, WE WANT GAMES TO RUN AT THE SAME SPEED ON ANY COMPUTER.GAME CODE MAY BE SPLIT INTO DRAWING CODE, WHICH RENDERS THE
ACTUAL GRAPHICS, AND LOGIC CODE, WHICH ENSURES THAT EVENTS OCCUR AT THE APPROPRIATE TIME.// If the computer’s too fast, don’t move// anything (like the right-moving pixel// in this code) until its time comes up.typedef struct{ int x, y, dx; DWORD speed; DWORD next_time;} pixel_t;
pixel_t pix;pix.x = 0;pix.y = 20;pix.dx = 1;pix.speed = 20;pix.next_time = 0;
while ( !done ) { if ( timeGetTime() > pix.next_time ) { pix.x += pix.dx; // move pixel right pix.next_time = timeGetTime() + pix.speed; } ClearScreen(); Pixel(pix.x, pix.y, RGB(0,255,0)); // draw pixel}
// If the computer’s too slow to draw everything as fast// as the logic dictates, then the logic must be run in// a non-drawing loop, to catch up prior to redrawing.DWORD master_time, now, catch_up;master_time = timeGetTime();
while ( !done ){ now = timeGetTime(); catch_up = now - master_time; while ( catch_up-- ) // run logic once for each // 'tick' missed while drawing { if ( now > pix.next_time ) { pix.x += pix.dx; // move pixel right pix.next_time = now + pix.speed; } } master_time = timeGetTime(); ClearScreen(); Pixel(pix.x, pix.y, RGB(0,255,0)); // draw pixel
// in a real game, all drawing could take a // while; master_time would allow it to be // noticed that more than one 'tick' has passed}
PART 3.4: GAME ARCHITECTUREPAGE 28
GAME PARALLELISMREDESIGNING GAME ENGINES TO TAKE ADVANTAGE OF MULTIPLE PROCESSORS CAN IMPROVE GAME PLAY WITHOUT SACRIFICING FRAME RATES.
MULTITHREADING INEFFICIENCIES MIGHT RESULT, HOWEVER.
FOR EXAMPLE, THE SECOND COLLISION DETECTION COMPUTATION AT RIGHT CANNOT TAKE ADVANTAGE OF THE FIRST CHARACTER ANIMATION COMPUTATION (WHICH IS INCOMPLETE), SO IT YIELDS THE SAME RESULT AS THE FIRST CD COMPUTATION.
SIMILARLY, THE THIRD RENDER COMPUTATION LACKS UPDATED CA DATA, SO RENDERING A NEW FRAME AT THIS POINT HAS DUBIOUS VALUE.
PART 3.4: GAME ARCHITECTUREPAGE 29
GAME ENGINE
PROGRAMMING PLATFORM-SPECIFIC, BUT NOT GAME-SPECIFIC, CODE TO SUPPORT MULTIPLE GAMES WITH COMMON FUNCTIONALITY, INCLUDING GRAPHICS RENDERING, AUDIO CONTROL, CONTROLLER INTERACTION, MULTIPLAYER NETWORK SUPPORT, PHYSICAL COLLISION DETECTION, AND AI PATHFINDING.
PART 3.4: GAME ARCHITECTUREPAGE 30
PLUG-IN TOOLS
EXTENDING EXISTING COMMERCIAL OFF-THE-SHELF MODELING TOOLS BY ADDING PLUG-INS TO ENABLE EDITORS FOR GAME LEVELS, SPECIAL EFFECTS, SOUND, PHYSICS, AI, ETC., IS A CRITICAL MEANS FOR IMPROVING THE RAPID DEVELOPMENT OF GAME PROGRAMS.
PART 3.5: MEMORY AND I/O SYSTEMSPAGE 31
MEMORY AND I/O SYSTEMSWITH TENS OF THOUSANDS OF ASSETS IN SOME GAMES (E.G., TEXTURES, BITMAPS, SOUNDS, MUSIC, SOURCE CODE FILES), THE MISPLACEMENT, CORRUPTION, OR ACCIDENTAL LOSS OF ASSETS.
THE HUGE INCREASES IN MEMORY REQUIREMENTS IN MODERN GAME SYSTEMS DICTATE THAT EFFICIENT ALLOCATION STRATEGIES AND EFFECTIVE ELIMINATION OF FRAGMENTATION BE IMPLEMENTED.
Atari 2
600 (1977)
Magnav
ox Odyss
ey 2 (1
978)
Atari 5
200 (1982)
ColecoVisio
n (1982)
Nintendo N
ES (1
985)
Sega
Mast
er Syst
em (1985)
Atari 7
800 (1986)
Turb
oGrafx 1
6 (1989)
Sega
Genesis (1
989)
Nintendo Su
per NES
(1991)
Atari Ja
guar
(1993)
Sega
Satu
rn (1
994)
Sony P
laysta
tion (1995)
Nintendo 64 (1
996)
Sega
Dream
cast (
1999)
Sony P
S2 (2
000)
Nintendo Gam
eCube (2001)
Microso
ft Xbox (2002)
Microso
ft Xbox 360 (2
005)
Nintendo W
ii (2006)
Sony P
S3 (2
006)
Wii U
(2012)
PS4/X
box One (2
013)
128
192
1600
0
4800
0
2000
2400
0
2000
0
7200
0
1280
00
2560
00
2000
000
2000
000
3512
000
4000
000
2600
0000
3600
0000
3200
0000
6400
0000
5120
0000
0
8800
0000
2560
0000
0
2000
0000
00
8000
0000
00
Game Console RAM(in bytes)
RAMPART 3.5: MEMORY AND I/O
SYSTEMSPAGE 32
CONSOLE MEMORY HISTORYAS WITH PERSONAL COMPUTERS, GAME CONSOLES HAVE EXPERIENCED AN EXPLOSION OF MEMORY CAPACITY, FREEING GAME DEVELOPERS TO ENHANCE THE VIDEO AND AUDIO OF GAMES, AS WELL AS THEIR PHYSICS AND AI.
PART 3.5: MEMORY AND I/O SYSTEMSPAGE 33
SERIALIZATIONGAME STATE INFORMATION OFTEN MUST BE STORED IN ORDER TO…
…SAVE A GAME FOR CONTINUED PLAY LATER.…SEND AN ON-LINE PLAYER’S STATUS ACROSS A NETWORK.…REVISIT GAME LOCALES PREVIOUSLY ALTERED DURING PLAY.SERIALIZATION PROBLEMS INCLUDE:
• DEALING WITH POINTERS, SINCE SAVING MEMORY LOCATIONS WILL RESULT IN CRASHES WHEN THE GAME IS RESTORED.• OBJECTS IN THE GAME MUST BE SEPARATED INTO STATIC
RESOURCES (SPRITES, TEXTURES, SOUNDS, ETC.) AND DYNAMIC ENTITIES (OWNED WEAPONS, CHARACTER LOCATION, CAMERA ORIENTATION, INDIVIDUAL HEALTH, ETC.), WITH ONLY THE ENTITIES BEING SAVED.• DECISIONS REGARDING THE PRESERVATION OF SMALL DETAILS
MUST BE MADE, E.G., IS EACH PARTICLE IN AN EXPLOSION’S PARTICLE SYSTEM STORED?
PART 3.6: DEBUGGING GAMESPAGE 34
DEBUGGING GAMESWITH THE DEVELOPMENT OF MULTITHREADED GAME CAPABILITIES ON MULTIPROCESSOR WORKSTATIONS, WITH GPUS AND NETWORK CONNECTIONS, GAME PROGRAM DEBUGGING ENCOUNTERS ADDITIONAL OBSTACLES.RACE CONDITIONS
//// Race.cpp//// Example of a race condition////
#include <windows.h>#include <stdio.h>#include <process.h>
int g_iResult = 100;bool g_bThreadOneFinished = false;bool g_bThreadTwoFinished = false; void ThreadOne(void*){ // Wait some random amount of time Sleep(rand()); // Set the result g_iResult = 50; // Finished g_bThreadOneFinished = true ; _endthread();}
void ThreadTwo(void*){ // Wait some random amount of time Sleep(rand()); // Set the result g_iResult = 150; // Finished g_bThreadTwoFinished = true ; _endthread();}
int main(){ // Start the threads _beginthread(ThreadOne, 0, NULL); _beginthread(ThreadTwo, 0, NULL); // Wait for the threads to finish while ((g_bThreadOneFinished == false) || (g_bThreadTwoFinished == false)) { Sleep(1); } // Print the result printf("Result: %i\n", g_iResult);}
IF ThreadOne ASSIGNS 50 TO g_iResult BEFORE ThreadTwo ASSIGNS 150, THEN 150 IS PRINTED; OTHERWISE, 50 IS PRINTED.
RACE CONDITIONS ARE NOTORIOUSLY HARD TO DEBUG,
SINCE THEY OFTEN DISAPPEAR WHEN A
DEBUGGER IS ATTACHED OR TRACE
MESSAGES ARE ATTACHED.
A COMMON SOLUTION IS TO GIVE ONE
THREAD EXCLUSIVE ACCESS TO A
“SHARED” RESOURCE, LETTING OTHER
THREADS ACCESS IT VIA INTER-THREAD COMMUNICATION.
PART 3.6: DEBUGGING GAMESPAGE 35
MULTITHREADED DEBUGGING PROBLEM 2DEADLOCK
//// Deadlock.cpp//// Example of a deadlock////
#include <windows.h>#include <stdio.h>#include <process.h>HANDLE g_hMutexOne;HANDLE g_hMutexTwo;
bool g_bThreadOneFinished = false;bool g_bThreadTwoFinished = false;
void ThreadOne(void*){ // Get first mutex printf("ThreadOne ask for g_hMutexOne\n"); WaitForSingleObject(g_hMutexOne, INFINITE); printf("ThreadOne gets g_hMutexOne\n"); // Wait some time, so second thread // can get second mutex Sleep(100); // Try to get second mutex. Waits // indefinitely as second mutex is // already owned by ThreadTwo printf("ThreadOne ask for g_hMutexTwo\n"); WaitForSingleObject(g_hMutexTwo, INFINITE); printf("ThreadOne gets g_hMutexTwo\n"); // Release the two mutex ReleaseMutex(g_hMutexTwo); ReleaseMutex(g_hMutexOne); // Finished g_bThreadOneFinished = true; _endthread();}
void ThreadTwo(void*){ // Get second mutex printf("ThreadTwo ask for g_hMutexTwo\n"); WaitForSingleObject(g_hMutexTwo, INFINITE); printf("ThreadTwo gets g_hMutexTwo\n"); // Wait some time, so first thread // can get first mutex Sleep(100); // Try to get first mutex. Waits indefinitely // as first mutex is already owned by ThreadOne printf("ThreadTwo ask for g_hMutexOne\n"); WaitForSingleObject(g_hMutexOne, INFINITE); printf("ThreadTwo gets g_hMutexOne\n"); // Release the two mutex ReleaseMutex(g_hMutexOne); ReleaseMutex(g_hMutexTwo); // Finished g_bThreadTwoFinished = true; _endthread();}
int main(){ // Create the two mutex g_hMutexOne = CreateMutex(NULL, false, NULL); g_hMutexTwo = CreateMutex(NULL, false, NULL); // Start threads _beginthread(ThreadOne, 0, NULL); _beginthread(ThreadTwo, 0, NULL); // Wait for threads to finish while ((g_bThreadOneFinished == false) || (g_bThreadTwoFinished == false)) Sleep(1); // Free the two mutex CloseHandle(g_hMutexTwo); CloseHandle(g_hMutexOne);}
EACH THREAD WAITS INDEFINITELY FOR THE RESOURCE IN THE OTHER THREAD’S POSSESSION.
EASY FIXES INCLUDE PROHIBITING THREADS FROM TRYING TO OWN MULTIPLE LOCKS SIMULTANEOUSLY, AND FORCING THREADS TO LOCK ALL NEEDED RESOURCES BEFORE STARTING UP.
PART 3.6: DEBUGGING GAMESPAGE 36
MULTITHREADED DEBUGGING PROBLEM 3MISMATCHED COMMUNICATION
//// Mistmatched.cpp//// Show mismatched communication//
#include <windows.h>#include <stdio.h>#include <process.h>HANDLE g_hMutex;
char g_achMessage[64];bool g_bThreadOneFinished = false;bool g_bThreadTwoFinished = false;
void ThreadOne(void*){ do { // Wait some time Sleep(1); // Get access to the message WaitForSingleObject(g_hMutex, INFINITE); // If we get an OK message, send // an OK message to ThreadTwo if (0 == strcmp(g_achMessage, "ThreadOne: OK")) { printf("ThreadOne received a message\n"); printf("ThreadOne send a message to ThreadTwo\n"); strcpy(g_achMessage, "ThreadTwo: OK"); g_bThreadOneFinished = true; } // Free access to the message ReleaseMutex(g_hMutex); } while (g_bThreadOneFinished == false); // Clean up _endthread();}
void ThreadTwo(void*){ do { // Wait some time Sleep(1); // Get access to the message WaitForSingleObject(g_hMutex, INFINITE); // If we get an OK message, finish the // thread. Unfortunately, the message we // are waiting for is not the right one if (strcmp(g_achMessage, "ThreadTwo: NOTOK") == 0) { printf("ThreadTwo received a message\n"); g_bThreadTwoFinished = true; } // Free access to the message ReleaseMutex(g_hMutex); } while (g_bThreadTwoFinished == false); // Clean up _endthread();}
int main(){ // Initialize the message strcpy(g_achMessage, ""); // Create the mutex g_hMutex = CreateMutex(NULL, FALSE, NULL); // Start the threads _beginthread(ThreadOne, 0, NULL); _beginthread(ThreadTwo, 0, NULL); // Send a message to ThreadOne printf("Main send a message to ThreadOne\n"); WaitForSingleObject(g_hMutex, INFINITE); strcpy(g_achMessage, "ThreadOne: OK"); ReleaseMutex(g_hMutex); // Wait for the threads to finish while ((g_bThreadOneFinished == false) || (g_bThreadTwoFinished == false)) Sleep(1); // Free the mutex CloseHandle(g_hMutex);}
THE MESSAGE RECEIVED BY ONE THREAD ISN’T THE ONE IT’S WAITING FOR.ONE OF THE EASIEST WAYS TO CATCH THIS PROBLEM IS THE USE OF MESSAGE QUEUES THAT RECORD THE SYSTEM STATE WHENEVER PENDING OR UNEXPECTED MESSAGES ARE SENT OR RECEIVED.
PART 3.6: DEBUGGING GAMESPAGE 37
GAME CHEATSUNDETECTED BUGS IN GAME CODE ARE FREQUENTLY EXPLOITED BY AVID PLAYERS, WHO DEVELOP “CHEATS” THAT PROVIDE THEM WITH ABILITIES THAT AREN’T PART OF THE GAME’S DESIGN.EXAMPLE #1: DIABLO’S TOWNKILL CHEATTHE STARTING TOWN IN DIABLO WAS INTENDED TO BE A SAFE ZONE WHERE PLAYERS COULDN’T ATTACK EACH OTHER.
HOWEVER, EVEN THOUGH IT WASN’T POSSIBLE TO ATTACK OTHER PLAYERS THROUGH THE GAME’S USER INTERFACE, HACKERS WERE STILL ABLE TO FORCE THE GAME TO SEND A MESSAGE OVER THE NETWORK SAYING ESSENTIALLY “I HIT YOU FOR 20 POINTS OF DAMAGE”.
WITH DIABLO’S NETWORK MODEL, OTHER COMPUTERS IN THE GAME WOULD SIMPLY ACCEPT THE MESSAGE AND DUTIFULLY SUBTRACT 20 HIT POINTS FROM THEIR CHARACTER. THE PROBLEM: ASYNCHRONOUS PEER-TO-PEER NETWORKING, IN WHICH EACH PLAYER’S COMPUTER IS RESPONSIBLE FOR MODELING HIS CHARACTER AND ALL OF HIS CHARACTER’S INTERACTIONS WITH THE WORLD, AND NOTIFYING OTHER COMPUTERS OF THE RESULTS.
PART 3.6: DEBUGGING GAMESPAGE 38
EXAMPLE #2: STARCRAFT’S MAPHACK CHEAT
IN STARCRAFT, THE PLAYER’S COMPUTER ALWAYS KNOWS WHAT THE OTHER
PLAYERS IN THE GAME ARE DOING, EVEN THOUGH IT DOESN’T NORMALLY DISPLAY
THAT INFORMATION TO THE PLAYER.
THE MAPHACK CHEAT MODIFIES THE GAME TO DISPLAY THE POSITION AND ACTION OF
EVERY UNIT ON THE ENTIRE MAP, WHETHER THE PLAYER HAS EXPLORED
THAT PART OF THE MAP OR NOT.
THIS CREATES A SEVERELY UNBALANCED PLAYING FIELD SINCE A PLAYER WITH A FULL MAP VIEW CAN LOOK INTO EVERY ENEMY’S BASE AND JUDGE PRECISELY
WHAT FORM OF ATTACK THE OPPONENT CAN MOUNT.
THE PROBLEM: SYNCHRONOUS PEER-TO-PEER NETWORKING, IN WHICH COMPUTERS ONLY SEND MOUSE AND KEYBOARD INPUT OVER THE NETWORK, IN ORDER TO GUARANTEE THAT THERE IS NOTHING A PLAYER CAN DO TO GIVE HIMSELF GREATER ABILITIES THAN THE GAME INTENDED HIM TO HAVE. UNFORTUNATELY, TO ACCOMPLISH THIS, COMPUTERS SEE TOO MUCH INFORMATION ABOUT WHAT THE OTHER PLAYERS IN THE GAME ARE DOING.
PART 3.6: DEBUGGING GAMESPAGE 39
EXAMPLE #3: ASHERON CALL’S ITEM DUPING CHEAT
PLAYERS TAKE A VALUABLE ITEM IN THEIR INVENTORY AND MAKE AN EXACT COPY OF IT BY
FINDING AND EXPLOITING A BUG IN THE PROGRAM.
TRYING UNUSUAL COMBINATIONS OF ACTIONS THAT HAVE NOT BEEN TESTED BEFORE, THEY
DETERMINE A COMBINATION THAT WILL CONSISTENTLY CRASH THE GAME SERVER.
TO DUPLICATE A VALUABLE ITEM, THEY SIMPLY HAND IT TO AN ACCOMPLICE, WHO THEN
IMMEDIATELY LOGS OFF, CAUSING HIS CHARACTER TO BE SAVED TO DISK.
THEN THEY CRASH THE SERVER BEFORE IT HAS AN OPPORTUNITY TO SAVE THEIR OWN
CHARACTER TO DISK.
WHEN THE SERVER COMES BACK UP, BOTH PLAYERS HAVE THE ITEM IN THEIR INVENTORIES.
THE PROBLEM: CLIENT-SERVER NETWORKING SETS THE CENTRAL SERVER UP AS THE ONLY COMPUTER THAT KNOWS WHAT ALL PLAYERS IN THE GAME ARE DOING, AND KNOWS THE ENTIRE STATE OF THE GAME. THE SERVER SENDS TO THE CLIENTS JUST THOSE EVENTS THAT THEY SHOULD BE ABLE TO SEE, ENSURING THAT THE CLIENTS CAN’T DO ANYTHING THEY’RE NOT SUPPOSED TO DO, AND THEY CAN’T SEE ANYTHING THEY’RE NOT SUPPOSED TO SEE. UNFORTUNATELY, IF THE SERVER CAN BE MADE TO CRASH, THE RESTORATION PROCESS MAY HAVE UNDESIRABLE CONSEQUENCES.
PART 3.6: DEBUGGING GAMESPAGE 40
GAME TESTINGTWO COMMON SOFTWARE TESTING METHODOLOGIES ARE ALSO APPLIED TO COMPUTER GAMES.
BLACK BOX TESTINGTHE TESTER HAS NO ACCESS TO OR KNOWLEDGE OF THE SOURCE CODE,
ATTEMPTING TO FIND DEFECTS BY USING THE SAME INPUT APPROACHES AS A
NORMAL PLAYER.
IT’S EASIER TO CONDUCT AND OFTEN IDENTIFIES EXTREMELY SURPRISING
FLAWS.
WHITE BOX TESTINGTHE TESTER IS MORE FAMILIAR WITH THE
INTERNAL SETUP OF THE GAME CODE AND ATTEMPTS TO TEST EVERY COURSE
OF ACTION THAT MIGHT LEAD TO AN ERROR.
IT’S MUCH MORE THOROUGH AND MAY BE EMPLOYED FOR BOTH MODULE AND
SYSTEM TESTS.