120

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 ...


31

Some games do indeed extrapolate. An advantage of extrapolation is that you can do it with just the single most recent state and a rate of change (like velocity, angular velocity, etc.) rather than two complete states. So it is simpler to implement and compute. The main disadvantage of extrapolation is that it's a prediction about the future, and like most ...


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 ...


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 ...


6

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 & ...


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 most often encounter this in the context of Unity, which has the following attributes: Input is checked once per displayed frame, before any of that frame's fixed/variable timestep updates Input is interpreted as one flat state for the entirety of the current display frame, not a queue of events Each logical button has three independent boolean states: ...


4

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 ...


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

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

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 ...


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

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

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

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. ...


3

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 ...


2

I think you have inverted the alpha in the interpolation. It should be curr*alpha + prev*(1-alpha). From Fix Your Timestep!: State state = currentState * alpha + previousState * ( 1.0 - alpha ); In fact you are rendering an interpolated status that has 1 time-step of latency, so Actual time elapsed |----------|---_______| Time simulated ...


2

Well, I am not sure what language you use for your game so I'll explain it in C++, but you could use something called 'deltatime' Uint32 last = 0; Uint32 delay = 0; void loop() { Uint32 now = SLD_GetTicks(); if(now > last) { delay = now - last; last = now; } moveUp(delay); } void moveUp(Uint32 delay) { ...


2

The solution provided in the Blog post you mentionned is not that good, even if you follow it to its end, that is to say if you interpolate. Because you won't be able to escape the case when the error accumulates until there's no need for update, and then obviously there will be the need for two. It's just maths here. The interpolation hides that issue since ...


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 ...


2

I solved it, "Enable Preprocessing" option should be disabled in the joints as described below: "Uncheck the Joint’s Enable Preprocessing property. Disabling preprocessing can help prevent Joints from separating or moving erratically if they are forced into situations where there is no possible way to satisfy the Joint constraints. This can occur if ...


2

Yes. Some games do just that. Even more, they run at constant (e.g. 10) fps for game logic and render at whatever fps they can. Solves whole bunch of problems between machines with different processing powers.


2

It is important to use a delta time (like Time.fixedDeltaTime) because it will make your movement be consistent. If fixedUpdate is slower, fixedDeltaTime is bigger so the increase in delta_v will be bigger.


2

So, it was said (paraphrased as I get it) that Time.fixedDeltaTime returns the interval at which the FixedUpdate method should be called with respect to the timeScale. Yes, it's the interval of game time between successive FixedUpdate calls. But the real interval could differ (for technical reasons) and that's why Time.deltaTime should be used instead to ...


1

I do see one flaw, your update worker (aka State Worker) will need input information to make the right updates. How can you update the player's position if you do not know that the player has moved. You would then be running collision tests on out-of-date data (See this image from IBM's tutorial on making a web game). Syncing the game state with the input ...


1

Small variation might not seem like much, but it really depends on what you are doing in your loop. To put in persepective, running at 50ms a step gives you 20 steps per second. Running at 53ms a step gives you a bit less than 19 steps per second, so about one lost frame. In the span of a full minute you will loose about 68 frames (or about 3 seconds of game ...


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