您的位置:首页 > 产品设计 > UI/UE

GAME TIMERS: ISSUES AND SOLUTIONS.

2016-07-23 06:40 615 查看
【固定的DeltaTime有两个优势:

   1. 对于配置好的多台机器,这可以让这些机器的帧率相同,电子竞技啥更加公平。

   2. 对于一台配置差的机器,用多次Update来代替一次Update,计算碰撞准确。不过缺点是,原本一次Update,现在需要多次Update,本来机器就不给力,现在要计算的次数更多了,更慢。

   SM也是用固定的DeltaTime进行Update,不过只进行一次Update,就进行Render,剩余的Time直接丢掉了。 这样呢,配置好的多台机器之间,帧率相同。配置不好的机器,计算不准确,由于人物之间没有碰撞,所以不存在碰撞的问题,只有位置同步的问题,如果Server发现Client上的位置与Server上的位置差距超过阈值,那么直接纠正Client的位置。SM这样做,感觉是不想让本来已经很慢的机器算的更慢。

   SM现在的性能瓶颈倒不是在客户端的帧率上,老游戏了,机器性能完全能满足。只有我这种2012年买的低端笔记本带着费劲。配好8GB内存后,内存不缺了,就是集成显卡太伤了。开最速模式,把其他人物模型都隐藏之后,就不慢了。竞技场,3V3,6V6,开人物模型,只隐藏他人特效,也是玩的起来的。】

原文链接:http://fabiensanglard.net/timer_and_framerate/index.php

When I started game programming I ran into an issue common to most aspiring game developers: The naive infinite loop resulted in variable framerate and variable time difference that made the game nondeterministic. It is a problem that Supreme
Commander/Demigod developer Forrest Smith described well in Synchronous Engine Architecture (mirror).

Since I came up with a simple solution in my last engine I wanted to share it here: Maybe it will save a few hours to someone :) !


Problem: Variable framerate and Variable timeslices.

When I started engine development I used a naive game loop that would:
Retrieve the time difference (timeslice) since the last screen update.
Update the world according to inputs and timeslice.
Render the state of the world to the screen.
It looked as follow :
int lastTime = Timer_Gettime();

while (1){

int currentTime = Timer_Gettime();
int timeSlice = currentTime - lastTime ;

UpdateWorld(timeSlice);
RenderWorld();

lastTime = currentTime;
}


With a fast renderer the game world is updated with tiny time differences (timeslice) of 16-17 milliseconds (60Hz) and everything is fine. 

The key concept is that timeslices at which the game is simulated are variables in size :



This architecture does work but is limited: The weakness in the design is that simulating the world accurately is tied to having small timeslices (a.k.a high framerate). Problems arise if the framerate drops too much: Updating at 30Hz instead of 60Hz may move
objects so much that collisions are missed (In a game such as SHMUP that was a big problem): 



There are algorithms to palliate to this problem but this naive design has many more flaws. The fundamental difficulty is not the length of a timeslice but its variability:

Record user inputs and replaying a game session (for debugging or entertainment) becomes difficult since the timeslice are different. This is true even if the replay machine is the machine that originally recorded the session since the operating system
system calls will never have the same duration.



This issue can also be solved by recording the simulation time along with inputs but the game engine design is now becoming messy. Besides, there is an other issue:

If your game is network based and you need to run several simulations simultaneously on different machines with identical inputs: The time slices will not match and small difference will appear until the simulation on each machines are out
of sync !


Solution: Fixed timeslices.

There is an elegant approach to fix everything at the cost of a small latency: Update the game timer at a fixed rate inside a second loop.
int  gameOn = 1
int simulationTime = 0;

while (1){

int realTime = Gettime();

while (simulationTime < realTime){
simulationTime += 16; //Timeslice is ALWAYS 16ms.
UpdateWorld(16);
}

RenderWorld();
}

This tiny change dissociates rendition and simulation as follow: 



The engine now simulates the world with CONSTANT timeslices, regardless of network latency/renderer performances.

It allows simple and elegant code for replay recording/playback, solid collisions detection system... but most importantly it allows simulation running on different machines to be synchronized as long as the same input/random feeds are provided.


Before you patent it...

The joy of "discovering" this approach was short lived: This system is very well known in the game industry and is actually the keystone of games such as Starcraft II or id Software
engines !


Further readings

Timestepping by Peter Sundqvist
Fix your timestep by Glenn Fiedler: Take the idea further and also mentions interpolations.


Merry Christmas....

...and Happy Hacking guys ;) !
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: