前言
在游戏设计中，思考方式本身不存在孰优孰劣，但在某些应用场景中，更适合的思考方式能够更容易得出更健壮的结果。
本文无意争论思维方式的好与坏，只是分享一种思考的方式，供设计师们参考。
什么是结构化思考？
我所认为的结构化思考更多是一种将事物本质进行结构分类，以及将各部分结构之间联系梳理清楚的思考方式。
以一个简单例子说明，在一般游戏公司中，
一般会把负责游戏设计的人员称之为“策划”，
负责美术制作称之为“美术”，
负责游戏实现称之为“开发”，
同样的还有运营市场等等······
这种划分方式叫做组织“结构”划分，这其实就是典型的”结构化“分类。
将事物本质按照特定的逻辑关系，分类成不同结构，并且将结构之间的逻辑联系梳理清楚，这就是我所理解的结构化思考。
当然，按照上述例子而言，每个结构之下可以继续进行细分分类，譬如策划可以分为系统、数值等，只要有需要，理论上可以无限拆分。
那么何时为思考完成呢？
因人、因事而异，当设计者认为当前结果已经足够完善即可。
怎么用 —— 以房间系统为实例
回到正题，那么在游戏系统设计中，如何利用结构化思考呢？
我个人而言会从三点去进行：
- 按照一定逻辑关系拆分结构。
- 简单将结构联系起来（不需要太精准）。
- 深入拆解结构之间的数据的输入输出。
- 基于第三步的结果，进一步优化结构或者生成有必需的分支结构。
- 重复上述2,3,4步，直至结构以及结构之间的联系是足够精准的。
上面几点有不说人话的嫌疑。
下面以一个简单游戏系统，房间系统为例子，讲述整个过程。
先说房间系统的需求，用相对浅显的语言描述就是，
“房间是为汇集不同玩家成一个个小群体而提供临时场所，它提供的是玩家进入游戏前的过度”。
但实际上，这依旧是一个相对模糊的需求，怎么样的“”不同玩家”？不同玩家是怎么样分类的？需要怎么样的过度？过度是为了什么？
梳理问题，以及解决问题，可能这本身就是设计师的工作。
让我们开始吧。
首先，先分析需求的本质，房间目的是为了分类不同玩家，让符合一定标准的玩家更好地一起进行游戏。
那么，第一步，房间系统的主体结构可以拆分为：
第二步，简单将结构联系起来。
结构相互之间关系为，用户进入到房间，房间将聚集好的用户输入到战斗中，战斗完成后，将结果反馈到用户当中。
这里的结构之间联系肯定是不够周全的，但先从最明显的关系出发。
第三步，深入拆解结构之间联系。
先从用户—>房间开始，用户是以怎么样的方式进入到房间呢？
对于房间来说，用户的进入，可以理解为不同的用户数据输入，这部分数据需要按照一定标准进行分类，目的是把玩家分成不同群体，每个群体即为一个房间。
这里需要一种对用户数据的筛选处理方式，一般情况下有下面三种，
匹配：按照一定规则，将用户特征相符合的玩家聚集在一起；适用大部分公平竞技游戏。
房间号：提供房间号，将输入相同房间号的玩家聚集在一起（好友邀请进入同理）；适用于个性化房间，即方便玩家自由组队。
房间列表：玩家建房间，客户端提供可用房间列表，其他玩家进行挑选；适用于有模式或者地图选择的游戏，如CSGO。
一般情况下，如果没有对整体结构有清晰认知，房间系统的设计往往约等于匹配系统设计或者房间列表设计，执着于具体的筛选方式。当然，这部分或许是整个房间系统最重要的部分，但是也只是一部分，一个完整的系统需要完整的闭环。
经过筛选后，符合条件的用户就会变成一个房间，房间需要输出房间数据，而不符合要求的玩家，则需要驳回到用户。
根据上述思路，我们可以得出以下结构：
第四步，在第三步的思考的基础上，实际上需要一分支结构。
思考到这个阶段，很容易就出现了疑惑，单纯把玩家聚集在一起，就足够了吗？
但实际上很多情况下，玩家进入到房间，实际上还有非常多操作需要进行，譬如在MOBA游戏当中选择英雄和技能等。
既然用户有相当大的一部分数据是需要在房间内进行的，因此这部分房间数据实际上需要返回给用户，用户再进入下一个阶段，我称之为用户准备阶段。
用户完成准备阶段后，实际上是将房间内的用户个人数据、房间信息、准备流程数据一起输出到游戏战斗中，战斗模块根据该部分信息生成战斗。
根据上述思路，我们可以得出以下结构：
根据游戏种类的不同，用户在房间内的准备流程各不相同，流程基准是能够产生生成战斗所需的必须数据信息。
第五步，需要从第二步开始，重复2,3,4步，继续深化结构与结构之间的联系。
当房间完成其任务后，自然将其输出的数据，输入到游戏战斗模块当中，去生成战斗。
此时要做的是，深化房间—>战斗的联系。
战斗模块各不相同，实际上只要保证生成战斗的必须数据，房间能够提供即可。
可得出以下结构：
同理，继续深化战斗与用户之间的联系。
当战斗结束后，产生的结果需要给予用户反馈，譬如谁胜利了，拿了多少分等等，这些可能在战斗流程就完成，但也有可能需要在战斗外处理。
除了结果外，战斗还会对现有信息产生一些变更，如用户的个人信息（KDA，胜率，常用枪支角色等等），这些数据，需要用户系统自行进行处理。
可以得出以下结构：
当思考到这一步后，我们继续重复第四步，有可能的分支漏了吗？
一个非常明显的问题，战斗结果的信息需要返回给房间吗？房间部分需要战斗的一些信息吗？
实际上，是需要的。房间在战斗结束后，需不需要根据结果的数据，保留房间还是销毁房间？房间内的角色是否缺失了？房间内的阵营这些信息会影响玩家准备阶段吗，还是直接可以带入到下一盘当中？
显然这些疑问都需要战斗产生的结果信息反馈到房间当中，所以实际的优化结构是：
战斗反馈结果到房间的结构是：
在此为止，整个房间系统就完成自我的系统闭环，可暂时视为已经完成结构化思考。当然，因为是介绍限制，在实际使用中，还可以继续对结构进行深化，直到达到自己认为完善的标准。
在达到自己认为完善的标准后，就可以对结构中每一部分进行深化了，譬如，到底是用匹配规则还是房间列表方式，用户数据有哪些，组成房间后，内部准备流程是怎么样的等等······基于结构进行详细设计的过程，会使整个设计脉络更加清晰。
总结 —— 结构化思考的优缺点
结构化思考并不能直接得出一个完整的系统，可做的是将整个系统骨骼搭建起来，为之后的交互规则、具体机制设计提供支撑。
对于一些十分熟练的设计师，可能稍显浪费时间，但结构化思考是存在一定价值的，下面将会总结一下结构化思考的优缺点。
首先，谈谈优点。
- 比较易懂，清晰，好用，**起来没烦恼。无论是主策还是实际设计落地的设计师，基于整个结构化进行讨论（**），都会更加有效率。在系统设计前期，讨论太多的交互细节容易扰乱其他人思维，同时，清晰的系统结构确定后，会极大减少返工的可能性，这一点无论是实际设计，还是实际开发中，都很重要。
- 逻辑点不容易漏。在结构化思考的过程中往往比较容易查漏补缺，就像上述房间系统需求当中，在深化结构与结构之间的联系过程中，往往能够排查出思考过程少了的部分。
- 扩展性强。当以后有新的需求需要加入时，可以很清楚了解新需求应该加入到哪一部分当中，结构的哪一部分变更了，从而更加直接找出需要变更修改的地方。
- 系统排错能力强。当实际验收过程中，发现错误时，大部分错误能够根据结构流程，快速找出其导致错误的原因，脑海里会比较清晰了解到底是哪部分结构卡壳了导致现有问题。
当然，这种思维方式肯定存在缺点。
- 只适合确定性比较强的游戏功能系统，对创造性需求较强的结果效果比较弱。对未见过，认知比较少，或者需要较强创造性的需求时，效果不好，特别是游戏艺术部分，但对一些确定性比较强的部分，譬如好友、公会等系统，结构化思考的优势就会显然易见了。
- 思考容易受限，特别是在结构化基本成型后。思考的边界往往摆脱不了现有已经成型的结构，这也是为什么结构化思考不太适合艺术创作的原因，突破思考边界的最有效的方式往往是交流。
- 结构一旦出错，往往都不是什么小事。这个，可能不用多说了。
结论：
我很喜欢埃隆·马斯克所提倡的“第一性原理“思考的法则，我认为结构化思考的本身就是第一性原理思考的延伸。
结构化思考带来的是整个系统的设计支撑，它本身不会直接输出一个完整的结果，如果说游戏开发是基于设计者的设计图，去开发整个系统，那么结构化思考更多是”设计图“本身的“设计”。
如前言所描述的，在游戏设计中，思考方式本身不存在孰优孰劣，但是合适的思考方式，帮助我们更容易的得出更周全的结果。希望这次分享的思维方式能够帮到你，也希望能够交流不一样的思考方式。
我是三季人，欢迎关注游戏设计思维（知乎号、微信号同名）。
笔者是游戏从业者，专注于游戏和游戏设计，欢迎交流互喷，一起共同成长。
一片赤诚之心，致我们热爱的游戏。
Steam 
App Store 
闽公网安备 35020302034348号