2. P ART 3.1: T EAMS AND P ROCESSES P AGE 67 S EVERAL SOFTWARE ENGINEERING METHODS ARE COMMONLY USED TO CREATE VIDEO GAMES. M ETHOD 1: E XTREME G AME P ROGRAMMING ( AKA : “C ODE L IKE H ELL, F IX L IKE H ELL ”) D ESIGN C ODE T EST D ELIVER A RGUMENTS F OR … C ODING WITH TOO MUCH PLANNING CAN BE AS BAD AS CODING WITH NO PLANNING AT ALLC ODING WITH TOO MUCH PLANNING CAN BE AS BAD AS CODING WITH NO PLANNING AT ALL T ENDS TO MAKE PROGRAMMERS TACKLE THE BIG PROBLEMS EARLIER RATHER THAN COMING UP WITH ( POSSIBLY FAULTY ) SOLUTIONS TO THE SMALLER PROBLEMS THAT ARE DISCARDED LATERT ENDS TO MAKE PROGRAMMERS TACKLE THE BIG PROBLEMS EARLIER RATHER THAN COMING UP WITH ( POSSIBLY FAULTY ) SOLUTIONS TO THE SMALLER PROBLEMS THAT ARE DISCARDED LATER A RGUMENTS A GAINST … T HE FRANTIC PACE OF THE PROCESS IS TOO STRESSFUL FOR MOST DEVELOPERST HE FRANTIC PACE OF THE PROCESS IS TOO STRESSFUL FOR MOST DEVELOPERS E RRORS ARE NOT SYSTEMATICALLY ELIMINATED AND SOMETIMES ARE NOT DETECTED AT ALLE RRORS ARE NOT SYSTEMATICALLY ELIMINATED AND SOMETIMES ARE NOT DETECTED AT ALL O NLY SUITED FOR SMALL PROJECTS WITH SIMPLE REQUIREMENTS ( I. E., NOT GAMES )O NLY SUITED FOR SMALL PROJECTS WITH SIMPLE REQUIREMENTS ( I. E., NOT GAMES ) T EAMS AND P ROCESSES

3. P ART 3.1: T EAMS AND P ROCESSES P AGE 68 M ETHOD 2: C LEANROOM S OFTWARE E NGINEERING ( AKA : “I NCREMENT - TO -C OMPLETION ”) A RGUMENTS F OR … P ROMOTES PARALLEL DEVELOPMENT OF INDEPENDENT FEATURESP ROMOTES PARALLEL DEVELOPMENT OF INDEPENDENT FEATURES R ELIES HEAVILY ON SYSTEM INTEGRATION, SO A PLAYABLE VERSION OF THE GAME IS AVAILABLE EARLY IN THE PROCESSR ELIES HEAVILY ON SYSTEM INTEGRATION, SO A PLAYABLE VERSION OF THE GAME IS AVAILABLE EARLY IN THE PROCESS A RGUMENTS A GAINST … P ARALLEL EFFORTS REQUIRE HIGH DEGREE OF COORDINATION TO BE SUCCESSFULP ARALLEL EFFORTS REQUIRE HIGH DEGREE OF COORDINATION TO BE SUCCESSFUL L OWER LEVEL DESIGN IS ALWAYS IN FLUX, WITH SPECIFICATIONS THAT ARE HARD TO DOCUMENT UNTIL AFTER FULL IMPLEMENTATIONL OWER LEVEL DESIGN IS ALWAYS IN FLUX, WITH SPECIFICATIONS THAT ARE HARD TO DOCUMENT UNTIL AFTER FULL IMPLEMENTATION G AME D ESIGN – H IGH L EVEL R EQUIREMENTS T EST I NTEGRATE WITH F ULL G AME I NITIAL L OWER L EVEL D ESIGNS K EY S YSTEM D ESIGN A ( E. G., R ENDERING ) K EY S YSTEM D ESIGN B ( E. G., G AME L OGIC ) C ODE P RE -I NTEGRATION S YSTEM T EST T EST I NTEGRATE WITH F ULL G AME C ODE P RE -I NTEGRATION S YSTEM T EST

