cse 381 – advanced game programming 3d game architecture

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