KIPA Game Engine Seminars

1
KIPA Game Engine Seminars
Day 1/25 Introduction

• Jonathan Blow
• Seoul, Korea
• November 26, 2002

2
Todays 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 QA
3
1. Context
Who is this guy?
What are these lectures about?
4
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

5
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

6
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!)

7
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

8
Making 3D Games is Hard

• Its 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

9
Format of the Seminars

• 25 days, in Seoul and Suwon
• 20 days of lecturing
• 5 days of consulting/QA/office hours
• Video Tapes will be available
• Source Code is available
• I will refer to it often in the lectures

10
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

11
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

12
Audience wants 3 different things

• Its difficult to please everyone
• But I will try!

13
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?

14
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

15
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

16
I am a computer scientistas 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

17
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

18
Criticism

• Also, criticism / negative comments must be taken
  in the right spirit
• As game programmers, we know theres just too
  much work to do, and its often too hard to
  implement what we know is the right thing
• Paradox of the Unreal Engine
• Its the best general-purpose engine, but it is
  not very good.

19
But

• Hopefully soon we will see licensable Korean game
  engines that are better than whats available now.

20
Questions?

• Break time!

21
2. Frame Rate in 3D Games
22
Purpose

• Provide a technical framework for the rest of
  todays 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

23
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

24
Effect of rendering timeon user perception/action

• Game performs 3 basic tasks
• reading input
• simulation
• rendering (output)
• Game spends most time in simulationrendering,
  very little time reading input.

25
Perception/action latencyas a function of
rendering time
Simple game pops up a target user shoots at the
target.
1/60 sec 16msec
CRT DISPLAYING SCENE
RENDER SCENE W/GUNSHOT
CRT DISPLAYING SCENE
RENDER SCENE W/TARGET
user reaction time
PAGE FLIP
USER PRESSES BUTTON
LIGHT FROM USERS OWN REACTION HITS HIS EYE
SIMULATION CREATES TARGET
LIGHT HITS USERS EYE
SIMULATION HANDLES BUTTON PRESS
26
This happens in a pipeline.
RENDER SCENE W/GUNSHOT
RENDER SCENE W/TARGET
CRT DISPLAYING SCENE
user reaction time
RENDER SCENE W/TARGET
CRT DISPLAYING SCENE
user reaction time
27
Be careful with the main loop

• Minimize latency!
• Good

while (1) read_input() simulate()
render()

• Bad

while (1) simulate() read_input()
render()
28
High Frame RateIs 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

29
Example Program specular_param

• (Overview of program, exploration of frame rate
  issues)

30
dt-Independent IIR Filter

• (derivation on whiteboard)

31
SummaryThree Methods of Frame Rate Measurement

• Instantaneous dt
• Array averaging
• Time-independent IIR Filter
• All have drawbacks, but the best one requires
  serious thought

32
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 dont
  recognize that sophistication is needed so we do
  something wrong

33
Frame Rate Stabilityis More ImportantThan High
Average Rate

• Most researchers are used to working on batch
  code
• SIGGRAPH 12 faster syndrome

34
Bruce Naylors GDC lectureabout dynamic scene
modification
35
Mark Duchaineaus ROAM algorithm

• Designed for features that dont even make sense
  if you want a stable frame rate
• (hi Mark)

36
(No Transcript)
37
binary triangle tree
38
Questions?
39
3. Process Coding
40
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?

41
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

42
Caseys 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

43
Reducing in name only dependencies

• In C all pointers are the same size
• The compiler doesnt 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

44
Source Control

• Universally bad
• SourceSafe
• CVS
• Perforce
• AlienBrain
• A huge time sink
• Explanation of the process at Ion