CS F EBRUARY 9, 2016 P ARTS 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

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

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 }

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.

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.

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.

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.

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.

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 ?