   Locking frame rates
  Hi thereI'm aware this is a common problem which has been solved many times, but I'm struggling to find a single simple algorithm that matches my situation so I wonder if anyone can point me in the right directionWe're running an online demo, where one person (that we call the shepherd) is performing actions that have to be replicated on all the other machines (the sheep). In order for this to work, we need to synchronise the machines to the same speed, with the shepherd running no more than a few frames ahead of the sheep, but never behind. This is distinct from standard multiplayer synch problems where people are playing simultaneously and dealing with lag issues. In this instance all the sheep are passive, slaved to the shepherd, and it's important that they run in lock-step, with every event from the shepherd occurring at the same frame in all the sheep - even if this is a second or two later in real time.We've got a reasonably good version working already, but it's suffering from a bit of a bungee effect, especially when more than two or three computers are connected. I'm sure there must be a standard algorithm for this - any takers?ThanksDanny   
  Sound very similar to what RTS do with their lock step algorithm, except the clients don't need to all be in sync in their case.http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.phpIf you have no packet loss, the algorithm is even simpler. You'll need to sync the clocks on the network so you have global network time, within a reasonable accuracy ( ~100 ms would be imperceptible to most people ). Once you have that you can then build a timeline which u plot all received packets (contain time information from sever) from the server. All clients then step through the timeline at a predetermined offset but only after initiated by the server (using the global network clock u can be reasonably certain other clients are executing the events within the timers accuracy threshold and allow clients to fast froward through events if necessary to keep up with other clients).So for ever sec the server sends out heartbeats which pushes the clients through the timeline for N interval. If for whatever reason the server stops sending heartbeats all the clients will stop on the last received heartbeat tick, so they don't become desync.Packet loss might be an issue, but using a reliable protocol should cover it, you just have to increase your offset to compensate for the time overhead.Good Luck!-ddn   ;  I just wrote a much longer reply which got lost because I got logged out. Very annoying. In a nutshell again, though:Thanks for that, it's a useful perspective. What I think you're suggesting is that all the computers synch to a central clock - in our case we can't do any server-side scripting, but the 'shepherd' can take on the same role.What I'm not sure about is how this can deal with what happens when things go wrong. If one sheep lags behind or is constantly running on ahead, how does the clock shift speed to take that into account?My ultimate goal is to have something that smoothly and seamlessly adjusts its speed to an optimum level that's achievable by all the machines in the group, while also rapidly adjusting for sudden spikes (eg one user's virus checker kicks in half-way through). What I primarily want to avoid is any computer having to actually pause to allow others to catch up.Danny   ;  Well once you have a synchronized clock between all the peers ( ie everyone playing an animation at time 1:00 will execute it across the network within +- the timers error ). The trick is to get everyone to agree when the play an animation, to do this you can't let them run unbounded, so the sever ( or shepherd in ur case ) has to keep them from running ahead of each other since they don't communicate with each other directly.There is faq about how to implement a network timmer, so I won't go into that. Clients won't overrun the timeline, since that's controlled explicitly by the server, but they could underrun it (for various reasons you've given). This is also where the network timer comes in, it tells the client nearly the exact network time currently and it knows then to run up to but not beyond that point in the timeline when it goes to update. This way if all clients agree to peg their updated to the network clock, they will be in sync (to their best effort).This system can only stall if you have some hard requirement that all clients must play all events at exactly the same time under all circumstances. If that is the case then u need a bounce back verification scheme similar to the RTS scheme for events on the timeline, and once the server has received validation for enough events it can then push the simulation to all users ahead.But if your flexible and allow for occasional minor visual discrepancy, you can avoid the bounce back and just give the clients enough of a time offset on the timeline from realtime to compensate for network overhead.Good Luck!-ddn;  Ah, that's obviously what I didn't make clear. It's fundamental to the issue that everyone stays in exact synch. The software is deterministic in the sense that whatever frame rate anyone's running at, after N frames (and if they perform the same actions at the same times) they'll all be in the same place. So my shepherd will be sending out events like 'at frame 156, click this button'. At this moment, the sheep will ideally be somewhere like frame 152, so that four frames later they'll execute the same event. Obviously if they're at frame 160 we've lost, so we have to absolutely bar that possibility (which is fine by your scheme, although as I said it's possibly a bit abrupt). And if they're at frame 140, we really need to tell the shepherd to slow down a bit, and it's that 'a bit' that's bothering me.My instinct is that I want my framerate to be like a damped spring.What is this RTS scheme of which you speak?Danny   ;  The link in my first reply goes to an article about how RTS (real time strategy games) do their networking. They use a lock step method where the server collates all inputs from the client (and themselves if they are playing) and rebroadcast them, and once all the clients have acknowledge the inputs reception, it then advances the simulation. Clients can't advance beyond the currently acknowledged simulation step, this prevents clients from having a critical failure in synchronization if they over advance the simulation with missing inputs. Also to hide this latency clients actually run offset from the real time (about 2-3 secs behind), so the simulation can appear continuous and smooth, but in actuality is very discrete depending upon heartbeats from the server.Your doing something very similar as well, but you don't need the server to rebroadcast client inputs since there are none. This simplifies the problem, to just the server broadcasting events to the clients. You also don't need the acknowledgment step form the clients because clients in this scheme can't over step the simulation nor generate any bad inputs which could corrupt the simulation (as long as you use a reliable data stream to send the input events and step message). The biggest problem is one of synchronizing the animations and virual fx so as the clients execute their events apparently simultaneously.The easiest way to do this is to synchronize a global network timer. Once you have a timer which is within +-100 ms of each other, you can now execute events on a timeline ( a set of stored events sorted in network time ) in a fashion as to make it appear simultaneous on multiple peers. To prevent clients from overrunning the simulation you can use the same scheme as the RTS method and have the server send not just input events but also heartbeat events to set the current maximum simulation step to which all the clients can proceed.If all goes well the clients will advance through their timelines at a smooth pace, the server pumps the system pushing the max sim step ahead of the realtime playback on the clients, and the clients using their network timer can execute their events within +-100 ms of each other, making it appear everything is happening simultaneously on all the peers.Good Luck!-ddn   