Just a quick DevLog video. I originally wasn’t going to post one, after I did that big technical and business analysis of SimCity 5 yesterday. But after I finally got that all out of my system, I changed my mind, so here it is:

It’s just a quick video, this week. In it I demonstrate some progress on my “Track” GUI control. And how I fixed a bug in the XNA game timing code that was causing my networking to desynchronise (which I demonstrated last time).


Alejandro Martinez-Chacin

9:06 am, Wednesday 20 March 2013

Are you going to dive in as how you managed to attack the update freeze when tinkering with the windows? Curious as hell…

Andrew Russell

1:02 pm, Wednesday 20 March 2013

Glad you asked. I’ve posted it as a question/answer on GameDev Stack Exchange (and added a link to the blog post).


12:18 am, Monday 1 April 2013

Hi Andrew: I have been watching your videos especially for networking physics simulations and they are very informative. I wanted your thoughts on a game I am developing. I am working on a soccer game (only 2 players play a match). I don’t have an authoritative server so to speak so the game is essentially P2P, however each player connects to a “dumb server” which works as a matchmaking server as well as “message router”, both players send messages to the central server and the server re-routes messages to the peers. This a generic service that I am using so I don’t have to maintain a server myself and it helps with NAT/Firewall stuff as peers are not connecting to each other directly. depending on where the peers actually are, message transmission from one peer to another may take anything between 100 to 500 milliseconds. So with this situation, what would you recommend as a good approach for networking the physics and gamestate. I started with a basic implementation, both peers are running physics and game logic. Each peer is authoritative over his soccer team (5 players aside) and sends player velocities across as soon as velocity changes and positions across 5 times a second. player positions usually look OK on both peers in initial tests. But there are serious issues. a) game time is not synced across peers, peer 1 action takes place immediately on peer 1 but arrives X milliseconds later on peer 2 b) no peer is authoritative over the ball so no sync in place for that. even if I use strategy like peer1 is authoritative over ball if peer1 is in control of the ball and vice versa, it still leads to issues.. who is authoritative when the ball is in flight, no peer is controlling it. and peer1 stealing ball from peer2 becomes impossible as peer1 action is delayed on peer2. also there is the matter of goal scored. peer1 kicked ball, peer2 got message late and applied kick, peer2 goalie took defensive action and saved the goal but peer2 goalie action took time to reach peer1, by then goal was already scored in peer 1 simulation. Any comments on this will be highly appreciated. I am noob so please pardon my ignorance. I read up a lot on prediction/lag compensation etc but all those discussions depend on ONE authoritative server. I also thought about running the game simulation on a separate thread 400 milliseconds ahead of rendering thread but want to get your expert thoughts on this. 🙂


12:22 am, Monday 1 April 2013

Also just to add, I am not concerned with player cheating and such and cannot go over to an authoritative server approach where game simulation/physics will run on server, so please give me your thoughts based on my peer-2-peer model.

Andrew Russell

8:59 pm, Monday 1 April 2013

Wow that’s a big question 🙂 These things are best asked somewhere like Stack Overflow (or GDSE).

My recommendation would be to treat one of the players as authoritative – even if this fact is not exposed to the players. Choose a player randomly if necessary. If you implement prediction well, the non-hosting player should have the same zero-latency feel as the host.

For the ball, look at my “slow prediction” stuff in previous videos. Something like that would allow you to smoothly transition the entity between the predicted and non-predicted timelines.