一种不那么草台的游戏制作方法

本文系用户投稿，不代表机核网观点
⚠️ 未经作者授权禁止转载
1. 前言
年前最后一天上班的时候，我收到了公司另外一个项目组的Demo，和Demo一起的还有一份调查问卷。 
试玩Demo和写反馈应该是一个非常常见的事情，但是在我现在工作的公司里，这两件事情是非常罕见的。三年前加入现在的公司的时候，我认为这是一个充满创造力的，有生气的公司；三年后我仍然认为我所在的公司充满了创造力，但是生气——似乎被一次次的项目失败所打消殆尽了——我不知道其他几个项目的制作人或者公司的老板是怎么看待的，但是这是我的真实想法。
一个由艺术家领导的公司，内部分布着几个十人左右的，同样由艺术家气息浓厚的制作人领导的团队，带来的好处是显而易见的：有想象力，审美趣味良好，创意天马行空。三年前我认为这是独立游戏的天堂，三年后我发现了这背后也有着一个巨大的“艺术气息”陷阱：如何把项目落地，制作出来一个好玩的游戏。
目前我所在的公司的这种模式拥有一个明显的特色：因为似乎没有资金压力，导致每个项目的周期极长。如果有合格的制作人，那么这是一个十分巨大的优势，简直就是每个独立游戏制作人的梦想模式。但问题是，如果没有合格的制作人，项目必然会陷入无尽的返工和方向变更。十分不客气的说，我所在的公司内暂时没有合格的能扛起来稍微大型的项目的制作人，正因为此，公司几个项目组制作周期长，不是因为精益求精，而是恰恰相反的原因：项目主导者 （制作人）控制不住游戏方向，带来漫长的内容修改时间。
有的时候，我十分希望我所在的公司能够仍然维持做小体量的游戏，最好是五人左右，一年到两年能够完成的游戏体量。这个好处显而易见：能够迅速磨合团队，培养新人，即使失败了，也能很快速的帮助项目制作人成长——体量小，所以能够及时反思更正，调整下一个项目的制作方式。与其五年做一个大项目，肯定是一年一个小项目带来的成长更大。但是很可惜的，我人微言轻，公司也没有合理的反馈渠道，我只能看着几个项目在一个前途未卜的道路上前进（即使我个人十分悲观）。恕我直言，这种制作方式已经接近于赌博了。
另一方面，我也很清楚地能够感受到，公司里对于学院派的游戏设计的不齿，以及对于游戏策划这个岗位（或者任何其他有软性能力的岗位）的轻蔑。我不是一个迂腐的人，我也不相信一板一眼的学院派式制作游戏的方法能导向成功的游戏（能保底一个合格的游戏是肯定的），但我更不相信凭借着直觉就能够做出来惊艳的游戏（我相信制作一个平庸的游戏不是任何人的目标）。工作之余我大量摄入了各种游戏的制作幕后，有开发者的Devlog，有开发者的播客、视频分享，也有文字版本的分享，我可以肯定这些成功的游戏没有一个是纯粹的碰运气碰出来的。正是因为如此，我才会越来越对公司目前的几个项目感到绝望。
我理解公司内的制作人们也一定是迷茫的，所以他们按照自己的方向去做。问题是，既然不确定方向是否正确，为什么不更加频繁的在公司内部开展Demo试玩呢？
在这里，问题就回到了开头：年前最后一天上班的时候，我收到了公司另外一个项目组的      Demo，和Demo一起的还有一份调查问卷。这个Demo已经闷头制作了至少12个月，任何反馈都变得没有意义了——各个部分的方向已定，除了一句“不错，挺好的”，还能给出什么反馈呢？
2. 从各个名词的解释，来解释一种游戏制作的流程
我参加过很多game jam和小型项目，和形形色色的人和项目组合作过。想要解释一种游戏的制作制作流程，是十分庞大且困难的，很多游戏设计的经典教材或者书籍中都花费了很大的篇幅才能够说清楚一种游戏制作的流程。更重要的是，对比其他行业，游戏行业本身十分年轻，游戏理论研究更加青涩，谈论一个“正统的”游戏制作方式无疑是十分幼稚的，何况每个游戏工作室都会有适合他们自己的一套游戏制作方法论。
但是，这些客制化的游戏制作方式中，一定有共通的关键之处。我希望能通过解释一些常见的名词，结合我自己的实践经验，进而尝试建立一个比较科学的关于游戏制作的大致印象。
2.1 Prototype（原型）/Demo/Vertical slice（垂直切片）/MVP
在谈论游戏制作的时候，这四个词一定会高频出现。在我的理解中，他们分别被使用在游戏制作的不同阶段里（从制作前期到制作后期）。并且他们都是为了一个简单但是重要的目的：提前验证，用最小的成本去测试项目的可行性。
2.1.1 Prototype（原型）
Prototype（原型），一个用于验证某一个功能的东西。在任何项目中，这一定是优先级很高的一个步骤。
比如要做多人游戏，那么需要一个多人联机的技术原型，去验证多人游戏是可以被实现的。如果说我想做一个战地的克隆游戏，那么首当其冲肯定就需要验证我们的技术能力能否实现六十四名玩家同时在线对战。如果不能通过技术优化满足网络的要求，那么项目的预算是否能够支持通过堆服务器的量来满足多人对战的条件？
这里可能还会涉及到的情况有，可能项目组的后端能力是满足的，但是美术上无法把画面渲染优化到足以支持多人玩法，那可能就会需要一个包含美术资源的多人游戏原型，用来测试项目的边界情况，例如项目支持什么样的贴图分辨率，每个人物的模型面数最大不超过多少等等。
再比如要做一个无缝开放世界，那么自然需要先有一个相应的技术原型来验证可行性；如果要做一个卡通风格的游戏，那么需要一个技术美术上的渲染原型来验证可行性；如果要做一个    rogue-like游戏，那么可能需要一个地牢生成的技术原型来验证随机生成的可行性；如果要做一个大量对话的叙事游戏，那么先要有一个良好的对话管理器技术原型来验证对话内容的维护或者文本本地化方面的可行性，等等。
可以说，除非你想要制作的游戏是非常轻量和休闲的小体量游戏，否则应该都是需要有原型的。（身边的做小体量游戏的朋友，一款游戏的制作周期也很短，通常三到四个月游戏就从想法到上线了。）