4. P ART 3.1: T EAMS AND P ROCESSES P AGE 69 M ETHOD 3: C ASCADE D EVELOPMENT ( AKA : “T HE W ATERFALL M ETHOD ”) A RGUMENTS F OR … E LIMINATES COMMON UNCERTAINTIES BY REQUIRING EXTENSIVE UP - FRONT PLANNINGE LIMINATES COMMON UNCERTAINTIES BY REQUIRING EXTENSIVE UP - FRONT PLANNING Y IELDS ACCURATE SCHEDULE AND COMPLETION ESTIMATIONY IELDS ACCURATE SCHEDULE AND COMPLETION ESTIMATION A RGUMENTS A GAINST … R ELIES HEAVILY ON CORRECT DECISIONS AT THE BEGINNING OF THE DEVELOPMENT PROCESSR ELIES HEAVILY ON CORRECT DECISIONS AT THE BEGINNING OF THE DEVELOPMENT PROCESS D OES NOT ACCOMMODATE SIGNIFICANT ALTERATIONS TO GAME FEATURESD OES NOT ACCOMMODATE SIGNIFICANT ALTERATIONS TO GAME FEATURES H IGH L EVEL G AME D ESIGN L OWER L EVEL F EATURES D ESIGN C ODING & M ODULE T ESTING I NTEGRATION & S YSTEM T ESTING D ELIVERY & M AINTENANCE

5. P ART 3.1: T EAMS AND P ROCESSES P AGE 70 M ETHOD 4: I TERATIVE D EVELOPMENT ( AKA : “T HE S PIRAL M ETHOD ”) A RGUMENTS F OR … F LEXIBLY ALLOWS THE DEFINITION, DESIGN, AND DEVELOPMENT TO BE ADJUSTED THROUGHOUT THE ENTIRE PROCESSF LEXIBLY ALLOWS THE DEFINITION, DESIGN, AND DEVELOPMENT TO BE ADJUSTED THROUGHOUT THE ENTIRE PROCESS P ERMITS DYNAMIC REACTION TO COMPETITIVE MARKET DEMANDSP ERMITS DYNAMIC REACTION TO COMPETITIVE MARKET DEMANDS A RGUMENTS A GAINST … F REQUENTLY RESULTS IN “ FEATURE CREEP ”, WITH CONSTANT CHANGES TO BOTH BUDGET AND TIMELINEF REQUENTLY RESULTS IN “ FEATURE CREEP ”, WITH CONSTANT CHANGES TO BOTH BUDGET AND TIMELINE T EMPTS DEVELOPERS TO SHORT - CHANGE HIGH - LEVEL DESIGN IN FAVOR OF AD HOC ADJUSTMENTST EMPTS DEVELOPERS TO SHORT - CHANGE HIGH - LEVEL DESIGN IN FAVOR OF AD HOC ADJUSTMENTS

6. P ART 3.1: T EAMS AND P ROCESSES P AGE 71 M ETHOD 5: A GILE P ROJECT M ANAGEMENT ( AKA : “A DAPTIVE S OFTWARE D EVELOPMENT ”) A RGUMENTS F OR … S IMPLIFIES THE DEVELOPMENT PROCESS TO A MINIMAL SET OF PRACTICES THAT MAY BE ADAPTED FOR EACH PROJECT AND EACH DEVELOPMENT ENVIRONMENTS IMPLIFIES THE DEVELOPMENT PROCESS TO A MINIMAL SET OF PRACTICES THAT MAY BE ADAPTED FOR EACH PROJECT AND EACH DEVELOPMENT ENVIRONMENT W ELL SUITED TO PROJECT MOBILITY AND SPEEDW ELL SUITED TO PROJECT MOBILITY AND SPEED A RGUMENTS A GAINST … D OES NOT PRESCRIBE SPECIFIC PRACTICES, SO GETTING STARTED CAN SEEM PROBLEMATICD OES NOT PRESCRIBE SPECIFIC PRACTICES, SO GETTING STARTED CAN SEEM PROBLEMATIC G AME PUBLISHERS MAY HAVE DIFFICULTY ACCEPTING THIS APPROACH UNLESS THEY VIEW THEMSELVES AS CUSTOMERS WHO CONTROL THE LIST OF PRIORITIESG AME PUBLISHERS MAY HAVE DIFFICULTY ACCEPTING THIS APPROACH UNLESS THEY VIEW THEMSELVES AS CUSTOMERS WHO CONTROL THE LIST OF PRIORITIES

