Hologryph是如何打造SAND的:《苏菲的掠夺者》实现可持续的实时运营节奏

对于 Hologryph 来说,开发沙:索菲的掠夺者这意味着将一个架空历史的 1910 年沙漠荒原变成一个资源开采游戏,并且这个游戏在发布后还能持续发展壮大。玩家驾驶着巨型步行机器“践踏者”(Tramplers),这些机器既是基地,又是战利品库,同时也是武器,然后驾驶它们穿越程序生成的开放世界,search残骸,并与其他玩家相遇。
要实现这种体验,需要严格的服务器和客户端权威分离、在两端运行完全相同的程序化世界生成、make单个 Trampler 的数百个实体的同步,以及足够流畅的世界流,以营造骑乘的感觉。团队还需要一个足够快的内容管线,以便定期发布新的舱室、武器、特效和季节性环境,而不会影响性能。
我们与 Hologryph 的首席技术官兼游戏总监 Serhiy Grinets 进行了交谈,探讨了如何为游戏的长期发展构建架构、如何保持内容管线的运转,以及如何在这样一款技术雄心勃勃的游戏中进行实时运营。
你们的实时运维模式是怎样的?一次典型的更新包含哪些步骤?
谢尔盖·格里内茨:我们为SAND制定的实时运营模式侧重于与我们充满热情的社区共同推动游戏发展。我们的首要任务是保持定期更新的节奏,将新内容、游戏玩法改进、平衡性调整、漏洞修复和生活质量改进结合起来。我们的最终目标是编译版本一个可持续的运营模式,以支持该游戏的长期发展。
你们最初的核心技术目标是什么?这些目标如何影响你们构建一款能够长期生存和发展的游戏的方法?
我们有三个主要目标:
- 严格区分权威服务器和客户端,程序生成的世界在服务器和客户端上运行完全相同。
- 同步大量实体——一个践踏者由数百个实体组成。
- 平滑的世界直播——世界真的很大,为了展现骑乘 Trampler 的感觉,你需要一个可以骑行的地方。

践踏者是游戏的核心特征。你们是如何编译版本定制系统的,才能将新的零件、外观和变体作为持续的线上运营内容推出?
整个系统都是围绕隔间构建的。舱室是 Trampler 船体的一部分——甲板、船舱、支持框架、设备间——每个舱室都经过精心设计,可以与其他舱室完美契合。
玩家可以用以下积木组装他们的践踏者:他们选择布局,堆叠甲板,放置设备,最终得到一台真正属于自己的机器——他们的基地、他们的金库和他们的武器。
对于我们开发者来说,这也是内容管线。要添加一个新的隔间,我们无需编写代码即可对其进行建模和配置。它像其他代码块一样插入建筑系统,玩家可以立即在设计中使用它。只有当某个部件需要新的机械师时,程序员才会介入,即使如此,也只是负责一些小的、独立的工作。
正因如此,隔间才成为完美的实战内容:每增加一款新产品,就能增加 Trampler 的制造可能性,而且生产成本对我们来说也很低。
隔间系统下方的架构是什么样的?它如何让您快速(用作动词)构建原型?
我们采用模块化方法,可以快速迭代原型。在底层,我们有一个自定义的控制反转容器,用于插入新功能,它与我们的实体组件System(ECS)非常契合。此外,我们定制的网络引擎意味着我们在构建新机制时几乎无需考虑网络问题。复制操作是在游戏玩法代码的下一层处理的。

Unity 的C#任务System和Burst编译器是如何提供性能余量,让您能够持续添加实时操作内容而不会出现性能下降的?
我们的模拟运行在我们自己修改的 Entitas 版本上,Entitas 是一个开源的ECS框架,而不是Unity Entities,但C#任务System和Burst编译器对于我们的热路径至关重要。程序化地形生成(包括高度图和生物群落采样作业)、Trampler 运动数学以及我们自定义的遮挡剔除,全部作为 Burst 编译的作业链运行。这项工作不在主线程上运行,因此更密集的世界不会影响帧数。
VFX Graph在帮助您的团队快速迭代现场活动、季节性时刻或里程碑事件的特效方面发挥了什么作用?
我们All的特效——沙尘、烟雾、护盾、武器特效——都是基于VFX Graph构建的,但关键在于我们如何使用它。除此之外,我们还编译版本了可配置的效果系统,例如枪口火焰或子弹冲击,这些系统以一个灵活的图表设置存在,并具有大量公开参数,包括大小、颜色、时间、碎片和烟雾。
所以当一种新武器出现时,美术师只需调整这些参数就能获得独特的效果——无需技术美术师参与,也无需从头开始构建新的图形。技术美术师的时间都花在了完善这些系统上,而不是为每种武器手工打造每一个特效。
正是这样才能保证生产速度足够快,从而维持稳定的内容节奏。新建武器和新事件的优质效果是以配置成本为代价的,而不是以开发成本为代价的。

