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 doesn’t 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 don’t 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 can’t 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 • Can’t 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