7. P ART 3.1: T EAMS AND P ROCESSES P AGE 72 P RODUCER D AY - TO DAY SUPERVISION OF DIRECT REPORTSD AY - TO DAY SUPERVISION OF DIRECT REPORTS R EVIEW OF WEEKLY TASK LISTSR EVIEW OF WEEKLY TASK LISTS E VALUATION OF RESOURCE ALLOCATIONE VALUATION OF RESOURCE ALLOCATION A SSIGNMENT OF PERSONNEL TO SPECIFIC GAME FEATURESA SSIGNMENT OF PERSONNEL TO SPECIFIC GAME FEATURES M AINTAINING COHESIVE AND CONSISTENT TEAM VISIONM AINTAINING COHESIVE AND CONSISTENT TEAM VISION M ANAGEMENT OF OUTSIDE CONTRACTORSM ANAGEMENT OF OUTSIDE CONTRACTORS F ACILITATING COMMUNICATION AND DECISION - MAKINGF ACILITATING COMMUNICATION AND DECISION - MAKING P ROACTIVE IDENTIFICATION OF POTENTIAL PROBLEMSP ROACTIVE IDENTIFICATION OF POTENTIAL PROBLEMS E NSURING THAT THE TEAM IS FULLY STAFFED AND SUPPLIEDE NSURING THAT THE TEAM IS FULLY STAFFED AND SUPPLIED P ROVIDING FEEDBACK AND PERFORMANCE REVIEWS FOR TEAMP ROVIDING FEEDBACK AND PERFORMANCE REVIEWS FOR TEAM P RODUCTION T EAM M EMBERS

8. P ART 3.1: T EAMS AND P ROCESSES P AGE 73 A SSISTANT P RODUCER P ROJECT MANAGEMENT AND GAME DESIGN EVALUATIONP ROJECT MANAGEMENT AND GAME DESIGN EVALUATION I NTERFACING WITH AND SUPPORTING DEVELOPERS, LICENSORS, AND MARKETINGI NTERFACING WITH AND SUPPORTING DEVELOPERS, LICENSORS, AND MARKETING D ESIGN DOCUMENTATION REVIEWD ESIGN DOCUMENTATION REVIEW T RACKING TEAM MEMBERS ’ PROGRESS ACCORDING TO SCHEDULET RACKING TEAM MEMBERS ’ PROGRESS ACCORDING TO SCHEDULE I NTERACTING WITH Q UALITY A SSURANCE TEAMI NTERACTING WITH Q UALITY A SSURANCE TEAM C OORDINATING INFORMATION RELEASED TO GAME FANSC OORDINATING INFORMATION RELEASED TO GAME FANS A SSISTING IN THE FULFILLMENT OF THE PRODUCER ’ S RESPONSIBILITIESA SSISTING IN THE FULFILLMENT OF THE PRODUCER ’ S RESPONSIBILITIES

9. P ART 3.1: T EAMS AND P ROCESSES P AGE 74 E XECUTIVE P RODUCER O FFERING CREATIVE INPUT AND DIRECTION TO GUIDE THE BRAND TO A SUCCESSFUL PLACE WITHIN THE MARKETO FFERING CREATIVE INPUT AND DIRECTION TO GUIDE THE BRAND TO A SUCCESSFUL PLACE WITHIN THE MARKET L EADING THE GLOBAL BUSINESS EFFORT AND VISION FOR A BRANDL EADING THE GLOBAL BUSINESS EFFORT AND VISION FOR A BRAND C LARIFYING THE VISION FOR THE BRAND, CONVEYING IT TO OTHER DEPARTMENT EXECUTIVES AND INTERNAL LEADERSC LARIFYING THE VISION FOR THE BRAND, CONVEYING IT TO OTHER DEPARTMENT EXECUTIVES AND INTERNAL LEADERS R ECEIVING REPORTS FROM PRODUCERS AND ASSISTANT PRODUCERS, AS WELL AS VARIOUS TEAM LEADS ( LEAD PROGRAMMER, LEAD DESIGNER, LEAD ARTIST, ETC.)R ECEIVING REPORTS FROM PRODUCERS AND ASSISTANT PRODUCERS, AS WELL AS VARIOUS TEAM LEADS ( LEAD PROGRAMMER, LEAD DESIGNER, LEAD ARTIST, ETC.)

10. P ART 3.1: T EAMS AND P ROCESSES P AGE 75 P RODUCT P LANNER D EVELOPING AND DEFINING THE FUTURE OF A GAME, A FRANCHISE, OR EVEN A PRODUCT PERIPHERALD EVELOPING AND DEFINING THE FUTURE OF A GAME, A FRANCHISE, OR EVEN A PRODUCT PERIPHERAL P LANNING FOR NEW CONSOLES, CONTROLLERS, HEADSETS, NETWORKING CAPABILITIES, ETC.P LANNING FOR NEW CONSOLES, CONTROLLERS, HEADSETS, NETWORKING CAPABILITIES, ETC. P ROGRAM M ANAGER C OMMUNICATING AS THE VOICE OF THE GAME TEAM TO OTHER DEPARTMENTS, INCLUDING MARKETINGC OMMUNICATING AS THE VOICE OF THE GAME TEAM TO OTHER DEPARTMENTS, INCLUDING MARKETING C ONTRIBUTING TO SPECIFICATION WRITING AND MANAGING DEPENDENCIES BETWEEN SOFTWARE GROUPSC ONTRIBUTING TO SPECIFICATION WRITING AND MANAGING DEPENDENCIES BETWEEN SOFTWARE GROUPS D EVELOPMENT D IRECTOR M ENTORING, TRAINING, AND COACHING DEVELOPERSM ENTORING, TRAINING, AND COACHING DEVELOPERS D EFINING INITIAL PROJECT SCOPES AND DELIVERY SCHEDULESD EFINING INITIAL PROJECT SCOPES AND DELIVERY SCHEDULES I DENTIFYING RISKS AND PRIORITIZING OBJECTIVESI DENTIFYING RISKS AND PRIORITIZING OBJECTIVES

