Transcript Advanced Game Design - Ohio State Computer Science and

Advanced Game Design
Dr. Matt Boggus
Slides based on work by Prof. Roger Crawfis
Computer Science & Engineering
The Ohio State University
Course Overview
 Project-based / Team-based
 Little lecturing
 Focus on programming for games
 Systems integration – graphics, sound, AI, networking, user-
interfaces, physics, scripting
 Utilize higher-level toolkits, allowing for more advanced
progress while still developing programming skills.
Course Structure
 We will have some lecture topics for the first 1-2 weeks.
 Student game project groups will provide several
presentations on their game ideas and progress.
 Student technology teams will provide an intermediate
and an advanced lecture on their findings and analysis about
their area.
Project Goals
 Large-scale software development
 Team-based (synergistic development)
 Toolkit-based (fast-start development)
 Learn and utilize the many non-graphical elements needed
for games.
 Leverage and extend your graphics and AI expertise.
Elements
 Gaming Engine
 Responsible for providing primitives
 Hardware abstraction
 Handle different areas of the game
 Physics, AI, etc.
 Game
 Defined by a genre
 Defines the gameplay
Requirements of a gaming engine
 Stunning Visuals
 Artificial Intelligence
 Immersive sound stage
 Simulation
 Animation
 Networking
Requirements of a game
 Scripting
 Varied input/output devices
 Supporting Tools
 Optimizing game content
 Developing game content
 Extending game content
 Debugging / Tuning of game performance
Stunning Visuals
 Adding realism
 Smarter Models
 Clutter
 Use hardware
 Bump-mapping
 Dynamic water or other liquids
 Rich textures (Billboards, gloss-maps, light-maps, etc.)
 Shadows
 Particle systems
Artificial Intelligence
 Games need specialized AI
 Strategy
 Path finding
 Modeling behavior
 Learning
Immersive sound stage
 Multi-track sound support
 Positional sound effects (3D immersion)
 Dynamic sounds / movement (doppler effects)
Input devices
 Commonly available devices are
 Keyboard, mouse, gamepads and joysticks
 Force feedback (haptic) devices are gaining popularity
 Steering wheels
 Joysticks
 Motion tracking
 Output devices
 Multiple monitors
 Head mounted displays
Scalability
 Multiple hardware capabilities
 Multi-resolution models
 Multi-user support
 LOD
 Multiple model definitions
 Multi-res models
 Subdivision surfaces
Scalability
 Multiple hardware capabilities
 Multi-resolution models
 Multi-user support
 LOD (Level-Of-Detail)
 Control – when to switch
 Construction – what levels to have
Animation
 Linear transformations
 Modeled animations
 Articulated motion
 Lip syncing
 Facial Expressions
 Blending animations
Networking
 Multi-player support essential
 Common problems
 Latency
 Synchronization
 Scalability
 Consistent game state
 Security
Scripting
 Strict coding is tedious
 Support for scripting is essential for RAD
 Scripting has added a whole new fun factor for many games.
Artificial Intelligence
 Games need specialized AI
 Strategy
 Path finding
 Modeling behavior
 Learning
 Non-perfect!
 Fast!
Tools
 Creating varied content
 models, video, images, sound
 Integrating content
 Common file format support
 Supporting existing popular tools via plug-ins
 3DS Max, Lightwave, Maya etc.
 Adobe premier, Adobe Photoshop
Interactive Programs
 Games are interactive systems - they must respond to the
user
 How?
Interactive Program Structure
Initialize
User Does Something
or
Timer Goes Off
System Updates
 Event driven programming
 Everything happens in response
to an event
 Events come from two
sources:
 The user
 The system
 Events are also called messages
 An event causes a message to be
sent…
User Events
 The OS manages user input
 Interrupts at the hardware level …
 Get converted into events in queues at the windowing level …
 Are made available to your program
 It is generally up to the application to make use of the
event stream
 Windowing system / Game Framework may abstract the
events for you
Polling for Events
while ( true )
if ( e = checkEvent() )
switch ( e.type )
…
do more work
 Most windowing systems provide a non-blocking event
function
 Does not wait for an event, just returns NULL if one is not ready
 What type of games might use this structure?
 Why wouldn’t you always use it?
Waiting for Events
e = nextEvent();
switch ( e.type )
…
 Most windowing systems provide a blocking event
