45岁的日本人来上海大厂做制作人：好难，但我挺过来了

做游戏之前，先学会沟通。

整理/以撒

3月20日，在美国旧金山举办的GDC大会上，不少知名游戏人都在做分享。其中有一位吸引了不少注意——冨永健太郎。没错，就是那位在任天堂参与过《旷野之息》，之后加入叠纸游戏，担任《无限暖暖》执行制作人的日本设计师。

现场有多火爆呢？葡萄君从机场马不停蹄地赶到，饭都没吃，提前20分钟到场，结果还是被大队人马挡在门外，心情十分绝望。好不容易入了场，依然是爆满。分享结束后，还有不少人围过去向冨永健太郎要签名。

说起来，这还是叠纸第一次出现在GDC这个舞台上，他们选择分享的话题也很有意思，不是硬核的技术、玩法解析，而是在他们这个涉及大量远程协作、跨语言沟通的项目中，如何才能消除沟通上的壁垒，让新手设计师也能做出合格的设计，而且还能充分理解背后的逻辑。

听到冨永健太郎聊到他们面对的那些问题，你可能会感叹，由这位日本设计师加入中国团队，来带这么大规模的一个项目，还真是困难重重啊。不过好在，他们已经总结出了不少有用的方法，也形成了可靠的解决方案。

以下是经过整理的演讲内容：

非常感谢大家今天光临，说实话，我没想到会有这么多人来，还有点紧张。

首先简单介绍一下我的背景：我于2002年毕业于庆应义塾大学研究⽣院，同年加入任天堂。此后的近20年里，我以游戏设计师的身份参与了各种游戏的开发。

自2022年起，我加入叠纸游戏（Infold Games），作为副总监全程参与《无限暖暖》的开发。《无限暖暖》是暖暖系列的第五部作品，延续了换装、摄影等最经典的玩法，同时新增了跳跃、平台探索等新的特色，致力于打造一个温馨的开放世界。

这里有人玩过《无限暖暖》吗？我们现在看到的画面，展示了引擎中实际的游戏渲染效果，其中大部分都由我们的新手关卡设计师设计。

当我加入《无限暖暖》项目时，团队已有数百名成员，大部分成员都在上海工作、只讲中文。因此，我和翻译是最早加入团队的日本人。

对一名语言不通的人来说，以副总监身份加入项目并不常见。所以除了游戏开发本身的挑战之外，我们还面临两大额外障碍：

一个是语言壁垒，作为团队中唯一一个讲日语的人，我需要通过翻译与中文团队沟通，你们应该能想象到那是什么感觉；

另一个是代际差异，这个项目中，大多设计师都是20~30岁，而我当时已经45岁，和最年轻的同事差了有20多岁。同事们一看，这个新来的外国人老得可以当他们爸爸了，这就挺吓人的。

所以今天，我想从翻译、沟通和讨论三部分展开，讲讲我们如何克服这些障碍——多亏有翻译，我们才能克服语言壁垒，解锁后续的沟通；进而在把设计落地的过程中，借沟通和讨论克服代际差异。

01

翻译

首先，我们来聊聊翻译方面的事。

因为有语言障碍存在，想要克服代沟，最关键的一点就是通过翻译，做到强有力的高效沟通。

在这个项目中，我们使用了内置机器翻译功能的飞书（Lark），它可以实时互翻中日双语的消息。如图所示，双方可以看到翻译结果，用母语实现顺利地简单交流——这不是啥重要的内容，大家不用找眼镜。

另一个工具，是基于ChatGPT的“中日翻译助手”，它能自动处理文档和聊天内容，进行双向翻译。相信大家都经历过，机器翻译有时会会丢失一些语义，对吧？每种翻译工具都各有特色和长短，所以通过对比两种工具的翻译结果，我可以更准确地理解内容全貌。

我们还使用机器翻译，处理开发过程中创建的网页文档，飞书内置了云端文档的自动翻译功能。此外，我们利用ChatGPT开发了一个自动翻译网页文档的独立管线。有了这些工具和管线，我们就不用再从头手动翻译，显著减少了沟通障碍、提高了效率。

接下来，我们来聊聊翻译团队。因为机器翻译仍然存在其局限性，我们在深度沟通中高度依赖翻译人员。

一开始，我们只有一名翻译，但随着团队发展扩大，一个人就兜不住了。所以我们增加了翻译的数量，并且把每个成员分配到不同职能的小组，比如玩家组、场景组、地牢组等等。规模化运作起来后，最多有六位翻译协助我工作。

但这些负责对接的翻译人员，不仅要精通中日双语，最好还得有游戏开发的相关经验。要招到这样的人真的很难，因为他们可能更倾向于去做研发。