11. P ART 3.1: T EAMS AND P ROCESSES P AGE 76 P RODUCTION A SSISTANTS I NTERNING AT THE GROUND LEVEL, DOING MUNDANE TASKS IN ADMINISTRATIVE WORK, SOFTWARE TESTING, MEETING PREPARATION, NOTE TAKING, ETC.I NTERNING AT THE GROUND LEVEL, DOING MUNDANE TASKS IN ADMINISTRATIVE WORK, SOFTWARE TESTING, MEETING PREPARATION, NOTE TAKING, ETC. L EARNING THE ROPES TO GAIN THE EXPERIENCE NEEDED TO BECOME ASSISTANT PRODUCER, PRODUCER, ETC.L EARNING THE ROPES TO GAIN THE EXPERIENCE NEEDED TO BECOME ASSISTANT PRODUCER, PRODUCER, ETC.

12. P ART 3.1: T EAMS AND P ROCESSES P AGE 77 P ROGRAMMING P LATFORMS W ITH 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.

13. P ART 3.1: T EAMS AND P ROCESSES P AGE 78 C ROSS -P LATFORM P ROGRAMMING T WO COMMON APPROACHES TO DEVELOPING A GAME FOR MULTIPLE PLATFORMS : P LATFORM A GNOSTIC – D EPEND ON PRE - EXISTING SOFTWARE THAT HIDES PLATFORM DIFFERENCES ( E. G., J AVA V IRTUAL M ACHINE ). P LATFORM A GNOSTIC – D EPEND ON PRE - EXISTING SOFTWARE THAT HIDES PLATFORM DIFFERENCES ( E. G., J AVA V IRTUAL M ACHINE ). S OURCE T REES - D EVELOP MULTIPLE VERSIONS OF THE SAME GAME FOR THE VARIOUS DESIRED PLATFORMS. S OURCE T REES - D EVELOP MULTIPLE VERSIONS OF THE SAME GAME FOR THE VARIOUS DESIRED PLATFORMS. A MONG THE PROBLEMS WITH CROSS - PLATFORM DEVELOPMENT : E ACH PLATFORM MUST BE TESTED SEPARATELY DUE TO SUBTLY DIFFERENT BEHAVIOR. E ACH PLATFORM MUST BE TESTED SEPARATELY DUE TO SUBTLY DIFFERENT BEHAVIOR. T HE TENDENCY IS FOR DEVELOPERS TO “ DUMB DOWN ” THE GAME TO THE PLATFORM WITH THE LEAST ADVANCED FEATURES. T HE TENDENCY IS FOR DEVELOPERS TO “ DUMB DOWN ” THE GAME TO THE PLATFORM WITH THE LEAST ADVANCED FEATURES. W ITH SOURCE TREES, SEPARATE TEAMS OFTEN DEVELOP FOR SEPARATE PLATFORMS, YIELDING INCONSISTENT VERSIONS OF THE GAME, INCLUDING DIFFERENT SETS OF DEFECTS. W ITH SOURCE TREES, SEPARATE TEAMS OFTEN DEVELOP FOR SEPARATE PLATFORMS, YIELDING INCONSISTENT VERSIONS OF THE GAME, INCLUDING DIFFERENT SETS OF DEFECTS.

14. P ART 3.2: C++, J AVA, AND S CRIPTING L ANGUAGES P AGE 79 C++, J AVA, AND S CRIPTING L ANGUAGES P ROGRAMMING 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.

