   30 cycle per second movement on a server
  I'm currently developing a server that simulates the platform physics for an mmorpg. I need the physics simulation to run at precisely 30 simulation steps per second, since the game client is only running at 30 Frames per second, I need the server and client simulation to be as close as possible.I currently have 2 ideas for this, and would like to know which one you think would be more accurate:1: Executing the physics simulation every 1/30th of a second. Before simulating the physics, I could check if 2 milliseconds has passed since the last simulation step, which would end up being 30 simulation steps per second. The only problem that I can think of with this, is if the server got a lag spike, and more than 2 milliseconds passes before the physics simulator has a chance to simulate.2: By getting the actual "frame rate" (more like cycle rate since I'm not rendering anything), I could use something like delta time, where the physics are simulated every step but the magnitude/speeds would change depending on the Delta time factor. I'm not sure how accurate this one would be since I have never tried delta time before. If the server Cycle rate is fluctuating, this could cause large changes in the delta time ratio which could effect the accuracy of the physics.I hope you guys can give me your opinion on this, or give me any other suggestions you may have. :)   
  The constant time step in option one seems to be the more stable approach, this article may help: http://gafferongames.com/game-physics/fix-your-timestep/   ;  Are you intending to actually be updating the client at this rate as well, or just handle the physics computations server-side and propagate the last-known state on network updates at a slower rate?Most network games, even action games with relatively low transmission needs, only update clients at around 10-15 times per second.   ;  Okay I'm going to put this here for the server update system.void Run(){   boost::posix_time::ptime targetTime = boost::posix_time::microsec_clock::local_time();   boost::posix_time::time_duration targetTimeTD = targetTime.time_of_day();   targetTimeTD = boost::posix_time::microseconds(targetTimeTD.total_microseconds() / 100000 * 100000);   targetTime = boost::posix_time::ptime(targetTime.date(), targetTimeTD);   while(true)   { boost::posix_time::ptime currentTime = boost::posix_time::microsec_clock::local_time(); Log[Logger::Debug] << "Current Time: " << boost::posix_time::to_simple_string(currentTime); Update(); boost::posix_time::ptime timeAfterUpdate = boost::posix_time::microsec_clock::local_time(); boost::posix_time::time_duration elapsedTime = timeAfterUpdate - targetTime; long long int delayTime = std::max<long long int>(0, 100000 - elapsedTime.total_microseconds()); boost::this_thread::sleep(boost::posix_time::microseconds(delayTime)); targetTime += boost::posix_time::milliseconds(100);   }}On most linux servers it'll call the update method every 100 ms with accuracy to 1/10,000's of a second. I'm sure if you're desperate there's a more accurate solution. Maybe I made a mistake though.You have to handle the problem though if the update takes too long. (I'd just skip to the next update though). There's a lot of gotchas. Fixed timesteps are the way to go.[Edited by - Sirisian on May 27, 2010 2:38:20 PM]