Chapter 3.2-3.7 Languages, Programming and Architecture“Core” languagesScripting LanguagesSlide 4Flash, Director, etc. (ch 3.3)Programming Fundamentals (ch 3.4)Debugging (ch 3.5)Adding Infrastructure to Assist in DebuggingPrevention of BugsGame ArchitectureOverall ArchitectureOverview: Initialization/ShutdownOverview: The Main LoopOverview: Main Game LoopSlide 15Slide 16Game EntitiesSlide 18Slide 19Slide 20Slide 21Memory ManagementSlide 23File I/OGame ResourcesSlide 26Slide 27Slide 28SerializationChapter 3.2-3.7Languages, Programming and ArchitectureCS 4455 2“Core” languagesC/C++: fast compiled languagesJava: getting better, still not there!–Niche games (web, slow-paced games, etc.)CS 4455 3Scripting LanguagesWhy use scripting languages?–Ease and speed of development–Short iteration time–Code becomes a game assetPopular scripting languages–Most common: Python, Lua–Other: Tcl, Ruby, Perl, Javascript, Scheme–Custom scripting languages•UnrealScript, QuakeC, NWNScriptCS 4455 4Scripting LanguagesKey issue–How will you use it?Speed only an issue if in main loop–Even then, perhaps not!Interactive runtime consoles–Extremely powerful for debugging–Esp. via network connectionCS 4455 5Flash, Director, etc. (ch 3.3)Self contained, interactive development environmentsIf they meet your game needs, they can’t be beat!Excellent for prototyping–Very commonly used in this wayCS 4455 6Programming Fundamentals (ch 3.4)Some ideas are reviewOthers may be newKey point–This is how engines are written!–Useful for writing your own games, vital for understanding existing tools!CS 4455 7Debugging (ch 3.5)Debugging RT interactive systems is HARD–Probe effects–Hard to reproduce errorsA great collection of debugging ideas and guidelines!–For more than just gamesCS 4455 8Adding Infrastructureto Assist in DebuggingInteractive shells–Alter game variables during gameplayVisual diagnostics–AI, entity stateLogging capability–With different “severity” levels, control via shellRecording and playback capability–Controllable global timeTrack memory allocation–(Return to this later)Print as much information as possible on a crashCS 4455 9Prevention of BugsSet compiler to highest warning levelSet compiler warnings to be errorsCompile on multiple compilersWrite your own memory managerUse asserts to verify assumptionsInitialize variables when they are declaredBracket loops and if statementsUse cognitively different variable namesAvoid identical code in multiple placesAvoid magic (hardcoded) numbersVerify code coverage when testingCS 4455 10Game ArchitectureThe code for modern games is highly complex–Code bases exceeding a million lines of codeMany commonly accepted approaches–Developed and proven over time–Ignore them at your peril!CS 4455 11Overall ArchitectureMain structure–Game-specific code–Game-engine codeArchitecture types–Ad-hoc (everything accesses everything)–Modular–DAG (directed acyclic graph)–LayeredCS 4455 12Overview: Initialization/ShutdownThe initialization step prepares everything that is necessary to start a part of the gameThe shutdown step undoes everything the initialization step did, but in reverse orderThis is IMPORTANT–Applies to main loop, down to individual stepsCS 4455 13Overview: The Main LoopAll interactive programs are driven by a loop that performs a series of tasks every frame–GUI, 3D, VR, Simulation–Games are no exceptionSeparate loops for the front end and the game itself, or unified main loop–Both work; a question of preference and styleCS 4455 14Overview: Main Game LoopTasks–Handling time–Gathering player input–Networking–Simulation–Collision detection and response–Object updates–Rendering–Other miscellaneous tasksCS 4455 15Overview: Main Game LoopCoupling–Can decouple the rendering step from simulation and update steps–Results in higher frame rate, smoother animation, and greater responsiveness•May be necessary for complex simulations–Implementation is tricky and can be error-proneCS 4455 16Overview: Main Game LoopExecution order–Can help keep player interaction seamless•Avoid “one frame behind” problems–Can maximize parallelism–Exact ordering depends on hardwareCS 4455 17Game EntitiesWhat are game entities?–Basically anything in a game world that can be interacted with–More precisely, a self-contained piece of logical interactive content–Only things we will interact with should become game entitiesCS 4455 18Game EntitiesOrganization–Simple list–Multiple databases–Logical tree–Spatial databaseCS 4455 19Game EntitiesUpdating–Updating each entity once per frame can be too expensive–Can use a tree structure to impose a hierarchy for updating–Can use a priority queue to decide which entities to update every frameCS 4455 20Game EntitiesObject creation–Basic object factories–Extensible object factories–Using automatic registration–Using explicit registrationIdentification (pointers vs. uids)Communication (messages)CS 4455 21Game EntitiesLevel instantiation–Loading a level involves loading both assets and the game state–It is necessary to create the game entities and set the correct state for them–Using instance data vs. template dataCS 4455 22Memory ManagementOnly applies to languages with explicit memory management (C or C++)Memory problems are one of the leading causes of bugs in programs–Or, “Reason 437 why I dislike C++”CS 4455 23Memory ManagementChapter gives lots of good advice on how to deal with memory and WHY–E.g., avoiding memory fragmentationCustom memory managers are great!For you, probably most important reasons: –Simple error-checking schemes–Debugging toolsCS 4455 24File I/OAs with memory, chapter gives lots of good advice on how to deal with loading things from disk–E.g., to avoid long load timesAside from efficiency, keeps things together!For you, probably not worth doingCS 4455 25Game ResourcesA game resource (or asset) is anything that gets loaded that could be shared by several parts of the game–A texture, an animation, a sound, etcWe want to load and share resources easilyThere will be many different types of resources in a gameCS 4455 26Game ResourcesResource manager–Uses registering object factory