【解决方案之道(一)】高阶游戏架构师进阶历程

D小游

文/邪让多杰

通常，一名程序员在进入岗位后，很快都会进入到一个工作上的良性循环中，这个循环算是一个程序员的通用工作流程，有了这个流程，能够让我们一直保持进步，并很好的完成工作任务。

首先会有项目提出自己的需求，在游戏设计领域中，通常就是某个系统的策划案。然后我们开发人员去分析这个策划案，看看是否有需要学习的技术点，如果没有，就可以直接上手，如果有，则经过一定的学习与查询后，完成这个功能，最后交付测试。

在整个游戏的开发周期内，通常我们就会经历这么一个流程：

1、 Demo阶段架构核心玩法

2、初期完善核心架构

3、中期扩展其他系统

4、后期根据商业需求进行增删改

如果我们将这个循环看做一个节点，我们就会得到一个恐怖的增长趋势，随着项目的进行，这个节点的被执行次数就越来越多。对应的，我们加班的次数，反复迭代，修改的次数也就会越来越多。

在实际生活中，这样的结果会导致什么样的现象？

1、 程序员们疯狂的加班

2、抱怨策划需求更改频繁

3、 系统维护成本高昂

4. ...

当然，这几个流程中的节点根据实际情况也有可能会改变，不过再怎么变，节点被循环的次数逐步增加，是大部分项目所遭遇的“痛苦”。

那么，别人是如何做的？那就是“解决方案”。

一、解决方案是什么

在百度百科中，有对解决方案的这么一个解释：

如果我们把它提炼出来，就意味着，在项目开发初期，我们就需要考虑到：

1、 已经的问题

2、预期的问题

3、 预期的需求

4、预期的维护方案

5、等等...

也许这里，读者的脑海里会想到：“这不是废话吗？这与一开始的流程有什么区别？”

同样的流程，不过在解决方案的思维下，多出的绿色部分就是与平日我们流程所不同的地方，我们需要在架构功能之前，就需要思考更多的问题。

同时，另一个重点就在于原本的流程中，我们往往学习与研究的是项目技术点，而到了解决方案思维中，研究的对象就成了作业流程。（指从开发到运行到维护的整个流程）

二、举个例子

抽象的提到解决方案，读者可能会一脸懵逼，不知道这个作者到底想说明什么。这里我就讲它进行一定程度的具体化。

策划提出了一个需求：“我需要在场景中布置怪物”。

年轻的司机同志就会立马开车，花费了几个小时做出一个布怪功能，然后交付给策划。

而老司机，则聪明的在开发前，与策划提出了一些自己的疑问：

1、不知怪物需要朝向？

2、怪物出生条件？死亡事件？

3、怪物是否分阵营？

4、 是否有具体的参数需要针对单个怪设置？

5、等等..

老司机称号代表着他是一个有故事的人，这些经历沧桑岁月的记忆，就是这名老司机存活下去本钱。这样的行为，在解决方案的思维中，就是“已知问题”。

老司机在开车之前，会去思考当前要做的功能是否有一些“已知问题”存在，把它们考虑进去，以避免前面所说到的循环节点狂增，后期维护成本太高的问题。

这时，老司机与策划确定完了那些已知问题，也想明白它心中的架构，正要着手去设计时。

老船长，出现了！

老船长之所以能在海面上航行一生而不落难，凭借的不仅仅是丰富的经验，也就是已知问题。还有他对大海与船只的熟悉程度，每一次航行前，都对将会遇到的问题做好充足的准备。

回到办公室里，老船长看到了策划案后，又对提出了更多的问题：

1、布置的流程是否容易？（优化作业）

2、是否可以搭建从美术=》策划=》产品的流程，中间程序不参与？（甩锅）

3、功能扩展是否容容易？（降低维护成本）

4、系统是否支持线上维护能力？（热更新，留后路）

5、是否还需要开发剧情模式？

6、 等等...

老船长开船了，果然放个屁都充满了大海的味道。在解决方案的思维中，这就是对“预期问题”的设计，是一开始就有的，而不是像老司机那样遇到了，才去提出问题。

三、解决方案的适用度

当老船长把这些问题摆出来后，问题变复杂了。

在我早期的程序工作中，面对这样的问题，会被一些经验丰富的老司机们告知：“敏捷开发，初期就不要考虑那么多，先做就好，初期考虑了那么多东西，你就做不完了，复杂了工作量。”

当时以我的能力来说确实无法在一个项目的初期完成这样高复杂度的设计，但随着开发经验的积累，以及对需要开发的游戏设计的领域知识的熟悉，在开发初期去思考并着手准备这些复杂的问题，就显得并不那么困难，通常来说，也是更划算的。

这也就说明，解决方案是需要一定的条件的：

1、丰富的经验（经历过完整的项目周期）

2、对领域的熟悉程度（不仅要懂程序内容，策划的内容也要理解。）

这是解决方案之道的基础条件，对于开发者个人来说的。

而对于项目来说，大部分项目“能实现出来就已万岁”。所以不以解决方案的思维去进行项目也成了一种习惯。

但对于那些开发周期较长的A级以上的游戏，如果我们依然不采用解决方案的思维去进行项目开发，就会产生极高的后期开发与维护成本。（作者已在此路含恨，一定要记住：项目越大，越需要一开始考虑清楚）

四、解决方案系列文章

接下来，作者就会边学边分享，解决方案之道是如何在游戏的各个模块中被实现出来的。

这里面我会分为“技术点”与“解决方案”，为了避免重复造轮子，通常情况下我会先写“解决方案”，如果遇到技术点在Gad中没有相关文章的，那么我也会停下来去完整这个技术点的学习与分享，反之如果在Gad中有相关的技术点文章，我会将它引用出来。