游戏程序员应具备的几种技能

1. 做好事务记录

2. 快速反馈

3. 快速开发(RAD)

4. 选择专业化方向

5. 靠数据决策

6. 掌握一些套路

一. 做好事务记录

方式：装个有道笔记，或者印象笔记，或者简单点，搞个本地的txt文件都可以。

1). 记录好TodoList，避免遗忘。

经常遇到这种情况：针对正在开发中的功能，策划口头跟你提了一些要求，过了几天来问你，‘做完了没有？’，‘哎呀忘记了’，版本计划延误。

2). 记录好每天做了哪些事，周末进行review，再制定下周计划。

一方面督促自己完成周计划；另一方面对自己一周的生产力有个大概的掌握。

3). 有什么思维闪光点，马上记录下来。

整一个专门记录奇思妙想、头脑风暴点子的文档。

二. 快速反馈

这应该成为开发人员的基本素养。

现象：在项目组群里，经常遇到QA喊：‘服务器初始化失败，帮忙看一下’、‘客户端崩溃，谁帮忙看一下’、

‘xx功能不正常，谁帮忙看一下’，然后，过了许久都没人回应，如果是小问题，最后可能不了了之。

心理学家早就知道，人在群体情况下，会有两种现象：责任缺失、冒进。

上述例子就属于‘责任缺失’的情况，要求一个群体负责，最终可能无人负责。

我的解决方法，分三步走：

1). 开发人员看到自己相关的问题，快速认领，在群里打1。

哪怕你知道了、已经在处理了，也要给予反馈，程序员往往懒的回复，这是不合适的。

这样做有两个好处：

告诉大家已经有人接手处理了，其他人不需要重复处理。

形成一种团队形象，给外界的印象是，这个团队响应是很快的，处理问题是靠谱的。

2). 3分钟内无人认领，QA按照事先定好的顺序表，找到对应的开发人员处理。

要做到‘责任落实到人’，持续跟踪处理情况。

3). 如果问题处理好了，再回复一条：‘xx已处理’。

让直属上级和其他团队成员都知道，问题已经处理好了，不需要再跟踪了，忘记它吧。

如果没法处理，需要外部帮助，也要给予及时沟通和反馈。

三. 快速开发

大部分开发人员都是‘业务开发人员’，属于‘开发组’、而非‘研发组’，首要任务就是‘业务开发’，那么生产效率就是一件很重要的事。

1). 开发各种工具和编辑器

以此提高整个项目组的生产效率，不光是程序的

比如Excel导出工具、技能编辑器、任务编辑器、过场动画编辑器等；有了编辑器，原本非得程序员完成的工作，可以交个策划美术了。

2). 利用脚本（推荐Python）完成日常机械化的操作

比如打包发布脚本（如果谁还在纯手工做版本，我也是醉了，我们10多年前有个项目就是这样的）

3). 利用脚本进行自动化测试

比如机器人压力测试，日常回归测试等。

能够减轻测试人员压力，提升幸福指数。

4). 利用好各种工具

作为一名侠客，在江湖上混，怎能没有一件称手的兵器？

如果你是做UI的，那么TexturePacker是一个很好的东西。

如果你用vs开发，那么应该要看一看《快速编码 高效使用Microsoft Visual Studio》

如果你的工作跟图形引擎有关，那么应该掌握PIX、Intel GPA、GPUView

如果你经常烦恼在硬盘上找文件，那么推荐安装Everything

如果你为编译大型C++项目而烦恼，一定要安装Incredibuild

如果你想知道进程访问了哪些文件，Procmon是个好帮手

四. 选择专业化方向

如同我们进了大学，要选择专业一样。

现实情况是：

绝大部分程序员没有专业性；绝大部分程序员是以语言划分专业的。我是做C++的，你是做java的。。。

