KIPA Game Engine Seminars
Day 1/25: Introduction
Jonathan Blow
Seoul, Korea
November 26, 2002
1
Today’s Schedule
Introduction (70 minutes)
break
Frame Rate in 3D Games (70 minutes)
Lunch
Game Development Process: Programming (70 minutes)
break
Game Development Process: Design Loop (40 minutes)
break
Literature Recommendations, More Examples of Math (70 min)
Closing Q&A
2
1. Context
Who is this guy?
What are these lectures about?
3
Who I Am
• Independent game technology researcher
– Attacking hard game engine problems
• Example: Autoportalization
• Consultant
– PC, Xbox, Gamecube games, a little bit of
PlayStation2. A lot of PC-side tools.
• Technical columnist
– Game Developer Magazine
4
Portalization Example
• Portals are a method for dynamic visibility in 3D scenes
– Why Dynamic Visibility
– Alternatives: PVS, dynamic occluders
• Creating portals for a 3D scene is hard
– Algorithms create too many portals,
and bad ones!
• Artist-placed portals are tedious (and produce bugs)
• Can we model a portalizer on perceptual heuristics rather
than geometric primitives?
– Applying computer vision research to building game tools
5
My History
• Hobbyist game programmer since I was 10 years
old (1981)
– Commodore Vic-20, Commodore 64, TRS-80 Color
Computer, Apple 2
• Professional programmer since 1988
– Sound tools for a C64 game!
• 3D game programmer since 1995
– Right when 3D was taking off in America
– Nearly 8 years ago (but 8 years is not long!)
6
Why I Am Lecturing
• Sharing information is important to the state of
the art
– I learned from magazine articles by Michael Abrash,
Chris Hecker and others
– By lecturing and writing articles, I continue that cycle
• Game Developers Conference, mailing lists
– American developers share technical information
freely
7
Making 3D Games is Hard
• It’s so hard, as a community we need all the
help we can get
• By improving the general level of game
quality, we grow the whole market
– As opposed to fighting over a small market
8
Format of the Seminars
• 25 days, in Seoul and Suwon
– 20 days of lecturing
– 5 days of consulting/Q&A/office hours
• Video Tapes will be available
• Source Code is available
– I will refer to it often in the lectures
9
These Lectures
• Audience is 3 different groups:
– Professional Korean 3D game developers
– Professional Korean 2D game / software
developers who are starting with 3D
– Students studying 3D graphics / games / media
10
Audience wants 3 different things
• Established 3D game developers
– Already have their own code or licensed engine
– Want high-level solutions for managing game
development (important!!)
• Developers new to 3D games
– Want specific introductory details
• Students
– Want open research problems, also game
industry experience and observations
11
Audience wants 3 different things
It’s difficult to please everyone…
But I will try!
12
I want the lectures to be as
interactive as possible.
• Will take questions in mid-lecture to help
steer things where you want to go.
• Will modify the source code based on your
questions and comments
– Updated source will be delivered to KIPA
– Maybe a CVS feed in the meantime?
13
Philosophy of Lecture Content
• Sometimes I will talk about very concrete,
low-level things (function calls, shader
equations and flags, etc)
• But I will be using these only as examples
to illustrate things that are more general /
important
14
I will focus on the “hard things”
• Areas of game programming that require a
lot of research and study to understand
– Focus on some particular math
• Things that game programmers have only
learned through years of experience and
getting things wrong
– Software engineering practices
– Ways to prioritize goals
– “Process”
15
I am a computer scientist
as well as a software engineer
• As much as possible, I will try to be
scientific
• This means reporting observations even
when the reports make people unhappy…
16
Criticism
• I will criticize established game engines and
code libraries
– Unreal, NDL NetImmerse, etc
• I will criticize my own code
• I will say negative things about many books
But I will say positive things about all these
subjects as well
17
Criticism
• Also, criticism / negative comments must be
taken in the right spirit
– As game programmers, we know there’s just
too much work to do, and it’s often too hard to
implement what we know is the “right thing”
• Paradox of the Unreal Engine
– It’s the best general-purpose engine, but it is not
very good.
18
But…
• Hopefully soon we will see licensable
Korean game engines that are better than
what’s available now.
19
Questions?
• Break time!
20
2. Frame Rate in 3D Games
21
Purpose
• Provide a technical framework for the rest of
today’s content
– Will discuss in later sections like “Process: Design”
• Show how math is important to all game
programming
– Not just 3D!
– Thus I justify my eagerness to focus on math
22
Biggest Purpose
• To show that something as simple as the
frame rate can be very complicated, can
benefit greatly from careful thought
• We must apply such careful thought to all
aspects of a game engine
23
Effect of rendering time
on user perception/action
• Game performs 3 basic tasks:
– reading input
– simulation
– rendering (output)
• Game spends most time in
simulation+rendering, very little time
reading input.
24
Perception/action latency
as a function of rendering time
Simple game pops up a target; user shoots at the target.
= 1/60 sec ~~ 16msec
CRT
RENDER
SCENE DISPLAYING
SCENE
W/TARGET
PAGE FLIP
SIMULATION
CREATES
TARGET
LIGHT HITS
USER’S EYE
user
reaction
time
USER
PRESSES
BUTTON
CRT
RENDER
DISPLAYING
SCENE
W/GUNSHOT SCENE
SIMULATION
HANDLES
BUTTON PRESS
LIGHT FROM
USER’S OWN
REACTION
25 EYE
HITS HIS
This happens in a pipeline.
CRT
RENDER
SCENE DISPLAYING
SCENE
W/TARGET
user
reaction
time
CRT
RENDER
SCENE DISPLAYING
SCENE
W/TARGET
CRT
RENDER
DISPLAYING
SCENE
W/GUNSHOT SCENE
user
reaction
time
CRT
RENDER
SCENE DISPLAYING
SCENE
W/TARGET
RENDER
SCENE
W/GUNSHOT
user
reaction
time
26
Be careful with the main loop
• Minimize latency!
• Good: while (1) {
read_input();
simulate();
render();
}
• Bad:
while (1) {
simulate();
read_input();
render();
}
27
High Frame Rate
Is Important
• How do you measure frame rate?
(t1 - t0) = frame time “dt” = seconds per frame
1/(t1 - t0) = frames per second = fps
• But the instantaneous value is not too useful…
especially at high frame rates
• Games these days can run at > 60fps!
• PC Bang equipment will be that good eventually
28
Example Program:
specular_param
• (Overview of program, exploration of frame
rate issues)
29
dt-Independent IIR Filter
• (derivation on whiteboard)
30
Summary:
Three Methods of Frame Rate
Measurement
• Instantaneous dt
• Array averaging
• Time-independent IIR Filter
• All have drawbacks, but the best one
requires serious thought
31
PROBLEM
• Many people think frame rate is simple, so
they end up with something like array
averaging
– We will see why array averaging is so bad, later
today
• Games are full of situations like this: we
don’t recognize that sophistication is needed
so we do something wrong
32
Frame Rate Stability
is More Important
Than High Average Rate
• Most researchers are used to working on
batch code
• SIGGRAPH ‘12% faster’ syndrome
33
Bruce Naylor’s GDC lecture
about dynamic scene modification
34
Mark Duchaineau’s
ROAM algorithm
• Designed for features that don’t even make
sense if you want a stable frame rate
(hi Mark)
35
36
“binary triangle tree”
37
Questions?
38
3. Process: Coding
39
Compile/Edit/Debug Cycle
• How long does it take to successfully make
a change?
– Syntax errors, crashes must be fixed
• How long does it take to judge the
suitability of that change?
40
Short Build Times Are Important
• But many companies suffer through long build
times
• Ion Storm has build times of 25 minutes; this is
not unusual.
• Unreal Engine encourages full rebuilds
– Even for script changes!
– NCSoft guys know what I am talking about here
41
Casey’s Study
• (refer to handout)
• Some conclusions:
– STL is very slow
– Template instantiation can be somewhat slow
– Requiring these in your header files really adds
up
42
Reducing “in name only” dependencies
• In C++ all pointers are the same size
• The compiler doesn’t need to know the size
of a class if you only use pointers to it
– A lot of things in C++ are about size really
• Forward-declare instead of #include
• Tremendous decrease in build times over a
large project
• Some people are aware of this but they
underestimate its importance
43
Source Control
• Universally bad
–
–
–
–
SourceSafe
CVS
Perforce
AlienBrain
• A huge time sink
– Explanation of the process at Ion
44