服务器调度频率问题

最近在做帧同步的PVP时遇到一个问题。在当初设计的帧同步方案中,服务器是以恒定每秒30帧的速率向客户端广播当前的双方的操作信息的。客户端也是按照每秒30帧的速率来处理这些信息,从而推进游戏逻辑的。这个方案双方速率一致是很重要的,如果服务器快了,客户端就要快进,如果服务器慢了,客户端就要等待。服务器方面我们是通过设置一个定时器来驱动这一部分逻辑的,这个定时器的间隔就是1000 / 30 ms,取值33或者34在个人电脑(Win7)环境下,都是能正常1秒能执行30次的。但部署到服务器环境(WinServer2012)下,定时器间隔无论设置33ms还是34ms,最终1秒都只能触发21次左右,如果把值设得更小,例如30,就会变成1秒执行32次,但无论设什么值都无法准确的1秒执行30次。

一开始在外网虚拟的服务器下发现这个问题,以为是虚拟机导致的,后面换到自己的物理服务器上(WinServer2008) 还是有这个问题,就开始考虑是不是服务器底层调度有问题,但后来通过一些测试发现是系统的问题。

Continue reading

《格鲁夫 给经理人的第一课》

这本书是英特尔的创始人安迪格鲁夫根据他在英特尔的20年管理经验写成的,大部分内容是面对中层管理者的,虽然年代以及实际生产环境跟现在的互联网企业有所不同,但其中大部分的内容还是能给我们带来很大的启发。这篇文章主要是我自己站在互联网企业游戏开发部门负责人的角度来理解书本提到的管理概念的一些记录。

首先这本书提出了要梳理生产流水线。重新审视流水线上每一个环节,找出制约环节,设定生产中每个环节的指标,提早安排测试,合理计划生产量等等关于具体生产线的工作原则。貌似与互联网企业的开发部门关系不大,但其实基于这些理念我们也能重新审视我们自己的团队。因为我们团队里的每一个工程师,其实就是生产流水线上的每一个环节。梳理生产流水线其实就是梳理我们团队的开发情况,一样会有薄弱的模块或者人,对于每个模块或者人也同样可以设法提高成产力,设定更具体的指标,提前安排测试验收,从而保证整体的产出及质量。

Continue reading

随机数生成算法 —— 线性同余法

最近在做帧同步的实时对战,要自己接管随机数的产生,所以看了一下随机数生成的相关算法。因为游戏会跑在不同平台(iOS/Android)及不同硬件上,所以使用的算法有以下的要求:1. 不能依赖系统;2. 不能依赖硬件;3. 计算中不能使用浮点数(不同平台不同硬件有可能结果不同)。再结合效率方面的考虑,最终选择采用了线性同余算法,并在基础上做了一定的加强。这篇博客主要记录关于这个线性同余算法产生随机数的一些思考。

首先要搞清楚随机数的定义,真正的随机数都不是计算出来的,这里我们说的随机数其实都是伪随机数,随机数伪随机数的定义,具体的论证等资料可以自行查阅。产生伪随机数的算法有很多种,线性同余算法基于整数的加、乘和求模,算法简单但是具有较强的规律性与周期性。怎么在这个基础上尽量降低规律性与周期性,使得在更广范围内覆盖更多可能就是我们的目标。

首先要了解的是线性同余函数公式,最终结果受乘数λ,加数C和模数M决定。M通常我们会使用一个较大的素数,而λ,C的选取在很大程度上会影响生成的随机数的质量。我们尝试使用不同的λ与C去生成一系列的随机数并观察他们。为了直观感受一些列的随机数是否足够随机,我们用这些数字作为X,Y填充一张1024 * 512的位图,观察图上的点的位置,可以得知这一系列随机数在1024 * 512范围内随机分布的情况。 Continue reading

记2018年做的两个游戏demo

2015年-2017年的创业经历在之前的博客中有聊到过,在上一款产品《侍灵》上线反响一般的情况下,我们公司被盛大游戏(也是我们原来公司的天使轮投资方)收购了。进入2018年后,我们全部人变成了盛大游戏的员工,开始了新游戏的研发。第一款做的游戏是按照动漫《七大罪》来制作的,时间应该是1月份到5月份,完成了两个角色的核心战斗以及登录、主城和一两个系统,后面因为版权不确定的问题放弃继续开发了,留个视频以作纪念吧。视频密码:2018

从《侍灵》转到这个《七大罪》的demo开发,首先面临的是从2D到3D的转换,不过依托于Unity的Animator抽象,其实过度并不需要花很大功夫。在卡通渲染方面程序与美术一齐花了一些时间去尝试,最终出来的效果也挺有动漫感觉的。demo最大的特点应该是依托于Unity2017推出的新功能TimeLine做的剧情动画与技能特写表现,这些给整个战斗体验加分了不少。 Continue reading

计算机网络——传输层:TCP与UDP

传输层与网络层一齐构建成了网络协议层次的核心。网络层解决的是计算机与计算机之间的通信问题,而传输层解决的是进程与进程之间的通信问题。传输层架构在网络层提供的服务之上,把数据传递服务从两台计算机之间拓展到两台计算机上的进程之间。因此,在传输层通信除了IP之外还需要有端口号来确认是与目标计算机上那个进程通信。与网络层类似的,传输层也提供了两种服务类型。一是面向连接的TCP传输,另外一种是无连接的UDP服务。所以要了解传输层的细节,就是要了解清楚TCP与UDP的细节。

UDP:用户数据报协议(User Datagram Protocol)为应用程序提供一种无需建立连接就可以发送封装的IP数据报的方法。UDP传输模型可以类比为邮递方式,发送方在发送之前无需建立连接,只需要知道接收方的地址(IP和Port),然后把数据报发送出去后,由网络自行路由,最终能否到达目的地,什么时候到达,发送方是不会得到反馈的。UDP除了提供发送数据包功能之外,几乎没有做任何事情,使用UDP传输的时候应用程序应该自己组织策略应对丢包、乱序和数据出错的情况。

TCP:传输控制协议(Transmission Control Protocol)是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。TCP传输模型可以类比为打电话,通信双方在通信之前必须先建立连接(IP和Port),然后在这个连接上收发数据,通信结束后要释放连接。TCP采用的是全双工连接,表示可以在两个方向上同时传输数据。为了提供可靠的端到端字节流传输,TCP在内部实现了丢包重传、乱序重排、校验数据的功能。此外TCP还实现了一个重要功能——拥塞控制,会通过一些数据来得知当前网络情况,在网络情况不好时降低发送速度,在网络情况优良时提高发送速度,从而让整个网络达到一个高效状态。正因为TCP实现了上述这么多的功能,所以TCP是Internet的主力军,大部分网络应用采用TCP传输数据。

想要真正了解TCP协议,就必须了解TCP应对网络不可靠情况做的策略。而要真正用好UDP,也要在一定程度上自己组织策略应对网络不可靠的情况。所以要了解传输层,用好TCP/UDP的核心就是了解要面对的情况及一些相应的处理方案。 Continue reading