前言

几天前已经在计划写日志，但是怀揣着好奇心打开《潜水员戴夫》之后……沉迷了一天半。

这次原先计划想先谈谈“思路”，然后借着“思路”顺势谈“未来”。这个“未来”，指的是我在进入社会的十年里，在不同的人生节点中是怎么看待那个阶段认知里的“未来”，而最终那些认知与现实产生的偏差与成因。但是担心字数太多导致阅读体验变差，所以还是缩减话题变为只谈“思路”。

这次聊一聊思路，不从具体的方向聊，而是从几个微观视角进行分享。

依然是胡说八道（叠甲），欢迎分享自己的理解。

思路

RTS的思路

最近一个月的娱乐活动，竟然成了看HBK08打红警，这件事的趣味程度远超日番和美剧。不仅如此，我甚至不会跳过08视频里的任何一个片段。

08视频的趣味在于其打红警时的思路异常清晰，观摩他博弈时的思路，常常能让我产生一些新的思考。

因此，让我对RTS有了更深的理解。

RTS与其他游戏技巧难度的不同点，在于玩家的信息获取能力，以及快速应对能力。

比如多线应对：主动发起方与被动防守方应对考验的方向是不同的，主动发起方更像是出题人，最大程度地消耗对手的精力。被动的一方需要快速应对，在有限的时间内化解对手的题目。

比如发起者一边在主战场拉扯，一边依托游走部队打击对手后方的资源单位。在此情况下，被动方需要同时应对两个难题：

1. 在主战场拉扯
2. 需要想办法处理后方的问题

这个时候进攻发起方具备很强的战略控制优势，因为发起方可以选择撤退而被动方不可以。被动防守方要避免出现这种局面，往往需要提前获取对手的信息以及动向。又或者同时给主动方出题，削弱对手的精力。

所有操作的目的，本质上都是在消耗对手的时间和精力。然而人类的操作是有极限，是故多线解题会有一个上限。而上限溢出的部分，最终会转换为对应玩家的优势。

精力消耗殆尽的标志，就是玩家开始手忙脚乱。

高手的应对是多重嵌套的，解题的同时还会伴随出题。出题的过程与玩家的信息探索同步发生，解题人需要提前侦测到对手的出题过程，否则解题会变得困难。比如看到对手出飞行兵的时候，就要准备防空手段。而在多家混战中，第一个飞行兵能同时消耗多家的资源。（对手需要暂停原来的计划，转而准备防空。）

理论情况下，玩家的操作线程是无穷个。因为对手的影响，这些线程会被打断。一旦精力消耗殆尽，就会回归单线操作。

以上是观测08打红警，个人得出的总结。而顺着这个话题，谈谈自己在RTS上的一些心路历程。

第一个阶段：形式的追求

时间要拨回2004年，彼时冰封王座的资料片推出了小半年，并在网吧的硬件配置更新后得已流行。

当时上的附属中学，5点下课后可以直奔网吧，于是打《魔兽争霸3》顺势在初中同学里形成一股小热潮。

那时候玩游戏的时间远远不像今天这样溢出，坐在电脑面前恨不得立刻开始打游戏，至于如何去查攻略应该怎么打好游戏，压根不会去考虑。当然，只是对我而言。

班级里一些富裕的同学往往有更多的电脑使用经验，顺理成章就开始上网看别人怎么玩魔兽。于是他们成为了RTS技巧的布道者，给我们阐述他们对游戏的理解，关于双线操作与微操等等。

并由此带来非常好笑的现象——游戏高手的指标不是输赢，而是通过玩家的切屏操作和微操数值（APM）来确立。

因为小鬼普遍嘴硬，输了也会说是故意让了一手。而对战的过程常常互有胜负，在没有数据统计的前提下，谁更厉害这件事，就成了吹嘘切屏和APM。

最终网吧里的画风就转变成了奇怪的方向，每个人都在想尽一切办法提高手速还有切屏。至于输赢？反正嘴巴肯定不会输。

第二个阶段：无形的实现

前几年DOTA时代的老朋友忽悠我去玩DOTA2，希望我能带他们在排位赛上脱坑。谁曾想竟输个不停，于是开始在排位的过程中走歪，玩起RPG地图。

这个地图传承自老时代的生存类RPG：玩家扮演一名幸存者，与其他玩家一起击退一波又一波的敌人，在防守的同时需要分兵去维修电场与呼救中心，完毕后等待救援，最后胜利通关。