15. P ART 3.2: C++, J AVA, AND S CRIPTING L ANGUAGES P AGE 80 T HE P ROS OF S CRIPTING L ANGUAGES A LLOW FOR COMPLEX ENTITY CREATION WITHOUT RECOMPILING THE ENTIRE GAME ENGINEA LLOW FOR COMPLEX ENTITY CREATION WITHOUT RECOMPILING THE ENTIRE GAME ENGINE C OMPLETELY PORTABLE TO OTHER PLATFORMSC OMPLETELY PORTABLE TO OTHER PLATFORMS A FFORD LESS OPPORTUNITY TO CRASH A SYSTEM, YIELDING A MESSAGE INSTEAD OF LOCKING UPA FFORD LESS OPPORTUNITY TO CRASH A SYSTEM, YIELDING A MESSAGE INSTEAD OF LOCKING UP U SUALLY PERMIT LOAD - ON - DEMAND, WITH ONLY SECTIONS CURRENTLY IN USE IN THE GAME LOADEDU SUALLY PERMIT LOAD - ON - DEMAND, WITH ONLY SECTIONS CURRENTLY IN USE IN THE GAME LOADED P ERMIT COMPLEX USER - MODIFICATION OF GAMESP ERMIT COMPLEX USER - MODIFICATION OF GAMES

16. P ART 3.2: C++, J AVA, AND S CRIPTING L ANGUAGES P AGE 81 T HE C ONS OF S CRIPTING L ANGUAGES U SUALLY LACK SYMBOLIC DEBUGGERS, MAKING DEBUGGING MUCH MORE COMPLICATEDU SUALLY LACK SYMBOLIC DEBUGGERS, MAKING DEBUGGING MUCH MORE COMPLICATED S CRIPTS ARE USUALLY COMPILED AT RUN - TIME, CAUSING SIGNIFICANT SLOWDOWNS COMPARED TO HIGH - LEVEL LANGUAGES LIKE C++S CRIPTS ARE USUALLY COMPILED AT RUN - TIME, CAUSING SIGNIFICANT SLOWDOWNS COMPARED TO HIGH - LEVEL LANGUAGES LIKE C++ I F THEY ’ RE POWERFUL ENOUGH TO DO ANYTHING SOPHISTICATED ( E. G., AI), THEN THEY ’ RE COMPLEX ENOUGH TO NEED ADVANCED PROGRAMMING SKILLSI F THEY ’ RE POWERFUL ENOUGH TO DO ANYTHING SOPHISTICATED ( E. G., AI), THEN THEY ’ RE COMPLEX ENOUGH TO NEED ADVANCED PROGRAMMING SKILLS

17. P ART 3.2: C++, J AVA, AND S CRIPTING L ANGUAGES P AGE 82 C++ VS. J AVA C++ S TRENGTHS H IGH PERFORMANCE H IGH PERFORMANCE OOP FEATURES ( E. G., POLYMORPHISM ) OOP FEATURES ( E. G., POLYMORPHISM ) E XTENSIVE LIBRARIES E XTENSIVE LIBRARIES B ACKWARDS COMPATIBLE WITH C B ACKWARDS COMPATIBLE WITH C J AVA S TRENGTHS I MPROVED PERFORMANCE I MPROVED PERFORMANCE M ODERN FEATURES ( E. G., OBJECT SERIALIZATION ) M ODERN FEATURES ( E. G., OBJECT SERIALIZATION ) E XTENSIVE LIBRARIES E XTENSIVE LIBRARIES L ESS COMPLICATED, WITH SHORT LEARNING CURVE L ESS COMPLICATED, WITH SHORT LEARNING CURVE C++ G AMES PC GAMES PC GAMES C ONSOLE GAMES C ONSOLE GAMES O NLINE MULTIPLAYER GAMES O NLINE MULTIPLAYER GAMES J AVA G AMES C ASUAL GAMES C ASUAL GAMES B ROWSER GAMES B ROWSER GAMES M OBILE G AMES M OBILE G AMES

18. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 83 P ROGRAMMING F UNDAMENTALS S EVERAL STANDARD DATA STRUCTURES FIGURE PROMINENTLY IN GAME PROGRAMMING … V ECTORS & M ATRICES F ACILITATE THE IMPLEMENTATION OF LINEAR ALGEBRA FORMULAS IN GRAPHICS AND ANIMATION D ICTIONARIES & H ASH T ABLES F ACILITATE THE IMPLEMENTATION OF MASSIVE LOOK - UP TABLES FOR AUDIO AND VISUAL ASSOCIATIONS S TACKS & Q UEUES M ANAGE THE APPLICATION OF AFFINE TRANSFORMATIONS ( TRANSLATIONS, ROTATIONS, SCALING ) AND ENTITY INTERACTIONS ( COLLISIONS, MULTIPLAYER COMMANDS, ETC.)

19. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 84 D ATA S TRUCTURE : L AYERED I SOMETRIC G RID O NE 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.). DirectionAdjacency 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

20. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 85 D ATA S TRUCTURE : P ARTICLE S YSTEM T O 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. FIELDTYPE PositionVector VelocityVector ColorVector EnergyInteger SizeFloat TransparencyFloat TimeToLiveInteger

21. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 86 D ATA S TRUCTURE : S UBDIVISION S URFACE W HEN 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. S UBDIVISION SURFACES ARE USED TO EXPAND A 3D MODEL LACKING DETAILS INTO A MORE ELABORATE MODEL. DATA STRUCTURE DESCRIPTION Vertex(x,y,z) coordinate info TriangleThree vertex objects Triangular MeshArray of triangles Adjacency Matrix2D table of vertex adjacencies Triangle SubdividerDrives triangular mesh subdivision

22. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 87 D ATA S TRUCTURE : I NTERACTIVE M USIC S EQUENCER A N 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 SequencePtrList_t; typedef list TrackPtrList_t; typedef list 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; }; // Note: The red fields are the // interactive features. typedef list SequencePtrList_t; typedef list TrackPtrList_t; typedef list 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 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; }; 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; };

23. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 88 D ATA S TRUCTURE : S PRING N ODE O NE METHOD FOR IMPLEMENTING ANIMATED CLOTH IS TO PLACE INVISIBLE SPRING NODES AT VERTEX LOCATIONS WITHIN THE CLOTH. FIELDTYPE PositionVector VelocityVector ForceVector MassFloat Neighbor ListLinked list of other spring nodes Distance ListParallel list of neighbor distances Neighbor CountInteger O NE REASONABLE MODEL HAS EACH NODE CONNECTED TO … ITS NEAREST NEIGHBORS ( VERTICAL AND HORIZONTAL ) BY STRONG STRETCH SPRINGS ITS NEAREST NEIGHBORS ( VERTICAL AND HORIZONTAL ) BY STRONG STRETCH SPRINGS ITS DIAGONAL NEIGHBORS BY WEAKER SHEAR SPRINGS ITS DIAGONAL NEIGHBORS BY WEAKER SHEAR SPRINGS ALL OF ITS NEIGHBORS BY WEAK BEND SPRINGS ALL OF ITS NEIGHBORS BY WEAK BEND SPRINGS

24. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 89 D ATA S TRUCTURE : BSP T REE T O EFFICIENTLY DETERMINE THE ORDER IN WHICH POLYGONS SHOULD BE RENDERED, BINARY SPACE PARTITIONING TREES ARE USED. I N THIS D OOM - 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. T HE LAYOUT SURFACES ARE USED TO PERFORM A BINARY SPACE PARTITIONING ( UP TO A CERTAIN DEPTH ). I N ADDITION, THE OPTICAL CONNECTIVITY IS DETERMINED BETWEEN THE VARIOUS ROOMS AND CORRIDORS, USING DOORS AND WINDOWS TO DETERMINE VIABLE ADJACENCIES. T HIS INFORMATION IS THEN COMBINED TO QUICKLY DETERMINE OVERALL VISIBILITY BETWEEN ROOMS.

25. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 90 B IT P ACKING FOR N ETWORK C OMPRESSION N ETWORK 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 { PkUint MsgType; // 5 bits PkUint Time; // 32 bits PkUint Element; // 10 bits PkUint XPosition; // 18 bits PkUint YPosition; // 18 bits }; B ASIC STRUCTURE WITHOUT BIT PACKING : 136 BITS B ASIC STRUCTURE WITH BIT PACKING : 83 BITS W HILE 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 ).

26. P ART 3.3: P ROGRAMMING F UNDAMENTALS P AGE 91 O BJECT -O RIENTED V S. C OMPONENT -B ASED T RADITIONAL OBJECT ORIENTATION USES AN INHERITANCE HIERARCHY TO DEFINE THE CHARACTERISTICS OF GAME ELEMENTS. ObjectObject Renderable Object Logical Object Spawn Point Trigger Box Particle System Physics Object Animatable Object Collectable Object WeaponWeaponHealthpackHealthpackActorActorDoorDoor GemGem H OW CAN W EAPONS BE MADE ANIMATABLE ? H OW CAN D OORS AND G EMS BE MADE D ESTRUCTIBLE, BUT NOT A CTORS AND W EAPONS ? Entity: Weapon Rendering Component Animating Component Collecting Component Entity: Door Rendering Component Animating Component Destroying Component C OMPONENT - BASED PROGRAMMING RELIES ON AGGREGATE BEHAVIOR, I. E., ASSIGNING EACH GAME ENTITY A SET OF BEHAVIORS AND FUNCTIONALITIES. T HE FLEXIBILITY OF COMPONENTS AND THEIR RELIANCE ON RUN - TIME MESSAGE PASSING COMPLICATES DEBUGGING AND PERFORMANCE.

27. P ART 3.4: G AME A RCHITECTURE P AGE 92 G AME A RCHITECTURE C ERTAIN ASPECTS OF CODE ARE UNIQUE TO GAME PROGRAMS. I NITIALIZATION CODE TO SET UP THE WINDOWS AND INTERFACES, AND TO LOAD DATA FROM EXTERNAL FILES U PDATE INPUT FROM DEVICES LIKE THE KEYBOARD OR JOYSTICK, AND UPDATE THE MUSIC STATE TABLE I NTERPRET CURRENT USER INPUT, UPDATE ONSCREEN CHARACTERS, DRAW MAP, PERFORM CURRENTLY LOADED EFFECTS L OAD GAMES, GENERATE CHARACTERS, PURCHASE ITEMS, SET EQUIPMENT, PLOT TEXTBOXES ( HEALTH, WEAPONS, ETC.) H ANDLE TURNS, ACTIVATING THE AI FOR ENEMIES AND ACTIVATING THE MENU SYSTEM FOR CHARACTERS R UN CURRENTLY LOADED SCRIPTS R ELEASE ALL CREATED OBJECTS, DEALLOCATE MEMORY, SHUT DOWN THE PROGRAM

28. P ART 3.4: G AME A RCHITECTURE P AGE 93 G AME T IMING W HILE COMPUTERS RUN AT DIFFERENT SPEEDS, WE WANT GAMES TO RUN AT THE SAME SPEED ON ANY COMPUTER. G AME 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 }