2.1.2 Demo
Demo，组合各种原型，用于向人展示项目可玩性的东西。在完成初步的验证后，接下来经过一段时间的前期制作（可能此时美术资源还是用临时资源代替的），团队应该能拿出来一个  Demo用于展示游戏的初步概况。有的制作团队为了让Demo更能吸引人的目光，可能会先制作一部分完成度很高的美术资源，那么此时这样一个完整的Demo应该要让来试玩的人快速地了解游戏的各个方面：美术风格，游戏的核心玩法，游戏故事的开头等等。总而言之，Demo是项目第一次面向项目组之外的人的游戏包，它是游戏在公共领域的初次登场，直接面向潜在玩家、投资人、发行商、媒体等等。

2.1.3 Vertical slice（垂直切片）
Vertical slice（垂直切片），是一个包含所有游戏中会出现的系统的游戏包。这种叫法常见于正规的开设了游戏设计专业的学校体系，因为从这一类专业中毕业的学生大概率是要进入大型公司制作大型游戏。那么在大型项目中，使用垂直切片的目的仍然是为了阶段性地确认目前项目的方向是正确的（修正方向），确保游戏这个状态是合格的，以便万一出现问题能够在继续铺量进行生产前做出补救。这样的一个游戏包应该包括的是游戏项目的完整骨架，比如：从开始游戏菜单——游戏的核心玩法——游戏的结束——游戏的保存和退出。

2.1.4 MVP(minimum viable product)
MVP，字面翻译是“最小可执行产品”。那么显然一个MVP应该是在游戏制作的中后期才会出现的游戏包，此时可能游戏填量的部分（比如音效音乐，美术动画资源，比如写好还没来得及实现的剧情设计）还没有完成，但是这个时候游戏已经有一个包含核心游玩体验的完整的包体了。我自己的理解就是，如果这个时候游戏已经能够上架了，剩下的未完成部分可以作为DLC上架，那么就代表项目组完成了一个MVP。

2.2 市场调查
对于中小体量的制作团队来说，我认为市场调查中最重要的事情应该是成本控制以及明确市场规模。
成本控制上，要选择力所能及的游戏制作方向，规避掉需要大量成本的游戏品类。比如，我认为应该规避的两个方向：即时的多人在线游戏（网络和服务器问题），需要大量美术资源的3D游戏（美术资产成本太大）。
明确市场规模，就是要能够大致估算出项目所需要的资源，并且要把所需要的资源量和目标游戏市场能够带来的利润做对比。比如我面向点击冒险游戏市场，那对于这个很小的市场来说，在Steam首月能够卖出两、三万份以上就算是不错的成绩，一年能够有十万份以上的销量就是爆款的情况下，如果项目估算制作完毕的成本总和在一百万以上，可以说就是在进行一次豪赌了。梦想谁都有，但是不是每个有实力的人都是那个被好运眷顾的人。这样的投资行为就全看投资人的目的了，如果目的不是盈利而是为了磨合团队培养人才，那似乎没有在这里讨论的必要了。
还有更多的市场调查的车轱辘话我就不再赘述了，很多调查并不适合本就资金紧缺的小型团队。而且我自己认为过度的市场调查一定会导向平均的游戏，那还为什么要加入小团队制作独立游戏呢？
2.3 Game loop（游戏循环）
谈论游戏设计，很容易形而上的走向讨论什么是游戏，在这里我不想也没有能力去讨论这个话题。我更加感兴趣的是更加脚踏实地的设计方法。
那么，以我浅薄的知识来说，让我们假设游戏设计的不同方式可以被放置在一个光谱上，光谱的一端是电影化的游戏设计（极端例子比如交互电影），另一端是纯粹的只有玩法的游戏（比如俄罗斯方块）。在这个光谱中，我的理解是：越靠近“电影化”的游戏，越难以归纳出属于游戏的循环，游戏的结构也越容易用电影化的叙事理论去分析；相反的，越是靠近“玩法”一侧的游戏，越容易归纳出一个属于游戏的循环。