最初游玩时我们有四五个人，随着一次次在最后关头失败后，其他人都兴致缺缺，最终只剩下我一个人。

于是这张地图就成了我一个人的竞技场，我开始思考一个人怎么通关。

在游戏中，玩家有时候会从资源中获取机器人部件，通过这些部件可以组装一些弱小的机器人单位。

在多人游戏里，人物资源往往都是稀缺品，玩家的背包尚不能够装满，这就导致花费资源制造出这些机器人的性价比极低。

而SOLO的情况就发生了微妙的变化，游戏里的资源开始溢出，用于武装这些破烂机器人绰绰有余。

由于之前的无数次失败，个人对整个地图流程都非常清晰，于是我开始尝试着使用机器人替代队友的路径。

在一次次的失败中思考多线操作，从最开始的手忙脚乱变成精力盈余。为了消耗这些盈余的精力，开始制造更多的机器人展开更多线的操作，最终得已一个人通关。

当通关以后，才意识到少年时代求而不得的多线操作，竟在无心之中得已实现。

思路与线

双线（三线）与多线实际是两个概念，我常听到周围的人吹嘘自己当年如何双线操作，现在老了手速跟不上。以前我会相信，但在实现多线以后便不再相信此类说法。

原因在于双线与多线实际上是两种不同的思路。

少年时信息闭塞，只能从同学的布道中获取信息。那时候讨论的双线操作，指的是一个人同时操作两条主线，一条建造，另一条战斗。为了实现这种“双线”，需要来回切屏快速操作，故而微操的数值极高。

于是游戏的技巧变成比拼动态视觉和手速，真正核心的游戏数值却无人关心。

在这种双线思路下，大部分的操作都是低效甚至无效。

处于这种盲目追求形式的环境中，所有人都在走偏。直到后来某天，隔壁班一个低频操作的同学用随机种族数十种流派血虐了我们班的各个“长老”以后，魔兽的热潮才开始消退。

何谓线？

双线三线四线，可以称之为n线，而多线与之有极大差别。

n线的线是“线性”，而多线的线是“线程”。n线是同步的，而多线是并行的。

所谓的线性指的是连续性的操作，玩家开了一条线以后要时刻关注这条线的发展，这也就造成了反复切屏带来的损耗。

而线程并不是连续性的操作，其仅在必要的时候发出指令，剩下的交由单位自行处理。

举个例子，在执行n线时，玩家需要建造的同时切换到战场操作战斗，然后又回到建造的部分继续建造，如此往复在两线操作。多线则不是，多线在给单位一个战斗指令后，便不需要操作，而是专注其他的部分。这样便能节省切屏的精力，同步下达更多的指令开辟新的线程，节省下精力后实现高效的操作。

n线与多线的不同点：

• n线讲究玩家的反应速度，多线讲究玩家对游戏整体的理解。
• n线极大的消耗精力，多线能够最大的节省精力。
• n线的重点在操作的细节上，多线的重点在于思路的清晰上。
• n线不需理解游戏，多线需要从一开始就对游戏有很深理解。
• n线关注一兵一卒，多线常常会不小心就失去一兵一卒。

从理想状态看，n线是完美的，只要人的大脑能够同步思考，就相当于对手需要同时面对几名玩家。这种理想状态散发的美感，很容易导致小鬼们的狂热崇拜。而多线是肮脏的，因为不管不顾一定会有损失。这种一眼就能让人看到“缺陷”的技巧，并不能让羸弱的小鬼觉得这是一件很酷的事情。

然而，人天生就是有缺陷。

天然的缺陷

如果以单一技术的身份在职场待得够久，一定会跟我一样有一个疑惑：产品经理为什么提需求的时候，不能动一动他的猪脑子？

有时候PM的新需求，甚至会导致自己白忙活了一个月。每当这种时候我都会想，存不存在一个完美的产品经理，能够分析清楚所有的开发需求以及流程，并以此分配给组员获取最大的开发效率。

带着这种疑问，我抽出了大把的业余时间着手学习产品经理的知识，想要摸索出一种完美的设计、开发文档。

（当然，这是不可能的，因为人不可能具备先验性。产品经理如果能够拿出一个没有差错的文档，那么最大的可能是因为这个项目已经存在。）

我开始分析和总结一份完美的文档应该具有的特征：

