Burnout 3: Case Study (Outline)

1
Burnout 3 Case Study(Outline)

• What is Burnout 3?
• What does this mean?
• How did we satisfy these constraints?
• Racecars
• Traffic system
• Aggressive driving
• What did we learn?

2
What is Burnout 3?

• Racing
• Aggressive driving
• Crashing
• Traffic
• Fast paced, twitch gaming

3
What does this mean?

• Racing
• Cars must be in the right position, travelling at
  the right speed
• Car movement should be as smooth and similar to
  offline as possible
• Cars will only change speed/direction gradually
• Aggressive driving
• Cars really, really must be in the right
  position, travelling at the right speed
• Important events must be the same on all consoles
  (slam/shunt/takedown)

4
What does this mean?

• Crashing
• Cars must be in the right position, travelling at
  the right speed
• Cars must be able to change velocity sharply
• Traffic
• Traffic system must handle up to 254 cars without
  maxing out bandwidth (10kB/s)
• Fast paced, twitch gaming
• Client must be authoritative

5
Racecars

• Client owns their own position
• Your car doesnt jump or move unexpectedly
• Open to cheating

6
Racecars version 0.1

• Send matrix and velocity in update packet
• Put the racecar where the packet says, when it
  arrives
• Cars are seen in the past
• Cars jump when latency varies (and it does!)
• Simple and cheap (memory CPU)

7
Racecars version 0.5

• Buffer message
• Apply it when its time has come
• Cars are smoother
• Cars are even more in the past because
  buffering adds latency
• If you dont apply packets you receive late you
  are artificially increasing packet loss too
• Uses slightly more memory, but still cheap in
  terms of CPU
• More complicated, and applying late messages
  makes it even more complicated

8
Racecars final version

• When message arrives extrapolate position
  forwards in time
• First attempt extrapolating position using
  velocity
• Second attempt Lightweight version of physics
• Cars are seen in the present
• Not as smooth as version 0.5
• Expensive in CPU

9
Traffic System

• Size of traffic ID/position/orientation 10 bytes
• Traffic system is updating up to 254 cars at once
• So total packet size to send position and
  orientation of all traffic is 2540 bytes!
• Traffic system must be deterministic

10
Traffic System

• Based on lanes
• Traffic cars follow a param along a lane
• Traffic cars stop at traffic lights
• Traffic cars change lane at certain points
  (splitters)
• Divergence detection
• In game replays helped lots!

11
Crashing traffic

• If a car crashes you cant remove it from the
  traffic system
• It becomes invisible, and ignored by physics
• Traffic ownership
• You detect that an unowned traffic car has
  crashed
• You start sending out updates (you own it)
• Other people apply your updates
• Is possible for more than one player to own a
  traffic car
• Cant afford to extrapolate, so run in the past
  (racecar version 0.5)
• Change to past masked by smoke and particles!

12
Aggressive Driving

• Send extra info in updates (slam/shunt/takedown)
• Send multiple times in case of packet loss, but
  only for about half a second

13
Pickups

• Similar to aggressive driving
• Two players can get the same pickup

14
End of race

• Send results packet
• Race time
• Fastest lap
• Crash damage
• Pickups
• Susceptible to cheating

15
What we learnt

• Plan to network from the outset
• Traffic system
• Try anything unknown in prototype
• Racecars
• Crashing traffic
• Networking strategy is game-specific
• Reassess if game design changes
• Develop and test in real world conditions