游戏设计知识分享笔记-依赖性
飞鱼丸的个人博客建成啦，欢迎大家参观！点击传送原文
前言
在构思一个新游戏时常常会有许多想法，诸如不同的挑战、系统以及界面，完整的游戏常常会包含上百种机制及子系统，在已经构思好许多子系统后，紧接着我们要开始游戏的开发，现在我们有以下的选择
- 最简单的模块
- 最擅长的模块
- 最具特色的模块
- 常常能听到的核心玩法
绝大多数游戏开发者都会建议从核心玩法开始开发，但是为什么要这样做呢？
游戏开发顺序的影响
当我们为某个已经完成的游戏制作几个额外关卡时，开发的顺序无关紧要，关卡之间并不会相互影响，但制作游戏并不一样，不同设计之间常常相互依赖
当我们修改某一个模块时，依赖于该模块的部分必然也会发生变化，例如，假设最初开发时先完成了场景布局，设计了一条玩家无法跳过只能从桥梁通过的河流，完成场景布局后，为了优秀的视觉表现，把桥梁设计的十分精美，河流周围的景色也十分美丽，但是在随后的开发中发现玩家的跳跃能力不够灵活，需要增强玩家跳跃能力，导致了原本设计无法跳过去的河流可以跳过去了，就得再修改场景布局，同时依赖于场景布局的视觉表现也需要再重新制作，若能够再开发前对不同模块的依赖性有更深刻的理解，我们也许会先确立移动体系，随后再去进行场景布局和视觉表现。
如何确定游戏开发顺序
我们可以通过画依赖关系图，来分析识别设计中关键的依赖性，从而确定开发顺序
- 将游戏分解成许多独立的因素，包含机制，操作，界面，子系统等等，每个因素应包含一份详细的设计方案。
- 识别出各个因素之间关键的依赖，并通过树状图的结构将所有的因素囊括进来，通过连线来描述依赖关系。
TIPS:对A模块进行修改时会影响B模块时，便可称B依赖A，在设计中常常会出现A与B之间互相依赖的情况，事实上任何设计之间都会存在一定的依赖关系，在依赖关系图中会有意忽略依赖性较弱的部分，以便开发时能够更加专注于最重要的元素，时刻记得依赖关系图只是帮助开发进行决策的工具，无止境的拘泥于过于细致的分析只会导致项目难以推动。
额外需要注意的地方
原创的不确定性
原创度较高的游戏常会出现不按照设计方案来实现，这种不确定性使得依赖性变得非常重要，某个设计中出现的不确定不足以说明问题，然后由于依赖性的存在，不确定性会因为多层依赖的存在逐步积累，因此位于依赖关系图顶层的内容常常重新设计，甚至直接被删除。
应对措施
重新梳理最初的依赖关系图，将短期内不会实现的内容以及相互独立的设计灵感放置于设计库中，将底层的内容实现并测试再进行迭代，此时并没有依赖关系的存在，因此并不会产生巨大的不确定性积累，等到底层系统确定性足够高后再将设计库某一内容添加进来。
TIPS：可以将最初版所有内容包含进来的依赖关系图中拿走但不会使游戏毫无意义的内容全部拿走，剩下的就是核心玩法，核心玩法常常可以用于定义某一游戏的类型，尽早完成核心玩法的开发，可以让项目尽快开始进行测试及迭代。