单人开发经典 CRPG：Unity、3.5 SRD 与模块化工作流
《长子复仇》是一款即将推出的小队制 CRPG，它深度倚重经典设计理念，从桌面系统的深度与复杂性中汲取灵感，同时拥抱现代开发工作流。该项目围绕 D&D 3.5 SRD 规则集构建，并且主要以单人开发的方式推进，融合了战术战斗、模块化系统设计，以及一条范围经过审慎界定的制作管线，并由承包商和可用的第三方工具提供支持。
在我们的采访中，Sawtooth Games 的开发者 Rob Koska 分享了《长子复仇》如何以《邪恶元素神殿》和《博德之门》等作品为灵感基础，同时应对以小团队构建系统繁重型 RPG 的现实挑战。
从基于 Unity 的架构和预制体驱动的工作流，到性能优化和自定义编辑器工具，该项目详细展示了经典 CRPG 设计如何适配现代开发约束。
现在还有一个Demo 现已发布！
《Revenge of the Firstborn》围绕经典的 3.5 SRD 规则集构建。是什么促使你决定将系统建立在这个基础之上，你又是如何将其调整以适应现代游戏体验的？为什么不直接采用 5E 本身或类似方案？
Rob Koska，Sawtooth Games 的独立开发者：我选择 3.5 SRD，是因为它比 5E 的规则要“crunchy”（繁复）得多。它让角色构建拥有更多选项（尤其是因为 5E 中的专长并未包含在 SRD 中），而且在我看来，它的战斗比 5E 更有深度。
我时不时会被问到的一个相关问题是：究竟为什么要选择桌面规则集？嗯，考虑到一个完整成熟的 RPG 所涉及的范围，我已经忙得不可开交，要去实现一些我不必从头设计（以及进行游戏平衡！）的内容。
你主要从哪些游戏（无论新旧）中汲取灵感？
Rob Koska：《Revenge of the Firstborn》最直接的灵感来源是《Temple of Elemental Evil》（邪恶元素神殿）。在完整打好补丁的形态下，ToEE 是对 3.5 版规则所能实现的战术战斗的一次大师级实现。我的目标是达到那款游戏所打造引擎的战斗能力，同时希望能为原本本质上只是一场没有太多故事的大规模地城探索，增添一点叙事上的趣味。
我是全部三款《博德之门》游戏的超级粉丝，这意味着它几乎必然会对我的作品产生某种潜意识的影响，但我决定走另一条路线：让玩家创建整支队伍，并偶尔有 NPC 加入，而不是创建一个单一主角，在游戏过程中招募队友。
团队规模有多大，每个人的过往经验如何，游戏开发了多久？
Rob Koska：总共有四个人以某种方式参与过这款游戏的开发。我很幸运能找到这些承包合作对象，尤其是我在业内没有任何人脉。工作分工如下：
有一位名叫 Kirill Buzmakov 的 3D 建模师。我委托的 3D 工作必须相当精挑细选，因为对我来说这非常昂贵。我很幸运在一个 RPG 论坛上看到了 Kirill 的作品，当时他正在寻找自由职业工作；他制作了一些怪物，帮助充实那本经典的 D&D 怪物图鉴，还为游戏的主要 NPC 创建了一个自定义模型。
我聘请了两位很棒的 2D 艺术家，名叫 Heitor Queiroz 和 Lucas Oliveira，他们正在为游戏中的 125+ 种怪物和众多 NPC 制作所有角色肖像，以及各种 UI 元素。这是这款游戏中单项最大的投资，我觉得它已经见效，让游戏拥有了精致、独特的外观
其余的都是我。我很幸运拥有软件工程和团队管理背景，这两项技能我都用来帮助把《Revenge of the Firstborn》变为现实。
演示版突出了开放探索与地牢探索的混合。从系统和关卡设计的角度，你是如何着手设计这两个截然不同的玩法空间的？
Rob Koska：它们并不像你想象的那么不同，至少在我看来。我尽量在两者中都加入一点环境叙事。尤其是在户外区域，你希望奖励玩家探索他们所在区域的每一个角落，并让他们有所发现。
室内和室外区域在我技术上的关注点确实差别很大。在户外区域，我不得不学习 GPU 实例化，以便让所有能同时出现在屏幕上的草和树不会拖慢玩家的电脑。在室内场景中，最大的技术挑战是光照。当然，在奇幻 RPG 中，火把是重中之重。你必须密切关注每盏灯与另一盏灯放得有多近，尤其因为在我的情况下，六名队伍成员中的每一位也可能携带自己的光源。
队伍制 RPG 在底层可能变得极其复杂。你如何构建角色构筑、能力和成长系统，使它们既灵活又易于维护？
Rob Koska：遵循良好的面向对象编码原则至关重要。倾向于使用组合，让一切模块化——属性是独立的类，效果是独立的类。属性包含效果，角色包含属性，依此类推。
同样重要的是，要理解如何在对象之间以最佳方式传递消息并触发事件。如果每个场景中有大量对象在每个 tick 都执行操作，即使单个对象的开销不大，累积起来也会很快。重要的是让尽可能多的脚本在无事发生时完全不执行任何操作，直到某个每个 tick/帧都在执行操作的脚本触发了一个需要响应的事件。这是良好的代码架构，有助于保持松耦合。
充分利用预制体和嵌套预制体（或虚幻引擎中的对应物）也非常有助于保持条理清晰和可维护性。《Revenge of the Firstborn》中的一个好例子是 UI 中显示物品栏物品的方框。它们用于角色物品栏视图（显然），但在搜刮容器时也会显示。为物品栏 UI 创建一个预制体、为搜刮 UI 创建一个预制体，并用嵌套预制体来表示实际的图标及其逻辑，这意味着如果我需要修改某些内容，只需在一个地方修改，所有使用它的地方都会随之改变。
从技术角度来看，你使用的是什么引擎？为这个项目做出这一选择的关键原因是什么？
Rob Koska：我使用的是 Unity。这一选择几乎完全归结于它底层是 C#，而我已经在职业层面拥有近十年的该语言经验。如今，做出那个选择十年之后，我可能还会继续使用 Unity，因为它恰好处于引擎能力与复杂度的最佳平衡点。
你能带我们走一遍你构建场景的典型工作流程吗？从早期的白模搭建一直到最终灯光和玩法实现。
Rob Koska：对于一个典型的地牢场景，信不信由你，我实际上是从 Excel 开始的，如上所示。我会调整列宽，使宽度与行高相同。这给了我一张虚拟的“网格纸”，我可以在上面规划我的地牢。我先勾画出我希望主要房间出现的位置，以及我希望楼梯出现在哪里，以增加地牢的垂直变化。
之后，我会寻找合适的位置放置一两个陷阱，并规划我希望遭遇战发生的地方。每个房间都标有一个数字，并配有图例说明该房间内会发生什么。
一旦我以这种方式将完整地牢可视化，就该开始在 Unity 中放置墙壁和地板了。我已经设置好所有预制体，使它们在放置到整数 Vector3 坐标上时能够正确对齐。这样，我就可以快速将地板和墙壁吸附到位，而不会出现缝隙或导致 z-fighting 的重叠。
我所有的墙壁上都挂着实用脚本，我可以用它们来生成并放置柱子、火把以及任何其他常用对象。这让我可以一键放置我想要的任何东西，并知道它们会被一致地放置。
一旦环境就位，剩下的就只是把我预先用 Excel 布局规划好的位置拿来放置陷阱、怪物和战利品了。
在你的流程中，用于环境美术、角色和资产（例如建模、贴图、动画等）的核心工具和软件有哪些？
Rob Koska：鉴于我不是 3D 或 2D 美术，我在这方面的流程非常有限。我依赖我雇用的美术来完成这部分工作。不过，我确实经常使用 GIMP 来更改物体的颜色。我还使用 Unity 资源商店中一个叫 Umotion 的工具，直接在 Unity 编辑器里制作一些非常基础的动画。《Revenge of the Firstborn》有一些独特的状态效果，比如睡眠和缠斗，这些并不属于任何资源商店中资产常见的动画集（出于预算原因，我不得不大量依赖这些资源），所以我用 Umotion 修改现有的动画，例如让一个待机动画看起来像是生物被击晕了。
你的团队是否开发了任何自定义工具、脚本系统或内部工作流来支持复杂的 RPG 系统？
Rob Koska：是的，而这正是 AI 对我真正发挥优势的地方。我让 ChatGPT 和/或 Claude 为我生成了任意数量的自定义检视面板和自定义编辑器窗口。对于生成游戏系统的代码，我目前还不太信任 AI，除了用于移动 UI 元素或搜索导航网格命中点的一些样板代码。
但是，组织属性的显示和更新，让我能在一个视图中看到所有我想看的内容？那当然好。例如，我游戏中的门有一个脚本，用于管理它是否上锁、是否设有陷阱、是否可以被摧毁以及如何被摧毁。我让 AI 给我写了一个自定义检视面板，以漂亮的选项卡格式直接在检视面板中显示所有这些数据。我仍然完全写不出自定义检视面板；我太忙于编写玩法代码了。
在系统繁重的 RPG 中，性能和可扩展性可能颇具挑战。你遇到的一些最大的技术挑战是什么，你是如何解决的？
Rob Koska：在任何内容繁多的游戏中，你必须注意的最大问题就是每帧都会发生的事情。一个例子是我的感知系统。对于游戏中的每个生物来说，这是一项相当繁重的工作，让它每帧运行会导致问题。所以，我做了修改，让每个怪物都注册到一个管理器对象，该管理器进行轮询，使每个生物每 x 十分之一秒执行一次感知检查。好处是我现在可以在一个地方调整我的感知系统，如果它看起来响应不够快的话。额外加分的是，把它做成检视面板中的序列化字段，这样甚至不需要改代码。
对我来说，另一个巨大的挑战是光照。由于地牢里满是火把，角色也能携带火把，我不得不非常仔细地梳理我的项目，比如找出可以设置为不投射阴影的物体。通过可配置的游戏设置来调整阴影距离和阴影质量，对于让游戏尽可能在更多系统上运行也至关重要。
其他的可扩展性挑战仅仅是在配置游戏中数量庞大的怪物和物品。这正是 AI 可以大放异彩的地方。让它为这些对象编写自定义检视面板，使它们组织有序并呈现良好，一直是一个巨大的帮助。
作为基本独自开发的人，你的主要流程具体是怎样的？你是所有事情都完全自己做，还是会通过 AI、外包人员、素材市场等途径借助外部帮助？
Rob Koska： 我喜欢用 [AI] 来写那些我自己也能写、但它能更快完成的样板代码，比如在导航网格上寻找有效位置，或者让 UI 元素移动和闪烁。正如我之前提到的，它在自定义检视面板（inspector）和编辑器窗口方面也帮了大忙。
所有编码和写作都是我自己做的，但只要能负担得起，我就会把美术工作外包出去。我既没有为游戏做美术的才能，也没有时间。我也很明智地利用了 Unity 资源商店。当你独自做一个规模如此庞大的项目时，关键是不能重复造轮子。例如，物品栏、战争迷雾和对话系统这些重要组件，都是从资源商店购买并集成到游戏中的。
和自己进行“自建还是购买”的对话至关重要。有时从头编写某个功能是值得的，这样你可以完全掌控；另一些时候，直接接入现成资源才是合理的选择。
展望未来，随着你继续开发直至完整发布，你认为你的工作流程会如何演变？
Rob Koska： 我希望尽可能地把更多自动化引入我的流程中。我的构建流程还没有达到它应有的效率。我想达到“点一下按钮就能得到构建”的程度，但我还没做到。
我想创建更多场景验证器，在每次场景保存时运行。我还想再创建一些在构建本身运行之前执行的验证器。比如确保你没有复制粘贴一个需要唯一的 guid 之类的事情。我已经有一些了，但拥有更广泛的一套会有助于防止那些被视为 bug 的问题进入发布版本。
我还想把 AI 接入我的代码审查流程。显然，作为一名独立开发者，我没有人来帮我复查代码，所以让 AI 接入合并流程可能是个不错的办法，让某个东西能说：“嘿，你确定这应该是这样的吗？”
最后，你是否还有一些额外的幕后素材可以分享，比如开发中的环境、节点图或引擎内的拆解分析，以帮助开发者更好地理解《Revenge of the Firstborn》是如何制作的？
Rob Koska：我所有的供应商数据都存储在一个可脚本化对象（scriptable object）中。这个可脚本化对象本身就是一场视觉噩梦，如上图所示。
我让 ChatGPT 为它创建了一个自定义编辑器，它的表现好得让我惊喜。实际上，这个窗口的代码没有一行是我自己写的。它也许不是最漂亮的，但作为不面向玩家的东西，它不需要漂亮。
Rob Koska：这是我为其中一个 NPC 制作的自定义检视面板。这个检视面板会遍历子对象，查找所有适用的脚本，并以标签页的形式显示它们的全部序列化属性。这为我节省了大量在层级视图中点击、在检视面板中滚动的时间。而且这完全是由 ChatGPT 编写的。
ChatGPT 甚至足够聪明，在我告诉它我安装了 Odin Inspector 之后，它会在合适的地方使用 Odin Inspector 的序列化器。
Rob Koska：我对在编码中使用 AI 持谨慎乐观的态度。对我们所有人来说，危险在于盲目信任并使用它生成的内容；但如果把它当作一名需要指导、其工作也需要仔细审查的初级开发者来对待，它就有很大的潜力。虽然我完全理解人们对 AI 艺术的抵制，但我认为 AI 编码是不同的。
互联网上有如此多的文档和开源代码可供训练，因此我不认为它会像 AI 艺术那样带来相同的版权伦理问题，更不用说人们在 AI 艺术方面所诟病的、缺失的人性元素了。
相关链接
原文链接：https://80.lv/articles/how-a-solo-developer-is-building-a-classic-crpg-in-unity
喜欢这篇内容吗？