function
 Waits (blocks) until an event is available
 Usually used with timer events. Why?
 On what systems is this better than the previous method?
 What types of games is it useful for?
The Callback Abstraction
 A common event abstraction is the callback mechanism
 Applications register functions they wish to have called
in response to particular events
 Translation table says which callbacks go with which events
 Generally found in GUI (graphical user interface)
toolkits
 “When the button is pressed, invoke the callback”
 Many systems mix methods, or have a catch-all callback for
unclaimed events
 Why are callbacks good? Why are they bad?
Upon Receiving an Event …
 Event responses fall into two classes:
 Task events: The event sparks a specific task or results in some
change of state within the current mode
 eg Load, Save, Pick up a weapon, turn on the lights, …
 Call a function to do the job
 Mode switches: The event causes the game to shift to some
other mode of operation
 eg Start game, quit, go to menu, …
 Switch event loops, because events now have different meanings
 Software structure reflects this - menu system is separate
from run-time game system, for example
Real-Time Loop
 At the core of interactive games is a real-time loop:
while ( true )
process events
update animation / scene
render
 What else might you need to do?
 The number of times this loop executes per second is the
frame rate
 # frames per second (fps)
Lag
 Lag is the time between when a user does something and
when they see the result - also called latency
 Too much lag and causality is distorted
 With tight visual/motion coupling, too much lag makes people
motion sick
 Big problem with head-mounted displays for virtual reality
 Too much lag makes it hard to target objects (and track them,
and do all sorts of other perceptual tasks)
 High variance in lag also makes interaction difficult
 Users can adjust to constant lag, but not variable lag
 From a psychological perspective, lag is the important
variable
Computing Lag
Process input
Frame
time
Update state
Render
Process input
Update state
Render
Process input
Event
time
 Lag is NOT the time it takes
to compute 1 frame!
 What is the formula for
maximum lag as a function of
Lag
frame rate, fr?
 What is the formula for
average lag?
2
fr
1.5
lag average 
fr
lag max 
Frame Rate Questions
 What is an acceptable frame rate for twitch games? Why?
 What is the maximum useful frame rate? Why?
 What is the frame rate for NTSC television?
 What is the minimum frame rate required for a sense of
presence? How do we know?
 How can we manipulate the frame rate?
Frame Rate Answers (I)
 Twitch games demand at least 30fs, but the higher the
better (lower lag)
 Users see enemy’s motions sooner
 Higher frame rates make targeting easier
 The maximum useful frame rate is the monitor refresh
rate
 Time taken for the monitor to draw one screen
 Synchronization issues
 Buffer swap in graphics is timed with vertical sweep, so ideal frame rate is
monitor refresh rate
 Can turn of synchronization, but get nasty artifacts on screen
Frame Rate Answers (II)
 NTSC television draws all the odd lines of the screen,
then all the even ones (interlace format)
 Full screen takes 1/30th of a second
 Use 60fps to improve visuals, but only half of each frame
actually gets drawn by the screen
 Do consoles only render 1/2 screen each time?
 It was once argued that 10fps was required for a sense of
presence (being there)
 Head mounted displays require 20fps or higher to avoid illness
 Many factors influence the sense of presence
 Perceptual studies indicate what frame rates are acceptable
Reducing Lag
 Faster algorithms and hardware is the obvious answer
 Designers choose a frame rate and put as much into the
game as they can without going below the threshold
 Part of design documents presented to the publisher
 Threshold assumes fastest hardware and all game features turned on
 Options given to players to reduce game features and improve their
frame rate
 There is a resource budget: How much of the loop is
dedicated to each aspect of the game (graphics, AI, sound, …)
 Some other techniques allow for more features and less lag
Decoupling Computation
 It is most important to minimize lag between the user actions and
their direct consequences
 So the input/rendering loop must have low latency
 Lag between actions and other consequences may be less severe
 Time between input and the reaction of enemy can be greater
 Time to switch animations can be greater
 Technique: Update different parts of the game at different rates,
which requires decoupling them
 For example, run graphics at 60fps, AI at 10fps
 Done in Unreal engine, for instance
Animation and Sound
 Animation and sound need not be changed at high
frequency, but they must be updated at high frequency
 For example, switching from walk to run can happen at low
frequency, but joint angles for walking must be updated at every
frame
 Solution is to package multiple frames of animation and
submit them all at once to the renderer
 Good idea anyway, makes animation independent of frame rate
 Sound is offloaded to the sound card