《Mongil: Star Dive》为全球玩家复兴了怪物驯养世界。在将这个系列现代化、面向新一代玩家时，团队的主要目标是什么？

我们的主要目标是延续原作的魅力，同时以符合当下潮流、易于上手且视觉上独具特色的方式，将 Monster Taming 重新介绍给全球玩家。首先，我们希望游戏易于上手，并能在较短的游戏时段中享受乐趣，让玩家可以随时投入冒险，而不必感到被沉重的时间投入所束缚。与此同时，我们通过电影化过场动画和全程语音强化了故事沉浸感，让体验依然丰富且富有情感吸引力。

我们还重新审视了原作的核心特色，并以更现代的设计理念对其进行了重建。一个很好的例子是怪物融合，这是原作的标志性系统之一。在 Mongil: Star Dive 中，这一传承演变为“Monsterling Combine”系统，既保留了成长与发现的兴奋感，又让体验更加精致、直观。我们在战斗方面也采取了类似方法，让直接操控角色感觉更快速、更具动态感，也更符合当今玩家的期待。

在视觉上，我们旨在创造一种既怀旧又新鲜的风格。我们没有沿用原作更简单的 Q 版风格，也没有采用早期版本中更写实的比例，而是借助 PBR 技术，以高质量的风格化渲染重新构想角色阵容。这让我们在保留干净轮廓和富有表现力动作的同时，获得了更强的材质细节感。Mina 和 Verna 等角色依然承载着老粉丝记忆中的身份特征，但它们已经被全面重做，以向首次接触该系列的玩家呈现更精致、更现代的外观。

这款游戏将角色驱动的叙事与怪物收集和快节奏动作战斗融为一体。团队如何平衡叙事、角色个性与玩法系统，从而打造出统一的体验？

我们的做法是让故事、角色和玩法感觉都朝着同一个方向发力。叙事沉浸感一直是团队的首要任务，因此我们设计每个可玩角色时，都会让他们在故事中承担明确的角色，并帮助推动每一集向前发展。我们不希望角色让人觉得只是战斗单位而存在。相反，随着玩家推进故事，他们会逐渐了解每个角色的个性、情感弧线和背景故事。

这种推进有助于建立更强的依恋感，让玩家愿意在叙事和玩法上继续与他们同行。与此同时，我们知道仅靠主线故事不足以充分挖掘每个角色。为了增加深度，我们在整个游戏中构建了多层叙事，包括支线任务、NPC 互动、特殊事件，以及嵌入装备中的背景设定。

这些元素让我们能够以契合整体体验的方式扩展角色和世界。最终，我们的目标是构建一个统一的结构：故事为角色收集提供语境，角色依恋增强玩家动机，而玩法则成为叙事的自然延伸，而不是与之割裂的东西。

《Mongil: Star Dive》是使用虚幻引擎5打造的。在构建游戏的视觉风格和世界时，UE5带来的最大优势是什么？

实际上，我们并不是从一开始就用虚幻引擎5启动这个项目的。开发最初是在虚幻引擎4上进行的，之后随着时间推移逐步升级。因此，我们对UE5的体验，与其说是从第一天起就采用它的各项功能，不如说是在评估引擎如何演进，以支持我们此前一直在自行解决的技术挑战。

对我们来说，虚幻引擎最大的优势之一就是可以直接访问引擎源代码。这种灵活性在视觉方面尤为重要。我们实现了一个自定义着色模型，从而能够在更深层次上控制光照管线，达到我们想要的精确外观。我们的目标并不是完全扁平的卡通风格，而是一种兼具赛璐璐着色可读性和更真实材质响应的风格化外观。

默认的着色模型不足以实现这一点，因此能够在引擎层面自定义渲染和光照是一个巨大的优势。我们也从材质图表（Material Graph）、动画蓝图（Animation Blueprint）以及更广泛的蓝图框架等工具中受益匪浅。它们为程序员提供了一种以可视化方式组织复杂逻辑的清晰方法，同时也让美术人员能够更直接地进行尝试，而不必每一次迭代都依赖代码。这种平衡为团队带来了极大的创作和技术灵活性。

在世界构建方面也是如此。由于项目启动时，World Partition 尚未成为我们工作流的一部分，我们开发了自己的系统，用于连接以独立关卡文件构建的地形。除了无缝流送之外，我们的方法还能在不同主题的相邻环境之间自动混合地形高度和表面纹理。这帮助我们在各区域之间保持自然的过渡，即使各个团队是在单独制作各自的关卡。