这似乎和游戏的本质有着密不可分的关联。在游戏研究领域中有各种各样的对于游戏的定义，我很喜欢的一个优雅的解释是：游戏是自愿地克服非必要的障碍。我自己更倾向于把游戏看作是一种人类天生的对于和物理环境交互的渴望——劳动。自然的，劳动带来的是客观环境的改变（对于现代的社会化的人类来说，能够在劳动中感受到劳动的结果是一种奢侈），这就是一种最原始的天然的循环：人劳动，劳动带来正反馈，人继续劳动。
所以归纳出一个属于游戏的游戏循环，在我自己设计游戏的一个基本方法论。而分析其他的游戏，如果不清楚游戏循环的概念，我相信也很难有效地做出分析进而学到精华而非表层的皮毛。
举例来说，比如非常电影化的Detroit: Become Human（底特律：变人），基本的循环是：玩家在场景中交互，推进既定的剧情分支，最后进行一个关卡的结算，并且看到全球玩家的对于剧情分支的选择数据统计。
再比如稍微添加了更多“玩”的部分的游戏，VA-11 Hall-A（赛博朋克酒保行动）的基本循环是：玩家开启新的一天在酒吧上班，选择歌曲，给不同的客人调酒（调酒游戏），触发新的剧情，下班结算。
接下来，添加更多的“玩”的游戏，比如新战神系列，一个基本的游戏循环首尾仍然是剧情的推进，只不过中间被动作或者解谜玩法填充。
最后，可能是光谱另外一头的游戏，比如Baba is You（Baba是你），游戏循环更加简单纯粹：打开新的关卡，完成解谜，进入下一个关卡。
而在真正制作做游戏的时候，不难发现的是，越容易归纳出想要制作的游戏的循环，越容易让人理解我们想要做什么样子的游戏。一个游戏的循环也不单单只有一个，可能游戏的每个系统都有相应的循环。
但是，游戏设计真的需要一个循环么？我将尝试在下一个部分回答这个问题。
2.4 Scripted Design（手工设计）/Systemic           Design（系统化设计）
“归纳出游戏的循环”，另一个侧面就是“游戏是否遵循一定规律”。在我看来，难以归纳出规律的游戏设计的重灾区就是点击冒险游戏，这也是一个极好的解释scripted design的例子。
点击冒险通常代表着一种技术上的妥协——限制玩家对于游戏世界的交互。例如早期的点击冒险游戏会限制玩家和环境的交互（如：拿取，检视，使用，交谈，给予）。这些交互行为是一种无可奈何的抽象归纳，显然玩家在游戏世界中的交互难以被这几个动词描述完全，所以玩家会出现一种经典的反应：“为什么我可以和A交互，却不能和B进行同一种交互？”。在更加现代的点击解谜游戏中，例如Machinarium（机械迷城），仍然并且一定会出现的游戏设计是：玩家必须在某处执行某种操作，才能推进剧情进展。这就是我所说的scripted design，而这种设计模式必然会导致玩家感受到一种抽离，既“出戏”。
诚然，这种“出戏”感可以被其他游戏设计方法所降低，比如：限定少量的可以游玩的场景，以降低玩家寻找那个特定的解法的难度。更多的方式不在此赘述，我可能以后会单独写一篇文章阐述一些设计点击冒险游戏的小技巧。
玩家在游戏世界中希望的是：“我可以拿起场景中的杯子，就应该也能拿起差不多大小的盘子”，而不是“我能拿起杯子，是因为这是任务道具，我拿不起盘子，是因为这个盘子根本没有出现交互UI”；“我可以爬进一个通风管道，就应该也能够爬上路边的箱子”，而不是“我能够爬进管道，是因为这是一个剧情动画，我爬不上箱子，是因为这里被放置了空气墙（更可能的是玩家根本没有攀爬的能力）”。
所以，与scripted design相对的是systemic design（系统化设计）。这个设计思路早就出现了，我认为最能体现这种设计的无疑是Arkane的几款沉浸式模拟（immersive simulation）游戏。但是直到2017年的塞尔达，使用这种设计模式的游戏才被更广泛的玩家接触到。
简单来说，系统化设计设计系统，并且尝试把游戏中的内容归纳成类。系统接受输入，改变受到系统影响的类（输出）。比如，玩家拥有瞬间移动的能力，那么这个移动系统如果接受到了合适的输入（比如能力范围内允许移动到的地方/距离），那就应该能够改变玩家的位置；同时这个系统肯定也会关联到场景系统，场景中能够容纳玩家的碰撞盒的空间都应该能够允许玩家到达。这两个系统合起来就是耻辱（Dishonored）系列中的瞬间移动能力。
在这种设计模式中，设计师设计的是规则，而非一个一个去设定玩家能够去到哪里/在什么地方可以瞬移。
更多的例子如：荒野之息中的天气系统配合上地形系统，导致洼地在雨天会积水，而非手工指定哪些地方会有积水；天气系统和元素反应配合，导致雨天火会熄灭，而非手工指定什么时候火会熄灭，等等。不难看出，系统化的设计非常容易导向涌现式的游戏玩法，因为设计师只设计系统的规则，没有指定任何特定的游玩方式。

