GAME 1024: Advanced Game ProgrammingLesson 9: A Glimpse Into Your Future!By Kain Shin

Quiz1. What is your name and are you a fighter, magic user, or stealth

specialist?

2. Give at least four steps of an algorithmic thinking process

3. What is one thing that can cause a delay in the instruction pipeline?

4. What is one thing you can do to minimize cache misses?

5. Unroll this loop:for(int i=0; i<100; ++i){ arrayValue[i] <<= 1;}

Bonus Topic: Finite State Machines for Games What Is It?

Example: Traffic Light Example: Animation state (stand, walk/run, jump, attack, react, die, etc.)

Why Should I Care? Because switch-statements-inside-update-functions suck

What’s a Basic Implementation? class cFiniteStateMachine

Holds a registry of all known states Associates state IDs to state objects Updates the current state

Abstract class iFiniteState OnEnter function Update function OnExit function

State Transition Methods From within the update function of the finite state Via an explicit call to cFiniteStateMachine::Transition(stateID)

User Interface Requirements

Hooks to Input Hooks to Simulation Pause/Unpause Modal Screens – Exclusive Input Non-Modal Screens – HUD Buttons, Checkboxes, Sliders, Scrollbars, Sprites, Models, etc… Preferably Data-Driven Minimize File I/O After Initialization

Systems Design class cUIManager

Contains a registry of all screens that will ever exist: map<screenID, iScreen*> Manages one stack of modal screens Non-modal screens can either be managed in a separate stack or piggy-back off a modal

screen Pointers of screens from the registry are pushed/popped to/from the stack Listen for Input Events: Routes input to the top-most modal screen Routes updates to the Topmost modal screen, no updates reach the other modal screens Renders all active screens after the world is done with its render

The game simulation takes place within a modal screen

Graphics Let’s Talk About…

How a block of memory turns into monitor pixels Blitting Sprites Rendering Vertex Data Rendering Texture Data Normals and the Lighting Model Orthographic vs. Perspective Projection 2D Animation UV Scrolling The 3D rendering state machine Scene graph 3D Animation (Bones System) Billboarded Quads Particles Pixel/Vertex Shaders Full Screen Effects

Artificial Intelligence Let’s Talk About…

AI for Games Meant to be fun, not smart Architecture Suggestion:

Brain (Eyes and Ears) – Manages states on the controller. Your AI code would live here.

Controller (Strings) – May contain multiple finite state machines for body animation, speech, health, superpowers, etc.

Character (Puppet) – Rendering Information lives here Event System Usage

The brain would be a listener Examples of events: explosion nearby, bullet fired, bullet hit nearby, actor

movement AI Programming falls into two categories…

Decision Architectures:Stimuli + CurrentState = Decisions

Path Planning:CurrentPosition + DesiredPosition + NavigationData = MovementDecision

3D Camera Programming Overview Camera on a stick Camera as an AI (Lots of Math!) Useful Features:

Debugging: Bread Crumbs Astral Projection

Gameplay: Designer/Artist Specified Camera Spline Movement (Cinematics) Camera Shake FOV changes (i.e. Burnout)

Common Issues: Camera + User Controls + Game Design = Lots of Iteration! Geometry Occlusion (Third Person)

Backing up into a wall Something moves between the player character and the camera

Audio Programming Overview Basic Model for 3D Audio

AudioListener – Position and orientation moves with the player AudioSource

Audio Programming Issues Resource Management (streaming, hardware limitations) Data hookup

Localization lip synching Association with actors in the world

Special effects Reverb Doppler Occlusion

Physics Programming Overview Basic Physics Model for Games

All actors have an invisible physics representation Movement is authoritative

Physical Properties Mass Restitution Coefficient of static/dynamic friction Joint properties Center of gravity Current linear velocity Current angular velocity Etc.

Types of physics interactions Collisions Applied Forces Volume Penetration Joint Simulation (including soft body simulations)

Multiplayer/Network Programming Issues Shared Screen Multiplayer (Gauntlet, Mario Party)

Shouldn’t be hard if you use the brain-controller-puppet model Split Screen Multiplayer

Render bandwidth is the primary issue Downgrade graphics features Downgrade art content

Memory is the secondary issue for streaming worlds Don’t let the players exist too far from each other… somehow

Screen real-estate is the remaining issue Design your UI and gameplay to support smaller screens

Network Multiplayer Event System Required! Network bandwidth is the primary issue

Minimize the size of event data, and compress the data before sending Freeze all clients until they are in synch (boo!) Make simulations deterministic so that you only need to send delta information with reasonable corrections

for lagged evvent notifications Design for lag (dead reckoning, time stamps, predictive algorithms, slow animations, etc.) Design for low bandwidth (i.e. state-base combat in MMOs)

Security is the secondary issue Authoritative Server data Cheat detection

Tools Programming Overview Purpose of Tools:

Allow non-programmers to be productive Minimize human error Save time

Tools are separate from the game Don’t have to be written in C++ (C# is becoming the language of choice) Doesn’t need optimized performance Outputs a file that the game can read

Examples of Tools World Editor Localization Remote Debugger

Final Thoughts Check your syllabus to see the other ACC courses that focus

on today’s material. This class was specifically designed to not overlap with these other courses

I learned more of this material from books than I learned in a class or on the job.

Don’t re-invent the wheel: Learn how other people have tackled the problem before you make up your own solution

Usually, a good system is one that people don’t talk about because they have no complaints. Try paying attention to these “invisible” systems the next time you play a game.