I don't use an "elapsed time" for enemy/player movement. it's an error?

Game Play & Game Design
#1

Hi, I’ve seen many game that use elapsed time to update the movement for player/enemies.
ex:

move(long elapsedTime)

My game call move method from gameloop and entity change their position without using “elapsedTime”.

Is this an error or I’m doing right?

#2

Depends on whether you want fixed or variable time steps.
Each is suitable for different types of games.

There is no harm in giving your interfaces the capability of variable time steps, but having the implementation support only a fixed time step.

#3

so your doing:


position.x += 0.1;

instead of:


position.x += 10*elapsedTime;

?

What you need to understand is that there are reasons for both ways. Your way, you must throttle the loop to get it around 60ish (or whatever) and ensure that the FPS doesn’t drop below that. If it does drop below that, then your going to get speed ups in movements…

The elapsedTime method can change the movement with the frame rate so that it always looks the same; unfortunetly, its horrendous with physics as the step time changes from frame to frame resulting in not having a deterministic physics response…

what you could do for the time being, is code using the elapsedTime technique, but pass a constant (like 1/60) so that you can simulate constant time step which you can easily change later with a timer…

DP

#4

If your game runs at a fixed frame rate (e.g., 30 frames per second) then you don’t need to worry about movement based on “elapsed time” since the elapsed time will always have the same value (e.g., one 30th of a second). I think that that’s the case for a lot of games.

If your frame rate varies (in particular, if the game occasionally runs at a slightly lower frame rate than you’re intending) then updating the game based on the elapsed time should help to make the game play smoothly. (Of course, if the game slows down severely, then there’s nothing you can do to make it feel smooth, and using the elapsed time may make it appear even more jerky.)

A simpler alternative to using elapsed time may be to increase the number of updates per frame if the frame rate drops. For example, if you can do { move(); draw(); } 30 times a second then that’s good, but if the game starts running slow then you could switch to doing { move(); move(); draw(); } 15 times a second instead, in which case the game will appear to play at the same speed.

Finally, I’d say that while updating the game based on the elapsed time is fairly common for 3D games, it isn’t nearly as useful for 2D (sprite-based) games since the movement and animation is often a lot more rigid.

Simon

#5

How I can know If my game runs at a fixed frame rate and if it is 30…40 etc fps?

#6

The fact that you’re asking the question rather suggests that your game’s running at a variable frame rate. For a fixed frame rate, you need to add some code to your game loop to make it wait for a little while between frames. If you want to run at (for example) 50 frames per second, then each cycle through your game loop needs to last for 1000/50 = 20 milliseconds. If you measure how long a cycle actually takes (using System.nanoTime() for instance, if you’re using Java 1.5) and it turns out to only have taken 8 milliseconds, then you can pause for 20-8 = 12 milliseconds to make the loop last for correct length of time.

(This can all get quite fiddly, but I’d still say that it’s easier than updating the game based on elapsed time between frames.)

I believe that this is discussed at some length in the first few chapters of Killer Game Programming in Java (which you can read online here: http://fivedots.coe.psu.ac.th/~ad/jg/). Also if you search these forums I’m sure you’ll be able to find plenty of old threads on the subject.

Simon

#7

i rather not make movement time dependable, but just set a fixed number of frames i wanna do each second. It allows me to decide on what to do each frame, and if im short on time i skip a frame render (you could maximize the number of skips before a render too to keep it under control, and if its skipping frames often you could allways lower the number of frames you wanna have per second). This way my movement is more predictable and saves me trouble when doing collisions for example, because im gonna know in front if im gonna hit something rather than finding it out after ive moved, at least thats my experience.

#8

It’s certainly faster to set fixed frames per second, which is what I personally do most of the time, but having non-fixed fps means that you can more easily judge how much processor your game eats, what the minimum system requirements, should be, etc. Essentially it gives you much more information on your efficiency than fixed fps does, but then you have to worry about moving things only as much as a fraction of the timestep.

#9

Using a fixed amount for elapsed time can create gameplay problems, the game will run too slow or too fast depending on the computer it runs on. The basic stuff to do is to use nanoTime method from the Java api to probe the time before and after you have rendered the frame and update the game logic, then compute you elapsed time as the remaining time for the next frame. If your game rendering time exceeds a frame you only update the game logic in the next frames (skip one render update) until you get back on track.

The problem with this is that either the method used to waste time is imprecise (you tell him to wait 10 milliseconds and it waits 15 instead) or the method used to probe time is imprecise. I know that nanoTime is very precise but the wait method is just aceptable for games that run around 60fps, which will cause some frames to be skiped after a certain period of time. To minimize this problem without using complicated solutions i usualy multiply the elapsedTime value by 2/3 and it will ensure, with a low 60 fps that the frame rate is at least what im expecting.

#10

Fixed vs. variable rate logic and fixed vs. variable rendering is an old topic thats been done to death on these forums, a quick search would be a good idea. Basically theres advantages and disadvantages to both, depending on your game requirements one may be a better choice than the other.

#11

See this thread, there’s an argument about fixed vs variable time: http://www.java-gaming.org/forums/index.php?topic=13469.0

If you use variable time, you need to know a bit of basic physics. But with a variable time update(float secondsElapsed) method you can just use fixed time anyway, so go with a variable time setup.

Also, you can change game speed really easily by multiplying the secondsElapsed by whatever to speed up & slow down :D.

Keith.