但是需要注意的是，这种设计模式不是一定优于scripted design。设计模式只是工具，适合的工具才是好工具。如果我在设计的游戏本身就是体量很小的游戏，或者我的游戏本就不追求涌现式的玩法/更高的自由度，那么构建多个系统的规则反而是事倍功半的。根据现实情况结合使用两种设计模式才是更好的设计方法。
所以，回到上一节的问题：游戏真的需要循环么？似乎是不需要的：越是难以归纳和抽象出循环的游戏，就会出现越多的scripted design。这对于有资源支持的公司或者工作室显然是没有问题的，比如Remedy。但是对于独立游戏或者小体量游戏的开发来说，显然应当控制成本，把有限的资源放在刀刃上——游戏循环上。另一方面，越难以被归纳出循环的游戏，    “游玩”体验似乎越接近于一种被动地，电影化的消费体验，即“观看”的体验。我不是在尝试贬低这一类游戏，而是尝试说明，这种游戏体验似乎丧失了游戏媒介本身的特点。制作这类游戏时，可能更加注重的是剧本而非玩法——不提优秀剧本的创作难度，如果要制作这样的游戏，为什么不去制作独立电影呢？（叠甲：当然可以做这样的游戏！但是我自己的态度如此，我必将狠狠地表达！）
2.5 Top-down design（顶底设计）
顶底设计模式即由上至下，由大到小地进行设计的设计模式。在游戏设计中，我认为使用这种设计模式能够十分有效地完成两件事情：明确设计目标，以及便于进行项目管理。在我的经验中，这两点是很多经验不足的团队栽跟头的地方。
设计需要设计目标，而顶底设计模式能够很好的帮助团队明确目标。举一个例子：赛博朋克的世界观特色是高科技，低生活。如果这六个字作为一切设计的最顶层，那么视觉上，故事上，玩法上等等项目各个方面的设计目标都应该向着这六个字靠齐。所以，赛博朋克世界观中之所以出现各种科幻视觉奇观，正式因为要遵循总的设计目标；而到底这个世界观中应该诉说什么样的故事，也需要确保故事要说的主题是和总的设计目标相关的。
同时，由大到小地确定了设计目标后，也就确定了衡量设计好坏的标尺，任何方面的设计才有讨论的空间，否则开会讨论就变成了无主题的辩论会。这也是很多经验不足的团队，开会总是效率很低的原因：无人确定设计目标。最终开会便是徒劳无功的过场（无人拍板）；如果有人拍板，那也是不欢而散，因为做出决定的人没有明确的理由去说服其他人，没有一个早先提出的设计目的。
项目管理方面，顶底设计的优点主要体现在便于把控项目进度。如果设计游戏的过程能够被一层层拆分成小的设计目标，那么我们可以在项目的早期就对于项目整体的体量有一个大概的估计；在项目进行中，我们也可以直观的看到项目进行到了哪里；如果进度偏慢，我们可以方便的看到是哪些部分在影响进度；如果要增加或者删减项目的某些部分，我们也可以很方便地对项目中的各个小的组成部分进行评估。而不是处处凭借感觉——感觉很重要，但绝不能只依靠感觉。
2.6 Concept Design（概念设计）
概念设计是我自己的专业方向。我教授过学生概念设计，也尝试在工作中进行“概念设计”。但是我发现大部分人不知道什么是概念设计，即使是从业者，也对概念设计有很多误解（概念设计就是画草稿），更别提在现在的环境中进行概念设计了。概念设计行业可以说是年轻且不成熟，甚至全世界没有几所学校开设了这门专业。下面我所说的一切都是我自己理解中的“概念设计”。
那么，什么是概念设计？
狭义的说，概念设计是把抽象的文字设计视觉化。概念设计行业的出现也是随着娱乐行业的兴起，特别是科幻、幻想题材的电影和文学作品大量出现，那么这类娱乐行业的最前沿自然是好莱坞。概念设计师脱胎自插画师和工业设计师：从美国科幻黄金年代，给科幻小说杂志绘制封面的插画师开始；到之后为科幻电影设计道具、场景的插画师/工业设计师；再到CG技术成熟，游戏行业兴起，给各个大厂绘制设计稿的概念设计师们——不难发现，最早的概念设计师负责给文字配上画面（那时候还没有概念设计），后来电影行业不单单要求概念设计师把文字画出来，还要确保画出来的东西能够落地，再后来的游戏行业则是要求概念设计师画出来的东西能够满足游戏设计的要求——概念设计是一个很混合的行业，它要求设计师产出的设计满足审美上的要求，也需要满足功能上的需求。

广义的说，设计了概念的人就是概念设计师。J·R·R·托尔金的小说描绘了生动的中土世界，那他其实就是在进行概念设计。金庸构建了一个自己的武侠世界，那他也是在进行概念设计。概念设计师绝不是只会画画的人，概念设计师也绝不是只需要会画画。
举一个工作中的例子，在进行一个游戏项目的前期概念设计的时候，概念设计师需要做的应该包括：根据故事大纲/时代背景确定美术风格方向；寻找视觉和文字参考资料，绘制草图；不单单要测试各个不同的角色服装风格是否满足审美上的要求，也要确保这些服装符合时代背景、人物个性；如果游戏有技术上的限制，还要确保不会给后续其他工种带来麻烦；如果人物在游戏的故事中有前后的变化，还要考虑两个阶段的角色设计是否有足够的对比……等等。而对于场景的设计，要确保游戏中镜头下角色的可见性；如果项目中会出现程序生成或者大量重复相似的场景，要考虑设计时尽量保证美术资源的模块化；如果游戏中角色身高多变，要确保场景能满足各个角色的交互需求不会穿帮……
实际中，各个项目的限制和要求不同，概念设计师需要面对的设计问题也多种多样。可以说发现问题、解决问题的能力才是概念设计师的核心能力，画得如何反倒不那么重要。
这种解决问题的能力在目前国内的概念设计行业基本用不到，而这也是我极其讨厌国内现在的行业现状的原因。游戏的视觉设计和游戏的玩法设计、叙事设计已经解耦到一个离谱的程度，游戏生产过程中的任何一个方面都被资本要求和其他方面脱钩，以便能够大批量的快速生产出一个“游戏产品”。这种高度原子化的螺丝钉式的生产模式，是不存在概念设计师的，只有画图的人。
概念设计师在游戏行业中一般只存在于中大型的工作室或者公司。小公司或者独立团队通常没有“需要概念设计的意识”。即使有这个意识，部分团队的游戏体量很小，完全没有概念设计师发挥的余地（比如休闲游戏）；又或者团队没有预算去雇佣负责前期设计的概念设计师，通常这个职能会被主美（可能是小团队中的唯一一个美术）负责。近几年也有越来越多的中小团队选择在进行前期设计的时候临时多找几个概念设计师/艺术家/插画家进行概念设计创作，比如 
Jusant、Outerwilds等。对于游戏项目的概念设计来说，这似乎是一个处在设计质量和成本的甜点的设计方式（相对于没有专人进行概念设计或者开放一个in-house概念设计师岗位来说）。

