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

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

希望文笔能被您get到~

1. 业务交流

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

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

对接策划

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

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

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

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

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

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

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

合理： 采纳即可。
不合理：总结好不合理点以白话形式沟通反馈即可