Continuous World

The Continuous World of
Dungeon Siege
GDC 2003
Scott Bilas
scott@gaspowered.com
Gas Powered Games

Everything on fire, all the time
Cell Phones?
Overview
What
is Continuous World?
Concepts
Terrain
Game Objects
World Streamer
Odds and Ends
What is Continuous World? V1.0

Many
Jak & Daxter, Drakan PS2, Spec Ops, flight sims
What
games have similar sounding feature

does it mean to Dungeon Siege?
No loading screens except initial game load

Gameplay never stops from begin to end
Seamless indoor/outdoor transition
Extreme changes in environment
Constantly changing working set of resources
8-Way client/server multiplayer (#@!!)
What is Continuous World? V2.0

Realized
Fine-grained streaming avoids choke points

No arbitrary constraints in any direction
Extreme density and variety of content possible
Scary
new advantages during development
things too
Teleportation across the map

Took over entire game despite our best efforts
(Fun) Demo!
Concept: Siege Node

Basic
Drives entire game
3D
artist makes mesh and exports to game
Mesh is completely arbitrary, no engine constraints on

size, shape, lights, textures, connections
Can mark polys as floor, water, etc.
Map
3D terrain element (tile)
= instanced meshes placed into graph
Placement done with Siege Editor

Similar to Lego system snap pieces together
Concept: Siege Door

Nodes
are connected along doors
Legacy term from when they really were doors
Artists
choose verts for each door in Max tool
Concept: Game Object

Represents
all non-terrain and

interactive logic content
Similar: Entity, Actor, Object, Pawn, etc.
99% are based in Siege Nodes
Node = spatial owner (this is key)
Result:
terrain engine drives game objects
Nodes act as buckets for spatial sorting

Nodes used for relative queries (whos near me?)
Concept: World Frustum

Visualize
as a box moving through the world
One owned by and centered on each party member

Intersect with world node graph to decide which
nodes and Gos are kept in memory and active
Box dimensions configurable by code or content
Large superset of view frustum
Anything outside the box does not exist
Term
is misleading and inaccurate (sorry)
(Happy) Demo!
The Precision Issue

Gigantic
continuous world != numerical stability

Increasing distance leads to quantized space
Eventually everything is in the same place

Increasing float precision will not solve
Conclusion:
axe the unified coordinate system
Segment the world

Periodically reset precision by switching
coordinate systems
Now you can go in any direction forever, worry free!
The Precision Issue (cont.)

Experimented
for a while
Ended up with variation on portal engine
Each chunk of geometry has its own space

Geometry (nodes) are linked together into terrain
Evolved
beyond FPU precision solution
Became primary method of subdividing space

Root of countless optimizations
There
is no world space!
Engine Mechanics
3D
Position had to be augmented
SiegePos = node ID + x,y,z (relative to node origin)

Can represent a position anywhere in the map
Rendering
to avoid seams
Just render nodes on top of each other

Stitching to form continuous mesh not necessary
Engine Mechanics (cont.)

Node
graph = entire continuous world terrain
Each node has a unique ID

Linking done through doors
Door really = transform under the hood
Engine
is 3D, but up is always up
Nodes are rotated in flat space to hook together

Can think of engine as old fashioned 2D tiles
Permits significant optimizations (e.g. pathfinder)
Had to alter some design elements such as flying
Constructing Worlds
Maps
built using our Siege Editor tool
Choose a start node, the type of node you want to

place near it, and flip through orientations
Drop objects into nodes and customize properties
Repeat hundreds of thousands of times!
Sarah Boulian is giving a talk on this in an hour

(go see it!!)
Constructing Worlds (cont.)

Maps
broken into regions
Editor not continuous; edit in chunks that fit in RAM

Stitch regions together, game sees as continuous
Allows
terrain that bends space
Convenient for designers (easier to make things fit)

Fading = interpenetrating terrain invisible to player
Goofy possibilities: infinite desert, moebius strips
(Fading) Demo!
World Space
Ok,
we actually do have world space
For one frame

Maybe longer, but dont count on it
Need world space for diff calcs, render tris, etc.
Space
is tracked by choosing a target node
This node defines space (its origin = world origin)

We just use the center of the current world frustum
Frustum moves with each party member
Party member crosses node: new coord system
World Space (cont.)

Why
Good balance of testing vs. efficiency

Need to change as often as possible to avoid boundary
conditions
The
change at node boundaries?
Space Walk
New coordinate system = must rebuild space

Each node requires transform to target node space
Walk outward from target node, visit neighbors, accumulate
transforms (similar to skeletal animation system)
War Story
The Arrow Problem

Walking
Find containing node for arrow to collide Gos

Relative coords requires starting node for ray trace
Ray trace has to walk outwards to max depth
Arrows can fly right through people!
Arrows
process
would break every couple weeks
Fading, scaling, attaching, spawning, collisions

Had frequent problems with node-straddling systems
(projectiles, particle system, etc.)
Evicting Nodes
Frustum
= cache management system
Anything inside is kept active in memory

Anything outside is thrown away or put on death row
Algorithm
Walk outward from target node

Any nodes intersecting frustum box are loaded
All others are deleted, and contained Gos notified that
they have left the world
Complicated by multiple frustums!
Multiple Frustums
Originally
implemented for party-split feature
Later required for multiplayer anyway
Implementation
Multiple simultaneous coordinate systems

Glomming technology to determine winner
Single
player still needs it
One is considered active and its contents get time

Everything else, time is frozen (by design, but good for
CPU also)
(Multi-Frustums) Demo!
Great World Detail

World
originally sparsely populated

Artists started experimenting with density just
to see how it would perform, what it would look
like, and
Evicting Game Objects

With
60,000 Gos per map, very important
That can take up a lot of memory

Have to classify critical/non-critical
Deciding
what to throw out (not like nodes!)
Keep everything: machine runs out of memory

Keep nothing: lose critical quest states and have I
killed boss X and gotten loot Y triggers
Want to try for keep nothing but err on the side of
keep everything.
Eviction Strategies
Fluff removal
Automatic expiration on leaving the world

Scid retirement
lodfi
(Scid = static content identifier)

Try to self destruct everything possible
Data reduction
Scidbits
Model/texture purging
Continuous Logic
Building
No fixed places (like level transitions) to delete everything

old and load everything new
No entry/exit points to hang scripted events
Long term game stability far more important
Difficult to affect objects not immediately nearby
Not
interactive logic without levels is hard
only is world continuous, but logic is too!
This took years for us to fully grok

Cant cover very much of it today!
Continuous Logic (cont.)

Continuous
world = constant change
0.4% of the games resources are in memory

Gos are constantly entering and leaving the world
Leaving is the hard one!
Dependencies
among Gos must be weak
Your referenced Go may leave world next frame

It may get deleted, too
A new one may get put in its place with the same ID
(although this is unlikely)
Two men enter, one man leaves
Continuous Logic (cont.)

Game
must be very tolerant of failure
Especially at frustum boundaries

Added a number of self-healing features
Multiplayer complicated things a little
Multiplayer
Each
Too expensive for bandwidth, CPU, otherwise

Server tells each client to create objects that are in its
frustum, and deletes them outside (no expiration)
Frustum membership used to route RPC packets
State
machine only knows about local frustum
delta transfer
Track dirty Gos

Send delta packet with creation request
Transfer minimum visual data required for client
(Dirty Gos) Demo!
World Streamer Implementation

Secondary
thread, loads resources
Primary thread makes requests:

nodes, textures, Gos
Textures use blank (or white) placeholder on load
Gos fade in when loaded
System bets on the objects being there
Streamer Problems
CPU
performance
Must be < 20% on second thread or player notices

Want to keep the load steady, not bursty
Original intention was DMA only, but zlib killed that
Kept load balanced by throttling work order filling
Continuous
performance
We are experts at thread contention (not good!)
Thread Contention
Bad
Much of Go load path on second thread

including parameterized content (gah!)
Most of game had to be thread protected
SmartHeap had to run serialized (5% perf loss!)
Not
threading model for Gos
fully solved
Still hitches due to lack of serious time spent on it

Maintenance of systems too difficult
Odds and Ends

Teleporting
hackery (H.U.B. system)
Became critical must-have feature

Engineering nearly drank the Kool-Aid
Implementation
Elevator system and invisible nodes

Wacky node swapping
Frustum size and fog changes to smooth load
Complicated level designer wiring of objects
It works!! Ship it!!!
(Teleporter) Demo!
Pathological Cases
The Castle Ehb
Its
slow
Blamed on high poly for a long time (partially true)

Was at end of game so few played it
Profiling
Implicit optimizations towards farmhouse nodes

Lighting expects small nodes (relatively few verts)
Game dbs expects few node occupants
Lesson
reveals
learned
Um, play the game (not obvious!)
Pathological Cases
U-Shaped Terrain
Direction
of motion
through world matters!
Exposed extremely obscure bug
Occurred in a totally normal-looking area

Caused Edge-of-World Syndrome
Complicated by multiple frustums, as usual
Lesson
learned
Build test maps for all possible boundary conditions

Not as obvious as this may seem
Hardware Problems
Setup
issues collide with streaming data perf
Hard drive fragmentation

Heavy reliance on DMA transfers enabled
Other games just load slower DS is paralyzed
Exercise
of most computer systems at once
CPU, video, HD, network, sound all constantly used

L33t overclocker troublemakers!
Quake 3 runs fine
Fun! Before and After
Further Reading
GDC
Neverwinter Nights Client/Server Postmortem,

Mark Brockington, Scott Greig
Highly Detailed Continuous Worlds,
Stuart Denman
Building an Object System, Alex Duran
Technology of Jak & Daxter, Stephen White
A Data-Driven Game Object System, Scott Bilas
Further Reading (cont.)

Papers
Postmortem: Gas Powered Games Dungeon

Siege by Bartosz Kijanka (on Gamasutra)
Be sure to read my paper in the Proceedings, it
goes into details in many places this lecture did not
Done!
Suggested Comments:
This is the (best/worst) talk Ive ever (been to/slept through)
<Insert name of speaker> changed my life forever.
I H4X0R YUO ALL!@!1!!
(He/she) didnt go into enough detail, and bored me to death.
(He/she) went into too much detail, and bored me to death.
Contact Info
Scott Bilas
scott@gaspowered.com
http://www.drizzle.com/~scottb/gdc
Paper is posted there currently
Slides will be posted sometime next week

Continuous World

Uploaded by

Copyright:

Available Formats

Continuous World

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Continuous World

Uploaded by

Copyright:

Available Formats

The Continuous World of

Gas Powered Games

What is Continuous World? V1.0

Jak & Daxter, Drakan PS2, Spec Ops, flight sims

games have similar sounding feature

No loading screens except initial game load

What is Continuous World? V2.0

Fine-grained streaming avoids choke points

new advantages during development

Teleportation across the map

Concept: Siege Node

Drives entire game

artist makes mesh and exports to game

Mesh is completely arbitrary, no engine constraints on

3D terrain element (tile)

= instanced meshes placed into graph

Placement done with Siege Editor

Concept: Siege Door

are connected along doors

Legacy term from when they really were doors

choose verts for each door in Max tool

Concept: Game Object

all non-terrain and

Node = spatial owner (this is key)

terrain engine drives game objects

Nodes act as buckets for spatial sorting

Concept: World Frustum

as a box moving through the world

One owned by and centered on each party member

is misleading and inaccurate (sorry)

The Precision Issue

continuous world != numerical stability

Eventually everything is in the same place

axe the unified coordinate system

Segment the world

The Precision Issue (cont.)

Each chunk of geometry has its own space

beyond FPU precision solution

Became primary method of subdividing space

Position had to be augmented

SiegePos = node ID + x,y,z (relative to node origin)

Just render nodes on top of each other

Engine Mechanics (cont.)

graph = entire continuous world terrain

Each node has a unique ID

is 3D, but up is always up

Nodes are rotated in flat space to hook together

built using our Siege Editor tool

Choose a start node, the type of node you want to

Sarah Boulian is giving a talk on this in an hour

Constructing Worlds (cont.)

broken into regions

Editor not continuous; edit in chunks that fit in RAM

terrain that bends space

Convenient for designers (easier to make things fit)

we actually do have world space

For one frame

is tracked by choosing a target node

This node defines space (its origin = world origin)