资深开发者:游戏策划必须会用代码写创意

【GameLook专稿，转载请注明出处】

GameLook报道/游戏策划是一个需要涉猎很广的职业，比如你可能需要做策划文档、写UI线稿、修改数值表或者做游戏关卡，还可能需要做剧情策划或者游戏菜单，也有时候可能需要涉猎bug修复以及游戏货币化系统。但是，很多时候，你的想法并不一定能够被团队中的其他人正确的理解。

最近，GameLook看到一篇海外资深策划Adriaan De Jongh的博文，他表示，和团队成员交流想法最好的方法就是创意原型。因此他建议策划童鞋们，最好是去学一些基本的编程、语法，做到可以用代码写出自己的创意原型，这样你的想法才能更好的被执行，以下是GameLook编译的博文内容：

这篇博文讲述的是我如何学到了基础的交流技巧和游戏策划经验。

Kent的创意原型给我的启发

在我实习期间，W！games（注）当时在研发Gatling Gears，我当时是6人策划团队的一员，主要负责写游戏设计、做关卡草纸、讨论故事剧情、做界面设计、系统设计、角色设计以及参加日常的和程序员以及其他策划之间的会议。我在那里学到了很多，但有一件事特别让我印象深刻。在我几个月的实习期间，高级策划Kent Kune有一次意外的出现在了办公室，并且展示了他为Gatling Gears做的一个角色创意，而且这个角色后来完全达到了他想要的结果。

Gatling Gears截图

在Kent的职位描述中，他从来没有写过创意经验，实际上，W!games所有的成员都没有在职位描述里加入游戏创意这一点。该公司的结构更像是我在学校时候了解的样子：一个游戏策划设计功能，然后程序员写代码，随后美术师补充美术部分、音乐师增加游戏音效。但Kent决定为主角做一个创意原型来真实的展现自己的看法，并向团队展示他自己所想的内容。

他很清楚的是：首先，如果他只是跟工作室的其他人用语言解释，那么他的话就会很快被忘掉。作为游戏策划，他可以让别人按照自己的意思做，但他不知道工作室的其他人会做成什么样（做好写代码、美术以及音效等工作对于很多人来说都是神秘的事情）。除此之外，他还知道，自己的想法很可能在被执行的过程中走样。

Kent的创意原型很好的展示了他对于角色的想法，通过亲自写代码做了创意原型，他可以把脑海中上千种微小的选择加进去，而不需要用过多的语言来表达。而且，由于创作了原型，他就不用再用很多时间跟整个团队讲自己的每一句话是什么意思，不再需要从整体到细节的赘述，比如在创作原型的时候的想法改变、加速器方面的修改、角色身体比例的调整之类的小细节。

创意原型是最好的交流语言

为了说明他的做法的高明之处，我们不妨看看这几个问题：你是否知道做角色加速和减速至少有10多种方法，每一种特定的方法都可以创造出不同的感觉？作为策划，在不知道这些方法和所能带来的效果的情况下，你怎么解释清楚？

首先，作为一个不会编程的游戏策划，你不得不跟程序员用言语解释你的想法，比如‘降低’、‘加速’或者‘自然地’等等，但这些词语并不能精确的传达你想要表达的意思，甚至你所表达出来的语言有可能跟你所想的东西相反。然后除了这些描述之外，你把自己的想法留给了程序员去做，让他们去决定加速的方法，比如赫米特插值（Hermite interpolation）加速，或者其他的样条插值（Spline Interpolation）加速方式，并为解析插值的数据点增加更多的控制。总结：作为游戏策划，你的想法很有可能被误解，你的语言交流很容易达不到想要的目标。

在Kent最初向团队展示创意原型的时候，工作室的所有人都表达了自己的看法和观点，游戏策划团队都努力的把他们的设计变成语言表达，看到了Kent的不同做法，这时候他们有了讨论的话题。角色制作团队不同意动画团队的做法，并且讨论下一步怎么做、做玩法的程序员也讨论他们如何用代码来表达出来。可能你会说，一个角色的具体数值在很早就已经确定了，只是，这些讨论讲的是细节调整。而Kent的原型成为了他与工作室成员们的交流语言，可以准确的表达出他的想法。

做原型的时机和调整自己的游戏概念

有趣的是，在工作室开始这个项目几乎半年之后，Kent才做了他自己的创意原型，为什么Kent没有在更早的时候做原型呢？为什么是Kent在展示了自己的创意之后才引发了这些讨论呢？其实，W！gams的成员们都低估了他们可以从原型当中能够学到的东西。

我们所有人都倾向于提高效率，以确保我们没有在浪费工作时间。Kent没有在更早的时候做，是因为那样是没有效率的：如果他很早就开始做，那不仅会占用很多的时间，即便做出来之后也会被程序员做修改很多次。然而，在项目进行到了一定程度之后有了Kent这样的创意原型，团队就很容易理解他的想法，而且他在创意方面所花的时间完全是值得的。可以肯定的是，任何一个做游戏玩法的程序员都能够理解Kent的创意，这样也会让他们对整个游戏有更好的理解。

另外：你是否考虑过你对游戏的理解、想法，你对游戏的看法是否是不完整的或者是没有根据的呢？你如何能够确定所有事情都能够按照你想象的进行呢？当然，你是做不到的。你必须真切的看到游戏，并且知道哪些东西是不能用的。Kent的原型就是让W！games的员工们第一次真正的看到了游戏，或者说，是Kent第一次在他们面前展示了真实的游戏。团队成员们第一次知道了游戏‘将会是什么样’，对它们来说，这就是一个填补空白的起点，抛去所有不起作用的事情，从已经出现的原型做起。

游戏策划最关注的应该是可以直接影响玩家体验的东西

Kent向我展示了原型创意的优势，并且我也因此决定开始学习基本的编程。他经常会走到办公室展示最新的作品，比如一个奇怪的联网多人游戏，或者一个风筝冲浪游戏或者是一个多人模拟游戏。他出于兴趣自学了编程，尝试并向我展示了如何面对各种技术困难，比如处理四元数（quaternions)或者做物理身体转向，他在讨论中经常会向其他策划让步，或者是得出更好的解决方案，而且他总能找到解决方法。

但是，作为游戏策划，我们究竟应该学多少编程知识呢？是不是所有的游戏策划都要学很多东西，做到像程序员一样呢？我们很容易看到，在游戏当中，即便是像插值这样的小问题，都可以引起游戏中完全不同的变化。游戏策划们经常会谈论这些东西，他们称之为‘游戏感’（game feel）。当有了一个创意原型作为骨架之后（或者说是你概念的雏形），所有的细节都可以让游戏感或者美术方面看起来有巨大的不同，这种影响几乎是在游戏制作的所有层面：核心玩法、整体结构、界面、游戏内反馈、敌人行为、特殊的玩法元素、细节情况的处理等等。

但是，这是否意味着一个游戏策划就需要知道资源管理的内部细节、渲染的功能、网络协议以及其他的技术细节呢？从我个人对于游戏策划的定义来看，我的答案是否定的，简单的说，一个游戏策划最应该关注的是所有能够直接影响玩家体验的东西。

创意原型是为了交流特定的东西，因此可以忽略一款游戏当中的很多细节或者方面。比如说你想要确认计分系统的表现，那么，你就不需要去为角色原型做动画、不需要写复杂的渲染代码、不需要优化原型的帧率，因为这些东西都和计分系统无关，在做原型的时候考虑这些就是浪费时间的。很有可能的是，你在表格或者文档中做的原型就能够展示游戏的计分系统是否有用。

然而，如果你想要测试FPS游戏中的闪光灯功能，那么纸上的原型可能就做不到你想要的效果了，游戏感很大程度上依赖于直观的视觉以及触觉反馈，在大多数的游戏研发当中，你都不是通过纸上的数据获得游戏感。所以为了测试闪光灯的功能，你必须考虑最小化的引擎消耗，并且要根据原计划来做。可能让你的数字原型看起来美观是非常有诱惑力的，但是这些对于你测试闪光灯功能又有多大的用处呢？如果你过多的专注于引擎、优化，并把原型做到尽可能美观，这是很浪费时间的，因为很多事情都可以用更简单的方法来实现或者交流。

游戏策划要做自己的决定

在学习一些基础的编程之前，我想不起来自己做过什么样的‘策划’，在此之前，除了把自己的想法留给其他人看之外，我甚至都不确定自己到底设计过什么东西。然而我现在明白了，如果我自己想要设计一个游戏，我就必须自己去做一些细微的选择，调整游戏感，做好游戏互动或者玩家行为体验，而不是要做到程序员那样熟知每一行代码。

当然我这么说并不是指程序员就做不好策划，我想说的是，程序员本身也是游戏策划，如果他们可以做所有这些细微的选择，就像游戏策划这样，那么他们本身就已经做了大量的策划工作。不管你是一个多么善于交流的游戏策划，也不管你对于游戏功能的理解有多深，有些时候一些小的选择你都是不能帮助程序员解决的，除非，你自己会写代码，因为游戏结构和技术方面的东西只有程序员才能做。

如果你是一名游戏策划，但却不会写代码，你要清楚：和队员们交流想法最好的方式就是做自己的创意原型。所以最好是学习一些基础的编程，根据脚本不断的修改，学习语法，搜索并改正你的错误，然后用代码写出自己的想法。这样，你的游戏策划之旅就会更顺利。

注：W！games即Woedend Games，成立于2005年，后来在2010年更名为Vanguard Entertainment。