2. CS 382.001 F EBRUARY 9, 2016 P ARTS 3.4-3.5 G AME A RCHITECTURE, M EMORY, AND I/O S YSTEMS G AME T IMING G AME T IMING G AME P ARALLELISM G AME P ARALLELISM G AME E NGINES G AME E NGINES P LUG -I N T OOLS P LUG -I N T OOLS M EMORY M EMORY S ERIALIZATION S ERIALIZATION

3. G AME A RCHITECTURE P AGE 98 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

4. G AME A RCHITECTURE P AGE 99 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 }

5. G AME A RCHITECTURE P AGE 100 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.

6. G AME A RCHITECTURE P AGE 101 G AME E NGINES 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.

7. P ART 3.4: G AME A RCHITECTURE P AGE 102 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.

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

9. M EMORY AND I/O S YSTEMS P AGE 104 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.

10. M EMORY AND I/O S YSTEMS P AGE 105 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 ?