炸弹人游戏的网络功能,有两套方案,但都是用的TCP:
1>类似于棋牌游戏中的网络,简单,正确,但对网络要求较高。
不考虑延时问题, 服务器直接转换所有的客户数据就行了,没有数据就发送心跳。
游戏中的最小时间单位是帧,而每帧的驱动都是倚赖于服务器发送的数据. 因此回放其它玩家的数据
的时候不会有任何问题.
2>类似于一般网游方式,复杂,有误差,但对网络要求较底。
游戏中的时间是人类时间,因此可能会有误差. 每次更新是一个固定时间,大约100ms左右.
期间必须把里面的数据按照时间进行排序,再发送.然后再进入下个100ms状态.
这时如果有非当前100ms的数据被接收则直接丢弃。
游戏也是需要服务器驱动的,但是每次是100ms,而不是上面说的一帧.
假如一个客户端在10 x 100ms的时间内都没有接收到任何有效数据,则断定该socket中断。
因此,客户机在没有数据时,也要发送心跳数据.
而在这一100ms内, 客户机中的数据与介面是分离的。介面还是按照上100ms的数据进行(预测),
主要是移动与动画等。而当服务器数据来了的时候,介面再根据当前数据进行更新。
因此,有时你在网游上看到人物明明走到N远,突然会被拉回来就是这么回事(预测失败)。
可能有的问题:
网络中的数据由于每次传送的量很小,因此有可能会阻塞在SOCKET的系统缓冲中,如果是这样的话可能就白白的浪费了20ms的时间.因此可能需要自定认缓冲算法.因为目前的SOCKET,似乎没有类似flush这样的方法吧?
1>类似于棋牌游戏中的网络,简单,正确,但对网络要求较高。
不考虑延时问题, 服务器直接转换所有的客户数据就行了,没有数据就发送心跳。
游戏中的最小时间单位是帧,而每帧的驱动都是倚赖于服务器发送的数据. 因此回放其它玩家的数据
的时候不会有任何问题.
2>类似于一般网游方式,复杂,有误差,但对网络要求较底。
游戏中的时间是人类时间,因此可能会有误差. 每次更新是一个固定时间,大约100ms左右.
期间必须把里面的数据按照时间进行排序,再发送.然后再进入下个100ms状态.
这时如果有非当前100ms的数据被接收则直接丢弃。
游戏也是需要服务器驱动的,但是每次是100ms,而不是上面说的一帧.
假如一个客户端在10 x 100ms的时间内都没有接收到任何有效数据,则断定该socket中断。
因此,客户机在没有数据时,也要发送心跳数据.
而在这一100ms内, 客户机中的数据与介面是分离的。介面还是按照上100ms的数据进行(预测),
主要是移动与动画等。而当服务器数据来了的时候,介面再根据当前数据进行更新。
因此,有时你在网游上看到人物明明走到N远,突然会被拉回来就是这么回事(预测失败)。
可能有的问题:
网络中的数据由于每次传送的量很小,因此有可能会阻塞在SOCKET的系统缓冲中,如果是这样的话可能就白白的浪费了20ms的时间.因此可能需要自定认缓冲算法.因为目前的SOCKET,似乎没有类似flush这样的方法吧?