所以，我们招聘了一些热爱游戏，但没有那么多游戏或游戏开发经验的人，从翻译文档开始，逐步交给他们更复杂的任务，比如会议翻译。

我们在日本和上海都有翻译人员，这能让我们随机应变。比如我前往上海时，日本团队可以直接与我沟通，而上海的翻译，则可以直接与当地的开发团队沟通。虽然线上会议也行，但在信息传达上，面对面沟通肯定还是更清晰。这样在两地安排翻译、尽可能当面沟通，也让我们很好地缩小了代沟。

所以在加入项目几个月后，我就去上海待了大概六个月，直接与开发团队一起工作。即使我们需要翻译帮忙，但和从未谋面的人面对面沟通过，还是会显著降低心理上的障碍。

02

沟通

聊过沟通方式之后，我们来聊聊沟通本身。

你们熟悉这句话吗？“知己知彼，百战不殆”——这是中国公元前五世纪，孙武所著《孙子兵法》中的⼀句著名谚语。

我相信，这一原则同样适⽤于游戏开发，但不是让你树敌，而是要把“敌我”视为项目同事和你自己。如果所有项目成员都能充分理解彼此，开发就会相当顺利，大家更容易朝着一个地方使劲儿。

为了充分理解同事的想法，我经常会用问题轰炸他们。因为这些年轻的关卡设计师们，往往会解释他们提案背后的目的和方法，但却不会详细说明选择这种特定方案的潜在逻辑。这在聊天发消息之类的文本沟通中特别常见，如果是结构化文档可能还好点，但早期还没有这种文档。

所以，如果有什么我不能完全理解的地方，我会反复提问，问到我完全理解为止。我特别执着，执着到很多年轻设计师肯定都被我问恼火了。

我们来看一个简单的例子。假设一位设计师提议：“这个Boss太强了，我们应该降低它的血量。”这看起来很合理，但削弱Boss的方法有很多种⸺降低伤害、减慢移动速度等等。这时我就会问：“为什么选择降低血量？”

如果回答是：“Boss太难打中，打败它花的时间太长了”，我们就得想想，在这种情况下，与其简单地降低Boss血量，不如换种方法。比如调整机制，让玩家更容易打中它。

攻击落空会让你沮丧，反过来说，命中时就会有满足感。如果打Boss的体验很好，那它血量高点，让玩家多打打可能也不是坏事。所以像这种情况，我们就可以考虑其他解决方案，比如增大Boss的弱点，或让它更长时间地暴露弱点。

另外，有经验的开发者在听取意见时，有时可能会不太理解年轻设计师的推导过程。

比如在《无限暖暖》中，我们在地图上放置了一种名为“噗灵”的游戏货币，其中一个目的是引导玩家。有一次，一位年轻的关卡设计师在地图上列了一长排噗灵，你一眼就能看出，这位设计师显然希望玩家沿着那条路线前进。

然⽽在开放世界游戏里，像这样过度引导，可能反而会让指引显得不⾃然，甚⾄让玩家有被强制走这条路的感觉。想象一下，玩家们要是一直追着噗灵跑，可能就会错过很多其他的体验或场景。所以我认为，我们应该减少地图上噗灵的数量。

在这种情况下，有经验的开发者可能就会不解释逻辑，而是直接简单地指导一下，跟他们说：“这么明显的事，你怎么就搞不懂呢？”

不过说到底，我和很多年轻设计师之间都有近20岁的年龄代沟，我们对“正确”的理解有所不同，也是很自然的一件事。

比如我小时候玩游戏那会儿，我玩之前就不会做任何研究，而是享受解决挑战的乐趣。但如今的许多玩家，包括我儿子，都会在玩之前看看攻略视频，提前做好准备。

这不是意识形态对错的问题，而是别人对“正确”的理解标准，可能就是和你不一样。所以即使某些事情对你来说显而易见，你也应该清晰明确地表达出来，确保双方理解一致。

通过重复这一过程，年轻设计师们就能改进自己的想法，让我们未来少兜些圈子。我知道这看起来是一项很沉重的前期投入，但这也是不应削减的成本。

另外，在指导年轻设计师时，我会确保自己不仅说明了目标和方法，还解释了决策背后的理由。你可以理解为，这是“不断提问直到我理解”的反向操作。如果有人没完全理解目的和逻辑，就去实现一个功能，那结果不太可能特别好。这同样受到语言障碍的影响。

不过，即使是用同一种语言交流，要准确传达关卡设计的细节也非常困难，更不用说跨语言交流了。

像是在放置噗灵的例子中，我可以指定精确的坐标，让设计师完全按我的要求布置。但如果真的需要做到这一步，那我自己动手可能会更快一些。

在这种情况下，解释逻辑就容易多了。比如，与其说“在这里放置三个噗灵”，我会说：“减少噗灵的数量，以免玩家感到被强制限制在特定路线上，并避免他们忽略其他环境元素。”

