P ART 3.1: T EAMS AND P ROCESSES P AGE 67 S EVERAL SOFTWARE ENGINEERING METHODS ARE COMMONLY USED TO...

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


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


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


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


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


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


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


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.)


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


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.


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.

http://www.youtube.com/watch?v=XCNw4i91oYk

http://www.youtube.com/watch?v=dDsEx8FKmJU&NR=1


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.


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


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


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.)


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


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


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


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;};


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


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.


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).


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


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}


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.


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.


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.


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.


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.


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.

http://www.youtube.com/watch?v=h9RG2DVqOsU


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.


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.


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.

P ART 3.1: T EAMS AND P ROCESSES P AGE 67 S EVERAL SOFTWARE ENGINEERING METHODS ARE COMMONLY USED TO...

Documents

Transcript of P ART 3.1: T EAMS AND P ROCESSES P AGE 67 S EVERAL SOFTWARE ENGINEERING METHODS ARE COMMONLY USED TO...