2.7 Game Design Document（游戏设计文档）
GDD是一系列项目设计文档的综合，各个项目的GDD结构不同，甚至有的项目没有一个完整的GDD。我认为GDD有两个目的：记录设计大纲，和让人快速了解项目概况。
2.7.1 记录设计大纲
GDD可以包含很多东西：比如技术文档，比如游戏剧本大纲，比如美术概念设定，比如项目的市场调研结果。GDD就是游戏设计思路的浓缩精华，一份设计的纲领。一个好的GDD一定会让游戏的设计和制作过程更加轻松，至少会有章法可循。
2.7.2 了解项目概况
GDD可以面向团队成员：除非你是一个单枪匹马的独立开发者，你可能不需要一个书面的     GDD，但是一旦组成团队，GDD能够帮助其他团队成员了解项目状况，同步各个成员之间的信息。
GDD也可以面向投资者：良好的GDD代表着项目更加规范，投资者自然也会更有信心进行投资的行为。
但是，独立团队要注意的是，自己的项目规模是否需要一个GDD。一个小的项目可能只需要一个Demo便能承担大部分GDD的作用。
2.8 Pitch
Pitch，就是向人推销自己的点子。

小团队、独立团队可能没有这个过程。比如团队可能是通过一个玩法Demo确定了这个方向可行，然后就直接进行制作了。等到游戏完成了部分再放出demo或者预告视频寻找发行商、合作伙伴。这个时候因为项目是自负盈亏的，所以没有什么pitch的必要，顶多是团队自己向自己“pitch”，说服自己这个方向能做下去。
正规的公司中大到项目立项与否，小到一个设计方案的选择，都会通过pitch来决定。这种工作方式的另一个好处我将在下一节详细说明。
2.9 项目管理，游戏测试
这两点都是我所在的公司中项目组暴露出来的问题。
2.9.1 项目管理
项目管理的问题我认为是没有使用顶底设计模式进行制作游戏的表现。说人话就是，没人能够掌控大局。不做顶底设计，项目的制作进度没有人能够做出大致的估算：因为每一个游戏部分的设计（游戏已经很难抽象出循环，所以只能说是游戏的“部分”），都是游戏设计者零散的游戏经验的组合，所以设计者自己也不知道项目会变成什么样，更不用说消耗资源情况了。
在有一个项目管理框架后，比如一个简单的工单系统，此时仍然需要人力去维护更新表格，并且最重要的是——进行验收。这就引出了下一个问题：游戏测试。
2.9.2 游戏测试
我对于游戏测试的看法是，多测试，尽量早测试。并且有条件一定要去实时的观察玩家的反应，而不是依靠测试问卷——大部分人不愿意填写问卷（或者不愿意批评），我们设计的问卷中包含的问题不一定是测试者遇到的问题。在这个问题上我也咨询了一位朋友，为了避免问卷的主观性，他举了这样的一个例子：比如在验证什么样的角色控制方式更能被玩家接受，他们会直接统计玩家在每种控制方式下的游玩时长，时长最长的控制方案即被采用。