最后，虚幻引擎一直是多平台开发的坚实基础。PC、主机和移动端都有不同的渲染要求和性能限制，而虚幻引擎提供了一套成熟的工具集，用于跨这些平台进行优化。大量自定义确实会在升级引擎版本或在每个平台上验证自定义着色器时带来额外工作，但即使存在这些开销，虚幻引擎仍然非常适合我们正在制作的这类游戏。

游戏采用受动漫启发的艺术方向，将赛璐璐风格的角色面部与更真实的材质和光照相结合。团队在技术上如何实现风格化角色与高质量渲染之间的平衡？

这是我们花最多时间打磨的领域之一，因为赛璐璐着色和真实感渲染从根本上由非常不同的视觉目标驱动。如果只是把它们简单叠加在一起，结果往往在视觉上显得不协调，而且两边都不够令人信服。从技术角度看，我们定制了光照模型，将点光源响应分解为更可控的阶段，这帮助我们实现了与赛璐璐着色相关的更清晰的色调分离。

对于面部和皮肤这类仅靠标准着色不够的区域，我们还使用了有向距离场（Signed Distance Field，SDF）技术，以创造更稳定、更便于美术控制的结果。我们对边缘光和镜面高光采取了类似的方法，对它们进行定制，而不是完全依赖默认实现，从而更好地支持我们想要的风格。与此同时，对于服装等材质，我们希望保留基于物理的渲染的优势，因为它为整体画面增添了丰富度和材质的可信度。

挑战在于让这些 PBR 元素与更具风格化的角色特征自然地并存，而不显得脱节。解决这一平衡需要大量迭代，不仅在技术上，在艺术上也是如此。最终，正是美术与工程团队之间的紧密合作，让我们达成了既风格化又高品质的视觉效果。

战斗围绕三人小队展开，玩家可实时切换角色。从系统设计的角度来看，你们是如何构建战斗框架，以支持流畅的角色切换，同时保持动作的可读性和响应性？

我们并没有从零开始构建全新的战斗框架，而是专注于最有效地利用虚幻引擎已经提供的系统。关键决策之一是以非常细粒度的方法，根据每个角色的战斗定位和状态来组织主资产（Primary Assets）。即使是同一个角色，根据其是在队伍中待命、作为助手出现，还是由玩家直接控制，所需的资源也各不相同。

我们没有把所有内容作为一个单独包加载，而是设计系统，使每个状态所需的最小资产包在正确的时间才被加载。我们对动画蒙太奇、声音和视觉效果等资源也采用了同样的方法。我们不是预先全部加载，而是依赖异步加载，让每个元素在需要时才被精确引入。

这有助于角色切换在战斗中显得即时且响应迅速，同时通过确保任意时刻只有必要的资源处于活动状态来控制内存占用。就战斗可读性而言，这很大程度上受美术方向和视觉效果影响，但底层系统仍然起着关键作用。

如果角色切换哪怕引入很小的加载延迟，动作的时机和呈现就可能开始显得不对劲。因此对我们来说，响应性、可读性和视觉打磨都紧密相连，战斗框架必须同时支持这三者。

游戏中最为有趣的机制之一是魔物灵（Monsterling）系统：被捕获的怪物会转化为装备，用来改变能力与战斗效果。这个系统在开发过程中是如何演变的？在实现过程中又遇到了哪些技术挑战？

魔物灵系统是为了传承原版怪物驯养系列最具代表性的理念之一，同时将其适配到《Mongil: Star Dive》的方向上而构建的。在原版游戏中，玩家收集怪物、将它们融合为更高阶的形态，并直接带入战斗。然而在《Star Dive》中，我们希望核心玩法与情感重心始终围绕可玩角色展开。这促使我们将怪物重新诠释为“魔物灵”（Monsterling）：一个由角色装备的独立系统，而不是一套单独的可玩角色阵容。

在 CBT（封闭测试）中，魔物灵主要作为支持角色成长与战斗定制的装备发挥作用。与此同时，我们一直在持续研发，让它们在整体体验中显得更有生命力、更具存在感。这包括让它们在视觉上伴随玩家、或更直接地协助战斗等想法，从而使角色与怪物之间的羁绊随着时间推移显得更紧密、更具动态感。

从系统层面来看，实现过程本身相对顺利。我们的装备、能力与技能系统在设计初期就已考虑到可扩展性，因此新增像魔物灵这样的物品类型并不需要重建核心结构。由于底层框架本就具备灵活性，团队得以将更多时间用于打磨该功能的设计层面，尤其是关于成长、融合，以及魔物灵组合应提供多少策略深度等问题。

