Delta Time?
Do you guys really think that it's so important? I dunno, it doesn't seem useful to me... I from what I can tell as far as the independent game world goes, its more of a western thing. I can't really think of ANY doujin games that use it. I mean some of the games popular in the doujin world like the Touhou shooters, the Touhou Fighting games, the Suguri series, Blood Over, not even Cave Story uses delta time. But nobody seems to care. I have actually played doujin games while they were lagging, and I didn't really feel like it was taking away from the gaming experience at all.
I'm not sure what to make of this post; are you talking about delta-time, as the measure of time between frames drawn on the screen?
If so, then its ridiculously important. Games have been implementing delta time ever since old PC-DOS games - worldwide.
You'll know immediately when a game does not base movement and updates on delta time, because as computers get faster, the game becomes unplayable. It begins to update SO fast, that you can no longer keep track of movement on the screen.
What you describe in these doujin games probably does not imply that they don't use delta time - it is just them handling lag differently.
If so, then its ridiculously important. Games have been implementing delta time ever since old PC-DOS games - worldwide.
You'll know immediately when a game does not base movement and updates on delta time, because as computers get faster, the game becomes unplayable. It begins to update SO fast, that you can no longer keep track of movement on the screen.
What you describe in these doujin games probably does not imply that they don't use delta time - it is just them handling lag differently.
Deep Blue Wave - Brian's Dev Blog.
Not sure.
What I mean, is using delta time to make the game's movement seem to be consistent. As in a game meant to run 60 making the player move at a speed of 5, if lagged to 30 fps the game would speed up the player to 10 instead.
But This kind of thing I have never seen in doujin games when they lag. When doujin games lag, the player that is meant to move at a speed of 5, will still only move at a speed of 5. Sure the game is slowed down, but it makes things always happen exactly the way that they should be.
Look at this example: Touhou: Scarlet Weather Rhapsody:
The game lags so obviously, but an animation that is supposed to last 17 frames will always last 17 frames if finishes. And yet it doesn't make the game any less fun. I actually think it makes it funner.
What I mean, is using delta time to make the game's movement seem to be consistent. As in a game meant to run 60 making the player move at a speed of 5, if lagged to 30 fps the game would speed up the player to 10 instead.
But This kind of thing I have never seen in doujin games when they lag. When doujin games lag, the player that is meant to move at a speed of 5, will still only move at a speed of 5. Sure the game is slowed down, but it makes things always happen exactly the way that they should be.
Look at this example: Touhou: Scarlet Weather Rhapsody:
The game lags so obviously, but an animation that is supposed to last 17 frames will always last 17 frames if finishes. And yet it doesn't make the game any less fun. I actually think it makes it funner.
You're talking about having physics coupled or decoupled to drawing. When physics is coupled to the draw rate, then you have a fixed number of physics updates for every draw cycle. As the game slows down, physics happens more slowly, so everything moves slowly. When physics is decoupled, the game will skip draw cycles (which take a nontrivial amount of time) to try to "catch up" on the physics updates. Thus, while things happen at the same rate as before (or close to it), you'll see fewer frames.
For example, say we have a player moving from X=0 to X=10 over the course of 1 second. The game tries to do 60 physics updates per second, and draws the game every time it does a physics update (that is, drawing is coupled to physics). So you get 60 frames drawn as the player moves. Now slow the computer down. It can no longer manage to do 60 physics+draw updates per second; instead, it can only do 30. Now you only get 30 frames drawn in the first second. At that point, the player is now at X=5 (halfway along). In the next second, the player closes the rest of the distance in another 30 drawn frames.
Now take a look at a decoupled system. Here the game still tries to do 60 physics updates per second, and draws the screen any time it's too early to do a physics update yet. Let's say that it takes a third the effort to do one draw cycle that it does to do one physics update. On a fast computer, you get all 60 physics updates, and the computer still has half its "computing power" left, enough for 180 draw updates. With proper location interpolation in those 180 draw updates, you can get a very smooth motion as the player moves across the screen (three times smoother than the coupled system). Now slow the computer down. It only has enough power for 40 physics updates (or 30 physics updates and 30 draw updates). You program the system so that it always draws after some fixed number of physics updates happen. This is basically setting a baseline past which you force coupling of the physics and draw cycles. You can set that ratio wherever you want -- if it's 1:1, then you're basically recoupling. With our numbers, you'd get 30 physics updates (moving the player to X=5) and 30 draw updates. But you could set it at 2 physics updates to 1 draw update, skipping every other drawn frame and getting a total of 34 physics updates per second. That's closer to the desired speed, at the cost of slightly jerkier motion.
Really it depends on your game where you set the ratio. The doujin games you mention demand high precision from the player, so having frameskip is not ideal. But in a multiplayer setting, everyone needs to move at the same speed all the time, so frameskip is necessary. A decoupled system can manage arbitrarily smoother motion on fast computers, and can do things that a coupled system can't on slow computers.
Bottom line, fix your timestep!
For example, say we have a player moving from X=0 to X=10 over the course of 1 second. The game tries to do 60 physics updates per second, and draws the game every time it does a physics update (that is, drawing is coupled to physics). So you get 60 frames drawn as the player moves. Now slow the computer down. It can no longer manage to do 60 physics+draw updates per second; instead, it can only do 30. Now you only get 30 frames drawn in the first second. At that point, the player is now at X=5 (halfway along). In the next second, the player closes the rest of the distance in another 30 drawn frames.
Now take a look at a decoupled system. Here the game still tries to do 60 physics updates per second, and draws the screen any time it's too early to do a physics update yet. Let's say that it takes a third the effort to do one draw cycle that it does to do one physics update. On a fast computer, you get all 60 physics updates, and the computer still has half its "computing power" left, enough for 180 draw updates. With proper location interpolation in those 180 draw updates, you can get a very smooth motion as the player moves across the screen (three times smoother than the coupled system). Now slow the computer down. It only has enough power for 40 physics updates (or 30 physics updates and 30 draw updates). You program the system so that it always draws after some fixed number of physics updates happen. This is basically setting a baseline past which you force coupling of the physics and draw cycles. You can set that ratio wherever you want -- if it's 1:1, then you're basically recoupling. With our numbers, you'd get 30 physics updates (moving the player to X=5) and 30 draw updates. But you could set it at 2 physics updates to 1 draw update, skipping every other drawn frame and getting a total of 34 physics updates per second. That's closer to the desired speed, at the cost of slightly jerkier motion.
Really it depends on your game where you set the ratio. The doujin games you mention demand high precision from the player, so having frameskip is not ideal. But in a multiplayer setting, everyone needs to move at the same speed all the time, so frameskip is necessary. A decoupled system can manage arbitrarily smoother motion on fast computers, and can do things that a coupled system can't on slow computers.
Bottom line, fix your timestep!
Jetblade: an open-source 2D platforming game in the style of Metroid and Castlevania, with procedurally-generated levels
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement