游戏服务器开发思维养成建议与规范

前言： 本人在2021年校招就业于广州一家大型游戏公司，并做了游戏服务器相关工作，本文将记录下磕磕笨笨的自己在这一两年工作中遇到的小例子，并阐述自己认为的服务器思维与工作交流的规范。

希望文笔能被您get到~

1. 业务交流

刚入职的我是十分胆怯的，最怕的就是说话吞吞吐吐的，让他人get不到你的点，最终造成沟通不当浪费他人时间。
这次我将以不同职能同学的沟通交流做例子分别来阐述。

一般服务器同学对接的职能有（策划，客户端同学，你的服务器朋友们或者导师， QA质量测试保障同学）

对接策划

1. 首先我们作为程序，要知道策划想要什么东西？

举个例子：策划说我们做一个队伍招募的需求，这时不要认为他想要的就是队伍招募，可以想一想或问一问他的需求目的（想降低玩家组队成本，让玩家快速组队, 这才是他真实想解决的点），
他是为了什么目的设计的队伍招募需求。

可以说：目的是想降低玩家组队成本，让玩家快速组队。 而需求设计是：队伍招募， 这种理解可以在我们开发不能满足需求时（这需求接不了）知道策划的痛点在何处，你们可以battle另寻可实现的需求（虽然我没经历过另寻需求这个过程，但明白策划痛点是可以增进彼此理解的）

2. 假如你在上一步接取了策划的需求，要认真评估策划需求的实现点

这里策划的需求实现包含的一般是： 提供的配表规则与逻辑（文字或者流程图）实现。 有部分策划喜欢把逻辑实现细节全给程序暴露出来（确实方便了程序，但也懒惰了作为开发者的我们）如果深陷其中，我们往往得不到提升，建议我们get到策划需求的各个点后自行判断我们自己实现起来的合理性即可（大概思考下什么时机有什么数据要修改，有什么和客户端的交互），不要深陷其策划的逻辑规则，毕竟他们不懂现有真实的代码逻辑结构，我们跟着他们的逻辑实现走很容易被误导编写一些难维护的晦涩代码夹杂在已有的逻辑结构。

• 最优先的评估点在与思考服务器压力：我们需要先站在全服的角度初步思考策划的实现可导致的IO与存储压力（比如某个需求点存储的东西过量，在某一时刻IO的内容过多）。
• 其次评估改动逻辑对现有项目逻辑造成多大的冲击，代码修改成本如何，时间安排是否合理。

比如一局大逃杀游戏，需要记录下助攻或者击杀的玩家的妆容信息和服装信息用于结算显示，我们知道妆容这种信息一般都是需要存盘的，且需要在结算那一刻同步给客户端，而妆容信息是非常大的，（我经历过的项目一个玩家妆容记录有约4000 * sizeof(int)) 可以想想击杀一个就记录一个是有多夸张， 而且还需要同步数据给客户端。。），这个点我get到后及时反馈给了策划，然后商量了一阵子，采取了让客户端存这个妆容数据，服务器存击杀基本数据，掉线的话就不显示妆容（让UX同学做了个数据丢失的显示），可以说很多问题及时沟通是很容易配合解决的，如果硬着头皮做服务器挂掉或者压力大责任就扣到你头上了。

合理： 采纳即可。
不合理：总结好不合理点以白话形式沟通反馈即可，能当场解决就解决，不能解决策划还硬做直接找服务器主管商量，把锅甩出去。

3. 与策划交流不要谈实现，谈需求本身即可

对接客户端程序

我们作为服务器程序，实现策划需求时，最先做的就是规划数据结构的合理性，并确认与客户端的交互逻辑接口是否行的通。

在思考好初步设计后，一定要自问一下，这样设计的好处是（直观简单易维护）？ 代价风险是（几乎没有还是存在隐患）？一旦后续出了问题或bug，你的师傅或者主管找上门来，一定要解释清楚，如果吞吞吐吐，他们会认为你这是乱做的，没有什么思考。。。。

举个例子：发布招募的这个功能如何与客户端对接。

1. 基本： 我们看到策划需求文档后一般我们要规划好发布招募的接口供客户端RPC远程调用，
并在发布成功/发布失败后告知回调RPC接口， 其次还要规划好发布招募的参数信息结构定义， 之后将接口和数据原型定义发给客户端同学，各开发各的，互不影响进度。

2. 其次： 一般团队都会有UX交互同学规划客户端的交互文档，因为交互文档和策划需求文档在需求描述上非一致性，一切以最终交互文档为主，（不过交互文档一般慢于需求文档），当我们按策划需求文档做完后需要浏览交互文档验证是否自己的代码逻辑交互和交互文档保持一致，不一致要尽快补充接口，避免后续客户端同学找上门来~~~~

经常遇到的小事情案例

1. 别人来问问题，也可能是他自身的角度不能考虑周全的，有他未知的东西，我们问下其真实需求是什么，往往能给出最好的答复。

