系列累计创收近100亿，GIANTS分享：《模拟农场》如何打造制作管线

【GameLook专稿，未经授权不得转载！】

GameLook报道/模拟玩法是游戏市场出现比较早的品类之一，其中，农场经营模拟则是全球影响范围最广的一个细分赛道。

在这个细分市场，有一家名为GIANTS Software的瑞士厂商深耕了15年，而且只做一个《模拟农场（Farming Simulator）》系列。业内数据显示，该公司上一款游戏《模拟农场22》发布9周就卖出了300万套，系列累计销量在2022年初超过2800万套，当时在Steam平台累计收入超过12.6亿美元。

GDC2023演讲中，GIANTS Software发行协调员Kenneth Burgess分享了这款独特沙盒游戏的制作管线，谈到了该公司是如何将系列的每一款产品从预制作走向全平台发布的。在题为“模拟农场制作管线”的分享中，Burgess还简单复盘了《模拟农场22》研发中遇到的跨平台玩法挑战、展示了用于创造和交付成功游戏所需的各种流程和工具，解释了如何通过游戏内ModHub与模组社区紧密协作将UGC带到所有平台的游戏中。

以下是Gamelook听译的全部内容：

Kenneth Burgess：

今天的主题是“模拟农场的制作管线”，有很多内容要说。不过，先做一个简单的自我介绍，我叫Ken Burgess，是GIANTS Software的发行协调员，学的是媒体制作和工程（直到2016年），随后在学习和担任游戏测试员期间，做了很多不同的工作，2017年加入GIANTS工作室担任QA分析师，随后不久成为了QA主管，领导内部的一个7人QA团队。

四年之后，我在2022年加入了发行团队作为发行协调员，因为你们可能有人不知道，我们完全是自发行游戏，我做的事情基本就是为游戏版本设置步骤和产品，让他们做好提交准备，初始化并管理整个版本流程。更高层面上，确保我们的开发者们能在公司设定的截止日期之前完成游戏研发工作。

我的另一个职责，就是管理我们的产品在手游市场的可见度和表现，前不久刚刚宣布了《模拟农场23》。接下来介绍一下GIANTS Software：

我们做的事情有很多，不只是研发游戏，我们非常擅长模拟、软件和游戏研发，我们有很多来自农业领域的粉丝以及来自农业的人员。我们是发行商、是营销者，我们还举办自己的活动，由于我们是自发行模式，所以很多事也都是我们自己做的。我们还做电竞，也就是模拟农场联赛。

我们一共有4个工作室，一个位于瑞士的苏黎世，这里是我们的核心引擎团队和一些地图美术师所在的地方；我们在德国埃朗根也有个工作室，我也是来自这里，这里主要是脚本作家、软件集成、QA、营销、发行；在捷克共和国，我们有布尔诺办公室，这里是我们的载具美术师、角色美术师的所在地；我们还在美国芝加哥有工作室，主要是社区和支持团队。

我们主要做《模拟农场》系列，从2008年到现在一直从未停止，而且我们自那以后发展的越来越好。在所有主流平台，我们发布了15款游戏，包括手游。当然，我们还在与不少农业大品牌合作，因为，我们做的是农场游戏。

对于今天的内容，我们希望分享我们是如何研发《模拟农场》的。我们会先说游戏的预制作阶段，然后说一些游戏制作环节比较细节的事情，也会说到我们如何打造版本并将它分发给玩家，最后是跨平台玩法如何影响了我们的制作管线，以及为何与社区一起支持游戏的生命周期对我们如此重要。

预制作

我们先从第一个踏脚石开始。对我们而言，预制作通常可以意味着很多不同的事情，比如想法、会议、反馈、信息分析等等。我们通常是从我们称为“FS Next”的会议开始，基本上就是我们坐在一起分析收集到的所有信息，比如之前游戏的信息，还会提一些大问题，例如，模拟农场的下一步是什么？游戏下一个重大发行中都会有什么？

我们做的事情就是决定我们想要在游戏里看到的是什么、我们的社区想在游戏里看到的是什么？或许还包括品牌想在游戏里与我们合作的是什么？这个阶段我们通常会做概念验证创意原型，当然也会做一些研发项目，我们需要弄清楚，因为我们用的是自己的引擎，我们需要增加什么样的要求来支持我们规划的新功能？也就是确定项目规模，并且确定需要增加什么东西才能让我们想要的游戏成为现实。