随着实时运营内容管线的扩展, Unity Profiler如何影响了您的优化工作流程?
我们会定期对客户端和服务器进行性能测试,以发现并优化薄弱环节。Unity Profiler中的系统细分显示了时间究竟花在了哪里,这使得我们的ECS非常便于进行配置文件。
我们还进行了自动化测试,以衡量固定场景下的性能,因此我们每天都能看到趋势,并能立即对变化做出反应。
您是如何使用Addressables来推送实时内容更新、热修复和季节性更新,而无需进行完整的客户端更新?
Addressables是我们内存管理的基石。世界正在被直播:当玩家骑马穿越沙漠时,身后的内容会不断地加载和卸载。All这些都通过Addressables进行,因此无论玩家移动多远,内存都保持不变。
第二个不太明显的作用是,我们有两个独立的项目,即主客户端项目和服务器项目,我们构建了一个自定义解决方案,可以将资源从一个项目传输到另一个项目。这样可以保持两个环境的一致性:服务器看到的是与客户端相同的数据,这些数据是通过相同的管线构建的,因此“客户端运行正常,服务器端出现问题”的内容错误在结构上是不可能的,而不是我们需要测试的内容错误。

是否有任何Asset Store工具可以帮助您更快地编译版本或维护线上运维管线?
来自Unity Asset Store的GPU Instancer Pro渲染了我们所有的沙漠散布物,这对于开放世界至关重要,而Amplify Impostors则处理了远处的物体。Odin 检查器为我们面向设计师的工具提供支持,这对于数据驱动的内容管线至关重要,而Rewired 则处理PC和游戏机的输入。Easy 保存 、 DOTween和I2 Localization都为我们节省了宝贵的时间。
Cinemachine如何帮助您捕捉可分享的精彩瞬间(例如机甲战斗、精彩场面)并推动您的内容策略?
我们对Cinemachine的使用刻意保持简单。它管理我们的摄像机并在它们之间切换——游戏玩法摄像机、机库摄像机和观众视角。我们不做任何额外的场景布置或剧本化的拍摄手法,这是我们有意为之的选择。沙:索菲的掠夺者是一款第一人称、竞争激烈的游戏,摄像机的任务是保证可靠性,而不是追求艺术效果。
游戏本身就具备影片动画的质感。当两座巨大的步行堡垒互相发射炮弹,而你正站在其中一座堡垒的甲板上重新装填炮弹时,任何精心设计的镜头语言都无法与之媲美。模拟场景的精彩之处在于其摄影技术。Cinemachine确保摄像机永远不会妨碍拍摄。

你搭建了一个双通道Vivox系统——船员聊天加空间近距离聊天。设计和实施过程中都考虑了哪些因素?
每个玩家同时处于两个Vivox频道中:一个是常规的船员channel,也就是你的船员始终能听到你的“无线电”频道;另一个是通过3D近距离语音技术定位的channel,这样你就能听到来自世界各地其他船员的附近玩家的声音。
位置channel使用Vivox 3D属性——范围、衰减、淡入淡出模型——在配置中进行调整。我们的ECS以限制的速率(每秒约 20 次)将说话人和听者的位置推送至Vivox ,并且仅在播放器移动时才会推送。身份验证通过我们自己的后端令牌服务进行。
除了语音功能之外, Vivox在您更广泛的实时运营战略中扮演了什么角色?它又是如何帮助推动社交互动和留存的?
对我们来说,近距离语音是一种游戏玩法功能,而不仅仅是用于通信。撤离游戏依靠涌现的社交时刻而存在,在沙漠中相遇的队员可以交谈、谈判、组队或互相背叛,听到附近陌生人的真实声音会产生任何脚本系统都无法产生的紧张感。机组人员使用无线电保持各队之间的协调。

对于想要编译版本一款以实时运营为驱动的游戏的开发者,你有什么最重要的建议?
开发一款可实时运营的游戏是一项充满挑战的任务,因此make确保您的团队有足够的韧性坚持到底,并且您身边有可靠的合作伙伴和工具。与你的社区保持紧密联系——倾听玩家的意见,从他们的反馈中学习,并让这些反馈帮助塑造游戏随着时间推移而发展的方向。
要了解更多使用Unity制作的项目,请访问资源页面。