如果设计师理解了背后的逻辑，即使精确的放置位置稍有不同，最终的实现效果通常也会很高。“按照我的指令精确放置噗灵”并不是优先事项，“理解关卡设计的目的和逻辑”才是关键。

通过这种反复沟通，我们在项目中积累了大量知识。由于我们独特的开发模式涉及大量远程工作，我们相当依赖于聊天沟通，此外还要创建文档来解释设计规范，这导致一个特别的情况——我们积累的大量知识，都以文本沟通形式为主。

所以结合这些过去的反馈，我们提取目标和原因、分类整理，创建了一个“反馈库”，以便关卡设计师可以随时查阅。这使得任何需求，都能立即追溯到过去所做决策背后的逻辑。对一款实时运营的游戏来说，这个资料库会不断积累。

通过创建这个资料库，我也发现，尽管反馈可能因情况而异，但很多时候它们的目标、底层逻辑和本质都是一致的。

举个例子：玩家试图从一个平台跳到另一个平台，但在转动视角时，他的视线被地形遮挡住了。还有些其他类似的情况，比如当玩家试图向前眺望，或是窥探洞穴、洞口等地方时，他们的视野可能会被意外出现的地形遮挡。

在这些情况下，设计师就应该思考，玩家将如何与这种不同类型的场景互动、完成挑战。不过即便这样遵循了引导，如果开发者反而让游戏体验变得困难或挫败，那也是个问题。

所以说，设计师有自己的反馈是很重要的。我们会模拟玩家的行为，尝试判断很多问题，比如“我去了这里，摄像机会在哪里”等等。

总的来说，与其收集特定情况，或摄像机移动不起作用时的特定反馈实例，简单地列出反馈条目，还不如理解玩家行为背后的逻辑，将知识结构化作为我们的参考，这有助于使其背后的根本目标和逻辑，被⼴泛应用于不同想法中。

03

讨论

现在，让我们进⼊最后⼀个话题：讨论。

通过这样的反复沟通，我们在团队成员之间建立了共识，确保游戏规范也在这个基础上制定，指向同一个方向。当我们实现不同特性的时候，整个团队都会测试、发现问题，然后讨论解决方案，进一步提升游戏的质量。

我来举个例子：在《无限暖暖》中，有⼀个关键物品叫“奇想星”。通过收集这些星星，玩家可以获得新的服装和能力。大家可以看到，大喵视野会让玩家知道附近有奇想星，并通过图标帮助玩家定位。如果星星在可见的屏幕范围内，它还会发光。一旦星星被标记，即使玩家关闭大喵视野，其位置仍然可见。

但你可以想象一下，我们最初的提议，其实是用引导线直接从玩家的起点连向奇想星。但在开放世界游戏中，我认为探索是体验和游戏玩法的一部分。如果我们强迫玩家走特定路线，就会削弱这种探索的乐趣。

一开始，我提出了一个想法：其他部分都和最终方案类似，只⼀个主要区别——没有追踪功能。你一关闭⼤喵视野，奇想星就又不见了。这意味着玩家需要记住大致方向，自主搜索。我认为这种基于记忆的探索，将为游戏增添乐趣。

随后我们做了一次团体测试，这么做有两个目标，不仅要测试搜索功能，还要看看游戏从开始到结束的运作中，会发生些什么。因为大喵视野会在游戏中被频繁使用，所以我不想只在特定情况下测试这个功能。

结果我们发现，最常见的反馈要么是“找到奇想星太难了”，要么是“得不停重新打开大喵视野”。

如前所述，我最初的设想，是让玩家记住奇想星的位置，并在关闭功能后搜索它。但很多玩家会不太确定——它真在那儿吗？我记不清了，天呐，太麻烦了，重新打开看看吧……这意味着，玩家们并没有像我设想的那样沉浸体验。

我和年轻的设计师讨论了这一问题。然后我们就决定调整系统，让大喵视野在关闭后仍然显示奇想星的位置，而不是把我最初的想法强加给他们。这就是最终版本中的追踪功能。

在实现追踪功能、减少搜索的激活次数后，我们再次测试，发现不再有反馈说找星星的乐趣减少或消失了。这让游戏在整体上变得更平衡了，因为通过平台跳跃探索奇想星的位置，本身就是一种乐趣。即使增加了追踪功能，它也没有减少玩家尝试穿越不同地形时的乐趣。

这么一看，我试图强迫玩家记住位置的想法，实际上有些过头，反而让游戏玩法变得复杂。所以在和许多年轻设计师讨论之后，我们最终采纳了他们的大量想法，而不是只有我的。

04

总结

最后，让我们总结⼀下今天的分享。

