GDC2011: Networking for Physics Programmers

This year I’ll be presenting a new version of Networking for Physics Programmers as part of the physics tutorial day on Tuesday.

As for the material to be presented this year, it will differ significantly from prior years. I’m going for more advanced material this year so I’m not going to spend 5 minutes explaining UDP vs. TCP. We’ll be skipping that and going right to the interesting stuff which is:

1. How to develop your own custom network protocol in UDP. Reliability and acks, node / transport abstraction, how to structure your game protocol and serialize packets.

2. Overview of game networking models. Pure client/server, FPS networking model with client side prediction, deterministic lockstep, authority scheme. Examples of games using each technique. How each networking model works. Advantages and disadvantages. Understand the trade-offs so you can pick the best networking model for your situation.

3. Worked example: authority scheme for networked physics in a large streaming world. Same cube demo. Different networking strategy. This year I’ll be doing it dedicated client/server style instead of P2P and I’ll focus on all the practical details and tricks required to synchronize physics state in under 64kbit/sec such as: compression tricks for position, orientation and linear/angular velocity, how to prioritize object updates when you have too many objects to fit in one packet, using a reliability system and acks to avoid sending at rest objects over and over, lossy compression, quantization and other neat tricks.

Hope to see you Tuesday, March 1, in Room 3007, West Hall Moscone Center. I’ll be talking from 3:30PM- 4PM

Schedule details here.

UPDATE: Unfortunately the original material as presented above consistently took 2.5 hours during practice sessions. As a result, I’ve had to cut section 1 and 3. There is a lot of great info in section 2 and the feedback from practice sessions was consistently that it was the best section of the talk. If you’d like some information about #1 and #3 you can ask questions during Q&A, plus I’ll be available during GDC for impromptu meetings etc. where I can go over this info with a whiteboard or a notepad. DM me on twitter if you’d like to meet up: @gafferongames

, ,
28 comments on “GDC2011: Networking for Physics Programmers
  1. Hi Glenn,

    Thank you for the wonderful website and awesome material.

    I was wondering how reliable NAT Punch-through can be for internet co-op games, we had plans to run our own facilitator server and connect host servers and other clients together using NAT punch through but recently we’ve been hearing some negative words about this technique not being reliable. I was wondering if we need to consider other methods for running the co-op game. (Proxy servers, dedicated servers?)

    Any advice from you is highly appreciated.


    • My experience is that it’s generally unreliable, and that you should implement packet forwarding through the server machine as a backup. cheers

      • Thank you for the reply. Packet forwarding would mean having setting up a proxy server and having all player traffic pass through our server, right?

        • Would it? If you are a peer-to-peer game why not just pick one of the peers as the “host” and forward packets through that guy. You pick the host as the player with the best NAT settings, eg. NAT type 1s and 2s

  2. Hi Glenn!

    I’ve used your previous networked physics code in my project. Basically rewriting it for my to-be game engine.
    However, I noticed that compiling and running your code as it is breaks it instantly. In history.h
    it breaks cause of the assert(!empty()); line 263: Move& oldest()
    return moves[tail];

    I tried imitating your code for collision with cube vs planes but between cubes. And I’m getting exploding physics, ie values out of bounds 😛
    I’ve got one static object, I simply don’t apply any physics to it (to simulate a collidable tile)
    and I’ve got one object falling straight down onto this static object. Upon impact the velocity up is going out of bounds :) instead of plane.normal I use Vector(0,-1,0). -1 is up for me. I’d be grateful for any help.

  3. Dear Mr. Fiedler,

    At first thank you for this very insightful blog, I particulary enjoyed the “Fix your timestep”-post as it helped me tremendously with a project I was working.

    Currently I’m investigating Networked Physics and how feasible it would be in my situation. I have watched your slides, however, they did not bring me the satisfaction I was looking for and would like to ask for some advice – mind you they were very informative regardless.

    I’m currently working on a singleplayer physics-orientated game where I would like the physics to be calculated server-side. This because the game will have leadersboards, persistant player progression, etcetera and I want to prevent cheating – basically a pure client-server architecture, the client is “dumb”. The problem however is that the game will most likely be played by hundreds (maybe thousands) of people at the same time. This “requirement” concerns me, as it will most likely kill server-processing power if I have to do and maintain thousands of states at the same time.

    I would have no problems moving all of the physics simulations to the client-side, but I can’t figure out a way to validate if a client-state is valid and not tempered with by hacking.

    What kind of approach would you recommend me considering the above described requirement? I particulary like the idea of having all physics client-side, but as said, I need a reliable server-side form of validation. Physics will become about as complex as the boxes in your GDC demo, maybe even less, but a lot more always colliding rigid bodies in a single scene, all visible at once.

    I thank you for your time,

    Yours sincerely,
    Lennard Fonteijn

    • This sounds particularly difficult, with 1000s of players you are basically making an MMO with physics. I don’t see too many of those around.

  4. Someone’s gotta film you next time. Can’t figure out the Deterministic Lockstep bit with GGPO and those forks.

    • When you have inputs from all players you step the simulation forward. When you want to locally predict ahead just using your own input, you copy (fork) the simulation and step forward in this copy using just your own inputs. The next time you advance the real simulation forward you throw away the copy and make another.

      • Yeah, us Windows guys can’t open the keynote file unfortunately. Any chance of getting a Windows-compatible version? Either PDF or PPT (PowerPoint) would be awesome. Thanks!

  5. Hello,
    I’ve been waiting for your slides and your source code since I’ve seen your post in your blog. Unfortunately, you are too busy to post or you just simply forgot about.
    Anyhow, we are still waiting for your slides and I hope you post it soon.


  6. Pingback: GDC Diary 4 – Tutorials and Summits : Hazel McKendrick

  7. Heads up I’m a bit late getting the final slides ready due to a problem with my macbook air. Final slides will be done this week. cheers all

  8. Hi!

    For those of us who are unable to attend the GDC, will you release any material (like slides, or video?) presented in your talk here on your blog? I can only speak for myself, but at least I would really appreciate that. :)


  9. If only I lived on the west coast…. I’d love to come listen. I hope it goes great and I really hope you post everything on your website after you’re done! :)

Comments are closed.