在大学生涯中，因为学期制的压缩属性，我总是需要在连续数周内，每周快速完成一款独特的原型创建。虽然之前已经参加过一些类似的过程，但是我却从未真正面对过反复的快速原型创建过程。
而之前的经验告诉我，当我们在设计一款游戏原型时，任何有关游戏设计过程的理念都将被抛到九霄云外。很多时候，对于设计一款完整的游戏来说非常重要的元素却并不适用于原型创建中；而其它看似很琐碎的元素却变得更加重要。所以我将在此分享我在原型创建中所吸取的经验教训。
规模与范围的不同
在大学课程中我们经常会听到，为了保持适当的工作量，我们需要同时限制项目的规模与范围。尽管我知道这意味着什么，但是我却从不愿意去思考这两个术语间的差别。而通过快速原型创建过程，我知道了范围决定着能否维持合理的工作量。
在制定项目建议书前，最理想的情况便是你已经拥有了一份原型，从而避免了时间约束，但很多时候你也会发现自己不得不匆匆忙忙地创建一份游戏样本。如果你马上就需要一份原型，那么规模和范围便是你的两大主要考虑因素。
就像我们所了解的，规模便是指游戏的大校如你所面对的是多大的游戏空间？当基于规模进行思考时，我们最好能够从整体的游戏时间开始。这是只需要3个小时的独立冒险游戏还是长达40个小时的角色扮演游戏，或者是只需要10分钟便能够完成的休闲游戏？明确这些问题能够帮助我们判断游戏的大小（和深度）以及最终呈献给玩家的游戏体验。
而范围则是指游戏中所需要的材料数值。也就是规模代表大小而范围代表密度。即关于你需要面对多少不同的游戏元素？你需要使用多少不同的角色和资产？最重要的是，你需要编译多少不同的功能？
在快速创建原型时，最后一个问题非常重要。就像我们常说的，游戏产业充满创意，所以开发者不需要花费大量时间去思考角色所拥有的不同技能或玩家可能面对的挑战等。如果你创建了游戏原型去演示游戏理念，特别当你是设计者时，你便会希望能够尽可能多地传达更多这类型元素。最好的情况则是你能够在将游戏交给发行商前编译出所有内容。而做到这一点的诀窍则是，始终以做不到这一点为压力去推动自己。
在现实生活中，创建计划非常重要，而在遭遇了失败后，我们便需要创建备份计划，然后再创建备份计划的备份计划。而在原型创建过程中，一份真正出色的计划必须已经包含了备份计划，并且备份计划是以不断扩大的范围形式呈现出来。也就是一开始先基于较小且简单的范围，随后基于此进行扩建。
也就意味着我们需要在创建过程中不断调整项目的整体属性。如果你所设计的原型是突出一个关卡，那么这个关卡需要基于所需要执行的功能数进行设计。
根据标准设计去调整范围
让我们假设你正在设计一款平台游戏。其中包含了最基本的平台元素——跳跃和奔跑，以及其它标准的元素，如二段跳，提速和三角跳。你同样也希望能够设置重力调整机制去控制个人的碰触。你已经设计了一个原型关卡能够传达这些能力，并且只有合理设置每种能力才能达到真正的效果。这么做能够让玩家们更加期待你的游戏。
接下来你需要制定一个原型创建计划。你将创建一些基本的平台机制去保证基本设置的运行。因为这是一款平台游戏，所以你需要在进一步发展前搞定这些元素。也就是你将在此执行你的重力调整系统。这是设计的关键——这一元素将能够让你的平台游戏区别于市场上的其它游戏。而如果缺少了这一元素，你便没什么好展示的了。
但是随后问题便开始浮出水面。现有的平台游戏机制的物理属性与你所希望呈现出的物理系统是相互矛盾的。也就是说你需要为此投入更多的时间。当然了，你也可以略过其中一些额外的功能，毕竟对于游戏的运转来说这些功能并不具备多大功效。
但是仍存在另外一个问题，即你所设计的原型关卡必须包含所有的这些元素。除非你一开始便使用了加速和三角跳元素，否则你的重力调整系统便很难发挥作用。而现在，你便会因为没时间去整合其中的某一元素而不得不重新设计整个关卡结构。这么做需要花费更多时间，从而让你不得不舍弃其它功能而再次进行关卡设计。
尽管你不能完全阻止这种问题的发生，但是你却能在原型创建（而非制作过程中）中缓解问题。这便是我所说的可调节的范围和标准设计。虽然我始终提倡创建具有凝聚力的游戏体验，但是原型并不是完整的游戏中所看到的混合元素——它只能用于呈现出游戏的运行。所以原型的创建将基于一些独立运行的关键机制。
举个例子来说吧，你可能想要创建一个专门演示加速机制的关卡模型，以及另外一个用于演示重力调整机制的模型等等。最理想的情况便是你可以按照自己的想法去创建关卡顺序。如果你想要混合某些元素，并且你已经接近原型创建后期了，那就将你所创建的内容组合在一起而生成一个完整序列的事件。后面的这种方法将能够创造出更连贯且更具凝聚力的原型，但却需要投入更多的设计时间。
外观远比想象中重要
这并不是说你应该聘请一些专业人员为一个10分钟的技术演示创造花俏的角色和视觉效果，而是需要牢记“电子游戏”中的“电子”的含义。在原型中明确游戏机制的可行性非常重要，但是从整体角度来看电子游戏是关于将所有的代码数字和符号转变成能够轻松理解的形式。如果代码能够有效运行的话，玩家便能够在屏幕上看到所有效果。就像开枪时能够提到“Bang！”声，添加能量时能够看到自己越来越亮之类。如果你使用“喝牛奶”功能，你便能看到牛奶在眼前逐渐减少。
同样还需要考虑到反溃我们总是很容易遗忘或忽略这一元素。如果玩家执行了某些行动，我们就需要去证实这些行动。不管是在原型还是完整的游戏中，这一点都非常重要——以证实代码真的能够有效运行。代码能够确保机制的运行，但是如果缺少了视觉元素，玩家便不可能意识到这一点。并且对于传统的玩家来说，调试屏幕并不是一种可行的视觉反馈机制。
总之，一定不能忽视原型中的反馈元素。尽管你并不需要在这一阶段设置超现实主义式的爆炸效果，但是玩家也希望确保受害人不会给自己造成任何威胁。除此之外，写着“Boom！Headshot！”的文本框也许算是一种可行的反馈机制，但是如果让我反复看到这一内容，我将不会愿意继续玩这款游戏。
在原型创建阶段做出改变
因为在大学课程中我曾经遭遇了半途重新设计游戏的经历，所以我希望可以不再重蹈覆辙。在游戏创造中，当我们发现游戏原型并不有趣时，事情就糟糕了。
其实我并不确定快速创建原型的实践在游戏产业中是否常见。我要说的是，在你将项目递交给上司前，你不可能根本地改变游戏设计。一周内生成一份可行的游戏原型是件极具挑战性的任务；而在24小时内完成更是自找麻烦。当然了，如果你的游戏原型并不有趣，别人便不可能接受你的游戏，而如果你只是在最后时刻才开始修改原型，也不可能改变最终结果。
为什么我要提及这一点？因为原型创建是我们开始明确游戏理念是否有趣的第一个阶段。所以我们最好能在这一阶段决定各种改变。如果这时候你发现游戏原型并不有趣，我便会说，不用担心，因为你还有机会创建另一个游戏原型。
结论
不管你所面临的是何种情境，你最好能够在创造一款完整的游戏前便找出更多问题。这便是创建原型的真正目的。原型是一种测试过程，能够让你在将理念投放市场前验证它的可行性。当然了，知道自己的设计不能有效运行时总是会很受打击，但是如果你能在投入更多时间去开发游戏前意识到这一点，那么这种打击力度便能够大大减少。