为了搞定这一切，我们使用一个内部规划工具，我们把它简称为planner，可以在那里确定项目规模和内容，分配任务、将它们连接起来，细分任务、分配到项目中、分配给开发者们等等。我们用自有工具做这些的原因是，它与随后的制作管线有非常重大的关系，因为我们可以用的要求或插件有很多，但Planner才是一切初始化的地方。

我们的想法是使用并利用这个规划工具作为一个不断增长或动态化的游戏设计文档，它可以让我们规划项目，从概念和规模，直到与制作阶段有重大关系的单个资产和载具，每一个都有不同属性。所以我们可以在这里创作资产，然后追踪，这个模型是否做好了？是否已经集成到了游戏里？是否做了配音、有没有做过测试？

基本来说，planner就是我们开始游戏制作之前的初始化踏脚石，我们确定概念和规模，而且可以在研发过程中回访和修改。

游戏制作

为了更深度了解我们的游戏制作，知道不同部门在做什么，我们会谈到我们都有什么部门、他们是如何在制作期间彼此互动的，以及我们GIANTS是如何制作游戏的。

引擎

在一切开始之初，我们有自己的引擎GIANTS Engine。自2008年之后，对我们来说最重要的事情始终是拥有完全的控制，所以在能用于我们引擎里的开源工具之外，我们不会使用其他任何中间件或过于依赖某个软件。

《模拟农场》作为一个沙盒游戏，每个部分以及运行方式都有很具体的要求，这也是我们引擎的作用。所以，通常我们的引擎团队是第一个开始参与新游戏制作的，因为他们需要准备引擎，就像我之前所说，为功能或者下一款游戏做准备。不仅如此，他们还可能希望创造一些我们在制作阶段可能需要的工具或其他东西，例如，可能是QA可能需要的工具，或者美术师可能用到的东西，这都是他们负责。

随后，我们的制作团队开始工作。基本来说，我们需要从两个不同的艺术角度来看待，简单来说，就是地图美术师和地图，以及载具和工具。

美术与其他资产

地图团队也是很早就开始参与新项目的团队，因为需要为游戏做大量的调研，不光是需要消耗大量时间的游戏设计阶段，还包括研究本身。因为我们需要考虑，下一个游戏里我们要做什么地图？我们是在美国、欧洲，还是在南极开农场？这些都是我们需要确定基调的问题。

我们还会设定制作目标，例如地图上我们想要集成的地标，玩家开始的区域看起来是怎样？以及，我们想要在地图里定义的兴趣点。而且，这个阶段的很早期，我们会有与其他部门持续的反馈循环，包括地图和QA，因为地图制作者和美术师可能并不会总是以玩家角度看待他们创作的东西，所以得到一些其他观点是有必要的。

我们可以问测试员，这样的布局是否有意义？玩家能否理解？玩家开始区域有意义吗？这些都是我们需要很早就回答的问题，而且我们也希望在这个阶段很早就把所有人拉进来。

除了地图之外，角色、物体、建筑等资产还需要美术工作，包括其他用在地图上的资源，包括动物等可以用在游戏里的资产。

我们最新的游戏《模拟农场22》有超过400个载具和工具，所以设置一个创作循环是很重要的。我们有三个部门，如载具美术师、集成师（Integrator）、以及QA团队。你们可能会问，什么是集成师？这是我们内部的一个术语，他们从美术师那里拿到模型，然后不仅要为其做玩法脚本，还要做动画，负责将游戏加载到游戏里，将所有的特效集成到游戏里、带有需要支持的功能，确保为驾驶习惯和物理效果做了打磨，以便让它适合我们的物理引擎。

此外，我们在美术师、集成师和QA之间还有创作循环，他们之间需要不断交换信息，以便看是否能找到任何问题。而且，玩家们也可能在寻找可能集成到载具中的工具，这也是他们经常要跟美术师反馈的原因，这是个持续的循环。即便是离集成到游戏里还有很久，QA也可以完全进行功能测试，这些工作开始的很早且贯穿整个制作流程。

