Transcript Lesson9 - A Ring of Blades

GAME 1024: Advanced
Game Programming
Lesson 9: A Glimpse Into Your Future!
By Kain Shin
Quiz
1.
2.
3.
4.
5.
What is your name and are you a fighter, magic user, or stealth
specialist?
Give at least four steps of an algorithmic thinking process
What is one thing that can cause a delay in the instruction pipeline?
What is one thing you can do to minimize cache misses?
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:



Gameplay:




Bread Crumbs
Astral Projection
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.