Simple question (time based movement)

Game Mechanics
#1

Everyone does this:

Your game logic cannot rely on FPS, as it may(read: will) vary on different hardware. Hence I am thinking you must know the FPS in order to calculate the movement on each game-logic step. Now to my question(s ):

  • Is it normal to just calculate the movement based on velocity divided by FPS for example?
  • If above method is correct, what is good programming practice when almost every class needs to know the current FPS of the game?(I’m guessing a static class, containing a continuously updated public FPS field)

I hope you can help me. Plz don’t flame me for asking a simple question, the answer is not obvious to me.

#2

Well, the current framerate isn’t really important if you just want to calculate the current frame. What you need is the delta time since the previous frame. If you have that, you can indeed multiply every increase by delta time. While this will work, it’s rather annoying. Another common way to solve this, is to separate the rendering and updating of the game. So there will always (for example) 50 updates per second regardless of the hardware, and the framerate will be as high as the hardware permits while still keeping the 50 updates per second.

(Note that what I said applies mainly to 3D games, I’ve noticed that most 2D games tend to just lock the framerate at a certain value)

#3

Is it normal to just calculate the movement based on velocity divided by FPS for example?

No, the delta is calculated and then it’s multiplied with some units per second (UPS) value. However, depending on the timing method it might be more natural to work with units per msec.

And how it’s done… well, basically you calculate the delta in the main loop and hand that over to the logic method. Over there you hand it over to other subsystems which need it (e.g. particle systems or the update methods of enemies).

Note however, that there are quite a lot of pitfalls. E.g. if the player runs at 400 UPS and there is a 2 second lag (may happen if some hdd spins up for example), he would move a whopping 800 pixels… right through a bunch of walls and through the floor. Stuff like that shouldn’t happen.

The easiest method is to cap the delta. E.g. with a maximum delta of 33msec (30fps) the game will slow down if the machine can’t even reach that target. However, that’s usually acceptable. With a cap in place it won’t break apart if the collision detection still works as intended at the low-target frame rate.

Another method is to run the logic at a fixed rate and render as fast as possible (with interpolated positions).

If it’s 2d you can also just ignore all that and just cap the frame rate at 60fps. Just ensure that it runs fine on mediocre hardware and that’s it. It doesn’t get any easier than that.

“Warning - while you were typing a new reply has been posted. You may wish to review your post.”
* oNyx ignores the warning :>

#4

This doesn’t really make sense to me. No matter what, in a single thread program I wont be able to do that in a good way. If the program is sequential, the logic will always be limited by the rendering method, as they must be part of the same loop.

But really, from your posts I find multiplying the deltavalue each time the best solution. What would you do to pass this value to almost every class in your program? Singleton approach or just a simple static class?

#5

You’re right, in a single threaded application that’s true, but multi-threading makes sense here… Why would you stick to one thread?

[quote=“hejfelix,post:4,topic:32987”]
Speaking from my experience: I always have a foreach-loop like this in my logic-thread (or in the logic-party of the main thread):

for(Entity e : entities) {
    e.doLogic();
}

Where entities is an ArrayList or something similar with all the objects, players, enemies, units, buildings, (they extend Entity)… and doLogic() recalculates positions, does the enemy AI, determines building times, …

#6

Well for each call of the update method you’ve got a parameter which you want to affect the behaviour of the method for that call only.

Nope, no idea how you could do that. ::slight_smile:

grumble Kids today, with their new fangled singletons and statics, don’t know what the world’s coming to, get off my lawn etc. etc.

#7

to perform fixed step logic you can do the following (enfin grosso-modo…):

in all your class assume that the delta time is fixed (for example 20ms)
and each time you are going to render call your logic as many time as necessary

for example if last frame was 40ms before call twice doLogic20ms()

[quote]render()
{
time=getTime(); //System.currentTimeMillis or other method

int nb=(time-lastTime)/20;

for(int n=0;n<nb;n++)
doLogicFor20ms();

if(nb!=0)
drawAllObjects()

lastTime+=20*nb;

}
[/quote]
this way you will always get exact same logic even with different frame rate

EDIT : add a call to draw all objects