GameKit Networked Box2D Physics

12 Dec

This isn’t a tutorial, it’s more of a record of what I’ve discovered when attempting to network Box2D using Apple’s GameKit networking.

Basically I took my game template tutorial and mashed in the networking tutorial to see what would
happen. The ultimate goal was to be able to add network multiplayer to iSoccer.  I was pretty close to success however the physics sync jitters more than I think is acceptable for a production iOS App.  It may be good enough for your purposes however so I suggest trying it out anyway. Perhaps you can suggest a better way, I’m really keen for one!

Download the Networked Box2D Xcode ‘Testing’ project from here.  If you’ve used my other testing projects please ensure you click Product , Clean in Xcode to remove any conflicts.

Network Game Ground Rules

After reading this article I can surmise that I should:

  1. Use UDP
  2. Send as little data between devices as possible
  3. Implement client side prediction (i.e. run the physics simulation separately on each device and only sync forces that change the simulation on each device)
  4. Send over the game state every now and again as a true-up

How’d that go?

Not great, although GameKit uses UDP so hooray for at least one thing.

Based on the rest of the ground rules I determined it would be a good idea to start the game on each device in the same state.  That is, the same physics starting point.  That begs the question – how do we sync two Box2D states on separate devices?  The answer direct from the creator of Box2D is you can’t.  Sad face. Part of the reason is that you can’t guarantee each device will produce the exact same simulation as the CPU and runtimes may differ.  There is no network support for Box2D.

Now what?

Maybe Client / Server?

Next step was to say well fine we will have one device do all the work and just send position info to the other device.  You can see the results for yourself in the downloaded project.  Close but no cigar as they say.

I’m still looking for a solution to this problem so if you have any tips send me an email!


Be Sociable, Share!

    About Tim Roadley

    I'm a Technical Solutions Architect at Park Assist (TKH Group). My current focus is the design and implementation of a Network Operations Centre (NOC) for Westfield (Scentre Group). Prior experience includes successful design and implementation of custom business intelligence dashboards for Westpac and a payments switch for Cuscal (RediATM). My current skill set includes solution architecture, business analysis, stakeholder management, project management, consulting, software development, IT infrastructure management and technical documentation. I've published a book on Core Data through Pearson Education, which you can find on Amazon by searching for my name. An updated version on this book is targeted for release before the end of 2016. I have several apps on Apple's App Store, including Teamwork, iSoccer, Grocery Dude (Objective-C) and now Groceries (Swift). In my down time I enjoy spending time with my wonderful wife Tracey and two lovely children Tyler and Taliah.

    Posted by on December 12, 2011 in Blog


    5 Responses to GameKit Networked Box2D Physics

    1. Pablo

      January 18, 2012 at 12:13 pm

      Hi Tim, how are you doing? Thanks for posting your findings.
      I am currently developing a platformer game that requires realtime multiplayer like for example Muffin Knight.
      Did you make any progress with this? Although my game doesn’t use any physics engine the same rules you wrote apply.
      If you have any useful info you can share or discuss, please contact me!

    2. Karl

      April 30, 2012 at 4:06 pm

      hi, if do all box2d simulation on one device then send the positions to other device, can the game run smoothli on other device?

      • Tim Roadley

        April 30, 2012 at 5:39 pm

        Nope, it doesn’t work and I have been unable to fix it.

    3. Ron Schachtner

      May 1, 2012 at 12:04 am

      Okay, I have not taken a deep dive into iOS networking support yet, but 15 years working on Infrastructure has given me plenty of looking at networking.

      So my fellow Wolfenstieners, welcome to solving the Doom issue.

      First, UDP is a terrible game networking protocol. Why you ask? it is simple, no synced transmissions and no error handling. I dont mean programming errors, I mean packets get dropped and it goes on. UDP also does do sequencing, however, there is no handshake or confirmation of delivery (the Syn-ACK part of TCP).

      Second, networking at a dedicated speed witha dedicated error free link (like through a cable) is really the only way to sync all game states between two applications.

      Third, the Peer -to- Peer model Apple has adopted natively has its limitations, as you are currently seeing.

      Solution 1) Client – Server, this model the servers are run remotely, the client application logs into it and only handles local displays of objects. This is very popular model in the current realm of iOS MMOs; however, it is also not ideal for small games developers nor of ad hoc type game play. This also requires formulating a restful XML calls, player disconnections and management of display objects from the backend. It does have its advantages, like new game play / features can be rolled out at any time.

      Solution 2) Local Peer -to- Peer networking. The way I see it depends on the game. I am also going to take a breath here for a second and share some thoughts:

      The real goal is to display two objects on two devices in sync with themselves. These two objects need to share the same attributes at the same time. The issue is that neither of the two devices are capable of displaying the EXACT same thing at EXACTLY the same time. PERIOD. The reason is that we write code, that code is complied and then processed on each devices separately. Everything takes weight at this point, what apps are running, if you got a banner message, GameKit call back completions, every thing on the device suddenly impacts the game and object sync.

      The old advice – “Send as little as possible” seems like a good thing, except it’s not. The second tendency is fire and forget. Fill up the /dev/null with it.

      So what about frame rate? how many frames per second is your app running at? The game code it self does not run at a frame rate, it runs at loops per second. HOW often is your update function being called to move the ball across the screen? 25 times per second? 180 times per second? We use frame rate as a visible test, but perception is the important part.

      So we know we have this update function that fires off to move the ball into position. And we know we can send that packet to the other device without issue. What we do not know is how long the delay is going to be before the ball is actually moved on the other device, which might be firing off messages back to us telling us the ball moved to position.x as well. So what we need is an object to pass between two points, that has all of the sync information, that will confirm the ball was moved, so we can continue moving it.

      So the first thing I would do is figure out the packet exchange rate on iOS. How many packets can i send per second as optimal vs. how many can be sent with loss.

      The second thing we should do is slow down the frames per second to 30 – 45 so we can get at least 4 packet update streams between the devices.

      The third thing we should do is write the same update function for both sides. One side will need to establish control but screen updates need to happen by both sides after confirmation, knowing there is going to be a delay due to packet exchange, loss, and processing.

      I will be starting a multiplayer shooter programing this weekend of May 5th. Maybe we can work out the issues together.

    4. Efekan

      September 17, 2012 at 6:47 pm

      Hi Tim,

      I was wondering if you were you able to do it ? I’m working on a similar project and I have the same problem.


    Leave a Reply

    Your email address will not be published. Required fields are marked *