从通用后台开发到游戏服务器开发的经历分享

导语1： 笔者在通用后台开发工作和学习了四年，然后转行进入游戏服务器开发一年（截止2023年），这里分享了一些关于转行的浅薄的个人经历和观点。

      转行的一个重要原因是感觉ai工程领域搞不动了，看不到前面的路。推荐系统、特征平台这些技术虽然非常有趣，但常常它们几乎影响不了产品的兴衰，反而这些技术是很需要产品业务来支持的，最终通过推荐系统来给产品锦上添花。通俗的描述，产品DAU突然翻了几倍，那么与推荐系统的优化基本上没有毛线关系，DAU突然跌了90%那与推荐系统的优化也没有锤子关系。推荐系统需要盘子足够大，普通的产品体验以及运营策略已经优化不动了，那么推荐系统最有效的时刻才终于到了。（仅个人观点，不喜勿喷）

      还有一个重要原因是笔者从小就特别喜欢打游戏，所以特别想去游戏开发领域看看。

      在转行进入游戏服务器开发领域之前，还是挺忐忑的，毕竟之前做的工作基本上是和游戏没有半毛钱关系的。

      大致了解了下游戏服务器会特别注重性能，并且会把一部分服务器逻辑以及很多频繁的计算逻辑放到客户端。此外想着好歹以前也写过几年cpp，一些通用的后台知识肯定也用得上。于是一拍大腿就去面试做游戏服务器开发了。有幸我的面试官知道我没有游戏开发经验，故而也没有考我游戏开发相关的知识，顺利的进入了游戏开发领域。

      然后很快体验到了所谓把部分计算逻辑放到客户端的这样的case，有幸基于UE5写了一些客户端代码(服务器逻辑)，把玩了一些，确实很有趣。体验到了写一天代码，晚上开几把游戏和同事一起测试，简直太棒了，恨不得早几年转入游戏行业。

      到现在，大概刚好转入游戏领域一年吧，想着该做个总结了，然后刚好收到个”写文章可以拿积分换福利“的活动。就这么散列的枚举一下游戏后台和通用后台的一些区别吧。

      印象中，最特殊的一点应该是帧同步服务了。大概就是客户端一直发操作收操作，然后服务聚合成一帧一帧的发给所以相关客户端，然后客户端们自己执行这些操作。直到接触到帧同步服务的时候，我才焕然醒悟为啥打个lol掉线了重连之后有个快进的过程。

      当战斗人数特别多或者整场持续时间特别长，我们还是得使用状态同步服务，比如DedicatedServers，我们所玩的3D游戏大地图可能就是多个ds server通过某种方式组合起来。

      这个直观的感受被上升之后，大概是游戏服务器需要把大量其他玩家的数据在变化时主动推送给很多玩家。比如放个群体攻击技能后范围内的玩家都掉血了。而帧同步或状态同步是实现该能力的主要方式。

      还有一个比较特殊的地方，应该就游戏的战斗core了，在线pvp服务器和客户端都会跑这个战斗核心，pve或者离线pvp则可能只做抽样验证。这也和进入游戏领域前了解到的知识对应起来了，游戏会把很多计算逻辑放到客户端进行，而计算量最大的应该就是战斗相关的了，客户端接受帧同步服务转发的指令，然后直接跑core就可以避免大量网络传输了。当然也可能没有战斗core，比如战斗逻辑都在状态同步服务里跑，那服务器和客户端就不需要跑战斗core了。不过，一般还是会有一些公共的逻辑是服务器和客户端共用的，这种时候可能会抽出这段逻辑放到专门的地方，以便服务器和客户端共享。这里也涉及到了跨环境编译兼容问题，因为这部分公共的代码是需要在服务器（Linux）和客户端（Windows或者说Unreal Engine

https://www.unrealengine.com/zh-CN）编译和运行的。

      游戏服务器除了少部分服务外，大部分是有状态的。这一点挺手生的，以前写过的都是无状态服务，天然的可以用微服务来组织然后部署在容器上，可以很方便的进行负载均衡、扩容缩容等。游戏用户的数据量会很大，一登录就需要把各种历史数据加载上来，并根据用户操作在内存中进行各种状态的更新，虽然舍弃了一些运维维护方面的灵活性，但性能确实可以高很多。既然是有状态服务，那么断线重连将会是非常复杂的逻辑，玩家可能在各种不同的状态中断线，要恢复不是容易的事情。需要分类讨论各种状态，有些该恢复并清理，有些该继续。接触到断线重连逻辑的时候，我才明白为什么有些渣渣游戏，我好不容易把人打残血，然后网络波动了一下就给我移到大厅了。估计是那游戏断线重连不好做（狗头）。总之断线重连做的好，玩家游戏体验会好很多。

      此外有个很特殊的点是游戏服务器开发，有很多东西可能是特化的，不讲究通用，估计在其它领域也用不了，以追求更高的性能。这一点我挺喜欢的，大学的时候打过acm竞赛那时就有个“手写的定制化的肯定比通用的性能”的概念，后来在通用后台开发领域，做各种事情要考虑很多的可扩展性相关的设计，经常在可拓展性和性能之前权衡纠结。其实我一直都很怕过度设计，之前也遇到过一些有点过度设计的例子，所谓的这样写很通用，以后发生什么需求变更的时候，我们可以怎么怎么样快速修改或者不用修改，但实际过了两三年这些设定的伏笔也没有用上。不过有时候最开始设计的时候可扩展性强一点，之后确实也可以省很多事。可扩展性、性能、现有工作量之间的权衡，估计每个程序员都有自己的一杆秤。总之设计很通用的东西很有趣，但做一些特化的优化也特别有趣。

      还有一个个人感觉的差别是，开发游戏特别的快乐，设计任务系统、装备系统、战斗服、匹配服等的逻辑，然后去把代码写出来，然后打游戏测试，特别快乐。以及大版本上线前一星期基本上大家都在打游戏看看能不能跑出什么bug来（其实主要是好玩[狗头]）。并且玩其他游戏的时候，也常常突然就懂了，它的底层设计应该是balabalabala的。

      未来的游戏开发之路还很漫长，与诸君共勉！

后记：这里也感谢“腾讯游戏学堂”对于笔者文章的收录。