29. P ART 3.4: G AME A RCHITECTURE P AGE 94 G AME P ARALLELISM R EDESIGNING GAME ENGINES TO TAKE ADVANTAGE OF MULTIPLE PROCESSORS CAN IMPROVE GAME PLAY WITHOUT SACRIFICING FRAME RATES. M ULTITHREADING INEFFICIENCIES MIGHT RESULT, HOWEVER. F OR EXAMPLE, THE SECOND C OLLISION D ETECTION COMPUTATION AT RIGHT CANNOT TAKE ADVANTAGE OF THE FIRST C HARACTER A NIMATION COMPUTATION ( WHICH IS INCOMPLETE ), SO IT YIELDS THE SAME RESULT AS THE FIRST CD COMPUTATION. S IMILARLY, THE THIRD R ENDER COMPUTATION LACKS UPDATED CA DATA, SO RENDERING A NEW FRAME AT THIS POINT HAS DUBIOUS VALUE.

30. P ART 3.4: G AME A RCHITECTURE P AGE 95 G AME E NGINE P ROGRAMMING 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.

31. P ART 3.4: G AME A RCHITECTURE P AGE 96 P LUG -I N T OOLS E XTENDING 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.

32. P ART 3.5: M EMORY AND I/O S YSTEMS P AGE 97 M EMORY AND I/O S YSTEMS W ITH 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. T HE HUGE INCREASES IN MEMORY REQUIREMENTS IN MODERN GAME SYSTEMS DICTATE THAT EFFICIENT ALLOCATION STRATEGIES AND EFFECTIVE ELIMINATION OF FRAGMENTATION BE IMPLEMENTED.

33. P ART 3.5: M EMORY AND I/O S YSTEMS P AGE 98 C ONSOLE M EMORY H ISTORY A S 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.

34. P ART 3.5: M EMORY AND I/O S YSTEMS P AGE 99 S ERIALIZATION G AME 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. S ERIALIZATION PROBLEMS INCLUDE : D EALING WITH POINTERS, SINCE SAVING MEMORY LOCATIONS WILL RESULT IN CRASHES WHEN THE GAME IS RESTORED. D EALING WITH POINTERS, SINCE SAVING MEMORY LOCATIONS WILL RESULT IN CRASHES WHEN THE GAME IS RESTORED. O BJECTS 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. O BJECTS 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. D ECISIONS REGARDING THE PRESERVATION OF SMALL DETAILS MUST BE MADE, E. G., IS EACH PARTICLE IN AN EXPLOSION ’ S PARTICLE SYSTEM STORED ? D ECISIONS REGARDING THE PRESERVATION OF SMALL DETAILS MUST BE MADE, E. G., IS EACH PARTICLE IN AN EXPLOSION ’ S PARTICLE SYSTEM STORED ?

35. P ART 3.6: D EBUGGING G AMES P AGE 100 D EBUGGING G AMES W ITH THE DEVELOPMENT OF MULTITHREADED GAME CAPABILITIES ON MULTIPROCESSOR WORKSTATIONS, WITH GPU S AND NETWORK CONNECTIONS, GAME PROGRAM DEBUGGING ENCOUNTERS ADDITIONAL OBSTACLES. R ACE C ONDITIONS // // Race.cpp // // Example of a race condition // // #include #include #include 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); } I F ThreadOne ASSIGNS 50 TO g_iResult BEFORE ThreadTwo ASSIGNS 150, THEN 150 IS PRINTED ; OTHERWISE, 50 IS PRINTED. R ACE 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.