为了快速分享这三个团队，我们先从载具美术师开始。通常我们有载具的CAD数据，这也是我们与农业大品牌有紧密合作关系的原因。但是，如果我们有一个非常奇怪的载具或拖拉机，我们也会走出去自己寻找，发现并且扫描它，以便将它做到游戏里。因为比较老的机械没有现代数据，所以在没有数据的时候我们需要知道如何做3D扫描和参照图。

随后，我们的集成师会坐下来将模型分解为模块元素，例如玩家可能想要给他们的拖拉机增添的定制化轮子、贴花以及其他东西，还需要准备做动画，还需要确定材质，这些会交给美术师和集成师两个团队做。

而且，特定的玩法元素需要做一些定制化脚本，整个流程中需要做大量的反馈。然后，集成师还需要负责机器的驾驶行为，确保它遵守我们的物理引擎要求，例如车斗空的与装满货物的感觉差别是什么？它如何用马力运行，如果上坡是怎么样？这些小细节都是他们需要负责的。

我们还有音频团队，比如当我们扫描一个机器的时候，我们也会派音频师，他们也是团队的一部分，他们有很多种方式记录音频并部署声音。

然后是QA，他们在制作期间用很多不同的测试方法和测试规划。比如对一个特殊的载具，我们会有一个表格测试它的模块，取决于载具的不同，有些测试案例可能会或者不会用到。这些表格是通过很多年来确定的，如果学到了新东西，我们会对它更新。

载具和工具功能测试之外，我们还有整体玩法多人测试，这样，如果你之前玩过《模拟农场》，就会注意到我们为游戏增加了变化。所以你可以收割麦子，然后可以把它放到你已拥有的谷物磨中。这样你可以得到面粉，把它拿到烘焙坊，制作面包、蛋糕等等。

这一切听起来都很好，而且字面上也行得通。当我们的QA开始测试多人功能的时候，可能会出现冲突，例如一个农场主的磨被其他农场主运送谷物的时候会发生什么？这些东西都会比较令人困惑，所以早期加入QA团队是很重要的，因为到了最后，这会带来高质量功能和高质量产品。因此，QA要确保新功能不仅可以运行，还要有趣和有意义。

你们有些人可能用过bug追踪数据库Mantis，这也是我们主要用的工具之一。你们可能会问为什么，与其他bug追踪数据库相比，它有什么特别？因为它最适合我们的需求，因为我们可以为它创作定制化插件，比如我们可以导入一个载具，然后导出进行测试，让它立即可以被测试员测试，而且我们可以更好地对它进行筛选。

这也是我们所有内部规划工具的选择原因，刚才的Mantis只是其中一个案例。

QA团队的另一个主要工作，就是管理外设设备的支持，从非常有名的品牌到普通的东西，我们都会出去寻找，有些是网购，还有些是到硬件论坛寻找。因为，我们需要确保所有的外设都能被游戏支持。

我们通过XML创造了资产地图，当你使用一个设备的时候，你可以在PC上自己创造，但还有些地图是我们默认的，因为它们经过了大量测试而且行之有效。我们做这个设备库的原因是所有这些都被我们的游戏支持，哪怕一些支持可能发布之后出现了问题，我们也能快速在下一次更新中解决。

QA团队的一部分，是我们的本地化团队，我们还在多个项目之间用了一个专用本地化工具，这带来了连贯性，我们可以多次复用。它还有一个非常好用的标签系统，当你将一款游戏提交给索尼、微软、任天堂的时候，就会知道他们对一些文本的要求，例如，你在主机上玩游戏，电池没电之后，它会提示“请重新连接手柄”，这些都是很具体的文字，我们要确保没有改变特定词汇，否则的话，提交审核就会遇到问题。

它不仅帮我们做标注，还可以让我们在不同项目之间搜索标签，确保我们不同游戏之间的连贯性。

代码库

我们使用的代码库是Subversion，它甚至能被团队成员轻松理解，哪怕是没有很强的技术背景，比如营销人员或者QA。我们还可以用它做分支，当研发时间不够的时候，我们可以将一些功能放到后续的更新或者DLC当中，同时不耽误主要功能的研发，唯一需要注意的问题是代码合并导致的bug，以避免带来问题。

