Social Quantum的游戏原型开发建议
什么是原型以及如何正确地处理它，—— 社交量子公司的技术总监基里尔·沙博丁讲述了这一点。
该报告是在今年夏季的 圣彼得堡白夜活动 2018中宣读的。我们在此提供演讲的简要版。
基里尔·沙博丁
何时需要原型
游戏的主要任务是带来乐趣和愉悦。情感和心情是很难定义的东西，涉及各种成分。并不总是清楚具体应该使用哪些机制。
情况的复杂之处在于，对快乐或某个具体论点的理解，来自不同背景的人会有不同的看法。如果我说“让我们做RPG”，许多人可能会想法类似。但一旦进行原则上的澄清，就会发现我们在细节上所想的完全不同。
而在这个时刻，当你的想法开始分崩离析为许多其他想法，而这些想法对你合作的人来说并不明显时，就需要一个原型。
我想强调的是，在这个阶段所需的不是详细的设计文档，而正是创建原型。
为什么？
因为详尽的设计文档是一个神话。最终的、完整的游戏设计文档在游戏发布的那一刻才会出现，而不是更早。我并不是说这不重要，它是必要的，但它的作用是在开发过程中不断修正的文档。
总体而言，软件产品的生产过程通常如下：想法、提案、设计文档（不断修正）、原型、进入生产周期。
原型是必要的，因为对游戏软件不同方面的语言表达相当复杂，这些方面不能仅仅通过解释来说明。
一旦我们感到语言表达的匮乏，一旦我们无法通过文本来定义这些方面，我们就开始编写原型。
原型是什么
让我们首先谈谈什么不是原型。它不包括：内部的工作成果、堆积如山的想法、糟糕的流程、无效的技术，以及关于这些的“是的，我做得不好，但这是原型，之后会做得更好”这样的话。顺便说一下，MVP（最小可行产品）也不算是原型。
也没有快速原型制作。这是一个循环论证。也没有慢速原型制作。任何原型都是我们快速完成的东西。
什么是“快速”？如果实现完整功能需要一个月，那么其原型的制作时间应该不超过两天。最好是一天。如果不是这样，那你是在做糟糕的功能实现，而不是在制作原型。
原型制作并不是做得不好，而是以不同方式进行制作。
那么，原型是什么，它代表了什么？
首先，任何原型都展示了你所做产品的一个重要方面。原型不是复杂的东西，而是展示一个关键方面的东西。
其次，原型生命周期的结果总是垃圾箱。原型必须被丢弃。
第三，原型应该有接收者，即做出决策的人。可能是一个或一组人。关键在于编写原型的目的是希望接收方给予二元答案：要么“是”，要么“否”。也就是说，要么我们做这样的功能，要么我们不做。
第四，原型必须使用该决策点最大理解的语言。
举个例子，如果你展示图形用户界面的工作给用户，那么你只需绘制一个截屏。它只回答一个问题：这是他所需的用户交互集吗？
最后，如果你从事原型制作，你应该拥有某种特殊工具，使得这一切能够快速完成。
如果你正在编写与平衡相关的故事，那么即使是一个包含两个脚本的Excel或Google表格，用于计算例如如果玩家朝一个方向走会怎样、朝另一个方向走会受到多少伤害，这也是一种原型。这已经可以进行游戏测试了。
游戏关卡的原型可以是在Unreal引擎上完成的场景，使用标准资产，可以清楚地了解地图上的兴趣点是否有效，敌人是否合理分布，急救包是否能被所有玩家看到，等等。
在此要注意的是，你的原型制作团队所提供的质量始终是相同的，而时间可能不同。为了缩短时间，应使用现成的解决方案。不要重新发明轮子。
进化原型制作
不要陷入所谓“进化原型制作”的陷阱。后者指的是逐步修正原型，使其转变为工作产品。
事实上，原型本质上无法转变为工作产品。我不知道有哪位成功的人。
那些称自己所修正的东西为原型的人，从理论上讲并没有在制作原型，而是在从糟糕走向优良的开发。迭代地开发了一个功能、第二个、第三个。在某种程度上，他们称其为原型。然后在没有改变代码的情况下，将结果称为产品。
概念验证
在开发之前，了解你在技术上是否适合现有任务是非常重要的。应当在战斗前进行侦察。
我知道三到四个故事，讲的是人们启动游戏生产，经过相当长的时间制作后，才发现无法实现基本功能。
举个例子。你打算制作一款多人游戏。在这之前，你需要问自己一系列问题。
- 我们能否承受制作一款多人游戏的成本？
- 在我们现有的硬件上，多少人能同时玩这款游戏？
- 什么是延迟补偿？
当然，问题还有很多。每个问题都需要不仅仅是具体的回答，还需要证明。
确实，存在大量的技术，不需要证明任何东西。你使用现成的引擎，使用现成的、易于理解的概念。因此，往往有一些解决方案不需要向任何人证明，你可以直接跳过这一步。
原型制作建议
最后，我将列出一些可以帮助你创建原型的建议：
1) 一定要使用适合原型的工具。例如，你在Unity中工作。对于某个2D任务，使用Defold或Game Maker验证会更快，而不是深入Unity的2D功能。
2) 不要在原型中做任何不展示想法的事情。
3) 不要将糟糕的实现称为原型。
4) 任何原型都比仅仅用语言表达更有效。
5) 尽量在原型中使用一种机制，一个方面。
6) 不要认为你必须雇佣儿童来制作原型。雇佣正常的程序员，因为正常的程序员工作更快。
7) 在原型制作过程中，重用内容总是比创造新的内容更快且合理。
9) 切换到另一种工具要比从头开始发明解决方案更合适。如果有人已经想出了某个解决方案，而团队的目标只是向一个能说“是”或“否”的人展示想法，那么使用其他工具显然更合理，而不是从零开始编写代码。