对接过程，经常会被客户端服务器同学问这个接口能不能做什么什么等等，很多时候回答会让他们感到很为难，比如他们感慨到如果不能这样的话那就很麻烦拉，之后他们又进行思考来问其他方面行不行等等，直到问到他们想要的结果或者他们拜托我去做一个接口才完毕，，，啊，，，好麻烦，最后发现被他们带偏了，其实他们的需求只需要用已有的东西就能做，因为他们不知道有，，，，，，因为经常和有经验又温柔的师傅坤哥询问交流，我从那里学到最直接的方法就是一句话“请问你的需求是什么？“，需求就是他们的痛点，你知道他们的痛点就能给出很好的回复，而不是被他们的组拼式完成目的带偏，才能更好的配合他们。

2. 既要站在别人的角度想问题，也不能深陷其思维，容易产生不必要的疑问，常常想是我我会怎么做，其实最终会发现，大家其实想法都差不多一样的，过程中有不同处其实没必要死钻。

上次和坤哥导师对一个需求点实现，其实我俩想的实现一模一样，但坤哥无意间说了具体实现过程，我对其描述产生了疑问，觉得有点错误，然后我俩就硬钻了5分种，发现只是描述上有参差，我俩想的一模一样，坤哥告诉我，大家对同一个实现的描述可能不尽相同而且说起来都会有小错误，不要死钻，在他说了需求大致实现，我直接说我明白他意思就行了。

2. 业务开发

开发初期

理解策划的需求本质 转换 为 程序的实现本质 是基本。

在脑子里把策划的需求转换为初步实现，比如发布招募本质就是把 要发布的招募数据放到全服的存储区，然后每个人都能拿到就行了，中间涉及一些与客户端表现的交互。这样一理解是不是轻松多了觉得这需求，尽管实际是涉及到全服的东西做起来都比较困难，不过你心里已经有需求实现的流程图了。

当你拿到一份需求文档：

1. 细看捕捉要点
2. 发现疑问要记录， 反馈给策划确定是否是自己的理解情况

开发过程

规范：

• 编码规范（PｙｔｈｏｎPEP8,　C++　Gｏｏｇｌｅ Sｔｙｌｅ），以及我们项目用到的各类架构规范。
• 日志记录步骤状态，日志记录以自己查该函数的问题时能否利用上为标准，记录有用信息。
• 操作基本数据记得封装，对一类常用基本行为做封装（很多增改需求都需要ｈｏｏｋ住这个事件，在之前做处理，之后做一些处理，不封装直接用改起来头皮发麻）
• 按文件划分功能模块，如果该功能模块影响到其他模块请用事件广播形式传递到其他模块。
• 如果有类似实现的业务功能，虽具体业务不同，但其内核思想是一致的，说明该实现是比较通用的，可以抽象成一个工具块。
• 服务器永远不做保底代码，比如本已经出现的问题，因为一重登触发到保底代码，给修复了，这属于隐藏逻辑ｂｕｇ，有ｂｕｇ要早修而不是惯性存在保底思想。

优化：

－全服玩家公共缓存要做，成本低，效益高。
－懒人思维，仅用时做处理（缓存？？）

制作过程：

1. 做一块的业务，一定要摸透这一块的上下文，直接改是行不通的，因为缺乏熟悉度，不关注上下文细节，会出现很多bug。
2. 考虑前辈们已经写好的业务架构，不要总想着自己再搞一套，这样代码是非常难以凝聚和维护的，前辈们的架构已经不支持你的需求时，请优先迭代架构做扩展，而不是搞一套新东西。
3. 其次考虑下自己的实现能不能 进行热补丁修复（很重要的点），如果策划改了表格或者东西，能不能及时热更到。
4. 接口是接口，实现是实现， 接口是给别人用的，别人可任意扩展，实现是比较原始的，自己维护好原始操作， 例如

def AddItem(self, item_id, count, extra)   这个是接口，其他人可通过extra进行接口扩展
   #
   接口扩展
   ...................................................
   #
   self.AddItemImp(item_id, count)

def AddItemImp(self, item_id, count)  这个是原始实现，仅自己可删减（牵一发动全身）
	

5. 版本上面要注意，任意一个服务器的svn版本都应该不是中间版本， 都应该是可运作的版本。
6. 接入其他类似SDK的服务时，务必想好其他服务阻塞到自己怎么办

测试

1. 编写测试指令方便你和QA同学

GM指令要尽可能模拟真实的玩家操作过程，而不是一昧去改数据。我们的一个功能往往在在处理数据后有一定的逻辑规则需要处理，就很容易导致ｑａ同学认为这个逻辑没触发导致的地方有ｂｕｇ。

查BUG和修BUG

只有BUG能提高一个人解决工程问题的上限。

BUG意味着有缺陷，不把这一块弄熟你是改不动也修不动的。

1. 严查版本，太多太多多版本导致的bug了，让人头大，但这是无可厚非的
2. BUG要评估好影响面，不要给他人造成麻烦，有bug不修逃避是非常错误的，不管是小bug还是大bug

3. 内功

1. 看东西前先思考自己做如何做，再去看别人的实现。