• 变量名统一，不需要一开始就赋值。产品经理在修改变量名时，代码与资源文件同步修改。
• 项目需求一定都有源头，而不是靠拍脑门产生。
• 阅读性高，让组员能够加入其中。
• 快速检索功能，方便查阅和修改。
• 模块化，分离度高，方便替换。
• 细化，能够清楚任务的完成度，顺势能够在甘特图上展开。
• 与协同软件关联，在文档上添加描述时，协同软件会同时增设一条任务清单。

既贪心又to young

在实践中发现这种做法非常臃肿，除非整个开发过程非常静态，否则将会掉入反复修改文档的漩涡之中。

尝试失败后我转变想法为专攻UML，在实践中发现这种想法依然存在的严重的弊端：能写好UML必须具备丰富的开发经验，如果已经具备了丰富的开发经验，UML却又不是一个必需品。

最后又转为老传统，流程图与原型设计。这个辗转反复的过程就与我少年时对双线操作的经历一摸一样——因为理解不够，最终流于追求表面的东西。

正常人类的内存是有上限的，想要管理好信息溢出的方法，不是依靠记忆，而是模块分离和具体细化的技巧。

流程图

最近因为写的文档字数超标，内容又大多由闪念汇集而成。闪念的集合往往意味着凌乱，这就导致想要整理文档的时候，思路一直处于混乱的状态之中，于是这段时间又开始思考设计文档应该怎么写这件事。

早年对于UML实践失败后，还试着使用Visio搭配Office套餐进行项目管理，但最后同样陷入了修改文档的漩涡之中。

那时没有好的思路，常常会把流程图绘制成庞大的蛛网。最后在开发中，发现很多预设信息都是没意义的。

这次着重思考设计文档里应该存在的几个点

• 文档的目录应该是怎样的？
• 如果想依靠单独的设计文档解决开发，如何同时解决设计与机制的表述？
• 传统的设计文档带有冗余性质，有什么方法避免？

说来惭愧，我经历的项目从来都没有像样的文档。哪怕是头衔很厉害的Boss，写出来的文档也跟小学生写出的内容差不多。唯一看起来“像样”的文档，是软件开发结束以后为了投标匆忙套的模板。

那么文档不重要吗？

文档很重要，文档是第一轮自我拷打的过程，很多想当然的东西会在这一层失效。

设计文档最大的核心是针对自身的业务而书写，个人现实所见或者网上能查到的文档，大部分都会添加无意义的内容在里面。又或者说，这类文档的目的不在于设计，而在于“表演”。这就如同我上文提到的RTS多线操作的误区，看起来厉害但只能武装表面。

而文档中一些看起来重要的部分，比如世界观、角色、场景之类，实际又是冗余重灾区的部分，劈里啪啦写上一大堆。问其意义何在，答曰故事的必要。基于这种理解，文档很快就会变成填充式的工作。

那么，文档的目录应该是怎样的？

我现在的答案是针对流程图而写，而不是从网上找一个看起来厉害的然后生搬硬套。

流程图就像RTS的多线，只有对整个游戏了如指掌才有可能接触到最核心的那一部分。而那些在游戏逻辑流程图以外的内容，他们不应该存在于设计文档之中，比如受众和市场之类带有商业性质的内容。

在此基础上，设计文档可以更大胆一些，比如写上自我问答的标注。例如某个地方为什么这么设计，他们可能存在的潜在问题，以及对应的解决方法。如此，便能进一步排查冗余的设计。

后记

最近开始尝试使用Draw.io，发现Draw.io更符合立项时的设计思考。（兜了一圈又开始走别人几年前走的路）

其所具备的便捷操作外加图层分类管理，能够在快速设计时专注单一模块。

技术文档和开发文档是互相纠缠的，并不是先有一个再有一个。在这个互为表里的设计过程中，可以同时对双方进行加减法设计。比如在技术文档里写了怪物的战斗逻辑，通过这个战斗逻辑，逆向发现设计文档里还可以加入更多有趣的怪物。

同样的，因为知道机制的设计，那么在写设计文档时，会非常清楚一个新的功能是否有必要，又或者思考如何使得不同的对象之间产生关联，于是就能够心安理得去做减法。

流程图的设计核心在于模块分离，虽然很久以前就知道设计原则需要专注轮廓而不要钻进细节的重要性，但实际上在项目经验不够的时候，对模块的理解很朦胧，这也导致分离的边界感很差，最终一头钻进细节里而不自知。

（模块的思想不单单在程序里，在绘画或者音乐领域也能大显身手）

这几年开始对自己的决策完全承压以后，思路同时发生了巨大的转变。