其中更具意义的技术与视觉挑战之一，来自魔物灵在游戏中的呈现方式。由于它们以类似装备的形式附着在角色身上，我们希望它们不只是静态的挂件。在开发早期，我们对使用虚幻引擎的物理系统持保守态度，因为多平台支持，尤其是低端移动设备上的性能表现，是重中之重，而且项目最初启动于虚幻引擎 4 时代，当时该领域存在更多实际限制。

随着该功能不断演进，我们看到了更积极地运用物理系统的机会，让魔物灵拥有更强的运动感与存在感。随着迁移到 Chaos 物理系统并扩大移动端支持，我们得以进一步推进这一点，使装备与魔物灵的视觉效果显得更加自然、响应更灵敏。

团队提到开发了一套内部触发器工具，用于管理战斗机制、AI 行为和事件逻辑。能否解释一下这个工具如何运作，以及它如何帮助设计师更快地迭代战斗场景？

我们知道，从纸面上看，这种做法未必是最符合趋势的。从结构上说，它是一个相当经典的基于触发器的系统，但它契合我们团队想要构建内容的方式。在虚幻引擎中，怪物 AI、战斗逻辑、关卡机关和谜题交互等系统往往最终由不同的工具和工作流来处理。我们想把这些统一到一个框架中。

因此，我们基于模块化的事件、条件和动作单元，构建了一套内部触发器系统。设计师可以组合这些模块来创建各种玩法场景，而无需每次都直接依赖程序支持。这就是该工具的核心价值。我们最初的目标是在一个完全自定义的编辑器体验中同时支持编写和调试。

但在实际制作中，受生产限制影响，调试部分并没有发展到我们期望的程度。于是我们采取了更务实的做法，自定义虚幻引擎现有的界面，比如大纲视图、属性检查器和蓝图细节面板工作流，尽可能减少操作摩擦。我们也非常重视对设计师友好的易用性，因此事件、条件和动作条目中的变量都可以通过简单的点击式工作流直接调整。

随着模块库不断增长，系统也变得更强大。一旦设计师拥有足够的构建模块，他们就能自行迭代越来越复杂的场景，无论是让 AI 对环境变化做出反应、让 AI 单位互相影响、通过变量控制蒙太奇行为，还是把关卡事件、序列和战斗动作连接成更有机的玩法流程。

设计师还可以实时调整自定义变量，以控制节奏、处理边界情况或构建安全检查，而无需等待工程支持。由于通常只需引入新的事件、条件或动作模块就能添加新功能，迭代速度会随着时间推移而提升，而不是变慢。当然，这套系统也有局限性。最终成果的质量仍然在很大程度上取决于设计师对该工具的熟悉程度。经验丰富的设计师可以通过创造性地组合现有模块来解决各种问题，而经验较少的用户则更可能要求全新的功能。

而且随着场景变得越来越复杂，即使整体触发器流程仍然容易理解，调试特定变量和微调行为也可能变得困难。即便如此，这个工具仍然很有价值，因为它让设计师对战斗和遭遇逻辑拥有了更多主导权，同时也建立了一套工程与设计可以长期共同改进的共享工作流。

《Mongil: Star Dive》将登陆 PC、PlayStation 5 和移动设备。在打造这种规模的跨平台体验时，最大的技术障碍是什么？

有意思的是，在我们的跨平台开发中，最耗时的领域是 UX，而不是渲染或原始性能。触控操作和键鼠输入相对容易处理，因为有大量参考可用，而且我们团队已经在这方面有丰富经验。更大的挑战出现在主机支持进入视野时。

主要原因之一是，这个项目长期基于 Unreal Engine 4 构建，我们已经围绕项目需求开发了自己的输入抽象层。虽然 Unreal Engine 5 提供了 Common UI 和 Enhanced Input 等强大的内置解决方案，但要完全替换一套经过多年开发积累下来的结构，实际上并不现实。与此同时，我们还需要支持基于控制器的导航、焦点流以及各平台特定的主机要求，这需要游戏设计、UI 设计和工程团队之间进行大量协调。

相对较早开始主机测试，帮助我们在这些问题于生产后期变得代价更高之前，发现并解决了许多问题。还有一些我们未能完全预料到的技术障碍。纹理内存行为，包括对齐和格式约束，在不同平台之间可能存在细微差异，而这些差异偶尔会在我们自定义过引擎的领域显现出来。我们的自定义着色模型和着色器代码也需要一些针对特定平台的调整。

这些并不是持续存在的大规模阻塞问题，但每个问题仍然需要仔细调查和验证。除此之外，Unreal Engine 的跨平台支持足够强大，许多潜在问题比预期更容易处理。硬件内存限制造成的干扰也比原本可能的情况要小，因为我们在开发早期就把移动端作为核心目标。从一开始就带着这些约束进行设计，最终让更广泛的多平台流程顺畅了许多。

事实上，在某些方面，主机开发最终没有移动端那么苛刻。因为我们选择维持统一的资产管线，而不是为 PC 和移动端分别拆分美术资源，所以我们的许多优化工作自然集中在移动端性能上。这项工作在游戏上线时仍在继续。从实际意义上说，对我们而言最艰难的跨平台挑战不是主机，而是移动端。

为移动硬件优化一款视觉丰富的虚幻引擎 5 游戏可能尤其具有挑战性。团队使用了哪些策略来在如此不同的平台上保持性能和内存效率？

正如我之前提到的，我们优化策略的基础是对统一资产管线的坚持。我们没有为 PC 和移动端创建单独的资产集，而是选择用单一资源库支持所有平台，同时尽量减少任何可见的画质损失。这一决定帮助我们在各平台之间保持视觉一致性，但它也成为我们最大的技术挑战之一。

在美术方面，尤其对环境资产投入了大量精力。目标是尽可能保持低多边形数量，同时仍然提供在 PC 上不会显得妥协的视觉效果。要达到这种平衡，需要美术团队进行大量迭代。在渲染方面，我们做出了一个要求很高的选择，即在移动端采用基于 Vulkan 的延迟渲染。在移动端运行带有延迟渲染的实时光照环境，无论从散热还是性能角度来看都极具挑战性，但我们认为有必要缩小移动端与其他平台之间的视觉差距。

那个决定意味着我们随后必须在移动端优化和热管理上投入大量精力。我们还对 GBuffer 的使用采取了非常激进的方法。移动端的 GBuffer 空间有限，因此我们努力尽可能高效地打包和复用数据，包括根据着色模型重新分配未使用的比特位，并在某些情况下使用非常规方法在渲染通道之间传递信息。由于我们的角色渲染管线已经需要自定义深度与模板通道，我们利用这个机会存储额外数据，并有效地将其视为一个额外的缓冲区阶段，而不会增加太多开销。

对于场景深度，PC 版本使用网格距离场来让远处结构具有更强的体积感。为了在移动端近似类似外观，我们定制了移动端 SSAO 并更激进地推动它。这在整体上给了我们令人满意的结果，但它也产生了副作用，尤其是在植被上，深度可能开始显得夸张。为了解决这个问题，我们将植被和非植被处理分离到不同的通道中，以便更精确地调整它们。

即使做出了所有这些努力，移动端在植被密度、道具密度、阴影质量和分辨率等方面仍然存在不可避免的取舍。这也是我们将在发布后继续改进的地方。在许多方面，移动端优化不是一次性任务，而是贯穿游戏生命周期的持续过程。

展望未来，团队提到有计划通过新区域和故事线来扩展世界。从技术角度来看，你们如何构建游戏的系统与管线，以支持发布后持续的内容更新？

说这款游戏是专门为发布后扩展而设计，可能听起来有些雄心勃勃，但我们实际的目标相当直接：构建一个结构，让我们能够持续添加内容，而不必每次都投入大量新的开发工作。对于游戏内内容，我们前面提到的触发器系统是这一策略的关键部分。新区域、玩法机制、Boss 模式以及脚本化场景，通常都可以通过组合系统中已有的模块来构建。

随着这个库不断增长，创建额外内容的成本会随时间变得更可控。我们对能力和装备等系统采取了类似的方法，这些系统在设计时就考虑了可扩展性，因此新的 Monsterling、技能类型或玩法变体可以在现有框架内引入，而不需要大幅重做。游戏外内容则遵循略有不同的模式。由于它主要位于 UI 层，因此往往需要更频繁的功能更新和调整。

为了以相对精简的团队快速响应，我们正在积极探索利用 AI 提高生产效率的方法。我们正在研究的一个方向是：基于控件结构或设计文档生成实现代码的管线。这仍在进行中，但我们相信它确实有潜力加速未来的更新。更广泛地说，我们认为 AI 可以支持管线的许多部分，而不仅仅是 UI 相关工作。

这可能包括资产制作支持、QA 工作流，以及其他重复性任务，这些领域的效率提升可以产生有意义的影响。由于我们的团队相对精简，我们一直在寻找减少开销、提高迭代速度的方法，而 AI 是我们认为未来尤其有前景的领域之一。

Ken Kim，Netmarble Monster 首席执行官

采访人：David Jagneaux

相关链接

• Mongil: Star Dive

原文链接：https://80.lv/articles/mongil-star-dive-netmarble-s-upcoming-monster-taming-action-rpg