Auto Builder（自动化版本构建）

Auto Builder是一个基于服务器的系统，我们用它创造所有的版本。我们有一个规定，就是所有的载具都必须通过Auto Builder，因此我们没有手动版本，这样做的原因是，可以轻易重做同样的版本。

我们可以通过shell scripts对一切进行定制化，以便为不同的平台打造版本，还可以让我们追踪所有的提交和发行版本，因为它们都存在于Auto Builder里。所有这些版本管理都是通过一个好用的UI完成的，我们创作了版本配置，它定义一些shell scripts和行为，这也是版本制作的过程之一。

一旦我们打造了一个发行版本，或许我们希望同样的版本，但增加一些开发者工具，我们可以轻松做到，并确保代码库完全相同。所以，我们可以从同一个版本制作一个PC版本、PS4版本等等，他们的代码库相同，而且所有都可以平行完成，可以节约大量的时间。

Auto Builder的仪表盘也很好用，它传递了非常方便的信息，例如剩余的版本时间，版本完成后的ETA，可以对规划和资源管理带来帮助。而且，它会直接展示错误和警告，比如对失败的版本，它可以直接给出错误的原因。大多数时候，这些错误都是因为我复制粘贴出的错。

这样，我们可以一夜之间做一个版本并上传到一个平台，然后将同样的般般发送到其他FTP位置，例如外部合作伙伴等。基本来说，我们这样做的目的就是以最优化的方式充分利用时间，并确保这个流程对所有人都是流畅的。

版本部署

我谈到过导出一个版本，但它看起来究竟是怎样的？Steam和Epic通常会在发布的时候自动更新游戏，那么，我们该如何帮助那些通过其他渠道购买游戏的玩家，例如一些人是从我们网站或者零售店买的。

我们的方法是部署服务器（deployment server），所以，一旦Auto Builder创建了一个版本，我们就可以在一个部署服务器对它定义，如基础游戏、DLC，然后加一个特定ID，然后为其中几个打造一个包体。比如，我们做了一个DLC，那么，就会有一个包含了基础游戏和新DLC的包体，然后把它分配到具体分支。

到了发布的时候，我们就知道那个包体是一直在测试的，就不用再做任何新东西，把它同步到默认支线就行。

在后端，这看起来可能非常令人困惑，但问题是，用户角度看起来是怎样的？

这是我们的《模拟农场22》游戏登录器，在我们网站或零售店买游戏的玩家都会得到这个游戏登录器，我们把它称之为自动更新器。一旦你联网打开游戏，它就会检查是否有更新，然后就会下载并打包到你的游戏文件里，完成之后就可以立即开始游戏，就像Steam那样。

此外，这个工具还可以用来解锁其他分支，比如你是个KOL或者主播，我们会给你一个特殊的密码，让他们测试即将到来的特定版本。或者，如果他们想要随时回退到之前版本，我们要满足玩家。因为，有些玩家可能不喜欢某个更新，或者某个版本有了问题，这样等你解决了bug之后，他们可以随时回到这个版本。

跨平台玩法

现在，我想解释一下跨平台玩法在我们整个制作管线是如何运行的，因为它会影响很多事情。跨平台始终是我们需要注意的，因为它为我们带来了一些新挑战。它对我们很重要，因为跨平台玩法可以连接全世界的玩家，意味着不管你的朋友在什么平台，你们都可以一起玩，这也是我们非常提倡的，是很好的社交互动，也是未来游戏应该追求的。

但是，说起来容易做起来难。

因为在多人游戏里连接不同硬件平台的玩家是非常复杂的，因为每个平台都有不同的处理方式。例如在主机平台，不同客户端之间是没有直接连接的，我们还必须考虑语音聊天，因为每个平台对语音数据、包体有自己的控制协议，否则，玩家只能用第三方工具聊天。我们不想那样，我们希望玩家可以直接在游戏内语音聊天。

另外，我们还需要知道如何处理不同平台的多人游戏归属权，如DLC。假设一个人在Xbox设备玩游戏并且购买了DLC，那么所有人还能联机玩吗？谁可以使用这个DLC中的载具和内容、谁不能使用？我们该如何处理平台独占DLC或者皮肤这类的东西？

