2
\$\begingroup\$

I'm currently working on a Java MMO with a pretty solid start, but I've come across an issue I need a little help with.

I'm working on player positions. Meaning their X/Y on the screen, if the PlayerA has a higher FPS (Frames Per Second) than other players, the resulting action will be that PlayerA will move faster than everyone else. I know the reasoning for this, it's because when the game draws I just use x++.

What would a better method be?

\$\endgroup\$

2 Answers 2

Reset to default
5
\$\begingroup\$

Basically, you need to repeat performing multiple different tasks at independent intervals. In pseudocode that will typically look something like this:

updateTime=1000/120
nextUpdate=time()
repeat{
    while(nextUpdate<time()){
        updatePlayerPositionPhysicsAndStuff()
        nextUpdate+=updateTime
    }
    render()
}

So updatePlayerPositionPhysicsAndStuff will run exactly 120 times per second, while render will take up all the leftover computing power running as often as there is time for.

\$\endgroup\$
7
  • \$\begingroup\$ This sounds logical, I'll try this out and hopefully it works. Thanks. \$\endgroup\$
    – Matthew Auld
    Commented Nov 14, 2011 at 21:48
  • 1
    \$\begingroup\$ Just keep in mind that simple implementations like the example code can do bad things whenever there's lag or delay in processing; it can result in a "spiral of death." You generally want to use a time delta combined with fixed interval, with a cap on the delta. In other words, calculate the time delta since the last update, cap that at some reasonable value (1/20th of a second, say), add that to an accumulator, and then do fixed timesteps draining from the accumulator. The accumulator also then gives you "left over" time at the end of an update loop to do interpolation for smoothness. \$\endgroup\$
    – Sean Middleditch
    Commented Nov 15, 2011 at 0:14
  • \$\begingroup\$ @seanmiddleditch More complicated, and ditches an important feature, that of determinism. \$\endgroup\$
    – aaaaaaaaaaaa
    Commented Nov 15, 2011 at 6:30
  • \$\begingroup\$ @eBusiness: it's more complicated by all of three lines, allows interpolation which is important if you want the rendering to look good at lower interval values, runs no risk of the spiral of death, and your comment about determinism just confuses me; can you explain further? \$\endgroup\$
    – Sean Middleditch
    Commented Nov 15, 2011 at 8:13
  • \$\begingroup\$ Determinism: If I run the same code with the same input twice I get the same results. That feature breaks if you don't use fixed steps, for any multiplayer game that is a pretty big deal, for single player games it can still be a nice feature to keep. I presume that by "spiral of death" you mean the situation where the computer can't keep up with the requirement of doing a specific number of updates. You obviously have to scale the requirement to a sensible level, in most games that will not be a problem. \$\endgroup\$
    – aaaaaaaaaaaa
    Commented Nov 15, 2011 at 13:43
7
\$\begingroup\$

Sounds like you might want to start using a delta time and a time-based movement speed. It could be a little difficult considering that it looks like you could be using a tile-based engine, but if you use a delta-time, your movement equation will look something like this:

x += unitsPerSecond * deltaTime;

Where x is a floating point variable (float or double), unitsPerSecond is how fast you want your characters to move per second, and deltaTime is in fractional seconds. Having your position as a floating-point value is key.

\$\endgroup\$
4
  • \$\begingroup\$ Seriously, why make him take a detour through that horrible principle? Fixed step is so much easier to get working nicely. gamedev.stackexchange.com/questions/1589/… \$\endgroup\$
    – aaaaaaaaaaaa
    Commented Nov 14, 2011 at 21:03
  • \$\begingroup\$ @eBusiness, I would probably do both, but yes, you are correct. A fixed time step would probably fix all of his problems \$\endgroup\$
    – John McDonald
    Commented Nov 14, 2011 at 21:04
  • 1
    \$\begingroup\$ @eBusiness, I too prefer fixed-step, but you can do most things perfectly fine with delta-time systems, and indeed many games in history have done just that. You only really start to see problems when you perform integration, like gravity and other physics. But feel free to post an alternative answer. :) \$\endgroup\$
    – Kylotan
    Commented Nov 14, 2011 at 21:12
  • \$\begingroup\$ @Kylotan 24 seconds ahead of you ;-) And yes, variable step has it's place, especially in the more processing power constricted past. That is not to say that it will have no place in the future, but fixed step really should be the default choice, and is thus the obvious place for a beginner to start. \$\endgroup\$
    – aaaaaaaaaaaa
    Commented Nov 14, 2011 at 21:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .