【GameLook专稿，未经授权不得转载！】
GameLook报道/所有的游戏项目，尤其是大项目，由于职业细分化，会导致人才分离。然而，每个参与研发的人都需要和谐一致才能做出最好的游戏，策划和工程师领域尤其如此。由于游戏的设计和实现需要不断迭代，策划和程序员必须密切合作。
问题在于，这两个领域几乎是对立的，他们的思维方式和沟通语言都不一样。在此前的GDC演讲中，前暴雪娱乐资深工程师Brian Schwab以“策划来自土星，程序员来自天王星”为题，讨论了如何让程序和策划之间的沟通更流畅，以及潜在的问题和解决方案。
以下是Gamelook听译的完整内容：
Brian Schwab：
我今天分享的主题是“策划来自土星，程序员来自天王星”，之所以这么说，是因为我本人就是个程序员。我在游戏研发领域从业很长时间了，此前最近的工作是在暴雪娱乐从事《炉石传说》项目，这也是我参与的第19款已发行游戏。
这些年来，我在各种规模的公司就职过，有车库创业公司，也有索尼SCE北美这样数千人规模的大公司。我几乎从事过所有的游戏品类，这是有点奇怪的，不过有趣的是，在《炉石传说》之前，我从未参与过卡牌游戏的研发。
大多数时候我主要从事玩法、AI，但也做过策划，甚至在一些参与过的项目上担任过主策划。我将它们以这个顺序排列，因为我发现AI实际上处于设计和玩法之间，也介于策划和编程之间。为了做好AI，你最后必须两方面都有涉猎，这也是我今天做这个分享的原因，因为我发现自己以及就职过的很多公司里，我就像是两者之间的翻译。
我经常在索尼工作的时候发现程序员和策划争论，然后花一些时间听他们在说什么，最后发现他们只是出现了沟通问题，他们需要类似谷歌翻译这样的工具来帮助。
总的来说，我算得上业内老鸟，几乎见过所有事情，而且经历过各种工作环境。那么，为什么要做今天的分享呢？
我们做游戏的方式发生了很大的改变，过去，策划写规定，程序员进行部署，然后进行测试，然后根据测试结果可能会不断重复以上过程。但是，如今的游戏研发中，系统策划会写项目文档，程序员部署内容策划使用的工具，程序员随后通过工具和功能变化支持策划，然后我们不断重复这个过程，直到游戏发布，有些时候我们会在游戏发布之后还重复这个过程，因为现在很多游戏都是网络游戏，发布之后还需要不断更新内容。
很明显，这个流程更偏向3A工作室的方式，如果你是独立工作室或者中小团队，可能有不同的方法，但这基本上就是如今游戏的研发流程。而且可以看到，在新的研发流程当中，策划与程序员的配合越来越紧密。另一个原因是，游戏里的功能也在发生变化，尽管方法仍然分为策划、程序员和美术师三大类，我们也是这么招人的，但游戏功能已经不再以这种方式分类。
即便是有些像素风的美术，现在也很多时候并不是由程序员一个人制作的，有人能说清楚图片中的功能哪一部分属于策划、哪一部分属于程序吗？
随着我们的游戏变得越来越复杂，这些功能本身也变得更加复杂，它们需要这些跨学科团队紧密合作才能做出来。而且，策划与程序员两个群体很难和谐相处，因为他们的思考方式完全不一样。
因此，我今天分享的内容包括：两者之间的基础差异，两者之间的协同工作，以及一些开始被行业采用的桥接方法。
游戏策划和游戏程序员的基本差别
我在谷歌搜索游戏策划（game designer）图片，得到的第一张就是左侧的图片，而再次搜索游戏程序员（game programmer），得到了右边的图片。即便是问用户，他们很多人也认为游戏策划在创意过程的作用很强大，而被问到程序员，很多人会想到约翰·卡马克，或者是某个坐在桌前敲代码的人。所以，即便是普通人，也知道两者之间有泾渭分明的差别。
同样，两个在职业的工作方式也是很不同的。游戏策划是非常自由的形式，很依赖团队合作，而且很大程度上是发现，你在很多规则之间组合找到一些特别的东西，而且它是很情景化的，取决于不同的游戏、不同的研发阶段，实际上没有固定的格式可以遵循。
相反，程序员的工作方式大不相同，他们是精心组织的，他们可以更容易将工作拆分成不同的系统，他们处理相对抽象的系统，他们的整体思维也是如此。而且，通常他们往往是比较孤立的，他们开始一个任务，完成然后寻求反馈。
如果让两个工种一起工作，你会发现程序员往往发现很容易被策划打扰，因为旁边经常有人在大声说话，他们的确有时候可以给出一些正确方向的反馈，但对于大部分人来说，更常出现的情况是他们会给出一些反馈或者拒绝一些想法，而这些是策划甚至还没有尝试做的创意原型想法，你显然不希望它被拒绝，因为会导致气氛令人窒息。另一方面，有些时候，策划可能对自己想要沟通的事情采用了不恰当的沟通方式，导致程序员误解，因此选择了拒绝。
我认为在研发的特定部分，混合团队是行之有效的，比如你在做新功能的时候，他们可以一起讨论想法。但随后，我认为程序员需要单独办公，这样他们才有更多的时间聚焦于自己的工作。
在做游戏的时候，这两个职业也有非常不同的目标。策划寻求的是乐趣，是连贯的玩家协议，他们希望制定一个可以持续的规则在一定程度上限制玩家；而程序员寻求的则是性能、缩放能力以及整个产品的维护，他们思考的并不是整个游戏，而是整体代码。
我认为双方都有简单整个口号，但这对于他们的意义则完全不一样。在《炉石传说》项目上，策划团队所在的地方有一个海报写着设计核心（design pillars），清晰说明了《炉石传说》的设计目标，它包括：面向所有人的游戏（game for everyone）、保持深度（Keep it deep）、做出实体感（make it physical）、Great Flavor、快节奏（play fast）以及无论输赢都有趣味（win or lose-still fun）。
回过头来看，可以发现这些图片色彩鲜明，很清晰地给出了游戏的基调，从比较高的层面来说，只是通过这些图片，你就能看出《炉石传说》应该是一款怎样的游戏。
接下来，我向你们展示游戏主程序Bob Fitch桌上的海报，说的是游戏的编程核心理念：解决遇到的问题（solve the problems you have）、快不代表马虎（fast doesn’t mean sloppy）、保持简单、知道问题来源（know how it broke）、更好用（it better work）、不留痕迹（leave no tracks）、玩你在做的游戏（play the game you’re making）以及使用对的工具（use the right tool）。
你们需要注意到的是，这些东西实际上和《炉石传说》没有任何关系，实际上，这是Bob Fitch使用了20多年的游戏编程核心理念。它们主要说的是打造工具、系统，以及如何与其他程序员合作。
问题是，一群人只关心游戏本身，另一群人则对过程更感兴趣。那么，这些目标是如何给两个不同岗位带来满足感的？
可以发现他们是非常不同的，对于策划来说，要保证游戏易于上手难于精通，你在做的是一款覆盖面很广的游戏，让很多人可以学习游戏规则并深入研究。而对于程序员来说，成功就是尽可能降低bug数量，是写了非常直观的代码，让新加入的同事都可以看懂并且帮助维护，如果代码没有重要问题，他们就是成功的。
所以你们可以发现，有些时候，策划要求达到的成功标准，实际上会让程序员的工作失败。
哪怕是优雅这个规则，对于两者都是完全不同的。比如一款优雅的游戏有着最少的规则，但同时又有深度，但并不是那么复杂的规则；对于程序员来说，优雅的代码意味着代码写的很聪明，但不是以特别直观的形式，因为这是字符串，不过它可以带来很好的性能和优化空间。所以程序员说的优雅，指的是代码本身，而非策划说的游戏。
游戏策划与程序员合作
那么，如何让这两群人一起工作呢？对我来说，很重要的是尽早。也就是当你的项目刚开始的时候，我更喜欢将其分为两部分。
第一个是pre-prototype，当你确定了一个不错的创意原型想法之后，就需要让程序员参与，这可以让所有人对游戏信息保持同步。实际上，在这个阶段，你可以告诉程序员你的思维方式、你是如何理解设计问题的。我喜欢使用多种媒体形式，创意原型白皮书是好的，也可以用谈话的方式，如果可以让想法更清晰，还可以做出行动。
人类有着固定的信息接收方式，有时候你可以发电子邮件，某人可能记10年，有时候给另一个人一张纸，他们可能阅读20次之后还拿着它。所以混合媒体形式是重要的，人们学习的方式是不同的。
这里的对话是一开始就与程序员一起探索游戏边界，他可以给你带来反馈，帮你找到意外和边缘案例，给你机会解释游戏设计如何涉及这些边缘案例和意外情况。因为在这个时候，程序员在确定一个行之有效的抽象概念以编译你的游戏设计，有些时候，这些边缘案例或者意外情况可能是你从未没有想到过的。
然后他们会走开，写自己的代码，某些节点反馈给你一个创意原型。
随后，相反的事情发生了。你作为策划需要了解程序员的想法，以确定他是否理解了你要传递的信息，以及他对此是怎么看待的。所以，这时候，你需要了解程序员所做的事情，让他解释这个系统是如何执行你的设计，他的抽象概念如何处理一切需要处理的东西，这是很重要的，程序员对于系统的性能也有很多的想法，这是两者对游戏设计和性能进行协商非常好的时机。
另外，你还需要注意可能出现的问题，比如程序员可能将系统做的太过于宽泛，抓住了每个可能出现的选择，但你看到之后可以告诉他，有些事情永远不会发生，你可以给他一些边界，让它能够将系统简化。当然，这是项目很早的时候，所以，如果你要说有些事情永远不会发生，最好是先确认好，以免后续还需要再加进去。
所以，我这里说的是在两个人之间建立连接，这是很简单的比喻。人与人之间建立连接很简单，但中间会有沟通问题，有信号丢失，我认为更像是这样：
他们说话的方式、学习以及理解事物的方式都不同。很多的编程都是自上而下，而内容创作则是从下而上，有些关卡策划也是自上而下思考的，所以他们之间有些共同点，但你需要注意这些差别。
策划喜欢使用华丽的辞藻，我们厌恶同一个单词被重复使用。但是，程序员喜欢语言的清晰，这或许也是我们与计算机打交道比与人沟通更擅长的原因，因为计算机是最简单直接的案例，你输入了错误的代码，计算机就会告诉你出错了。
所以我们需要记住的是，沟通清晰度很关键，词汇的连贯性很重要，形成自己的词汇表，人们这么做是为了让彼此之间更亲近。这也是很多极客聚集的时候提到电影的原因，我们觉得彼此是连接的，这是我们共有的词汇。
因此，当你和程序员沟通的时候，要知道他们是连贯和清晰语言的高手，因为这是计算机需要他们具备的特点。
有时候开会的时候，策划说的一个事情，可能会让程序员想到另一个完全不同的方向。因为有时候同一个词汇对于不同的人来说，其实不是一件事，因此在预制作阶段就要形成连贯的单词表。
到了创意原型阶段，程序员可能会带来一些新词汇，可能是资源命名系统。比如在《炉石传说》研发过程中，我将卡牌文件命名给策划看的时候，他觉得不理解其中的含义，因为我是以第三人称写的。随后，他检查完了所有文件，并且重写了名字，这时候我发现，他是用第一人称命名的，所以，随后我再和他聊天的时候，就很容易使用更好让彼此理解的词汇。
然而，要做到一目了然，这也是表达清晰度的问题。有些东西是你必须做到简明扼要的，其一是优先级，哪些是必须有的，哪些有了会更好？不过post ship的优先级不好确定，如果一个功能是必须在发布后做的，那么在游戏研发的时候，作为程序员，它对我而言的优先级就不是那么高。
另外，不要做快速预测，因为程序员可能会永远记住它。范围会好很多，因为它可以展示确定性。如果我说一个任务可能需要15到20分钟，我觉得这是相当确定的。如果你说可能要1到4天，那么我很快就会意识到，我让你做的事情可能没有表达清楚，因为这个范围差别是400%。
游戏开发者之间还有很多的沟通方式，其中一个很重要的就是开会。
绝大多数的程序员都不喜欢开会，策划可能感觉会好些，制作人可能比较喜欢开会。但问题的关键是，两者之间的工作量是有很大差别的。程序员的工作块可能是4小时，如果你在早上开会，那么程序员一上午的工作就被打乱了，如果下午的时候再开一次会，那么程序员一天的工作量可能很少，因为需要高度集中的工作是不能被打断的。
因此，你需要对开会认真考虑，看是否有必要。
另一个问题是，程序员没有策划那么喜欢社交。哪怕是在GDC，如果有人走过来跟我说话，基本上三句话就能知道他是策划还是程序员。程序员说话会比较谨慎，他们不喜欢成为关注的焦点，尤其是在开会的时候，我见过最自信的程序员，就是开会时让台下的人们停止大声说话。
持续沟通也有差别，在团队合作开始的时候，我就会问，你是喜欢电子邮件、聊天软件、电话还是面对面沟通？因为每个人喜好的沟通方式都不一样。不过对于程序员，还需要注意的一个点，就是每天的“聚焦时间”。他们可能会说，“4点之后不要再来找我，我很忙，发一封邮件就行。”这些都是你需要考虑的，因为很容易影响一个人的工作效率。
最后是反馈和建议。我很喜欢这个问题，这是Eric Dodds（炉石首席设计师）交给我的，当有人找到你给出反馈或建议的时候，不要说没时间做或者我不同意那个想法，你有一百万种方式回答这个问题。不过，最好的是“你要解决的是什么？”
首先，这是对给出反馈者的尊重，不管你的想法是什么，这都意味着你是为了游戏好，而我看到了这一点。其次，这可以深度挖掘问题，让你知道对方试图要表达或者想解决的事情是什么。
其他沟通方式，还包括文档，尽量将你的设计文档保持最新版本，尽量做到简短。我们的《炉石传说》策划在这方面很自豪，因为他可以将文档控制在两页范围内，我对此非常认可，因为这样做实际上需要投入时间，因为减掉东西是需要时间的。
有时候，研发任务会分散到很多方面，这时候，流程文档是有必要的，这样，当你的团队加入新策划、新程序员的时候，他们知道过去发生了什么，可以更容易上手。最后是内容与脚本，当我和程序员合作的时候，往往让他们对自己的代码写批注，这样在一段时间之后，其他人依然能够知道你当时写这行代码的意图是什么，尤其是出现bug的时候。我对于内容和脚本也做同样的事情，这会在研发阶段带来帮助。
Bug报告很重要，策划不会给出bug报告，但他们是游戏最早的测试者，早期粗糙的功能、工具都是他们首先测试的，所以在某种方式上，他们就成为了bug报告者。因此，在他们的评价之外，最好是让他们给出更多的信息，而不是凭借直觉给出一个很笼统的评价，这是双方的合作，我们都在努力让游戏变得更好。
问题
工作流，尤其是刚开始的时候，人们很早就会拿到一些工具，这总会有问题出现。比如遇到问题之后，人们总会用手头的工具解决问题，不管它是否好用。我的建议是，询问个人偏好，尽快让你的程序员做出适合你用的工具，因为这不仅会提高你的工作效率，还可以消除你们之间的误会。
另一个问题是发现，不要笑我的图片，你能否发现关键信息？没错，就是那几个字母。在游戏设计方面，发现是很难处理的，这会给代码带来非常大的改变，尤其是比较大的游戏设计改动。如果你能够投入时间尽早发现比较大的改动，很明显是最理想的，但这并不是常态，如果沟通不畅，很容易导致两者冲突，因此，当你有比较大的改动，最好是与程序员协商。
过度加班
每个人都小心翼翼，如果有不擅长社交的人存在，那么过度加班就会变得很艰难。这一点我不希望说太多细节，但需要提醒自己，你面临的是两个不同类型的人群，你需要知道两者的差别，并尽量做好沟通工作。
这些问题其实最重要的是信任，如刚才所说，随着时间的推移，工作流会侵蚀彼此的信任，比如工具做不到我想要的效果、如果提出请求则会带来更多的尴尬。发现方面，策划与程序实际上存在某种契约，程序员将其写在代码里，而策划则没有这样的认识，他们更倾向于不断改变这个契约，然而这样的大改会让程序员很难做，这种契约不连贯是导致问题的原因之一。
策划与程序员的桥接方式
最后，我希望谈一些开始在行业内出现的桥接方法。这里我用了一个绳索桥，虽然两端有连接，但也有些危险是需要注意的，一个拿着大刀的人就可以将其砍断。
首先是技术策划，这是两者兼顾的岗位。你要么有一个具备很多编程技巧的策划，或者一个想要走策划方向的程序员，不管是哪一种情况，这里你都有了一个懂得双方语言的人。这些人在他们所做的事情上有很高的效率，不仅可以缩小两者的差距，还可以让双方的沟通更顺畅。
不过，这同样是有问题的，他们需要双倍的指导或者管理，他们既是策划又是程序员，如果得不到两方面的指导就会遇到一些green programmers的问题。我们都知道green programmers可能给代码库带来严重破坏，他们可能会在周末有了好想法的时候checkin一些未被通过的信息，并且加入游戏当中，认为一切都会很好。
我们非常不喜欢这样的情况，尤其是原本应该帮助我们的人。这很容易带来优化很糟糕的代码，或者很容易被破解的代码，对在线游戏而言这是灾难性的。
对于这个岗位，你还需要注意任务分配和职责的重叠。我还认为技术策划不应该是主策划，后者的脑海中只应该有玩家需求，技术策划，不管是否愿意，他们都需要考虑到游戏性能和可维护性。我认为跨学科是一些功能的未来，懂两个领域的人是不可或缺的。而且这会对公司文化带来影响，目前行业内有三个主流职业方向（策划、程序、美术），跨领域的人才有时候难以得到晋升，如果没有两个经理知道他们所做的事情，他们很难知道这个岗位的真正价值。
另一方面是管理方面，也就是双料创意总监。他是管理层面的技术策划，知道足够多的东西，可以成为两个领域的调节者和管理者。但是，由于需要处理两个领域的事情，因此他自己可能做不了太多的工作。
需要注意的是，程序员和策划是非常不同的人群，他们的思维方向也是完全不同的，这实际上不是坏事，而是好事。最优秀的系统和最佳游戏来自于策划和引擎方面的融合，程序和策划是对立的，它们之间的冲突和拉锯，会让系统变得尽可能好。
但由于它们如此的不同，你需要建立一个良好的开发者关系。在任何沟通中，沟通都是核心、信任是灵魂。
如果能够克服对应的问题，跨学科员工的价值很高。需要记住的是，每天都要提醒，我们都在同一个团队，都希望做伟大的东西，我们希望做出一些让我们自豪的东西。
如若转载，请注明出处：http://www.gamelook.com.cn/2023/07/520218