有的时候，一些游戏的测试demo是无法进行评价的。通常这种demo没有一个完整的玩法循环，试玩者无法进行任何有价值的评判，顶多评价两句画面表现如何如何。更糟糕的情况是，在进行一些demo的试玩过程中，出现了大量的待优化的UI/UX、逻辑、表现问题。这个时候不提评价demo了，此时这个项目的管理和沟通一定出了问题，否则不会放出来一个明显各个功能未验收的版本。
测试游戏，验收功能其实和项目组所使用的制作工具和制作流程相关性很大。小项目组通常没有一个好的工具和工作流程，如果项目规模很小，那尚且可以通过蛮力一一验收游戏的各个部分。但是，当项目规模变大，此时好的工具、工作流程就是必要的了。
举一个简单的例子，文本测试：当小项目组进行一个文本量小的项目的时候，文本写完了就可以通过程序（或者文案自己）配进引擎中，然后跑一遍对话就可以验收了。但是，当项目的文本量比较大，特别是牵扯到多分支文本的时候，上述的工作流程会出现这样一些问题：
当文本分支变多，并且选择会影响到游戏进程的时候，负责配文本进引擎内的人如果不是文案自己，那会增加一层沟通成本：文案要和对接者沟通好如何配置文本分支以及后续影响；如果文案自己配置文本，那要求文案需要拥有使用引擎配置文本逻辑的能力。
在这之上，如果文本配置过程中还包括动画演出、逻辑更改、数据更改等更加复杂的要求，这对于文案的要求更加高了。如果不是文案自己去配置，那么就需要一个更加详细的文档去说明这些内容。
此时，验收文本配置的工作就变成了一个艰难的任务。在没有良好的文档的情况下，一个一个分支去验收变成了几乎不可能完成的任务。即使有良好的文档，也需要耗费大量时间实机运行游戏才能测试。
雪上加霜的是，即使配置验收完成，一定会发生的情况是后期对文本表演等内容进行修改或者优化。而每发生一次这种迭代，基本意味着把之前的流程全部重来一遍。
很显然，项目规模变大后，拥有良好的工具和工作流程就变成必要的了。寄希望于小项目的经验，企图纯粹依靠人力或者蛮力去完成大项目是十分不理智也不现实的。
但是引入新工具和规范制作流程会增加工作量，并且接入新的工具和流程势必需要其他游戏制作的其他部分配合。所以比较理智的选择是，进行制作前先跑通流程，评估工具带来的便利和增加的成本是否处在合适的平衡点，确保从设计生产到最后的测试环节都合适自己的项目组。
3. 沟通
在讨论完以上这些名词后，我想谈谈制作游戏中更软性的能力——沟通能力。
3.1 关于如何讨论问题
讨论的规模有大有小，有全组成员的大会，也有两个人之间的小会。有的人讨论问题的时候，面对和自己相反的观点会变得非常的passive aggressive，会尝试寻找各个理由进行反驳；有的人讨论问题的时候，会带上过多的个人取向，会尝试加入自己喜欢的内容；还有的人会十分看重自己的观点，尝试说服所有人同意自己的看法……

所以我认为，讨论问题的时候，所有人都需要做到以下四点，讨论才有进行下去的可能性：
3.1.1 明确讨论中要解决的问题是什么：
讨论一定要有一个大纲，至少应当记录下来每个讨论主题的关键字。这样可以避免讨论的时候在一个点上无限发散，最终回不到要讨论的问题上——讨论的时候需要发散，而且一定会有成员喜欢发散性地思考事情。
3.1.2 明白讨论的时候，我们在就事论事：
那么接下来，讨论进行时，针对同一个问题一定会有不同的人提出不同的方案。没有人喜欢自己提出的方案被否定，但是讨论中我们应当明白的是，自己的方案被否定，不是自己的人被否定了。同样，指出他人方案的不妥之处的时候语气可以委婉，但是应当直接了当地指出问题。
这种快速高效的沟通方式的前提就是，大家应当明白讨论的时候，所有的意见都只是针对讨论的问题。在讨论中人产生情绪是应该的，但是我们应当能努力消化掉这些情绪——想想大家都是为了项目更好而说出自己的想法，这样应该能让自己好受很多。
3.1.3 给出的解决方案要完整：
在讨论之前，方案提供者准备好完整的解决方案，是提高讨论效率的最佳方式。工作中我遇到过一类“即兴思考者”：他们给出问题的解决方案可以很迅速，但时常无法细细思考下去，连续追问一两次便会卡壳。讨论时一定会有灵光一现的时刻，但是在讨论前能进行提前的思考，给出完整的方案一定是更尊重所有参与讨论的人的工作方式。
3.1.4 要记录下来讨论出的解决方案：
小团队中还容易出现的一个问题就是没有会议记录。会议记录不用非常正式，但是应当至少能给参加会议的人在日后提供一些回忆的锚点。特别是两三个人的小型讨论会，如果不做记录，一定会出现过了一段时间后所有人都忘记了当初针对某一个问题得出的具体解决方案，那就只能几个人再重新讨论一遍，事倍功半。
当没有人做会议记录的时候，讨论中还会出现一个问题就是随着讨论的深入，或者话题的偏离，大家会渐渐忘掉讨论的主题，自然也就很难日后回忆起当初在讨论什么。通常来说，如果有一个会议大纲，那么也应当会有有效的会议记录，这两者像是双胞胎一样，一般都是同时存在，或者同时不存在。
3.2 从不同视角进行沟通
最有效的沟通往往产生在沟通双方都对对方负责的环节有一定程度的了解。
在制作游戏的流程中，越是早期的工作越需要对下游工作环节有一定的认知。如果策划提出要增加某个系统，ta应该能了解到一个新的系统对于程序、美术、动画等工作环节会产生多少影响；如果美术提出要修改一些表现，ta也需要了解美术表现上的改动是否会对玩家体验造成影响，这些改动又是否会需要程序进行配合；如果文案提出需要进行修改，那么ta应当确认好这些改动是否会影响到动画的演出……

