游戏服务端实习小结

实习基本情况

最近在某公司实习了两个月，两个月实习主要实现一个mini项目。我们的项目是2d俯视角射击游戏，安卓端的，前端使用unity3d，后端使用skynet。
人员配置为两策划，一前端，两后端，一测试。时间大约为期10周，我们一共做了5关的单机关卡加一关的联机关卡。
虽然实习面试的时候都在面C++，但是实际来了发现要学lua + skynet。花了大约两周时间。接着编写了导表工具后才正式开始游戏服务端的编码工作。个人主要实现了登录注册，云存档，以及一个简陋的帧同步。

项目使用框架

项目使用了skynet作为底层架构，上层使用lua进行编写。传输协议使用protobuf。

架构设计

整体架构参考了skynet的example。如图

每一个Agent对应一个玩家，不过这里有点问题，应该通过LoginManager登入后才能分配Agent。这样做法会更好一点。

游戏同步

由于是第一次做游戏同步，说实话做出的效果挺差的，最致命的原因是unity自导的物理引擎碰撞产生的不同步。其中还涉及到前后端对接，调试的问题，加上时间只有两周多一点。实际编码时间其实很少，大多数时候在讨论两周内可以实现的同步方案，以及留出部分时间debug。

这是我觉得挺有挑战的一件事，首先前后端都没做过同步，从最初一开始同步的概念都很模糊，这时隔壁小组做的是3D回合制的pvp，我们也过去交流了一下，他们采用的是直接同步角色位置的方式，碰撞检测依旧在客户端做，但是伤害计算在服务端计算。

我们没有考虑相同的做法是因为游戏类型不同，我们的游戏是双摇杆射击类型的，即时性比较强，短时间内会有大量的子弹射出。一但出现不同步就gg。并且我们右摇杆操作也比较难处理（右摇杆涉及到两种武器，拳与枪，并且摇杆拖到轮盘内是一套操作，拖到轮盘外又是一套不同的操作，并且这些操作还会与左摇杆组合）。如果直接同步这些信息我觉得对我们游戏而言状态过多，并且客户端表示写起来比较难受。

所以我们使用比较传统的帧同步，也就是同步摇杆的操作。虽然在做之前已经预感要踩挺多坑，但是实际上手后发现坑是一个跟着一个。

在一开始，我有提议做状态同步试一试，在服务端做一个碰撞的检测，但是被策划以及客户端他们否决了，原因是难度以及不确定性太高了。因为做碰撞检测绕不开一些问题，物体穿越了怎么办？如何将unity的平面地图转换为数据等问题。最后决定放弃状态同步做帧同步。

在做帧同步时，我最担忧的问题就是unity的物理引擎导致的不同步，很多网络上的案例都是自己实现一个物理引擎来避免这个问题。后面将最小demo做出了后果然踩到了这个坑，只要角色不停怼门的边缘（碰撞），就可能出现不同步问题。并且大多数方案比如，预测回滚，提前预判等一些商业游戏使用的技术我们没办法实现。后面和策划商量改了需求以及玩法。

但除了碰撞以外还有好多问题，比如多个客户端发帧频率无法控制，不同步后如何补救等，都是大坑。

接口对接

与前端的接口我们用了三套，因为都没做过，都想做一做对比一下效果如何。
我们用了明文，json，proto三种协议。在最后用下来发现用proto最为舒服。因为只需要定义好proto文件就可以减少前后端扯皮，至于为什么不用json，是因为我认为json是文本的，而proto是二进制的，游戏同步有个小点是需要避免分包，所以需要控制传输内容的长度，所以我更倾向于二进制协议的proto，并且proto支持的格式也远多于json。

总结与感想

挺深刻的一次实习，体验了一次游戏制作的全部流程，虽然实习前半部分都在学lua+skynet，但是后面就开始越来越有意思了。无论是与策划，客户端的扯皮都让我感到很快乐。每次讨论都有新想法产生，或者是想法被否决。最后作品也拿到了小组中的第一名，白嫖了个小米手环，血赚。