36. P ART 3.6: D EBUGGING G AMES P AGE 101 M ULTITHREADED D EBUGGING P ROBLEM 2 D EADLOCK // // Deadlock.cpp // // Example of a deadlock // // #include #include #include 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); } E ACH THREAD WAITS INDEFINITELY FOR THE RESOURCE IN THE OTHER THREAD ’ S POSSESSION. E ASY FIXES INCLUDE PROHIBITING THREADS FROM TRYING TO OWN MULTIPLE LOCKS SIMULTANEOUSLY, AND FORCING THREADS TO LOCK ALL NEEDED RESOURCES BEFORE STARTING UP.

37. P ART 3.6: D EBUGGING G AMES P AGE 102 M ULTITHREADED D EBUGGING P ROBLEM 3 M ISMATCHED C OMMUNICATION // // Mistmatched.cpp // // Show mismatched communication // #include #include #include 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); } T HE MESSAGE RECEIVED BY ONE THREAD ISN ’ T THE ONE IT ’ S WAITING FOR. O NE 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.

38. P ART 3.6: D EBUGGING G AMES P AGE 103 G AME C HEATS U NDETECTED 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. E XAMPLE #1: D IABLO ’ S T OWNKILL C HEAT T HE STARTING TOWN IN D IABLO WAS INTENDED TO BE A SAFE ZONE WHERE PLAYERS COULDN ’ T ATTACK EACH OTHER. H OWEVER, 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 ”. W ITH D IABLO ’ S NETWORK MODEL, OTHER COMPUTERS IN THE GAME WOULD SIMPLY ACCEPT THE MESSAGE AND DUTIFULLY SUBTRACT 20 HIT POINTS FROM THEIR CHARACTER. T HE P ROBLEM : A SYNCHRONOUS 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.

39. P ART 3.6: D EBUGGING G AMES P AGE 104 E XAMPLE #2: S TAR C RAFT ’ S M AP H ACK C HEAT I N S TAR C RAFT, 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. T HE M AP H ACK 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. T HIS 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. T HE P ROBLEM : S YNCHRONOUS 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. U NFORTUNATELY, TO ACCOMPLISH THIS, COMPUTERS SEE TOO MUCH INFORMATION ABOUT WHAT THE OTHER PLAYERS IN THE GAME ARE DOING.

40. P ART 3.6: D EBUGGING G AMES P AGE 105 E XAMPLE #3: A SHERON C ALL ’ S I TEM D UPING C HEAT P LAYERS TAKE A VALUABLE ITEM IN THEIR INVENTORY AND MAKE AN EXACT COPY OF IT BY FINDING AND EXPLOITING A BUG IN THE PROGRAM. T RYING UNUSUAL COMBINATIONS OF ACTIONS THAT HAVE NOT BEEN TESTED BEFORE, THEY DETERMINE A COMBINATION THAT WILL CONSISTENTLY CRASH THE GAME SERVER. T O DUPLICATE A VALUABLE ITEM, THEY SIMPLY HAND IT TO AN ACCOMPLICE, WHO THEN IMMEDIATELY LOGS OFF, CAUSING HIS CHARACTER TO BE SAVED TO DISK. T HEN THEY CRASH THE SERVER BEFORE IT HAS AN OPPORTUNITY TO SAVE THEIR OWN CHARACTER TO DISK. W HEN THE SERVER COMES BACK UP, BOTH PLAYERS HAVE THE ITEM IN THEIR INVENTORIES. T HE P ROBLEM : C LIENT - 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. T HE 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. U NFORTUNATELY, IF THE SERVER CAN BE MADE TO CRASH, THE RESTORATION PROCESS MAY HAVE UNDESIRABLE CONSEQUENCES.

41. P ART 3.6: D EBUGGING G AMES P AGE 106 G AME T ESTING T WO COMMON SOFTWARE TESTING METHODOLOGIES ARE ALSO APPLIED TO COMPUTER GAMES. B LACK B OX T ESTING T HE 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. I T ’ S EASIER TO CONDUCT AND OFTEN IDENTIFIES EXTREMELY SURPRISING FLAWS. W HITE B OX T ESTING T HE 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. I T ’ S MUCH MORE THOROUGH AND MAY BE EMPLOYED FOR BOTH MODULE AND SYSTEM TESTS.