cse 381 – advanced game programming 3d game architecture
TRANSCRIPT
CSE 381 – Advanced Game Programming3D Game Architecture
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
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 – 1st team project
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
• Everything fits in one of three levels
High-Level Game Architecture
Game Application Layer
Game LogicGame View
• Logic Layer – manages game state• View Layer – presents game graphics & audio• App Layer – deals with hardware & OS• Think MVC
Game Lifetime
The Application Layer
Input Files RAM Time
Language DLL Threads Network
CoreLibs
MainLoop
Init &Shutdown
Devices
Operating System
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
Game Lifetime
The Game Logic Layer
Game State& Data
StructuresPhysics
ProcessManager
CommandInterpreter
• 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
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
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
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
Game View
• For Human Player• For AI• Dictates decision making for both
InputInterpreter
The Game View Layer for Humans
3DScenes
UserInterface
Video
SFX Music Speech
Display
Audio
ProcessManager
Options
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
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.
Scene Graph• Manages positioned game objects
– models
– sound effects
– portals
– camera
Only render things in the view frustum
Rendering System Layers
Back-Face Culling
Scene Graph
Frustum Culling
Game Objects
Scene-Clipped Items (PVS)
Frustum-Culled Items
Display List
Renderer
StimulusInterpreter
The Game View Layer for AI Agents
DecisionSystem
OptionsProcessManager
• Stimulus Interpreter receives events• Movement, collisions, etc.
• AI programmer determines response via decision systerm• Translates stimuli into actions
Networked Game ArchitectureAuthoritative Server
GameLogic Remote
Game View
HumanGame View
Game Events
Remote Game Client
Human Game View
RemoteGame Logic
Game Events
Internet
TCP/IP
or UDP
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.
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
• Know your way around
• What goes in:• Assets/?• Game/?• Source/?
• What gets loaded via PlayerOptions.xml?• into GameOptions
To Start With
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
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.
Who runs the game loop?
• DXUT• look in 3rdParty dir
• DXUTMainLoop
• When does our code get called?
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