或许最重要的问题是，我们如何同时给所有这些平台更新？PC和Mac很容易，因为我们直接可以给客户端发送更新，但其他平台就有一些认证程序。

我们是怎么做的？先从多人玩法的网络代码开始，由于主机和PC之间无法直接连接，我们创造了世界范围的中继服务器（relay server）连接所有平台的所有客户端，这也是我们在全球主要国家和大城市部署服务器的原因。

对于语音聊天，我们选择了OPUS音频解码器，因为它是一个非常不错的免费开源解决方案，且适合我们的需要。或许我们最重要的一个解决方案，就是如何在不同平台打补丁？对于补丁，我们需要同步所有版本以便同时发布。

作为给所有开发者制造截止日期的基础，我们需要了解需要最长认证时间的平台版本，将其作为更新发布时间的基础。例如，所有平台当中，有一个最长的需要一个月时间通过认证，那么我们就会提前一个月确定发布日期，因为代码库需要保持相同，而且不能有任何不透明。

处理DLC归属权方面，我们允许玩家根据自己的状态确定是否要开启或关闭一些内容，如果房主拥有一个DLC，加入者没有，那么他可以在这次游戏的时候关闭那部分内容。不只是DLC，还有游戏模组，对于平台独占模组或者推广内容，我们会直接更新到游戏里，哪怕你没有，但仍然可以加入，我们要确保没有连接限制。

模组

最后但同样重要的是模组，也就是UGC内容。我们有很出色的模组社区，他们非常有创意、充满热情，我们认为继续提供这些新颖和创意的想法，对于《模拟农场》是非常重要的，尤其是这些内容来自对游戏和社区很有热情的人，而且他们希望丰富所有人的体验。

模组在PC平台很受欢迎，但我相信，我们即便不是第一个，也是极少数在主机平台支持模组的团队，从《模拟农场17》就开始有了。在PC平台，你可以从互联网直接下载一个模组，然而在主机上，这些平台对模组内容有大量的要求，他们希望做到更加安全，这也是我们为《模拟农场》系列创造GIANTS ModHub的原因。

基本来说，这就是一个让用户可以下载高质量和经过测试模组的平台，从单一可信的来源，也就是直接从游戏里下载。即便是在PC上，你可以到其他网站下载模组，也可以直接在游戏里选择，这对我们所有玩家来说都是非常好的。

我们有专门的模组测试团队，他们处理模组申请，而且在PC和主机平台测试这些模组，流程如下图。

大多数之后，提交模组的人阅读了指南，但仍然没有通过，我们需要给他们反馈，告诉他们需要怎么做才能通过审核，一旦通过，就需要在PC平台测试功能，确保模组不会导致游戏崩溃。然后是在主机平台测试，最后正式发布到游戏里。

我们还提供了一些激励措施鼓励创作者将他们的内容提交到ModHub，我们有一个奖励项目，所有的模组下载都会带来一些收入，对应的创作者就可以得到收入。或者，玩家们也可以选择捐赠创作者。

另外，我们还有颁奖项目，一旦模组达到特定下载里程碑，我们会奖励创作者牌匾，他们可以放在家里展示。这是我们想社区表达感谢的一种方式，让他们知道，我们在意且感激他们的努力和热情。

总结

将《模拟农场》制作管线作为一个整体来看，或者将其作为灵感启发，与制作阶段的概念验证是很重要的，因为设置项目规模是最基础的事情，这确定了你计划做的事，并且兑现承诺。

另一个很重要的是，不管有多早，都要让所有研发部门尽早介入，因为得益于持续的反馈，早期参与意味着更高的品质，还可以让一些话题有更多的视角，尤其是你在做一些无法从所有角度思考的东西，能够一直得到不同的观点很重要。

我们还提倡版本流程自动化，包括交付在内，尤其是当你为多个平台研发的时候，这很重要，能帮你留出大量的时间做其他重要的事情。

我们认为跨平台是未来。所以，不要害怕面对新挑战，因为你得到的奖励会让一切麻烦都是那么值得。

我们觉得要鼓励UGC和模组创作，如果你的游戏可以做，就尽量尝试，因为这对于想回馈游戏和社区的人来说是一种奖励。你的玩家会很喜欢，还会让社区和游戏品牌保持增长。