这就会产生一个问题，年纪大了，性价比较低，竞争不过小年轻；要价高，精力差，你能做的应届毕业生也能做，你有什么优势？如果35岁之前不转管理岗位，或者手下没有一支亲信部队，很容易找不着好工作；工作是肯定能找到的，但你不太可能成为核心成员。我们经常收到一些40~44岁左右的人的简历，一看到这样的简历，我们第一感觉总是：这人还能不能加班？跟我们之间会不会有代沟？面试官产生这样的疑问很正常，等你到了这样的年纪，你是否也会面临这种尴尬？

为什么会这样？作为一名技术人员，最常见的原因就是：没有专业性。通俗的讲，‘没有哪方面做的特别好，各方面都很平庸，遇到难题解决不了’。你可能确实有一些经验，但是这些经验写下来估计还不到两页纸；这些‘经验’很简单，没什么技术壁垒，新人很快就能掌握甚至超越你。

解决方法是：

选择若干方向，钻研下去，要有深度，让别人不能轻易替代你。

由于人的精力是有限的，你不可能什么都会，至少选择一个方向吧，哪怕偏门的也可以。

这个过程确实很痛苦，没办法，竞争太激烈了。

五. 靠数据决策

现实情况是：

经常面临这样一些问题：

平台反应创角转化率偏低，是什么原因？

导量阶段，玩家反映服务器延迟很高，快点看下。

客户端今天怎么这么卡？

为什么这个月收入跌了这么多？

我们找不到是什么原因，或者回答不出比较准确的数字，往往是“我不知道”、“我觉得大概是这样”、“可能是这里有问题”，无法定位问题，也无法决策。

为什么我们经常束手无策，一脸懵逼？因为我们缺乏数据。有了数据，小学生都能决策。

解决方法是：

建立数据反馈、收集、统计的机制。

我觉得，应该主要掌握两种数据：

1). 用于统计分析的数据，便于下一步决策。

2). 系统实时运行的数据，便于定位和解决问题。

想想：

游戏项目上线前夕，为啥要做后台？

大型电商搞活动期间，如何掌握系统运行情况？

交通部门如果对全市道路没有任何监控措施，会面临什么样的窘境？

飞机上没有任何仪表，飞行员如何了解飞机飞行状况？

军舰上没有雷达，会变成什么样？

六. 掌握一些套路

现实情况是：

1. 面对复杂的系统，往往不知所措，不知道如何切入。

2. 或者面对一些新技术，学起来很费劲，不能快速掌握。

拿起一本书，从头看到尾，低头死命的啃，啃完也就这样，脑子里一团浆糊，知识点难以形成体系。

解决方法是：

对于第一类问题，其实很多系统、或者功能模块，都有‘常见的组成架构’，并且都有‘常用的分析方法’，

通俗的讲，都有一些套路在里面；掌握这些套路，分析起来就容易了，你会觉得豁然开朗。

比如客户端帧数低的问题，通常就从3个方面去考察：CPU、GPU、总线带宽。

比如客户端防Hack的问题，也有一些常用的打法：加壳、通信协议加密、花指令、内存混淆、关键数据放到服务器验证、不定期更换通信协议等。

比如客户端渲染效果该如何分级，得先知道有哪些渲染步骤：折射反射、场景、角色、UI、后期。场景里面又有哪些组成部分：天空盒、地形、植被、水、场景物件。掌握了这些，才能决定哪些效果开、哪些效果关、哪些效果降低品质。

怎么搭建一个游戏客户端：App框架完成以后，先搞定核心战斗框架、再合入UI库、主界面、主角属性界面、聊天好友公会组队、包裹商店拍卖行。。。

对于第二类问题，掌握这门技术的构成、框架，掌握起来就容易了

比如侯杰先生写的《STL源码分析》中，把STL分为六大组件：容器、迭代器、Allocator、算法、仿函数、配接器。

按这个思路再去学习STL就更清晰了，而不是一直搞不懂，为什么容器参数里还要带个Allocator参数？stack怎么会用dqueue来实现？

掌握一些套路吧，套路多了，行走江湖就不怕了。