Solving the Networked Physics Puzzle

Traditional networking techniques work well for simple linear motion, but start to break down when networking complex rigid-body physics simulations where objects can tumble, stack and interact with each other. This light-hearted and humorous tutorial takes a look at various options, techniques and pitfalls to watch out for when networking this sort of simulation, providing you with a tool-bag of new techniques and ideas you can use to network your physics based game.

I’ll be performing this talk at the Montreal International Game Summit on November 16, 2009 – 10:15AM in the Verdun Room. I’m honored to be invited to perform one of the first sessions at the conference and hope to see some of you guys there! Please come up after the talk if you would like to discuss anything at all I will be available for questions.

Plus, this will be my first time visiting Montreal so I’m very excited!

I have the demo for the talk almost ready and have been working on the slides over the last few weekends. Right now I’m trying to lock down the overall theme of the talk and the content. My goal is to provide lots of interesting information without going to deep into the specifics on any one thing. Ideally folks should leave the talk with a great outline of the whole field and some great ideas and inspiration to take home to apply to their own projects!

Here is a more detailed version of my talk plan:

I intend to start by asking the question: why is it that very few games provide meaningful interaction with networked physics objects? In other words, folks it’s 2009 – why exactly are we still running around mostly static worlds shooting other people in the face?

There are many reasons. It is difficult to light a dynamic world. Character movement and animation is difficult. But also, it seems very difficult to network a dynamic world. Why is this? Traditional networking techniques don’t work. Objects can stack and tumble and interact with each other.

In truth: It’s like a puzzle. It’s actually really simple – you just need to think in a different way.

Quick 5-10 minute recap of a game networking engine. UDP vs. TCP, how to construct packets, serialization, reliability, flow control. All of the stuff in my online book and more at a brisk pace for folks already in the field. My goal is simply to get everybody on the same page and provide some very useful, concrete information for folks in the field. Here is my network engine and how I do everything.

The plumbing is out of the way. Now, lets explore options for getting a physics simulation on one computer to be simply *viewed* on another. Two main options: 1) run the simulation on one side and present an approximation on the client side (pure client/server model), 2) run the simulation on both sides and synchronize via state replication. Compare and contrast these two approaches. Touch on time synchronization and real-time nature of protocol and why it is now this way vs. traditional networking technique.

Latency compensation. Consider the same situation: A simulation synchronized between two computers, but now client controls their own object. Recap traditional client side prediction from FPS games. Attempt to apply it to network this physics simulation. Problems: Rewind and replay cost. Simulation islands. Complexity. Authority scheme as an alternative. Dining philosophers problem. Distributed programming. Dykstra. Consistency vs. throughput trade-off. Case studies.

Live demo. P2P authority scheme. Late joins. Corrections. Reverse corrections. Challenge: Think outside the box. Maybe client/server should not be the automatic choice? How important is anti-cheat for your game? How important is meaningful interaction with a dynamic world? Which one wins? Is it possible to have both? How?

Future looking. What can you do moving forward? What can physics engine developers do to make their engines network better? What do we need before this becomes practical? What will game networking look like in 10 years? Bandwidth considerations. Real-time protocol requirements. IPv6. RSVP, Flow Routing. QoS guarantees. Network neutrality.

Summary. Bring it back to the original point about the puzzle. Conclusion. Best approaches for each situation. Call to action. Triumphant dance. Q&A.

That’s about it for now. Please be sure let me know what you think and if you are planning on attending the conference. Sound off in the comments below – thanks guys!