为了克服语言障碍，我们依赖于三大解决方案：机器翻译、翻译团队和商务差旅。如果缺少其中任何一个，我与团队之间的沟通将难以实现。但不幸的是，正是由于我们启动了这些机制，我的中⽂学习完全没什么进步，而且你们可能也猜到了，我的英语一样不太好。

为了克服代际差距，我们通过提问来沟通，分享我们的思维方式，协调思维达成共识。这在跨境工作中非常重要——其实在当下这种信息驱动的社会中，对任何无法达成一致的情况或场景而言，这一点也都挺重要的。所以我鼓励并恳求所有的游戏设计师，无论你们是在跨国工作还是远程工作，都要考虑这种沟通方式。

另外，我们一直在将所有积累的见解整理成一个反馈库，以便团队随时可以参考。我相信，这是我们在沟通时端正态度、不投机取巧，才能得到的副产品。

最后，游戏开发中最重要的一个方面就是游戏测试。在构建游戏内容之后，你要基于结果讨论和完善。如果我们投入时间良好沟通，那随后的游戏开发就会更加顺利。最终，正是这种迭代学习的过程，会真正帮助设计师们不断成长和超越自我。

通过培养年轻的关卡设计师，我们成功发布了《无限暖暖》。在已实现的机制中，当然有⼀些是我亲自指导的，但正如我之前提到的，许多是由年轻关卡设计师提出的。对于尚未体验过的朋友⸺我强烈推荐你们试玩！感谢整个开发团队，帮助组织本次GDC分享会的工作人员，以及今天在座的所有人！

05

Q&A

问：你如何将非常规的设计理念传达给程序员？

答：在这种情况下，我可能会尝试使用非语言形式来表达，比如依靠图表——虽然我不擅长绘画，但我会画一些简笔画，然后努力传达意图。或者我们可以在网上找到类似的参考视频，再用文字补充。因此，我建议大家用不同的沟通方式来传达想法。

问：你对年轻设计师有很强的信任。我想知道，如何培养这种信任和成长型思维模式，以及如何让其他资深人员，愿意将一些控制权交给他们的下属？

答：这真是个好问题。在这种情况下，如果他们的年龄与我相仿甚至更大，我显然会以他们应得的尊重去接触他们。但我会尝试展开更具逻辑性的对话，努力让他们看到全局。

或许可以退一步说：嘿，如果我们这样做，先尝试A，然后想象B和C，再模拟可能会发生的情况，最后争取让他们站在我这边。从整体角度来看，这样不是更好吗？

问：你们会在反馈库中使用什么工具？更新频率和节奏是什么样的？

答：我们使用类Wiki工具整合文档、链接和视频。随着时间的推移，所有内容都会被收集和积累起来。

就节奏而言，我们实际上很难在开发过程中完全投入其中。因此，我是在游戏即将发布时，才开始创建这个资料库的，最终才赶上进度并开始整理。直到现在，我仍在继续完善它，因为游戏会持续进化。

很多时候，我们在早期沟通或文档中认为非常好的功能或想法，到发布时可能已经不再适用，甚至无法真正服务于我们最初设想的游戏玩法。

问：这是你参与制作的第一款暖暖IP系列游戏吗？你最喜欢的机制是什么？

答：是的。在机制方面，我在演讲中介绍过了，大喵视野是我非常自豪的一项设计，不仅仅因为这是我的想法，而是因为它汇集了许多设计师的想法。

奇想星也是一个非常重要的机制。在一个开放世界游戏中，我知道我们需要鼓励人们收集这些星星，但我也确实希望他们能拥有探索的感觉。以这个概念为基础，如果设计得过于简化，像从A到B画一条直线那样，就会限制整体体验。

而我最初的想法——要求玩家记忆并探索，对许多设计师来说显然太复杂了。于是我们经过游戏测试，反复迭代后最终实现的这一套机制，是我们很自豪的一部分。

问：你说会有团队成员被你问得恼火，怎么处理这种团队摩擦？

答：如果是面对面交流，我可能会说：让我们先放下这个问题，思考一下，等会儿再回来重新讨论。

但无论是好是坏，远程工作或文字沟通，确实会降低沟通的清晰度。我们团队大多是远程工作，沟通就主要依赖文字。在文字沟通中，你可以就把信息那么搁着，稍后再回来处理，所以情绪成分往往会被抽象化，你可以有时间思考对方的意图是什么、如何回应，而不必总是担心情绪成为主导因素。

也许当你第一次读到文字时，会觉得“我很生气，这人到底想干什么？”但随后你就有机会冷静下来——我自己也是如此。然后你可能会想，也许这就是他们想表达的意思，于是你可以用更合适的方式组织回应。所以在某些情况下，文字沟通可能反而比面对面交流更适合实现目标。

因此，在不同情况下确定使用哪种沟通方式，是我处理这种情况的核心方法。