当然，这是不现实的幻想，每个人有专精，不可能一个组的所有人都是全才。但是，这应当是每个制作游戏的人努力的方向，也只有这样能够换位思考，团队成员沟通起来才能够更加顺畅。
3.3 如何critic
接下来，我将从两个角度来更具体的说明，明确设计目标后我们应该如何讨论设计问题。
3.3.1 方案提供者
对于方案提供者，要尽可能的提供多个解决方案，并且应该保证每个方案方向尽可能不同。比如，假设现在要解决玩家在游戏中走路的时间过长这一问题，那么以下两个方案显然过于相似：
1. 给与玩家速度更快的交通工具，比如马匹；
2. 给与玩家飞行的能力。
这两个方案本质上都是缩短玩家从A到B的时间，那么作为设计者，此时我们应该提供更多其他的方向，比如：
1. 增加玩家路程中可以游玩的内容，比如增加NPC、交互内容、或者更多的支线任务；
2. 直接减少玩家的走路时间，在玩家完成从A到B的首次旅行后，直接跳过旅行阶段；
这是一个非常粗糙的例子，但是在实际设计中，设计者会非常容易陷入一个方向的更加细分的解决方案。最差的情况是，这些方案显得十分像是拿来凑数的。

接下来在展示自己的方案时，不要一上来就直接跳跃到方案结果，而应该一步一步说明自己是如何得出这个设计方案的。说明自己遇到的设计困难，以及如何克服困难，这也是在给方案的聆听者时间去思考。而当确实无法提供更多方向的方案时，不如开诚布公，提出自己方案的缺点，询问其他人是否有更多的提案。这时候，作为讨论中的另一方，应该如何讨论呢？
3.3.2 方案聆听者
首先，如果方案十分成熟完整，那么皆大欢喜，不要吝惜自己的赞美。
其次，如果面对的是一个不成熟的方案，仍然第一步是找到其中的闪光点。这一步足够难倒很多人。我不知道有什么方法能让人发现一个不好的设计的优点，我能总结的方法就是跟着提供方案的人的思路去思考，明白ta为什么会做出这样的设计选择，这样总是能够找出值得夸赞的地方的。
接下来，才是找出方案中的缺点。这一步不是只指出问题，而应当要提供一个自己认为的能够让这个方案更好的设计。对一个设计评头论足永远是简单的，困难的是如何帮助一个设计方案变得更好。

3.4 尊重你的工作伙伴
一个只在公司工作过的人永远也不会明白这句话的意思，他们的工作伙伴不是自己挑选的。经历了更换专业，更换学校，参加各种小项目之后，我深切体会到，能找到志同道合的人一起为一件事情努力是多么的不容易。并且我越发体会到，团队中一个人的能力如何绝对不是最重要的，因为能力总是能够提升的。更重要的是，在团队中一个人能否百分百的发挥自己的能力，能否和其他人共同合作，产生一加一大于二的效果。
我记得以前看过一篇小岛秀夫的采访（写文章的时候我又去找了很久，结果没找到），采访人问他为什么要制作这么多游戏的宣传片，并且频繁的放出这些预告片。小岛秀夫的回答大致是这样的：他明白制作一款大型的游戏需要很多人很多年的努力，这些共同工作的人会在制作这个游戏的过程中经历很多新的人生阶段，有的人会结婚，有的人会生小孩，有的人会经历亲人离世等等。他希望和自己共同工作的人能在这么长的时间跨度中，有东西能告诉身边的人自己在为什么东西努力工作。
我记得当时看到这里我感慨万分，这种对于工作伙伴的尊重，是我这三年工作从来没有体会到的。所以我自己带队参加jam的时候，哪怕队友只是做了很少的工作，我也会在制作人名单里加上他们的名字，我想要和大家分享制作游戏的快乐。

4. 可行的制作流程
制作流程分为制作前期、制作游戏、游戏制作完成后三个部分。而我已经在第二部分的各种名词概念解释中，先把这三步走的流程中容易踩坑的地方提取出来详细展开描述了。
那么，笼统地再梳理一遍，制作前期包括市场调研，确定方向，招兵买马，前期设计，拉投资立项等环节。对于非商业的独立游戏制作者来说，这一部分可能会非常精简——所有和市场调研、拉投资立项相关的内容都可以省去。但是以国内的环境来说，即使大部分团队或者个人打着独立游戏的旗号进行游戏开发，其实大家都是希望能赚到钱的，那么这些很“商人”方向的环节其实才是最重要的。
像前文所说的，如果一个项目制作前期完成的很好，制作中期其实就是漫长的堆量过程。无论是团队还是个人开发，如果制作框架没有大问题，在这个阶段倒不如多花点时间照顾照顾自己或者团队成员的心理健康，这是我根据自己的经验唯一能想到会踩雷的地方。
制作完成后，一般来说是测试，优化和发行的部分。但是，我认为测试优化和宣发都应该提前到制作中期就开始进行。特别是宣发，对于我个人来说这反而是最消耗精力的部分，因为这需要我频繁地在开发者和宣传者的工作状态中切换。而即使游戏开发完成，我能够暂时卸下开发者的担子之后，我也很难在痛苦的开发工作之后马不停蹄地继续制作更多宣传物料，去各种平台上吆喝——实在是没有干劲了！
如果想要更加“专业”一点，那么提到制作流程，就不得不提到游戏设计文档（Game design    document）。网络上能够找到很多制式的游戏设计文档，不提其中的内容，光是文档的格式就能吓人一跳。对于我这样的实用主义脑袋来说，我更希望知道的是抛开它的结构和格式，这份文档到底应该发挥什么样的作用？或者说，应该如何写一份适合自己的游戏设计文档呢？

