117

There's a long history of how we arrived at this common convention, with lots of fascinating challenges along the way, so I'll try to motivate it in stages: 1. Problem: Devices run at different speeds Ever try to play an old DOS game on a modern PC, and it runs unplayably fast - just a blur? A lot of old games had a very naive update loop - they'd collect ...


24

I've worked on a couple of game servers, including a suite of them for an MMO. In general, they don't have physics at all. In the few situations where physics are necessary (jumping, primarily) we let clients calculate their own physics, and we just deny anything that's too outlandish (players moving too fast for too long, going much higher than they ...


11

Besides the other good answers given, I want to add the fact that some physics commonly is not driven by the server or even know about by the server and is a common trick to make the world seem more rich without adding overhead to the networking or server side processing. For instance there might be debris you can kick around on the ground or blowing around ...


8

The other answers are good and talk about why the game loop exists and should be seperate from the render loop. However, as for the specific example of "Why render a frame when there hasn't been any changes?" It really just comes down to hardware and complexity. Video cards are state machines and they're really good at doing the same thing over and over ...


7

Second Life implements physics on the server side using Havok, and locks updates to 45 per second. https://community.secondlife.com/t5/General-Discussions/SIM-FPS-is-maxed-out-at-45/td-p/181120 Earlier versions around 2005-2006 let the physics updates float as high as the server would allow. An uncomplicated region with few scripted objects could run at ...


7

What you mention is a well understood problem in general. The "virtual second" you mention is generall just thought of as a fixed time delta that is updated baed on an accumulator from wall time. The reason some developers use wall time directly is mostly ignorance on their part in most cases, and special circumstances in others. The usual article to link ...


6

You seem to assume that most games aim for 60FPS, but actually it's much more varied than that. Console games tend to be either 60FPS or 30FPS. And games for PCs and other platforms tend to be wildly variable, though often related to the monitor refresh rate (which can be 60Hz, or 70, or 75, etc). The reason you would want to tie game time to real time is ...


6

I'm not entirely sure that you understand what the article means by a fixed timestep. requestAnimationFrame is defined as: Tells the browser that you wish to perform an animation; this requests that the browser schedule a repaint of the window for the next animation frame. The amount of time that passes between each invocation of the function varies ...


6

Rendering is usually the slowest process in the game loop. Humans don't easily notice a difference in a frame rate faster than 60, so it often less important to waste time on rendering faster than that. However, there are other processes that would benefit more from a faster rate. Physics is one. Too big of a change in one loop can cause objects to glitch ...


5

Your game loop code is correct, but your units are all mixed up -- you are effectively setting to your timestep to .00000003 nanoseconds! Your clock is counting in nanoseconds, so your dt should be in nanoseconds. If a clock ticks 30 times a second, it will tick every .033 seconds. There are many nanoseconds in a second, so it will take more nanoseconds to ...


5

Locking at 60 fps is certainly viable. From what I've seen, just as you've said, it appears fighting games typically describe timings in number of frames, even as most fighting games have transitioned to 3D (where it's rare to rely on discrete frames of animation). The drawback of doing this logic in Update() in Unity is that the game will slow down if the ...


5

I've done some tests simulating low framerate conditions, and empirically confirmed that the deltaTime value for each FixedUpdate step does indeed stay consistent. For example, using the default Fixed TimeStep of 0.02 (50 Hz) and Maximum Allowed Timestep of 0.3333333 (as set in Edit -> Project Settings -> Time)... At 60 fps we get 0-1 physics & ...


4

You are probably updating the velocity twice, since this is usually done in the integration step itself. I expect you implemented the RK4 integration from http://gafferongames.com/game-physics/integration-basics/. The author defines Derivative.dv as the acceleration (derivative of velocity) and State.v as as the velocity In the evaluate function you can ...


4

Frames Per Second (FPS) should be just that. The number of frames drawn every second. What FPS is not is something that you should be basing your gameplay timings around. You are running into issues when spawning enemies according to elapsed time because the rest of your game is not based around time, I bet. In your current setup I imagine you are updating ...


4

A construction like the one in your question can make sense if the rendering subsystem has some notion of "elapsed time since last render". Consider, for instance, an approach in which the position of an object in the game world is represented through fixed (x,y,z) coordinates with an approach that additionally stores the current movement vector (dx,dy,dz)....


4

In addition to other answers... Checking for change of state requires significant processing. If it takes similar (or more!) processing time to check for changes, compared to actually doing the processing, you really haven't made the situation better. In the case of rendering an image, as @Waddles says, a video card is really good at doing the same dumb ...


4

On some platforms the game actually starts running before the splash screen is gone. So this may give the illusion of a defective timer if you test it right at the start. Another issue on slow devices is that your first frame of timer activation may have a very large deltaTime if other things happen at the same time. For example if it takes 2 seconds to ...


4

Your lerps and slerps are backwards: lerp(current, previous, alpha) should be lerp(previous, current, alpha) ie. increasing alpha (more time accumulated since the last update) should move us toward the future, not toward the past. This could account for at least some of the choppiness you perceive. There could be additional judder coming from the player ...


4

TL;DR they work exactly the same; the difference comes from trade-offs like performance, value range and (sometimes) syntax. It's is possible to simulate floating- or fixed-point math, you just have to write all logic yourself (or use library). The only limits are your creativity and resulting performance overhead. Fixed-point math may be considered a subset ...


3

Part 1: Interpolation: Interpolation let's us approximate something that already happened. Multiplying "trick" (which is just math) is to mix the previous state with the current state by a certain percentage. If previous was dark and now is bright, we assume in the middle it was grey. So if for example we take a moving train. We know that right now it is ...


3

EVE Online, an MMO with a single shard and up to several thousand plaers in big space battles runs its physics on a 1 Hz tick, called the "destiny" tick. http://community.eveonline.com/news/dev-blogs/fixing-lag-drakes-of-destiny-part-1-1/ The so called "Bloodbath of B-R5RB" is the biggest emergent player fight ever to happen in an online game to date ("the ...


3

Gordonk was absolutely spot on. It now appears that I have silky smooth movement at 60fps. If I cap the frame rate at anything less than 60 I start to see serious stuttering, but I guess that's a separate issue to explore. So here is the code I am using right now. It hasn't been optimized in any way, it was just to implement a fixed time step. I'm using the ...


3

Basically you have three ways to periodically invoke some code. have a infinite loop with sleeps. use setIntervall to perodically be waken use requestAnimationFrame for when the browser is idle Although this is about animation, it covers the basic crux of the problem: Animating In Code Using JavaScript


3

That's "server reconciliation", I've written specifically about it here: http://www.gabrielgambetta.com/fpm2.html Since you link to one of these articles in your question, I assume you've read it already. Believe me, the answer is there :) It's more like your option "A". Typically what happens is that you get a server update for a "true" state of the world ...


3

XNA (in fixed time mode) will try to call you 60 times per second, but that doesn't mean that the calls are always 1/60th of a second apart. GameTime will tell you how much time has elapsed since the last call, and you should use that to feed into any time-sensitive calculations.


3

There is a wrong assumption behind this question which leads to a solution that is not well prepared for real world requirements. Don't ever count on a consistently stable frame time X, unless you are on a Real Time Operating System. The usual gaming platforms don't fall under this category. On all other systems the frame time is not deterministic (even if ...


3

Sleeping is a valid solution and it's easy to implement. Pick a sleep duration that will use less CPU but still give you acceptable simulation accuracy. An alternative solution is to use an event loop on your server. An event loop would only wake up the main thread when it's needed, for example at a regular interval, or when a network message arrives. ...


2

I see several issues with your code: First, your update loop never sleeps, it just busy-waits until enough time has passed. While this shouldn't actually cause any problems in your example (other than possibly overheating your CPU), it would be a problem if you wanted to do anything useful in some other thread at the same time. Also, it's just plain silly....


2

The precision should be precise enough to meet your requirements. Your requirements may allow for some missed updates now and then. Your requirements may allow only high-end hardware. It's up to you to find the balance between resource usage and precision. The precision will vary from genre to another, from one game to game and even from one game mode to ...


2

It's hard to tell for sure from the information given but it sounds like what you are trying to do is make the client and server run deterministic code such that if they start with the same starting state and process things on the same loop numbers that they will result in the same values for the same calculations. Is that correct? One thing you are doing ...


Only top voted, non community-wiki answers of a minimum length are eligible