DEVELOPER'S BLOG

Experimental betas - Interpolating the future

As mentioned on the forum, a few beta-patches released recently contain "highly experimental" features. Their most visible manifestation so far were various bugs, including severe ones, like substantial memory leaks, and a single line in the changelog:


[79670] Fixed: AI warping at distance in single-player.


It is therefore not unexpected some users started to wonder what is going on and what is this "new experimental technology" about.


The goals of the technology are as follows:


- fixing the old problem of far units "jumping"


- improving the frame-rate


- based on this technology even unit jumping seen in multi-player could be reduced


I will first describe what is the "new technology" about, and then how it will address the goals.



Interpolating visuals


Until now the link between the simulation and rendering was straightforward in our games: first the simulation has updated the world state, then the rendering has rendered it. This is quite a common architecture in games, it is simple, but it comes with some drawbacks:


- when the simulation of the objects in the game world is complex, increasing frame rate becomes very hard, as the simulation can be very hard to optimize


- when you reduce the frequency of simulation for some game objects to improve performance, the objects start jumping


- it is hard to make the rendering to run in parallel with simulation, as it is sharing the same data, resulting in either race conditions or a significant synchronization overhead


The solution to all of these problems in simple: make simulation independent on rendering, and interpolate results of simulation to have the onscreen motion smooth (this is well known approach in gaming industry, one good description can be found at Fix your timestep!). Some of you may ask now: if it is this simple, why took it so long to implement it in our games? As usual, it shows it is not as simple as it seems at first sight. If implemented naively, the result would be very ugly. As there are many units in our games and their simulation is quite complex, we want their timestep to be not something like 1/60 sec, but rather 1/10 sec or even more. While adding interpolation improves framerate, it also increases the latency, the increase being the timestep. The latency is already quite high because of multiple stages participating in the process (see Gamasutra articles Programming responsiveness and Measuring Responsiveness in Video Games), but increasing it 100 ms or more would result in a game with a high framerate, but very slugging controls. Fortunately, it seems there might be an other way.


Living in the future


Living in the future


The increased latency is primarily a problem for the player. Imagine we could simulate the player each frame, but the rest of the game would have the fixed time step. "Elementary, dear Watson?" Not that fast, dear Holmeses, we are not done yet. If done this way, the result would look nice, but you would be often unable to hit anything, as everything would be displayed on the screen on a position where it was 100 ms before, which in case of fast running soldier means about 50-70 cm away, enough to miss when shooting. The final solution we are implementing is similar, but a bit more elaborate. You can imagine it like all AI units are living in the future, but player interacting with "recent" state, which from their point of view is already "past" state. There are multiple corner cases to be solved with various possible combinations of "recent" and "future" objects interacting, but with some work it looks possible. And this is exactly what is the point of those "experimental" betas.


Current state


Recent versions already have interpolations fully working (you should never see a far units jumping in single-player), they have a player living "now", nearby units live "now" as well, and only distant units live "in the future". We did not allow the future for the nearby units yet, as there still some corner cases unsolved. Before we proceed to that, we want to make sure we have fixed all the major issues caused by the pure fact the changes were very extensive and deep in the core engine.


Future future


We hope that most of the issues with the future are solved now as of 81921 beta and we will soon be able to proceed into enabling this technology fully. This should hopefully improve the frame-rate on its own, but furthermore it will provide us a solid basis to make more of the rendering to run in parallel, and to improve the multi-player "jumping" issues as well.

Published on