4.1 从设计者角度
无论是美术设计者、还是程序设计者、还是游戏设计者……任何设计者在设计前都需要明确的两件事情是：设计目标和设计限制。所以从设计者的角度来说，一份设计文档应该包含的是满足设计目标和设计限制的框架。这份文档需要阐明设计目的、设计方法，能让团队中的其他成员快速地了解对应方向的概况，并且指导游戏的设计开发工作。
举例来说，我熟悉的美术方面，一份良好的美术文档除了包含最基础的制定风格（画成怎么样）外，更重要的是能够说明如何达成指定的风格（怎么画成这样），以及说明选用这种风格的原因（在限制下进行设计）。很多美术主导的团队，很容易出现如下两种情况：第一种是美术表现力很好，但是主美术没有能力制作美术文档，导致除了风格制定者以外的美术团队成员无法很快地加入美术资源的生产中，更糟糕的是这种团队也很难培养美术新人，极度依赖关键角色的发挥；第二种情况是团队因为擅长美术表现，所以过于依赖美术，轻视游戏的其他方面，以及在某些设计问题上企图使用美术表现大力出奇迹而不是思考更加有效的解决方案。
一个简单的例子：假设一个2D为主的项目中需要一个书本翻页的动画，一个更加需要动脑子的解决方案是团队讨论能否使用3D完成翻页动画，方便以后资源复用。但是过于依赖美术的团队很可能会出现如下情况：团队第一次遇到需要翻页的动画时决定使用逐帧动画解决问题（甚至不会去思考复用的问题），以至于之后的所有翻页干脆全部使用逐帧解决。
需要注意的是，这种路径依赖并不是只出现在美术上。团队中如果程序能力十分突出，也可能会出现对应的问题，仍然拿翻书动画举例，假设这个动画只会出现一次，那么如果一个逐帧动画可以解决自然好过更加复杂但是通用且便于维护的解决方式。这里的关键是，设计文档应该是非常务实的指导解决问题的方法的文档，什么方法性价比最高就使用什么设计方法。
4.2 从制作产品的角度
如果跳出设计者的视角，从“生产产品”的角度来看待游戏制作，又有哪些需要明确并且记录在设计文档中的内容呢？
首先，先要确定游戏这个产品各个方面所需要用到的生产路径。在这一点上，技术实现和美术实现两个方面是更加贴近传统的制作“产品”的思路的：即要使用到什么样的技术，以及要实现什么样的美术效果。
举例来说，如果要做一个类似猛兽派对式的游戏，那么需要解决的技术问题可能有在线联机、多人在线物理解算等后端问题；以及一些和画面表现相关的技术问题，比如毛发渲染、ragdoll系统、程序生成的动画等问题；还可能会有一些和游戏系统相关的问题，比如文本管理系统的本地化、搭建和使用音乐/音效系统、多种操作模式的映射、内购、更新等问题……美术方面则在上面的美术文档部分讨论过了，不再赘述。
在确定了生产路径之外，还有一点也同样重要，那就是成本估算。但无论是时间成本还是金钱成本，成本估算总是更加依赖经验的。就像每个独立开发者可能都听过的传说：要给自己的项目至少两倍以上的时间预算（或者更多，哈哈）。这就需要文档作者确实了解一些生产的细节，从生产实践中来，最终才能走到生产实践中去。
4.3 从创业者的角度
文章写到这里的时候其实我内心是很虚的，即使听过有人说独立开发者应当把自己视为创业者，而我自己也赞同这一点，我也没法说出更多的见解——我自己还没真正开始“创业”！但是在写文章的时候碰巧我看到了这个视频This Problem Changes Your Perspective On Game Dev（作者是Thronefall和ISLANDERS的制作者），作者是从Search Algorithm的角度来看待独立游戏设计的。这对我启发很大，特别是站在一个创业者（开发者）选取创业方向（游戏制作方向）的角度来说，用搜索算法的视角来看待选取方向的问题确实帮我梳理了思路。
5. 后记
首先要感谢你能阅读到这里，也感谢文章成稿后提出各种反馈意见的朋友们，谢谢你们的反馈、鼓励和支持。
这篇文章大部分总结出来的经验都是来自于我观察自己所任职的公司内部各个项目组的情况得来。但是越往后写，我越释然。开始时我是很愤怒的，语言也尖酸刻薄。写着写着我觉得没必要这么愤怒了，因为每个人做游戏追求的东西都不一样：
有的人追求的是把游戏作为表达自己的媒介，那么我就很难苛责ta在制作游戏流程上的各种缺点；
有的人追求的是画面好看，想把自己作为艺术家的审美散播开，让大家视觉上得到享受，那我也无法对ta的游戏的游戏性要求很多；
还有的人追求的是做一个自己梦想中的游戏，把所有自己觉得好玩的内容都塞进去，那我便无法去批评ta的游戏体验混乱，设计糟糕；
更多的人不知道要做什么，做游戏只是一份工作，混口饭吃，那我更加无法要求ta要全身心投入项目，做个好游戏……
到头来这变成了一篇写给我自己的避坑指南，一份提醒我自己不要再犯文中所提到的这些错误的备忘录。文中很多观点可能都经不起推敲，因为我自己的实践经验有限。在写完这篇文章之后，我也将更多的投入实践，真正地使用我的游戏制作方法论进行游戏开发。
希望这些凝结自痛苦彷徨的经验总结能帮助到你。