CN111265854B - 一种帧同步方法、装置、设备及介质 - Google Patents
一种帧同步方法、装置、设备及介质 Download PDFInfo
- Publication number
- CN111265854B CN111265854B CN202010053969.0A CN202010053969A CN111265854B CN 111265854 B CN111265854 B CN 111265854B CN 202010053969 A CN202010053969 A CN 202010053969A CN 111265854 B CN111265854 B CN 111265854B
- Authority
- CN
- China
- Prior art keywords
- time
- update
- server
- target object
- updating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
- A63F13/35—Details of game servers
- A63F13/358—Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/55—Controlling game characters or game objects based on the game progress
- A63F13/56—Computing the motion of game characters with respect to other game characters, game objects or elements of the game scene, e.g. for simulating the behaviour of a group of virtual soldiers or for path finding
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/55—Controlling game characters or game objects based on the game progress
- A63F13/57—Simulating properties, behaviour or motion of objects in the game world, e.g. computing tyre load in a car race game
- A63F13/577—Simulating properties, behaviour or motion of objects in the game world, e.g. computing tyre load in a car race game using determination of contact between game characters or objects, e.g. to avoid collision between virtual racing cars
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
- A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
- A63F2300/534—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for network load management, e.g. bandwidth optimization, latency reduction
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/60—Methods for processing data by generating or executing the game program
- A63F2300/64—Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car
- A63F2300/643—Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car by determining the impact between objects, e.g. collision detection
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请实施例所提供的帧同步方法,包括:根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;根据服务器的计算压力信息确定目标对象的更新安排,更新安排包括目标对象状态更新的更新频率和更新开始时间;按更新安排所指示的更新开始时间和更新频率对目标对象进行状态更新;向客户端发送更新安排,以使客户端在更新开始时间以更新频率对目标对象进行状态更新。本申请还一种装置、设备及介质,在帧同步过程中,间隔预定时间执行更新,其余时间各自执行本地的对象更新,从而减少了帧同步对于网络传输质量的依赖,提升了帧同步的稳定性和传输效率;同时实现了更新安排的动态调节。
Description
技术领域
本发明涉及电子技术领域,更具体地说,涉及一种帧同步方法、装置、设备及介质。
背景技术
在网络游戏过程中,例如多人在线战术竞技游戏(Multiplayer Online BattleArena,MOBA)或即时战略游戏(Real-Time Strategy Game,RTS),由多名用户分别通过各自的客户端连接服务器,以实现多人在线的游戏。在此过程中,服务器需要确保游戏中的非玩家的角色(Non-Player-Character,NPC)在各个客户端中保持同步。
现有技术中用于同步服务器和客户端数据的方案,一般是基于状态同步的方案,也叫网络数据复制。即服务器检测一个对象的变量是否有发生改变,如果有改变,就把这个改变通知相应的客户端,客户端收到消息也做相应的改变。
当网络不好,产生延时或丢包时,客户端跟服务器同一个对象的状态就会产生越来越大的差异,直到下一次数据发送过来才能进行纠正。导致不同客户端之间NPC的状态发生偏差。
发明内容
有鉴于此,为解决上述问题,本发明提供的技术方案如下:
一种帧同步方法,包括:
根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;
根据该服务器的计算压力信息确定该目标对象的更新安排,该更新安排包括目标对象状态更新的更新频率和更新开始时间;
按该更新安排所指示的该更新开始时间和该更新频率对该目标对象进行状态更新;
向该客户端发送该更新安排,以使该客户端在该更新开始时间以该更新频率对该目标对象进行状态更新。
一种帧同步装置,包括:
第一获取单元,该第一获取单元用于根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;
确定单元,该确定单元用于根据该第一获取单元获取的该服务器的计算压力信息确定该目标对象的更新安排,该更新安排包括目标对象状态更新的更新频率和更新开始时间;
更新单元,该更新单元用于按该确定单元确定的该更新安排所指示的该更新开始时间和该更新频率对该目标对象进行状态更新;
发送单元,该发送单元用于向该客户端发送该确定单元确定的该更新安排,以使该客户端在该更新开始时间以该更新频率对该目标对象进行状态更新。
可选地,该发送单元还用于:在第一时刻向该客户端发送第一子更新安排;
其中,该第一子更新安排为该第一时刻时生成的该更新安排,该第一子更新安排用于使该客户端在第一时段内进行本地更新,该第一时段为该第一时刻到第二时刻的时段,该第二时刻为该第一时刻之后该客户端发送更新安排的时刻。
可选地,该目标对象至少包括第一目标对象、第二目标对象和第三目标对象,则该确定单元还用于:
为该第一目标对象分配第一更新频率;
为该第二目标对象分配第二更新频率;
该第一目标对象与第三目标对象的距离小于该第二目标对象与该第三目标对象的距离,该第三目标对象为用户控制的目标对象,该第一更新频率大于该第二更新频率。
可选地,该目标对象的数量为多个,则该确定单元还用于:
从多个该目标对象中获取尚未分配更新安排的待分配对象;
通过随机分配算法为该待分配对象随机分配该更新安排,其中,每个该待分配对象对应有一个该更新安排。
可选地,该第一获取单元还用于:
根据该实际耗时占用目标对象进行状态更新的理想耗时的比值获取该服务器的计算压力信息。
可选地,该服务器的计算压力信息为该服务器的当前负载高低数值PerfRatio,则该第一获取单元还用于:
执行以下算法:
PerfRatio=Clamp(PerfRatio’+(1.0f-cost/DesiredCost)*af,0.0f,1.0f);
其中,该Clamp()为取值算法,该PerfRatio’为前一次目标对象状态更新时该服务器的负载高低数值,该cost为该实际耗时,该DesiredCost为该理想耗时,该a为敏感度参数,该0.0f为该Clamp()的取值下限值,该1.0f为该Clamp()的取值上限值;
该根据该服务器的计算压力信息确定该目标对象的更新安排,包括:
该根据该负载高低数值PerfRatio确定该更新安排,其中,该负载高低数值PerfRatio的数值大小与该更新安排所指示的更新频率大小成正比。
可选地,该装置还包括:
第二获取单元,该第二获取单元用于根据当前该目标对象的位置获取碰撞位置,该碰撞位置为该目标对象与其他目标对象发生碰撞时,用于判断碰撞区域的位置。
一种帧同步方法,包括:
获取服务器发送的更新安排,所述更新安排包括目标对象进行状态更新的更新开始时间和更新频率;
获取服务器时间,所述服务器时间为所述服务器的实时时间;
根据所述服务器的实时时间在所述更新开始时间以所述更新频率对所述目标对象进行状态更新。
一种帧同步装置,包括:
第一获取单元,该第一获取单元用于获取服务器发送的更新安排,该更新安排包括目标对象进行状态更新的更新开始时间和更新频率;
第二获取单元,该第二获取单元用于获取服务器时间,该服务器时间为该服务器的实时时间;
更新单元,该更新单元用于根据该第二获取单元获取的该服务器的实时时间在该更新开始时间以该更新频率对该目标对象进行状态更新。
可选地,该第一获取单元,还用于:获取该服务器发送的第一子更新安排,该第一子更新安排为该服务器在第一时刻生成的该更新安排;
该更新单元,还用于:在第一时段根据该第一子更新安排对该目标对象进行本地状态更新,该第一时段为该第一时刻到第二时刻的时段,该第二时刻为该第一时刻之后接收该服务器的更新安排的时刻。
可选地,该第二获取单元还用于:该更新频率至少指示在第一时间点和第二时间点与该服务器交互以实现对该目标对象状态的更新,则该更新单元还用于:
在该第一时间点与该第二时间点之间的第三时间点,获取该第三时间点与该第一时间点的第一时间差;
将第一目标对象移动到该第一时间点的位置,该第一目标对象为该目标对象中的任意一个;
从该第一时间点开始,以该第一时间差为时长对该第一目标对象进行本地更新。
可选地,该装置还包括纠正单元,该纠正单元用于:
当位于该第二时间点时没有收到由服务器发送的更新数据,获取该第一目标对象的目标操作,该目标操作为该第一时间点时该服务器向该第一目标对象输入的控制操作;
根据该目标操作对该第一目标对象的运动进行本地更新。
可选地,该装置还包括第三获取单元,该第三获取单元用于:
根据第一位置获取碰撞位置,其中,该第一位置为最近一次更新时服务器发送的该目标对象的位置,该碰撞位置为该目标对象与其他目标对象发生碰撞时,用于判断碰撞区域的位置。
一种计算机设备所述计算机设备包括:交互装置、输入/输出(I/O)接口、处理器和存储器,该存储器中存储有程序指令;该交互装置用于获取用户输入的操作指令;该处理器用于执行存储器中存储的程序指令,执行如上述任意一项所述的方法。
一种计算机可读存储介质,包括指令,当该指令在计算机设备上运行时,使得该计算机设备执行如上述任意一项所述的方法。
本申请实施例所提供的帧同步方法,包括:根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;根据服务器的计算压力信息确定目标对象的更新安排,更新安排包括目标对象状态更新的更新频率和更新开始时间;按更新安排所指示的更新开始时间和更新频率对目标对象进行状态更新;向客户端发送更新安排,以使客户端在更新开始时间以更新频率对目标对象进行状态更新。在帧同步过程中,服务器并不是在对象状态改变时立即向客户端发送通知,而是约定更新频率,间隔预定时间执行更新,其余时间由服务器和客户端各自执行本地的对象更新,从而减少了帧同步对于网络传输质量的依赖,提升了帧同步的稳定性和传输效率;进一步地,更新安排根据服务器的计算压力大小而动态调节,进一步提升了本方案的灵活性和稳定性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为本申请实施例所提供的帧同步方法的一个实施例的流程图;
图2为本申请实施例所提供的帧同步方法的工作场景图;
图3为本申请实施例所提供的帧同步方法的另一个实施例的流程图;
图4为本申请实施例所提供的帧同步方法的另一个实施例的流程图;
图5为本申请实施例所提供的帧同步方法的另一个实施例的流程图;
图6为本申请实施例所提供的帧同步方法的一种实施方式的示意图;
图7为本申请实施例所提供的帧同步方法中更新碰撞位置的时序图;
图8为本申请实施例所提供的帧同步方法中更新碰撞位置的示意图;
图9为本申请实施例所提供的帧同步方法的另一个实施例的流程图;
图10为本申请实施例所提供的帧同步方法的另一个实施例的流程图;
图11为本申请实施例所提供的计算机设备的示意图;
图12为本申请实施例所提供的帧同步装置的示意图;
图13为本申请实施例所提供的帧同步装置的示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在网络游戏过程中,例如多人在线战术竞技游戏(Multiplayer Online BattleArena,MOBA)或即时战略游戏(Real-Time Strategy Game,RTS),由多名用户分别通过各自的客户端连接服务器,以实现多人在线的游戏。在此过程中,服务器需要确保游戏中的非玩家的角色(Non-Player-Character,NPC)在各个客户端中保持同步。
现有技术中用于同步服务器和客户端数据的方案,一般是基于状态同步的方案,也叫网络数据复制。即服务器检测一个对象的变量是否有发生改变,如果有改变,就把这个改变通知相应的客户端,客户端收到消息也做相应的改变。
当网络不好,产生延时或丢包时,客户端跟服务器同一个对象的状态就会产生越来越大的差异,直到下一次数据发送过来才能进行纠正。导致不同客户端之间NPC的状态发生偏差。
因此,为了解决上述问题,本申请实施例提供一种帧同步方法,能够通过对更新频率进行动态调节,使得服务器和客户端之间按照预设的频率进行更新,保证对象的帧同步。为便于理解,以下结合附图,对本申请实施例所提供的方法进行详细说明。
需要说明的是,本申请实施例所提供的方法可以应用于各种不同的领域,例如游戏领域中的多人在线战术竞技游戏(Multiplayer Online Battle Arena,MOBA)、即时战略游戏(Real-Time Strategy Game,RTS)或者第一人称射击类游戏(First-person shootinggame,FPS)等,还可以是其他需要进行帧同步的使用领域,对此本申请实施例并不进行限定。
请参阅图1,如图1所示,本申请实施例所提供的帧同步方法的实施例一包括以下步骤。
101、服务器根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息。
本实施例中,目标对象可以是游戏中的NPC、或者各种道具及背景等,也可以是游戏角色,或者其他应用场景下需要进行帧同步的对象,对此本申请实施例并不进行限定,为便于理解,本实施例后续以目标对象为NPC为例进行说明。在帧同步过程中,服务器和客户端之间每间隔预定帧进行一次帧同步,以在服务器和客户端两端同步NPC的状态。帧同步的速度影响了游戏画面的显示质量,二者的关系为:游戏画面显示帧数=1000ms/每次更新的总耗时,可见,每次更新的总耗时(即所有NPC完成一次更新的总耗时)越低,游戏画面显示的帧数就越高,则游戏画质就越高,因此,在游戏开发过程中,为达到理想的目标显示帧数,需要预设一个理想的更新耗时,然而在实际工作过程中,耗时会有一定的偏差,因此,每一次NPC更新结束后,获取本次所有NPC完成状态更新的实际耗时,从而根据实际耗时,即可知晓当前服务器的计算压力信息,从而可以通过计算压力信息获取当前服务器工作的繁忙情况。
102、服务器根据服务器的计算压力信息确定目标对象的更新安排。
本实施例中,更新安排包括目标对象状态更新的更新频率和更新开始时间。其中,计算压力信息表明服务器的计算压力较小时,可以安排较高的更新频率对目标对象进行更新,从而获得更好的游戏画质;当计算压力信息表明服务器的计算压力较大时,可以安排较低的更新频率对目标对象进行更新,以防止服务器因算力无法满足而发生卡顿或延迟。更新开始时间用于指示更新开始的时间,更新开始时间可以根据网络延迟来调节,当网络延迟较大时,更新开始时间更靠后,当网络延迟较小时,更新开始时间更靠前,以使得服务器端和客户端同步开始对NPC进行更新。例如,更新开始时间约定本次更新在0.6-1.2秒之后生效。这样使得服务器有足够的时间把这个新的更新安排发送给客户端,客户端也来得及应用新的更新参数。
在实际工作过程中,每个更新安排由两个整数组成,例如1000:3,代表从第1000时间单位开始,以每3时间单位的频率进行更新。每个时间单位可以根据用户的需求进行调节,例如每个时间单位可以固定等于0.01秒,此时,更新开始时间为第10秒,更新频率为每0.03秒更新一次。
103、服务器按更新安排所指示的更新开始时间和更新频率对目标对象进行状态更新。
本实施例中,例如,更新安排为1000:3,则服务器端从服务器时间的第10秒开始,以每0.03秒一次的频率对NPC进行更新,从而和客户端保持对NPC的同步更新,实现了帧同步。
104、服务器向客户端发送更新安排。
本实施例中,更新安排用于使客户端在更新开始时间以更新频率对目标对象进行状态更新,以实现服务器和客户端的帧同步。
105、客户端获取服务器时间。
本实施例中,客户端在工作过程中,并不是以本地时间来计算更新开始时间,而是以服务器提供的服务器时间来计算的,因此,客户端需要获取服务器的时间,以服务器时间为基准执行更新安排,才能实现与服务器端的帧同步。
106、客户端在更新开始时间以更新频率对目标对象进行状态更新。
本实施例中,客户端以服务器端发送的更新安排对本地的NPC进行更新,例如,更新安排为1000:3,则客户端从服务器时间的第10秒开始,以每0.03秒一次的频率对NPC进行更新,从而和服务器保持对NPC的同步更新,实现了帧同步。
需要说明的是,上述服务器和客户端两侧各自执行更新安排,从而在服务器和客户端两侧实现帧同步,可选地,服务器和客户端两侧执行更新安排的方式并不相同,其中,服务器实时地生成更新安排并对目标对象执行该更新安排,而对于客户端而言,客户端每间隔预设时间接收服务器发送的更新安排,其余时间按照服务器发送的更新安排执行本地更新。具体地,可以包括以下步骤:
1、服务器在第一时刻生成第一子更新安排。
本实施例中,第一时刻为服务器时间中的一个时刻,第一子更新安排是服务器在第一时刻按照上述步骤101至102所述的方式获得的更新安排。
2、服务器在第一时刻向客户端发送第一子更新安排。
本实施例中,服务器将第一时刻生成的第一子更新安排实时发送给客户端。
3、客户端在第一时段根据第一子更新安排对目标对象进行本地状态更新。
本实施例中,第一时段为第一时刻到第二时刻的时段,第二时刻为第一时刻之后接收服务器的更新安排的时刻,即,在收到第一子更新安排后的第一时段内,服务器与客户端之间不再收发更新安排,客户端按照第一子更新安排对目标对象进行本地更新。直到客户端在第二时刻收到服务器发送的第二子更新安排,则在第二时刻之后的时段,客户端按照与上述同样的方式,按照第二子更新安排对目标对象进行本地更新。
可见,服务器仅在预定的时刻向客户端发送更新安排,其余时间由客户端执行本地更新,从而使得客户端根据更新安排做实际更新并在其余时间做插值更新,这样一来,可以节省服务器与客户端之间的通信资源,降低了帧同步操作的网速的依赖,如果遇到延时太大,或丢包的情况,也不要紧,因为每过一段时间服务器就会向客户端发送新的更新安排,此时客户端可以跟据服务器的更新安排中目标对象的位置信息对本地目标对象做平滑纠正。
本申请实施例所提供的帧同步方法,包括:根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;根据服务器的计算压力信息确定目标对象的更新安排,更新安排包括目标对象状态更新的更新频率和更新开始时间;按更新安排所指示的更新开始时间和更新频率对目标对象进行状态更新;向客户端发送更新安排,以使客户端在更新开始时间以更新频率对目标对象进行状态更新。在帧同步过程中,服务器并不是在对象状态改变时立即向客户端发送通知,而是约定更新频率,间隔预定时间执行更新,其余时间由服务器和客户端各自执行本地的对象更新,从而减少了帧同步对于网络传输质量的依赖,提升了帧同步的稳定性和传输效率;进一步地,更新安排根据服务器的计算压力大小而动态调节,进一步提升了本方案的灵活性和稳定性。
需要说明的是,在实际工作过程中,为节省算力资源和传输资源,并不是每一次都需要对所有的目标对象进行更新,例如在如图2所示的FPS游戏中,由玩家控制角色201对多个NPC怪物202进行射击,由于怪物202的数量较多,只需要按照预设规则,每次对部分的怪物202进行更新即可,因此,本申请实施例提供一种方式,有选择地对目标对象进行更新。为便于理解,以下结合附图进行详细说明。
请参阅图3,如图3所示,本申请实施例所提供的帧同步方法的实施例二包括以下步骤。
301、服务器根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息。
本实施例中,具体实施方式可参阅上述步骤101,需要说明的是,此处的实际耗时,指的是需要更新的所有NPC完成更新的耗时。
302、服务器根据服务器的计算压力信息确定特定目标对象的更新安排。
本实施例中,为节省算力资源和传输资源,并不是每一次都需要对所有的目标对象进行更新,而是根据实际使用需求,由服务器根据特定的规则每次对部分NPC进行更新,可以是一、按照预设规则对指定目标对象进行更新;二、按照随机规则对目标对象进行均匀的更新。为便于理解,以下分别对此两种情况进行详细说明。
一、按照预设规则对指定目标对象进行更新。
本实施例中,按照预设规则对指定目标对象进行更新包括以下步骤。
1、为第一目标对象分配第一更新频率;
2、为第二目标对象分配第二更新频率;
其中,第一目标对象与第三目标对象的距离小于第二目标对象与第三目标对象的距离,第三目标对象为用户控制的目标对象,第一更新频率大于第二更新频率。
本实施例中,预设规则的思想为,目标对象的更新频率主要取决于它距离玩家所控制的游戏角色的位置。这样一来,距离玩家越近的NPC更新频率会变高,从而使得玩家具有较好的游戏体验,同时,距离玩家所控制角色距离较远的NPC采取较低的更新频率,既不会影响玩家的游戏体验,也节省了更新的算力资源,提高了更新的稳定性。
二、按照随机规则对目标对象进行均匀的更新。
本实施例中,本方法主要针对距离玩家所控制的游戏角色较远的NPC,这些NPC由于距离玩家较远,不需要进行高频率的更新,但是依然需要调用一套规则,对这些NPC进行均匀且稳定的随机更新,以保障游戏画面的流畅性。具体包括以下步骤:
1、从多个目标对象中获取尚未分配更新安排的待分配对象。
本实施例中,服务器为NPC分配更新安排,NPC收到更新安排后,周期性按照该更新安排进行更新,直到收到新的更新安排后,再以新的更新安排进行更新,由于每次服务器只对部分NPC分配更新安排,因此,在向NPC分配更新安排的过程中,服务器优先向尚未分配更新安排的NPC分配更新安排,因此在此步骤中,需要首先获取获取尚未分配更新安排的待分配对象。
2、通过随机分配算法为待分配对象随机分配更新安排,其中,每个待分配对象对应有一个更新安排。
本实施例中,服务器对待分配对象分配更新安排,这样使得每次都只有部分NPC被设定新参数,平均的随机性,避免产生更新和数据发送的峰值。可选地,随机分配算法可以是现有技术中的任意一种随机分配算法,优选地,本申请实施例提供以下随机分配算法。
通过取NPC的ID的模来选择分发更新安排的待分配对象,例如,向模7ID等于7的NPC分配更新安排。具体地,取模即取NPC的ID的余数,以7除以每个NPC的ID,余数为7的NPC,即为本轮需要分发更新安排的待分配对象。下一轮取模8ID等于8的NPC分配更新安排,即以8除以每个NPC的ID,余数为8的NPC即为下一轮需要分发更新安排的待分配对象,以此类推,即可均匀且随机地向所有NPC分配更新安排。
可选地,随机算法还可以是其他的方式。例如,按照NPC的ID顺序,每次向预设数量的NPC分配更新安排,例如,第一轮向第1至30个ID的NPC分配更新安排,第二轮向地31至60个ID的NPC分配更新安排,以此类推,每次向30个NPC分配更新安排。
303、服务器按更新安排所指示的更新开始时间和更新频率对目标对象进行状态更新。
本实施例中,服务器跟据每个NPC设定的更新频率对NPC进行更新,自上一次更新开始到目前位置的时间即为DeltaTime,DeltaTime会随着更新而累加,并以固定的最小时间单位(例如0.01秒)前进,例如:一个NPC的安排是从1000:3,现在系统时间是1002.2,并且DeltaTime=0.063,即系统需要从1002.2运行到1008.5,则该帧实际会调用该NPC的更新两次,分别在1003,1006时调用,对应传递的DeltaTime都是0.03,结束后NPC会处于Time=1006时的位置。
后续步骤304至306可参阅上述步骤104至106,此处不再赘述。
本实施例中,通过随机分配算法,使得NPC能够由平滑而稳定的表现,确保了用户的游戏体验。
需要说明的是,本申请实施例中,根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息时,需要考虑实际耗时占用理想耗时的比例,为便于理解,以下对此种方式进行具体说明。
请参阅图4,如图4所示,本申请实施例所提供的帧同步方法的实施例三包括以下步骤。
401、服务器获取目标对象进行状态更新的实际耗时。
本实施例中,本步骤可参阅上述步骤101,此处不再赘述。
402、根据实际耗时占用目标对象进行状态更新的理想耗时的比值获取服务器的计算压力信息。
本实施例中,通过计算实际耗时占用理想耗时的比例,服务器即可知晓当前实际工作状态偏离理想状态的情况,从而能够根据这种偏移的程度获取到服务器的计算压力信息。
具体地,服务器的计算压力信息可以通过服务器的当前负载高低数值PerfRatio来表示,PerfRatio可通过以下算法来实现:
PerfRatio=Clamp(PerfRatio’+(1.0f-cost/DesiredCost)*af,0.0f,1.0f);
其中,Clamp()为取值算法,PerfRatio’为前一次目标对象状态更新时服务器的负载高低数值,cost为实际耗时,DesiredCost为理想耗时,a为敏感度参数。
在上述算法中,cost/DesiredCost是一个最大值等于1的数值,通过1.0f-cost/DesiredCost即可知晓实际耗时偏移理想耗时的程度,敏感度参数a用于调节耗时偏移程度对PerfRatio取值大小的影响,a越大耗时偏移程度对PerfRatio的影响就越大,例如a可以为0.08,则此时PerfRatio受耗时偏移程度的波动就较小,PerfRatio可以平稳地改变。Clamp()为取值算法的取值范围区间为:(0.0f,1.0f),即,当Clamp()内的取值小于0时,Clamp()取值为0,当Clamp()内的取值大于1时,Clamp()取值为1,从而使得PerfRatio的取值范围为[0,1]。其中,PerfRatio=1代表服务器计算压力最小,PerfRatio=0代表服务器计算压力最大,从而可以通过PerfRatio来表示服务器的计算压力。
403、根据负载高低数值PerfRatio确定更新安排。
本实施例中,PerfRatio的数值大小与更新安排所指示的更新频率大小成正比。如上所述,PerfRatio的取值范围为[0,1],当PerfRatio为1时,代表服务器毫无压力,直接在更新安排中使用最激进的参数,PerfRatio等于0则相反,代表压力太大,更新安排需要使用最保守的参数。在PerfRatio大于0小于1时,数值越大,则更新安排中使用越激进的参数。
后续步骤404至407可参阅上述步骤103至106,此处不再赘述。
本实施例中,服务器上的NPC逻辑计算和其他计算会占用CPU资源,从而影响服务器帧数,进而影响客户端表现。所以服务器根据计算压力信息确认当前负载,从而进行自动参数调配变得非常重要,能确保帧数达到玩家可接受的范围。
需要说明的是,客户端在接收到服务器发送的更新安排后,需要按照服务器的时间来执行更新安排;这里面有一个前提,即客户端的时间要和服务器的时间同步,才能保证两端同步执行更新安排,实现帧同步。在具体工作过程中,服务器会定时向客户端发送当前服务器时间,以使得客户端时间与服务器时间保持同步,然而,在实际实现过程中,由于网络延迟等原因,服务器发送的时间信息会延迟到达客户端,导致时间不准确,例如,服务器向客户端发送时间信息,表明当前服务器时间为1004ms,然而由于网络存在延迟,时间信息3ms后才到达客户端,当客户端收到服务器时间信息时,服务器时间为1007ms,而客户端以为当前服务器时间为1004ms,导致两端出现了3ms的延迟。
为解决此问题,服务器的网络层会根据网络延迟情况,估算一个网络层时间,来抵消网络延迟对时间信息准确性的影响,然而,网络层时间相较实际的延迟情况依然可能存在误差,为解决此问题,本申请实施例提供了一种方案,为便于理解,以下结合附图进行详细说明。
请参阅图5,如图5所示,本申请实施例所提供的帧同步方法的实施例四包括以下步骤。
步骤501至504可参阅上述步骤101至104或上述任意一种实施例,此处不再赘述。
505、客户端根据本地时间和网络传输时延估算服务器时间。
本实施例中,客户端本地时间为:客户端上一次执行更新后到目前位置的时间,即上述的DeltaTime,网络传输时延可以通过上述网络层时间来获得,从而客户端可以根据DeltaTime和网络层时间,估算服务器时间,从而克服网络延迟对时间不同同步的影响。
可选地,如图6所示,上述服务器时间的估算可以由客户端通过平滑服务器时间算法来实现。
如图6所示,diffRangeLimit为期望的服务器时间与网络层时间之间偏差值的容忍度数值,minIncreasTime为最小时间单位,diffRangeLimit与minIncreasTime的数值均可根据实际需要进行调节,如图6所提供的实施例中,diffRangeLimit-=0.3f,minIncreasTime=0.01f。realDeltaTime为客户端本地实际的DeltaTime,logicServerTime为上述网络层时间,通过以下算法获取理想服务器时间idealServerTime(即没有网络延迟的情况下的服务器时间):
idealServerTime=Clamp(SmoothServerTime’+realDeltaTime,
logicServerTime-diffRangeLimit,logicServerTime+diffRangeLimit);
其中,Clamp()为取值算法,取值区间在logicServerTime-diffRangeLimit和logicServerTime+diffRangeLimit之间,SmoothServerTime’为上一次更新的平滑服务器时间。
smoothRate’为当前的平滑率,平滑率的初始值可以根据实际需要进行调节,通过当前平滑率smoothRate’即可计算当前的服务器平滑时间SmoothServerTime’。当SmoothServerTime’大于logicServerTime时,平衡的服务器时间大于网络层时间,说明当前平滑服务器时间的走时较快,需要通过较低平滑率的方式来调慢平滑服务器时间,以使得平滑服务器时间更贴近服务器实际的时间,通过以下算法获取本次更新的平滑率:
smoothRate=FMath::Max(smoothRate’*0.25f,smoothRate-
(SmoothServerTime’-logicServerTime)*0.75f)
其中,Max()为取最大值算法,从算法中可以看到,当前平滑服务器时间SmoothServerTime’与网络层时间logicServerTime的差值越大,smoothRate-(SmoothServerTime’-logicServerTime)*0.75f的结果就会越小,从而由此作为调节得到新的平滑率smoothRate。
基于更新后的平滑率,进一步计算平滑服务器时间SmoothServerTime:
SmoothServerTime=Max(SmoothServerTime’+miniIncraeseTime,idealServerTime*SmoothRate+logicServerTime*(1.0f-SmoothRate))。
从而根据上述算法,使得客户端能够较为准确地估算服务器的时间,使得客户端和服务器能够同步执行NPC的更新,精准地实现帧同步。
506、客户端在更新开始时间以更新频率对目标对象进行状态更新。
本实施例中,当客户端接收到服务器发送的更新安排后,在更新开始时间以更新频率对目标对象进行状态更新,在客户端接收到服务器的下一次更新安排之前,客户端在本地按照更新安排对NPC执行更新。NPC的位置分为逻辑位置和视觉位置,逻辑位置表示“确信的位置”,包括服务器告知的位置或者跟据已知的更新安排,在相应时间更新后得出的位置。而“视觉位置”是为了让客户端表现连贯,每帧展现给玩家看的NPC的位置。服务器上只有“逻辑位置”,没有“视觉位置”。基于此,客户端可以采取以下方式按照更新安排对NPC进行更新。
1、在第一时间点与第二时间点之间的第三时间点,获取第三时间点与第一时间点的第一时间差。
本实施例中,更新频率至少指示在第一时间点和第二时间点与服务器交互以实现对目标对象状态的更新,则在第三时间点,客户端并没有与服务器进行交互,此时需要由客户端按照更新安排来对NPC执行本地更新,因此,首先获取第三时间点与第一时间点的第一时间差,以知晓当前时刻距离上次更新的时间。
2、将第一目标对象移动到第一时间点的位置。
本实施例中,第一目标对象为目标对象中的任意一个,即本次需要进行更新的NPC,第一目标对象在第一时间点的位置,是与服务器同步的位置,即上述逻辑位置。
3、从第一时间点开始,以第一时间差为时长对第一目标对象进行本地更新。
本实施例中,例如NPC的更新安排是1000:3,客户端在1004时收到服务器发送的NPC在1003时的位置,那么该1003的位置就作为“逻辑位置”保留,但假设现在时间是1004,DeltaTime=0.01,即需要计算NPC在1005时的位置,作为“视觉位置”显示,客户端会先把NPC临时的移动到1003的逻辑位置,然后用第一时间差DeltaTime=0.02进行更新,得到的位置就是1005的视觉位置。如果下一帧到了1007.3,而且之间没有服务器额外的数据,那么客户端会先把NPC移动到1003的位置,执行第一时间差DeltaTime=0.03的更新,得到的数值作为1006的“逻辑位置”,再执行DeltaTime=0.013的更新,得到的就是1007.3的视觉位置了。这样可以保证服务器和客户端的逻辑位置是一致的,而且客户端的“视觉位置”能确保连续的连接相应的“逻辑位置”。
进一步地,在上述更新的过程中,客户端执行数据纠正的情况仍然是不可避免的,例如网络出状况时,客户端无法在约定的时间收到服务器发送的最新的更新安排,此时,客户端需要执行数据纠正,以在这段无法与服务器通信的时间内尽可能地保证游戏的流程运作。具体通过以下方式实现。
1、当位于第二时间点时没有收到由服务器发送的更新数据,获取第一目标对象的目标操作。
本实施例中,第二时间点原本为服务器和客户端之间进行通信的时间点,当位于第二时间点时没有收到由服务器发送的更新数据,说明网络发生异常,使得客户端没有在该时间点收到更新数据,此时,获取目标操作,目标操作为第一时间点时服务器向第一目标对象输入的控制操作,即上一次服务器与客户端之间通信时,服务器所更新的操作,例如NPC执行了特殊操作如技能、带位移攻击、重新寻路等
2、根据目标操作对第一目标对象的运动进行本地更新。
本实施例中,在网络发生状况时,客户端需要在本地计算最终显示的“视觉位置”,此时,根据目标操作额外计算视觉位置变化的速度和加速度,这些额外的速度和加速度是由该目标操作所引起的,并加上相应的最大变化限制,最终显示平滑过的视觉位置,这样确保视觉位置总是连续的,避免了由于网络卡顿对用户的使用体验造成影响。
需要说明的是,在帧同步的过程中,还有一个重要的问题,就是NPC之间的碰撞问题,例如,在服务器中,NPC甲与NPC乙同时走向A位置,甲比乙快0.1s到达A位置,则乙为了避免与甲碰撞,需要改变路线绕开A位置;此时需要客户端中的甲和乙与服务器保持同步,否则,若客户端中乙比甲快0.1s,则造成在客户端中乙先到达A位置,而甲绕开,使得客户端中NPC的行为与服务器中不同步。
本申请实施例所提供的方案通过障碍物规避算法(Reciprocal VelocityObstacles,RVO)来解决上述问题。由于帧同步涉及服务器与客户端的同步,就会产生一致性的问题,因为细小的误差,就会导致计算出的规避结果有很大的差别。这些误差的来源包括:
1)、数据精度问题:服务器的位置为了节省带宽,只精确到0.2厘米
2)、更新顺序问题:由于客户端可以使用多核,通过多线程对多个NPC分别进行处理,而服务器只使用单核单线程对NPC进行处理,造成了不同的Update顺序,使得结果千差万别。
为此,本申请实施例提供以下技术方案来解决上述两个误差的来源。
1)、数据精度问题。
本实施例中,在服务器向客户端发送位置、速度等信息的过程中,为节省带宽,仅将信息的精度精确到0.2cm,例如,NPC甲的移动速度为6.23cm/s;为节省带宽,服务器向客户端发送NPC甲的移动速度为6.2cm/s,使得NPC甲的移动速度在服务器与客户端之间造成了0.03cm/s的误差,随着多次更新,该误差会发生累积,导致服务器与客户端之间发生较大的误差。
为解决此问题,当服务器更新位置、速度等信息时,也会把这些数值替换成低精度数值进行存储,例如,在服务器端,NPC甲的移动速度为6.23cm/s;为节省带宽,服务器向客户端发送NPC甲的移动速度为6.2cm/s,此时,服务器将本地NPC的移动速度由6.23cm/s改为6.2cm/s,从而确保客户端与服务器两端的数据保持同步,防止误差累积造成偏差。
2)、更新顺序问题。
本实施例中,由于客户端会采用多核操作,对应多个线程,其中,每个线程负责一批NPC的更新,而服务器仅采用单核的操作,仅有一个线程来处理所有的NPC;此时,由于两端线程的不同,可能会导致NPC更新的不同步,例如,在服务器的单线程中,先更新NPC甲再更新NPC乙,当甲乙同时去往A位置时,由于甲先更新,则甲会先到达A位置,而乙为了避免与甲碰撞则会绕开A位置;而在客户端中,乙由第一核对应的第一线程来处理,甲由第二核对应的第二线程来处理,此时第一线程先更新,第二线程后更新,则会导致乙先到达A位置,而甲为了避免与乙发生碰撞绕开A位置的情况。
为解决此问题,提供如下方法:
服务器根据当前目标对象的位置获取碰撞位置。
客户端根据第一位置获取碰撞位置。
本实施例中,第一位置为最近一次更新时服务器发送的目标对象的位置,碰撞位置为目标对象与其他目标对象发生碰撞时,用于判断碰撞区域的位置。
上述方法中,对于更新顺序问题,在动态帧同步的框架内,仍然允许客户端多线程运行,服务器单线程运行,不过额外引入“碰撞位置”信息。该位置信息取自于“逻辑位置”,但并不是每次“逻辑位置”改变就存储的,而是固定每预设个时间单位(例如可以是12个时间单位,即0.12秒)会使用当前的“逻辑位置”更新,这个更新发生于所有NPC在当前时间更新结束时,所以能保证服务器和客户端更新的“碰撞位置”都是一致的。在RVO计算中,使用“碰撞位置”进行注册,即“逻辑位置”对RVO系统来说是透明的。这样就能保证RVO结果的一致性。碰撞位置也同样运用于玩家和其他需要参与RVO的NPC。
如图7所示,服务器和客户端各自在t1时刻更新了逻辑位置,则到了t2时刻时,服务器和客户端各自获取逻辑位置为碰撞位置。从而实现了碰撞位置的同步,克服了由于更新顺序不同引发的碰撞问题。
可选地,如图8所示,对于任意一个NPC而言,碰撞位置801的面积可以大于NPC802所占用的面积,以使得NPC之间可以提前发生碰撞,使得服务器和客户端可以提前判定碰撞,避免因更新误差导致碰撞顺序发生改变。
进一步地,结合具体的实施方式,本申请实施例提供一种帧同步方法应用在实际工作中的具体实施方式,为便于理解,以下结合附图进行详细说明。
请参阅图9和图10,如图9和图10所示,本申请实施例所提供的帧同步方法的实施例五包括以下步骤。
如图9所示,对于服务器而言,执行以下步骤。
901、当服务器更新开始时,判断当前是否达到本帧结束时间。
本实施例中,服务器在预定帧对NPC进行更新,因此需要在每次工作开始时,判定本轮更新是否结束,若本帧没有结束,则需要完成本帧的更新,执行步骤902至905,若确定结束,则直接执行步骤906和907。
902、步进时间0.01s。
本实施例中,0.01s为预设的时间单位,根据实际需求,该时间单位也可以设定为其他数值,对此本申请实施例并不进行限定,时间单位越大,更新的步长越大。
903、对目标对象进行更新。
本实施例中,根据更新安排,当到达了更新开始时间时,按照更新频率对特定的NPC进行更新。具体更新开始时间和更新频率的获取方式,以及特定NPC的分配方式可参阅上述记载,此处不再赘述。
904、判断是否到达碰撞位置的同步时间。
本实施例中,碰撞位置的同步时间即图7中所记载的t2时刻,在碰撞位置的同步时间,需要将当前NPC的逻辑位置更新为碰撞位置,以解决NPC之间碰撞的同步问题,若当前时间为碰撞位置的同步时间,则执行步骤907,若当前时间不为碰撞位置的同步时间,则重新执行步骤901,进行下一轮的更新。
905、将所有目标对象NPC的逻辑位置更新到碰撞位置。
本实施例中,对将NPC逻辑位置更新到碰撞位置的具体实施方式可参阅上述记载,此处不再赘述。
906、根据更新耗时计算负载高低数值PerfRatio。
本实施例中,当本帧所有NPC结束更新后,更新耗时即为前述目标对象进行状态更新的实际耗时,根据实际耗时计算PerfRatio的具体实现方式可参阅上述步骤402,此处不再赘述。
907、根据负载高低数值PerfRatio对目标对象NPC设定更新安排。
本实施例中,通过PerfRatio即可获知服务器的计算压力情况,从而为特定的NPC设定更新安排,其中,选择特定NPC的方式可参阅上述步骤302的记载,此处不再赘述,更新安排的设定可参阅上述步骤403的记载,此处不再赘述。
如图10所示,对于客户端而言,为了保持与服务器的帧同步,客户端需要执行与服务器类似的步骤,唯一的区别在于,由于客户端是多线程操作,而服务器是单线程操作,因此在对NPC进行更新时,二者操作会有区别,具体包括以下步骤。
1001、当客户端更新开始时,判断当前是否达到本帧结束时间。
本实施例中,客户端在预定帧对NPC进行更新,因此需要在每次工作开始时,判定本轮更新是否结束,若本帧没有结束,则需要完成本帧的更新,执行步骤1002至1005,若确定结束,则直接执行步骤1006和1007。
1002、步进时间0.01s。
本实施例中,0.01s为预设的时间单位,根据实际需求,该时间单位也可以设定为其他数值,对此本申请实施例并不进行限定,时间单位越大,更新的步长越大。
需要说明的是,客户端的步进时间需要与服务器端的步进时间保持一致。
1003、对目标对象进行更新。
本实施例中,根据更新安排,当到达了更新开始时间时,按照更新频率对特定的NPC进行更新。具体更新开始时间和更新频率的获取方式,以及特定NPC的分配方式可参阅上述记载,此处不再赘述。
需要说明的是,若客户端是通过多线程的方式对NPC进行更新,则更新前,客户端需要先让NPC回到上一次更新时服务器发送的逻辑位置,然后根据当前时刻与上一次更新时间点点第一时间差,对NPC进行更新(具体可参阅上述步骤506的记载,此处不再赘述)。从而避免因多核操作导致的更新顺序问题。
1004、判断是否到达碰撞位置的同步时间。
本实施例中,碰撞位置的同步时间即图7中所记载的t2时刻,在碰撞位置的同步时间,需要将当前NPC的逻辑位置更新为碰撞位置,以解决NPC之间碰撞的同步问题,若当前时间为碰撞位置的同步时间,则执行步骤1007,若当前时间不为碰撞位置的同步时间,则重新执行步骤1001,进行下一轮的更新。
1005、将所有目标对象NPC的逻辑位置更新到碰撞位置。
本实施例中,对将NPC逻辑位置更新到碰撞位置的具体实施方式可参阅上述记载,此处不再赘述。
1006、根据更新耗时计算负载高低数值PerfRatio。
本实施例中,当本帧所有NPC结束更新后,更新耗时即为前述目标对象进行状态更新的实际耗时,此时,客户端也可采用与服务器相同的方式,在本地计算服务器的计算压力信息,根据实际耗时计算PerfRatio的具体实现方式可参阅上述步骤402,此处不再赘述。
1007、根据负载高低数值PerfRatio对目标对象NPC进行平滑操作。
本实施例中,平衡操作可以包括:为NPC补足剩余时间、对NPC进行视觉位置更新,或进行简单的平衡操作,具体平滑操作的方式取决于PerfRatio和NPC的重要性。其中,PerfRatio所反映的服务器计算压力越大,说明当前更新频率越低,则客户端此时需要对NPC执行更积极的平衡操作,以保证游戏画面的流畅;NPC距离用户所操作的游戏角色约近,则NPC的重要性越高,对重要性越高的NPC,需要更多的平衡操作,以提升用户的游戏体验。
本申请实施例所提供的帧同步方法,包括:根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;根据服务器的计算压力信息确定目标对象的更新安排,更新安排包括目标对象状态更新的更新频率和更新开始时间;按更新安排所指示的更新开始时间和更新频率对目标对象进行状态更新;向客户端发送更新安排,以使客户端在更新开始时间以更新频率对目标对象进行状态更新。在帧同步过程中,服务器并不是在对象状态改变时立即向客户端发送通知,而是约定更新频率,间隔预定时间执行更新,其余时间由服务器和客户端各自执行本地的对象更新,从而减少了帧同步对于网络传输质量的依赖,提升了帧同步的稳定性和传输效率;进一步地,更新安排根据服务器的计算压力大小而动态调节,进一步提升了本方案的灵活性和稳定性。
上述对本申请实施例提供的方案进行了介绍。可以理解的是,计算机设备为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的模块及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
从硬件结构上来描述,上述方法可以由一个实体设备实现,也可以由多个实体设备共同实现,还可以是一个实体设备内的一个逻辑功能模块,本申请实施例对此不作具体限定。
例如,上述方法均可以通过图11中的计算机设备来实现。图11为本申请实施例提供的计算机设备的硬件结构示意图。该计算机设备包括至少一个处理器1101,通信线路1102,存储器1103以及至少一个通信接口1104。
处理器1101可以是一个通用中央处理器(central processing unit,CPU),微处理器,特定应用集成电路(application-specific integrated circuit,服务器IC),或一个或多个用于控制本申请方案程序执行的集成电路。
通信线路1102可包括一通路,在上述组件之间传送信息。
通信接口1104,使用任何收发器一类的装置,用于与其他设备或通信网络通信,如以太网,无线接入网(radio access network,RAN),无线局域网(wireless local areanetworks,WLAN)等。
存储器1103可以是只读存储器(read-only memory,ROM)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(random access memory,RAM)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(electricallyer服务器able programmable read-only memory,EEPROM)、只读光盘(compact disc read-only memory,CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器可以是独立存在,通过通信线路1102与处理器相连接。存储器也可以和处理器集成在一起。
其中,存储器1103用于存储执行本申请方案的计算机执行指令,并由处理器1101来控制执行。处理器1101用于执行存储器1103中存储的计算机执行指令,从而实现本申请上述实施例提供的方法。
可选的,本申请实施例中的计算机执行指令也可以称之为应用程序代码,本申请实施例对此不作具体限定。
在具体实现中,作为一种实施例,处理器1101可以包括一个或多个CPU,例如图11中的CPU1和CPU2。
在具体实现中,作为一种实施例,计算机设备可以包括多个处理器,例如图11中的处理器1101和处理器1107。这些处理器中的每一个可以是一个单核(single-CPU)处理器,也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中,作为一种实施例,计算机设备还可以包括输出设备1105和输入设备1106。输出设备1105和处理器1101通信,可以以多种方式来显示信息。例如,输出设备1105可以是液晶显示器(liquid crystal display,LCD),发光二级管(light emittingdiode,LED)显示设备,阴极射线管(cathode ray tube,CRT)显示设备,或投影仪(projector)等。输入设备1106和处理器1101通信,可以以多种方式接收用户的输入。例如,输入设备1106可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的计算机设备可以是一个通用设备或者是一个专用设备。在具体实现中,计算机设备可以是台式机、便携式电脑、网络服务器、掌上电脑(personaldigitalassistant,PDA)、移动手机、平板电脑、无线终端设备、嵌入式设备或有图11中类似结构的设备。本申请实施例不限定计算机设备的类型。
本申请实施例可以根据上述方法示例对存储设备进行功能单元的划分,例如,可以对应各个功能划分各个功能单元,也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。需要说明的是,本申请实施例中对单元的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
比如,以采用集成的方式划分各个功能单元的情况下,图12示出了一种帧同步装置的示意图。
如图12所示,本申请实施例提供的帧同步装置,包括:
第一获取单元1201,该第一获取单元1201用于根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;
确定单元1202,该确定单元1202用于根据该第一获取单元1201获取的该服务器的计算压力信息确定该目标对象的更新安排,该更新安排包括目标对象状态更新的更新频率和更新开始时间;
更新单元1203,该更新单元1203用于按该确定单元1202确定的该更新安排所指示的该更新开始时间和该更新频率对该目标对象进行状态更新;
发送单元1204,该发送单元1204用于向该客户端发送该确定单元1202确定的该更新安排,以使该客户端在该更新开始时间以该更新频率对该目标对象进行状态更新。
可选地,该发送单元1204还用于:在第一时刻向该客户端发送第一子更新安排;
其中,该第一子更新安排为该第一时刻时生成的该更新安排,该第一子更新安排用于使该客户端在第一时段内进行本地更新,该第一时段为该第一时刻到第二时刻的时段,该第二时刻为该第一时刻之后该客户端发送更新安排的时刻。
可选地,该目标对象至少包括第一目标对象、第二目标对象和第三目标对象,则该确定单元1202还用于:
为该第一目标对象分配第一更新频率;
为该第二目标对象分配第二更新频率;
该第一目标对象与第三目标对象的距离小于该第二目标对象与该第三目标对象的距离,该第三目标对象为用户控制的目标对象,该第一更新频率大于该第二更新频率。
可选地,该目标对象的数量为多个,则该确定单元1202还用于:
从多个该目标对象中获取尚未分配更新安排的待分配对象;
通过随机分配算法为该待分配对象随机分配该更新安排,其中,每个该待分配对象对应有一个该更新安排。
可选地,该第一获取单元1201还用于:
根据该实际耗时占用目标对象进行状态更新的理想耗时的比值获取该服务器的计算压力信息。
可选地,该服务器的计算压力信息为该服务器的当前负载高低数值PerfRatio,则该第一获取单元1201还用于:
执行以下算法:
PerfRatio=Clamp(PerfRatio’+(1.0f-cost/DesiredCost)*af,0.0f,1.0f);
其中,该Clamp()为取值算法,该PerfRatio’为前一次目标对象状态更新时该服务器的负载高低数值,该cost为该实际耗时,该DesiredCost为该理想耗时,该a为敏感度参数,该0.0f为该Clamp()的取值下限值,该1.0f为该Clamp()的取值上限值;
该根据该服务器的计算压力信息确定该目标对象的更新安排,包括:
该根据该负载高低数值PerfRatio确定该更新安排,其中,该负载高低数值PerfRatio的数值大小与该更新安排所指示的更新频率大小成正比。
可选地,该装置还包括:
第二获取单元1205,该第二获取单元1205用于根据当前该目标对象的位置获取碰撞位置,该碰撞位置为该目标对象与其他目标对象发生碰撞时,用于判断碰撞区域的位置。
图13示出了一种帧同步装置的示意图。
如图13所示,本申请实施例提供的帧同步装置,包括:
第一获取单元1301,该第一获取单元1301用于获取服务器发送的更新安排,该更新安排包括目标对象进行状态更新的更新开始时间和更新频率;
第二获取单元1302,该第二获取单元1302用于获取服务器时间,该服务器时间为该服务器的实时时间;
更新单元1303,该更新单元1303用于根据该第二获取单元1302获取的该服务器的实时时间在该更新开始时间以该更新频率对该目标对象进行状态更新。
可选地,该第一获取单元1301,还用于:获取该服务器发送的第一子更新安排,该第一子更新安排为该服务器在第一时刻生成的该更新安排;
该更新单元1303,还用于:在第一时段根据该第一子更新安排对该目标对象进行本地状态更新,该第一时段为该第一时刻到第二时刻的时段,该第二时刻为该第一时刻之后接收该服务器的更新安排的时刻。
可选地,该第二获取单元1302还用于:
根据本地时间和网络传输时延估算该服务器时间。
该更新频率至少指示在第一时间点和第二时间点与该服务器交互以实现对该目标对象状态的更新,则该更新单元1303还用于:
在该第一时间点与该第二时间点之间的第三时间点,获取该第三时间点与该第一时间点的第一时间差;
将第一目标对象移动到该第一时间点的位置,该第一目标对象为该目标对象中的任意一个;
从该第一时间点开始,以该第一时间差为时长对该第一目标对象进行本地更新。
可选地,该装置还包括纠正单元1304,该纠正单元1304用于:
当位于该第二时间点时没有收到由服务器发送的更新数据,获取该第一目标对象的目标操作,该目标操作为该第一时间点时该服务器向该第一目标对象输入的控制操作;
根据该目标操作对该第一目标对象的运动进行本地更新。
可选地,该装置还包括第三获取单元1305,该第三获取单元1305用于:
根据第一位置获取碰撞位置,其中,该第一位置为最近一次更新时服务器发送的该目标对象的位置,该碰撞位置为该目标对象与其他目标对象发生碰撞时,用于判断碰撞区域的位置。
进一步的,本发明实施例还提供一种计算机存储介质,包括指令,当该指令在计算机设备上运行时,使得该计算机设备执行上述方法。
有关本申请实施例提供的计算机存储介质中存储的程序的详细描述可参照上述实施例,在此不做赘述。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的核心思想或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (15)
1.一种帧同步方法,其特征在于,包括:
根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;
根据所述服务器的计算压力信息确定所述目标对象的更新安排,所述更新安排包括目标对象状态更新的更新频率和更新开始时间;
按所述更新安排所指示的所述更新开始时间和所述更新频率对所述目标对象进行状态更新;
向客户端发送所述更新安排,以使所述客户端在所述更新开始时间以所述更新频率对所述目标对象进行状态更新。
2.根据权利要求1所述的方法,其特征在于,所述向所述客户端发送所述更新安排,包括:
在第一时刻向所述客户端发送第一子更新安排;
其中,所述第一子更新安排为所述第一时刻时生成的所述更新安排,所述第一子更新安排用于使所述客户端在第一时段内进行本地更新,所述第一时段为所述第一时刻到第二时刻的时段,所述第二时刻为所述第一时刻之后所述客户端发送更新安排的时刻。
3.根据权利要求1所述的方法,其特征在于,所述目标对象至少包括第一目标对象、第二目标对象和第三目标对象,则所述根据所述服务器的计算压力信息确定所述目标对象的更新安排,包括:
为所述第一目标对象分配第一更新频率;
为所述第二目标对象分配第二更新频率;
所述第一目标对象与所述第三目标对象的距离小于所述第二目标对象与所述第三目标对象的距离,所述第三目标对象为用户控制的目标对象,所述第一更新频率大于所述第二更新频率。
4.根据权利要求1所述的方法,其特征在于,所述目标对象的数量为多个,则所述根据所述服务器的计算压力信息确定所述目标对象的更新安排,包括:
从多个所述目标对象中获取尚未分配更新安排的待分配对象;
通过随机分配算法为所述待分配对象随机分配所述更新安排,其中,每个所述待分配对象对应有一个所述更新安排。
5.根据权利要求1至4任一所述的方法,其特征在于,所述根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息,包括:
根据所述实际耗时占用目标对象进行状态更新的理想耗时的比值获取所述服务器的计算压力信息。
6.根据权利要求5所述的方法,其特征在于,所述服务器的计算压力信息为所述服务器的当前负载高低数值PerfRatio,则所述根据所述实际耗时占用目标对象进行状态更新的理想耗时的比值获取所述服务器的计算压力信息包括:
执行以下算法:
PerfRatio=Clamp(PerfRatio’+(1.0f-cost/DesiredCost)*a*1.0f,0.0f,1.0f);
其中,所述Clamp()为取值算法,所述PerfRatio’为前一次目标对象状态更新时所述服务器的负载高低数值,所述cost为所述实际耗时,所述DesiredCost为所述理想耗时,所述a为敏感度参数,所述0.0f为所述Clamp()的取值下限值,所述1.0f为所述Clamp()的取值上限值;
所述根据所述服务器的计算压力信息确定所述目标对象的更新安排,包括:
所述根据所述负载高低数值PerfRatio确定所述更新安排,其中,所述负载高低数值PerfRatio的数值大小与所述更新安排所指示的更新频率大小成正比。
7.根据权利要求1至4任一所述的方法,其特征在于,所述方法还包括:
根据当前所述目标对象的位置获取碰撞位置,所述碰撞位置为所述目标对象与其他目标对象发生碰撞时,用于判断碰撞区域的位置。
8.一种帧同步方法,其特征在于,包括:
获取服务器发送的更新安排,所述更新安排包括目标对象进行状态更新的更新开始时间和更新频率;其中,所述更新安排为所述服务器根据所述服务器的计算压力信息确定出的所述目标对象的更新安排,所述服务器的计算压力信息是服务器根据所述目标对象进行状态更新的实际耗时获取得到的;
获取服务器时间,所述服务器时间为所述服务器的实时时间;
根据所述服务器的实时时间在所述更新开始时间以所述更新频率对所述目标对象进行状态更新,以便与所述服务器保持对所述目标对象的同步更新。
9.根据权利要求8所述的方法,其特征在于,所述获取服务器发送的更新安排,包括:
获取所述服务器发送的第一子更新安排,所述第一子更新安排为所述服务器在第一时刻生成的所述更新安排;
所述根据所述服务器的实时时间在所述更新开始时间以所述更新频率对所述目标对象进行状态更新,包括:
在第一时段根据所述第一子更新安排对所述目标对象进行本地状态更新,所述第一时段为所述第一时刻到第二时刻的时段,所述第二时刻为所述第一时刻之后接收所述服务器的更新安排的时刻。
10.根据权利要求8所述的方法,其特征在于,所述获取服务器时间包括:
根据本地时间和网络传输时延估算所述服务器时间;
所述更新频率至少指示在第一时间点和第二时间点与所述服务器交互以实现对所述目标对象状态的更新,则所述根据所述服务器的实时时间在所述更新开始时间以所述更新频率对所述目标对象进行状态更新,包括:
在所述第一时间点与所述第二时间点之间的第三时间点,获取所述第三时间点与所述第一时间点的第一时间差;
将第一目标对象移动到所述第一时间点的位置,所述第一目标对象为所述目标对象中的任意一个;
从所述第一时间点开始,以所述第一时间差为时长对所述第一目标对象进行本地更新。
11.根据权利要求10所述的方法,其特征在于,所述方法还包括:
当位于所述第二时间点时没有收到由服务器发送的更新数据,获取所述第一目标对象的目标操作,所述目标操作为所述第一时间点时所述服务器向所述第一目标对象输入的控制操作;
根据所述目标操作对所述第一目标对象的运动进行本地更新。
12.一种帧同步装置,其特征在于,包括:
第一获取单元,所述第一获取单元用于根据目标对象进行状态更新的实际耗时获取服务器的计算压力信息;
确定单元,所述确定单元用于根据所述第一获取单元获取的所述服务器的计算压力信息确定所述目标对象的更新安排,所述更新安排包括目标对象状态更新的更新频率和更新开始时间;
更新单元,所述更新单元用于按所述确定单元确定的所述更新安排所指示的所述更新开始时间和所述更新频率对所述目标对象进行状态更新;
发送单元,所述发送单元用于向客户端发送所述确定单元确定的所述更新安排,以使所述客户端在所述更新开始时间以所述更新频率对所述目标对象进行状态更新。
13.一种帧同步装置,其特征在于,包括:
第一获取单元,所述第一获取单元用于获取服务器发送的更新安排,所述更新安排包括目标对象进行状态更新的更新开始时间和更新频率;其中,所述更新安排为所述服务器根据所述服务器的计算压力信息确定出的所述目标对象的更新安排,所述服务器的计算压力信息是服务器根据所述目标对象进行状态更新的实际耗时获取得到的;
第二获取单元,所述第二获取单元用于获取服务器时间,所述服务器时间为所述服务器的实时时间;
更新单元,所述更新单元用于根据所述第二获取单元获取的所述服务器的实时时间在所述更新开始时间以所述更新频率对所述目标对象进行状态更新,以便与所述服务器保持对所述目标对象的同步更新。
14.一种计算机设备,其特征在于,所述计算机设备包括:交互装置、输入/输出(I/O)接口、处理器和存储器,所述存储器中存储有程序指令;
所述交互装置用于获取用户输入的操作指令;
所述处理器用于执行存储器中存储的程序指令,执行如权利要求1-7或8-11中任意一项所述的方法。
15.一种计算机可读存储介质,包括指令,其特征在于,当所述指令在计算机设备上运行时,使得所述计算机设备执行如权利要求1-7或8-11中任意一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010053969.0A CN111265854B (zh) | 2020-01-17 | 2020-01-17 | 一种帧同步方法、装置、设备及介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010053969.0A CN111265854B (zh) | 2020-01-17 | 2020-01-17 | 一种帧同步方法、装置、设备及介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111265854A CN111265854A (zh) | 2020-06-12 |
CN111265854B true CN111265854B (zh) | 2021-06-15 |
Family
ID=70990925
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010053969.0A Active CN111265854B (zh) | 2020-01-17 | 2020-01-17 | 一种帧同步方法、装置、设备及介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111265854B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112657187A (zh) * | 2020-12-24 | 2021-04-16 | 北京像素软件科技股份有限公司 | Npc控制方法、装置、服务器和存储介质 |
CN117650866A (zh) * | 2023-11-23 | 2024-03-05 | 广州致远仪器有限公司 | 一种can帧解码方法、装置、设备及存储介质 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011147562A (ja) * | 2010-01-20 | 2011-08-04 | Konami Digital Entertainment Co Ltd | 情報処理装置、情報処理方法、プログラム、ならびに、ゲームシステム |
CN104168274B (zh) * | 2014-08-05 | 2018-11-09 | 广州华多网络科技有限公司 | 数据获取请求的处理方法、客户端及服务器 |
CN106559426B (zh) * | 2016-11-24 | 2019-02-05 | 腾讯科技(深圳)有限公司 | 一种基于帧同步的数据处理方法和服务器以及客户端 |
CN108379832B (zh) * | 2018-01-29 | 2021-03-30 | 珠海金山网络游戏科技有限公司 | 一种游戏同步方法和装置 |
CN109364473A (zh) * | 2018-09-29 | 2019-02-22 | 杭州电魂网络科技股份有限公司 | 游戏举报分析方法及系统 |
-
2020
- 2020-01-17 CN CN202010053969.0A patent/CN111265854B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN111265854A (zh) | 2020-06-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111265863B (zh) | 一种目标对象的位置纠正方法、装置、设备及介质 | |
CN108379832B (zh) | 一种游戏同步方法和装置 | |
CN111265854B (zh) | 一种帧同步方法、装置、设备及介质 | |
CN108022286B (zh) | 画面渲染方法、装置及存储介质 | |
US10319065B2 (en) | Intra-frame real-time frequency control | |
CN106302679B (zh) | 一种虚拟对象移动同步方法、客户端及服务器 | |
CN110662238B (zh) | 一种针对边缘网络下突发请求的强化学习调度方法及设备 | |
CN111167116A (zh) | 一种平滑显示的方法、终端和计算机存储介质 | |
CN110521203B (zh) | 多头戴式显示器虚拟现实配置中的显示调步 | |
CN111061560B (zh) | 云渲染资源调度方法、装置、电子设备及存储介质 | |
CN106162214B (zh) | 视频编码方法及视频直播客户端 | |
JP2006260565A (ja) | プロセス・スレッドのアダプティブ・パーティショニングを用いたプロセス・スケジューラ | |
CN106484528A (zh) | 分布式框架中用于实现集群动态伸缩的方法及装置 | |
CN108310766B (zh) | 数据处理方法和装置、存储介质、处理器及终端 | |
CN116389831B (zh) | 一种基于云原生的离线渲染系统及方法 | |
CN109460297A (zh) | 一种边缘云游戏缓存和资源调度方法 | |
KR20240052091A (ko) | 그래픽 처리 유닛 자원 관리 방법, 장치, 디바이스, 저장 매체, 및 프로그램 제품 | |
CN111767146A (zh) | 一种基于网络重配置的分布式机器学习系统加速方法 | |
JP5866077B2 (ja) | 情報管理方法及びデバイス | |
EP2535860A2 (en) | Method for synchronising character information according to data-type classification | |
CN111632382B (zh) | 游戏数据同步方法、装置、计算机及可读存储介质 | |
CN110941404B (zh) | 激光打印机的共享打印方法及系统 | |
CN112398957B (zh) | 服务器的调度方法和装置、存储介质及电子设备 | |
US20230033785A1 (en) | Remote image processing method and apparatus | |
CN117138329A (zh) | 基于分布式的虚拟游戏设计系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40024154 Country of ref document: HK |
|
GR01 | Patent grant | ||
GR01 | Patent grant |