1. CSE 381 – Advanced Game Programming 3D Game Architecture

2. For Next Week For Monday read Chapters 6 & 7 make your own RTS model For Wednesday read Chapter 8 sub your model for the teapots in Teapot Wars

3. Plan then Code, right? Game Engines must be carefully planned make smart decisions early plan for expansion What do we need to plan for? a 3D RTS – 1 st team project

4. Many different architectural models We’ll examine our authors’ model Why? 1.Because we have their code 2.Because the book explains their code 3.Because it’s based on principles from real games

5. Everything fits in one of three levels High-Level Game Architecture Game Application Layer Game Logic Game View Logic Layer – manages game state View Layer – presents game graphics & audio App Layer – deals with hardware & OS Think MVC

6. Game Lifetime The Application Layer InputFilesRAMTime LanguageDLL ThreadsNetwork Core Libs Main Loop Init & Shutdown Devices Operating System

7. Important App Layer Functionality Game Init/Shutdown Run game loop queue game input, tick game logic force game state to all views (graphics, audio, connection) Translate input to game commands Manage a resource cache Manage memory System clock String handling DLLs Thread synchronization Network communications

8. Game Lifetime The Game Logic Layer Game State & Data Structures Physics Process Manager Command Interpreter Important Consideration: How should we store, search, & stream game objects? How much cross-referencing do we want to do? Do we need custom data structures? Events

9. Choosing an Event-Based Game Logic System What is it? When an important game event happens, and lots of subsystems need to know about it. An event-based system has those subsystems subscribe to that event via an event manager. For example: An explosion happens Who needs to know? Graphics system Sound system Physics system

10. What’s a Process Manager? Keeps a list of active processes Gives each one CPU time each frame Shouldn’t the OS be doing this? we’re talking your GAME processes

11. And a Command Interpreter? Game systems talk via commands Where can commands come from? network subsystem (i.e. physics) user typing in console Command-based interface talk to game logic Requires a command langauge

12. Game View For Human Player For AI Dictates decision making for both

13. Input Interpreter The Game View Layer for Humans 3D Scenes User Interface Video SFXMusic Speech Display Audio Process Manager Options

14. The Rendering System Manages: GPU memory Scene Graph Level of Detail Transitions between LOD hopefully without “popping” Decides which triangles to render Renders the correct ones beautifully

15. 3D Game Engine Goals Only render that which is visible Only test collisions between objects that could possible collide Only send network data back & forth that needs to be sent Bottom Line: a 3D Game Engine is expert in work avoidance Solution? layered approach: scene graphs potentially visible sets frustum culling display list back-face culling NOTE: All this work affects level & game design decisions as well: -max triangle count -max scene density -etc.

16. Scene Graph Manages positioned game objects –models –sound effects –portals –camera

17. Only render things in the view frustum

18. Rendering System Layers Back-Face Culling Scene Graph Frustum Culling Game Objects Scene-Clipped Items (PVS) Frustum-Culled Items Display List Renderer

19. Stimulus Interpreter The Game View Layer for AI Agents Decision System OptionsProcess Manager Stimulus Interpreter receives events Movement, collisions, etc. AI programmer determines response via decision systerm Translates stimuli into actions

20. Networked Game Architecture Authoritative Server Game Logic Remote Game View Human Game View Game Events Remote Game Client Human Game View Remote Game Logic Game Events Internet TCP/IP or UDP

21. Remote Player Similar to AI agent for server Remote View receives game events from game logic responds with commands back to the game logic Game Events received from game logic packed up & sent across network processing necessary before sending eliminate redundant messages package commands together etc.

22. Some tips to think about Avoid hidden code that performs nontrivial operations Keep your class hierarchies as flat as possible Be aware of the difference between inheritance and composition Avoid abusing virtual functions Use interface classes and factories Encapsulate the components of your system that are most likely to change Use streams in addition to constructors to initialize objects Etc. Read more in Chapter 3

23. Know your way around What goes in: Assets/? Game/? Source/? What gets loaded via PlayerOptions.xml? into GameOptions To Start With

24. GameCodeApp Application Layer look inside GCC4/GameCode4/GameCode A container that has: Text manager Game Logic Game options Resource cache Event manager Network communications manager

25. What needs to be done at startup? Check system resources Check CPU speed Init your random number generator Load programmer options Init your memory cache Init Lua script manager Create your window Init audio system Load player’s game options Load saved game files Create drawing surface Init game systems: AI, physics, etc.

26. Who runs the game loop? DXUT look in 3rdParty dir DXUTMainLoop When does our code get called?

27. And how do we examine the system? gamecode4/Source/GCC4/Mainloop/Initialization.cpp has GameOptions methods Let’s look at these methods: CheckStorage CheckMemory ReadCPUSpeed GetFreeVRAM GetSaveGameDirectory Now let’s run the debugger and look where the code goes