编辑 / 游戏那点事 Sam、Jimmy

自从腾讯网易两家巨头掀起“元蛋大战”开始，国内游戏行业的UGC生态就一直处在蓬勃生长的势头当中。单在过去一年里，不仅腾讯的《和平精英》“绿洲启元”宣布DAU突破3300万大关，米哈游的《原神》也推出了自己的UGC模式「千星奇域」，仅用三个月时间就汇聚了超过3万名创作者，地图关卡总游玩人次也超过了1.5亿之多。

作为一款运营已经超过5年的产品，米哈游为什么会突然决定为《原神》推出这么一个UGC模式？背后又存在怎样的开发理念和长线目标？近期在美国开幕的GDC2026大会上，来自原神程序团队的宁锌就以“在《原神》中实现内置多人用户生成内容体验”为主题进行了一场演讲分享，回顾了关于「千星奇域」框架搭建的诸多技术细节，以及开发过程中面临的挑战与难点。

以下为演讲内容翻译，为优化阅读体验有所删改：

一、“最小化沙盒，最大化复用”

大家好，我是来自原神程序团队的宁锌，目前负责《原神》的UGC项目，也就是「千星奇域」。今天，我将和大家聊聊我们如何在《原神》这款持续运营的跨平台开放世界游戏中，深度集成一个完整的多人UGC系统。我会重点分享我们在沙盒设计、系统复用、创作者工具以及性能优化方面的技术决策，以及我们如何让这一切与不断演进的线上服务和谐共存。

「千星奇域」是《原神》中的多人UGC扩展玩法，目标是让玩家可以自己创作并分享高度定制化的游戏体验，同时保持和原生内容一样的高品质画面、流畅操作和稳定性能。作为一款持续运营型产品，游戏本身和玩家群体的庞大规模，既给UGC的引入带来了机遇，同时也提出了不少挑战。

此外，我们的开发周期实际上非常紧张——需要在一年左右的时间里，从零开始完成整个项目。这种限制让我们做出了一个关键决定：不去开发一个独立的UGC游戏，而是将「千星奇域」深度集成到《原神》当中，最大程度地复用现有系统。

今天的分享会按这几个部分进行展开：首先介绍关于「千星奇域」技术框架的设计思路，其次是「千星奇域」的核心功能及其实现方式，之后则会聊到UGC关卡的性能问题，并且介绍我们接下来的规划、以及从这次将UGC集成进大型在线游戏中学到的一些经验。

先从技术框架的设计思路开始说起。我们做UGC的动机来自三个方面：一是从行业趋势来看，玩家创造力和创作者驱动的游戏生态正在成为主流；其次，《原神》本身已经拥有一个非常庞大且富有创意的社区，很多玩家不满足于只做内容的消费者，同时也想要亲身参与到创作当中。因此无论对于创作者、玩家还是游戏本身而言，一个成功的UGC系统都能够带来不少益处。

更重要的是，在经历了家园系统「尘歌壶」和游戏内小型沙盒原型「神工天巧」的开发之后，我们已经积累了一些可行的技术和机制，也证明了UGC的可行性。所以我们面临的问题不再是“要不要做”，而是“怎么去做”——在保证基础游戏品质和稳定性的前提下，如何大规模地推进UGC？

接下来的问题是范围：究竟哪些内容应该开放给玩家定制？我们的目标不只是让玩家简单混搭现有玩法，而是希望支持从“对熟悉玩法的小幅调整”到“完全自定义玩法”的完整光谱。同时，我们也必须脚踏实地、充分考虑引擎和平台的现实限制，从而让创作者在获得发挥空间的同时确保平台的兼容性、内容稳定，以及运行时行为的可预测性。既要敢想，也要负责。

因此，我们选择把注意力集中在了最能影响玩法多样性和玩家创造力的几个方面：化身呈现、3C配置、技能编排、关卡构建，以及事件驱动的玩法逻辑。这些领域对游戏体验影响最大，同时也让我们能继续保证跨平台的安全性、性能和确定性。

为了实现这一点，我们一方面希望创作者能直接使用《原神》的原生功能来创作，而不必从头实现移动、战斗、相机、特效等基础系统；另一方面，我们也需要一个既强大又对非专业创作者友好的编辑器。因此，我们的目标就变成了在现有系统之上提供有意义且易用的自定义选项，同时尽量减少每个平台上需要单独开发的全新工具。

除了目标以外，还有三个核心约束始终贯穿我们的决策。第一是必须一年内交付完整产品（时间）、第二是绝不能意外改动原生游戏行为，不能让UGC影响基础游戏的稳定性（安全）、第三是在PC、移动端和主机上开发一个功能完善的编辑器成本太高，而且主机端的界面本身就对创作者不友好（工具）。这促使我们选择了“以PC端为主进行创作，同时确保运行时在所有平台上拥有确定性和一致性”的方案。

我们的解决方案可以总结为“最小化沙盒，最大化复用”。系统被分为两部分：一个是仅限PC端的创作沙盒，另一个是负责受控执行的UGC运行时沙盒。创作者生成编辑数据，这些数据再被转换为运行时数据。在运行时，这些数据会被解析成模拟的原生功能配置，而不是直接修改原生系统。这样既能复用成熟的功能，又能把风险控制在UGC的边界之内。

这里展示的是核心的数据分离模型。编辑数据只用于创作和工具链，包含了丰富的元数据、引用信息和UI结构。运行时数据只用于执行，原生功能数据保持原样不变。我们生成的是临时的、限定于功能模块的配置，运行时像使用原生输入一样使用它们。这种分离让我们可以快速迭代、保持安全，同时让「千星奇域」能够和《原神》本体同步演进。

二、让创作者的创作过程像「搭积木」一样

框架定下来之后，我们再来看看「千星奇域」的核心功能。

先从化身说起。化身定制是UGC的基石，因为这是玩家表达自我和主题的主要方式。在「千星奇域」里，定制内容包括面部特征以及覆盖多个身体部位的模块化服装。其中的技术难点在于，单个化身不仅复杂度高，还要同时支持多人同屏，并且严格遵循各平台的性能预算。尤其是移动端，包括CPU、带宽和发热等因素都有可能成为瓶颈。

相比于《原神》的原生角色，「千星奇域」的每个化身成本更高。因为一个化身由多个重叠的身体和服装网格组成，容易造成穿模、增加不必要的Draw Call、蒙皮计算和GPU过绘。

更棘手的是，「千星奇域」的目标是同屏人数达到战斗中最多8人，社交场景中最多40人。和原生的四人联机相比，渲染和动画所需的成本会成倍增长。哪怕每个化身的开销和原生角色一样，并发数量的增加也会让渲染、动画和功耗飙升。这迫使我们从底层重新思考每个化身的效率，并引入系统级的可见性管理和LOD控制。

我们的优化思路是直击痛点——重叠、部件数量和蒙皮。以消除重叠为例，我们把身体划分为预定义区域，让服装部件“认领”对应区域，从而在制作时就能预烘焙或清理重叠，减少过绘和无效着色。

其次是减少部件。如果服装更换不算频繁，我们就在更换时把多个部件合并成一个网格和一张纹理，减少运行时的Draw Call。第三是提升蒙皮效率，即从CPU密集型的蒙皮改为GPU顶点着色器蒙皮，CPU只提供紧凑的矩阵数据，由GPU高效地批量处理。这些改进叠加在一起之后，成功大幅降低了单个化身的开销。

在单体优化之外，为了对化身质量在不同距离下实现平滑降级，我们还增加了系统级控制：基于距离的LOD简化远处网格，对性能敏感平台限制最大可见化身数量，从而让近处化身保持最高质量，远处化身在贡献不大时逐渐简化或隐藏。

通过重叠消除、网格合并、蒙皮优化，再加上LOD和可见性管理，我们把每个化身的渲染效率提升到了接近原生角色的水平，显著降低了CPU和功耗，让移动端也能承载大型社交场景。

除了化身定制以外，创作者当然也希望能自定义玩法本身。而我们的原则也很简单：复用现有的成熟系统，并通过安全的创作界面开放自定义选项，而不是让玩家重写底层工具。我们把玩法自定义聚焦在四个方面：3C配置、技能、关卡布局和逻辑脚本。这些元素足以支撑多样的玩法，同时仍能让我们进行验证和保证跨平台的确定性。

先从3C说起。因为这个系统既强大又极其敏感，连专业开发调优都需要经验和反复试错，因此我们刻意不暴露底层机制，而是复用原生系统，只开放那些不易误用的高级参数。比如移动能力的开关、限定范围的战斗数值，以及相机配置等等。这样既保留了“原神感”，防止创作者对基础移动机制造成破坏，又能保证平台性能可预测，同时支持多种玩法风格。

一旦在合适的抽象层次开放3C，实现不同类型的游戏就变得异常简单。第三人称动作可以直接沿用默认预设，做俯视角Roguelike只需切换相机模式、加上移动限制、调整数值节奏即可；第一人称射击则可以通过第一人称相机加上投射物交互来实现。

关键在于，创作者觉得自己在“设计游戏”，但实际上并未触及底层的移动逻辑，这让系统在所有平台上都保持稳定、可测试且一致。

与3C不同，「技能」更具标志性，也定义了实时的玩法变化。因此这里需要真正的编排能力，而不仅仅是对参数进行调整。对此，我们把技能设计成了动画片段、特效触发器、伤害判定框（Hitbox）、攻击窗口、逻辑事件等模块化的构建块创作者可以在可视化的时间轴编辑器里编排这些元素，预览和快速迭代，无需启动整个游戏。

重要的是，时间轴数据只是创作层的表示，运行时我们会把它编译成原生的战斗动作和行为数据，以确保和现有战斗系统兼容。

这里举个例子。创作者在时间轴上放置事件：开始动画、开启伤害窗口、生成特效、触发镜头震动……编辑器会验证顺序和收束，然后生成一份紧凑的数据。运行时，这些数据被转换成和原生内容一样的动作和行为结构。这样既给了创作者表达的自由，又让运行时能和现有战斗系统、工具链无缝对接——这对长期维护一个在线服务至关重要。

有了角色和技能，就需要关卡来承载它们。关卡布局既是UGC大放异彩的地方，也是最容易无意间制造性能优化灾难的地方。我们主要关注两个部分：用于结构布局的体素地形，以及用于玩法实现和场景装饰的实体（Prop）。我们的目标是保持创作易上手，同时让引擎在加载、剔除、实例化和资源预算方面拥有绝对控制权。

之所以选择体素而不是传统的高度图地形，主要是为了降低创作者的使用门槛。高度图固然好用，但学习成本太高，很容易出现边界报错、纹理混合或者根本走不上去的斜坡等问题。体素虽然有更多约束，但这种约束从另一角角度来看其实是优势——创作者能很快做出清晰、一致的地形，学习成本低，整体质量高。对一个UGC生态来说，“快速出个不错的效果”和“极致的表达力”其实同样重要。

体素地形也提升了游戏手感。我们调整了体素块的大小和踏步行为，使其与默认的跳跃弧线、攀爬判定、冲刺穿行以及通用的碰撞预期等移动模型保持一致。这意味着即便创作者不懂移动设计，也会下意识地搭出和默认3C“天生契合”的关卡。换句话说，地形系统会引导创作者做出合理的几何结构，且不需要去记那些隐性的移动规则。

性能优化是另一个重要考量。传统地形常把高度图和多个纹理层、混合贴图结合在一起，既占用大量存储，也对渲染带宽很不友好。我们的体素地形采用分块设计，即使在大规模下也非常紧凑，天生适合实例化。我们还采用了基于GPU缓冲的渲染方案，最大程度减少每帧CPU和GPU的通信——这对移动端尤其重要。这种组合既能支撑大规模UGC，又能保证性能优化可预测。

地形提供结构，实体则承载玩法。逻辑实体采用实体-组件的架构，通过组件插件来扩展功能，比如触发器、计时器、运动装置、交互提示等基础元素。关键的架构决策是：插件不是任意脚本，而是映射到经过验证的行为，并通过受控的适配器桥接到原生功能上。这让创作者可以通过可靠的模块组合玩法，运行时再把这些模块在UGC沙盒内编译成对应的原生系统调用。

相比之下，静态实体用来丰富体素地形上的环境——做场景装饰、地标和细节。在编辑器里我们也尽量保持了和逻辑实体相似的操作，这样创作者就不用换来换去了。但在运行时，静态实体是不支持插件或节点图的，因此组件更轻量，更新开销更低。这种分离让创作者能搭出视觉丰富的场景，且不用承担不必要的消耗。

当然，如果只有实体和基础插件，玩法的多样性很快就会触顶。所以我们通过节点图引入了一个基于节点、事件驱动的可执行逻辑脚本系统。节点图可以挂在玩家、关卡、怪物或实体上，可以通过“实体生成”或“计时器触发”等驱动。

触发时，服务器会解析节点图并执行动作。比如，当玩家点击某个交互标签，就生成一枚硬币、打开宝箱、播放特效。这样创作者就能做出多步骤解谜、生成序列、计分规则、动态遭遇等。我们特意选择节点图而不是文本脚本，是因为它表现力更强，同时又足够受约束，可以在千星奇域的运行沙盒中安全执行。每个节点动作本质上都是一个适配器，像组件插件一样，通过配置调用原生服务器动作（如生成、交互、销毁实体），而无需改动原生功能本身。

而节点图运行在一个服务器状态同步的框架中，这和《原神》中处理多人一致性的方式相同，不仅保证了跨平台的体验一致性和玩法公平性，也防止客户端差异演变成“内容性错误”。同样重要的是，这个框架为我们提供了天然的验证和保护层——即使创作者犯了逻辑错误（比如无限循环），我们也能发现并断开，防止整个应用崩溃。

同时，我们为节点图做了一个可视化编辑器，让创作者能直观地看到控制流和数据流转。而且我们把编辑器做成了一个独立于主客户端的应用程序，这有助于保持原生代码库的干净，也为诸如执行日志、图跟踪、数据检查、性能优化分析等强大功能预留出了空间。实践证明，这笔投入很值，因为如果没有这些工具，调试UGC逻辑对创作者和支持团队来说都极其耗时。

回头看，这套方法基于两个支柱：第一，通过最小化沙盒实现数据分离，让创作数据、运行时数据和原生数据各司其职，UGC保持独立封装；第二，深度复用原生功能，并精心选择自定义点，让创作者在无需重构整体规则的情况下，获得强大能力。这不仅让千星奇域得到快速交付，也让线上服务变得长期和可持续。当原生功能迭代时，我们可以通过适配器把新功能带入UGC，不用再为创作者重做一套系统。

项目上线后，很快得到了正面的市场反馈：创作者们迅速做出了“自己的游戏”——第三人称动作、PvP、体育竞技、类似射击的玩法等等。这种快速涌现说明我们在激发创作者表达欲，工具易用性，开发流程可迭代性等环节都找到了一个不错的平衡点。

大约半年后，玩法进一步扩展到俯视角MOBA、融合了俄罗斯方块规则集的解谜游戏，以及更复杂的射击和竞速变体。关键原因就在于创作者不用花时间去重建基础，因为他们有了3C预设、技能模版、体素地形、插件和节点图等功能丰富的工具，可以专注于节奏、目标、可玩性、趣味性等设计上。这正是我们希望在一个UGC生态中看到的。

三、用“模型预警”辅助性能优化

接下来，我们来聊聊任何UGC平台最棘手的问题之一——性能优化。

大多数创作者都知道性能优化很重要，但往往不知道哪些具体操作会导致性能优化出问题。所以UGC的性能优化很容易“爆炸”：实体数量多、结构以及可见性等方面都极容易出问题。关键是这些问题往往基于空间和系统的综合因素：分布、可见性、光照交互……而不仅仅是“实体太多”。因此，仅仅限制实体数量是不够的。

传统的预算系统（限制对象数量和类型）在UGC中效果有限。两个关卡即使对象数量相同，空间分布、可见性、光照和动态生成不同，性能优化也可能天差地别。虽然可以用线性或多项式估计模型，但在一个原生资源和功能频繁演进的线上服务框架中，需要针对每个平台不断手动调优启发式规则，维护成本高且效率低。所以我们想找一个能从数据中学习、在内容变化时可以重新训练的模型。

而《原神》恰巧已经有大规模的自动化性能优化测试数据，这也引导了我们摸索出数据驱动的方法：一个神经网络模型。它的输入包括资源构成、空间布局、功能特性，以及实测的CPU帧时间、内存开销和功耗。我们内部评估下来，预测误差通常在10%左右。最大的优势是运维层面：当加入新内容或新功能时，我们可以收集新样本重新训练模型，而不用手动维护跨平台的启发式规则。

训练好之后，我们把模型集成到创作者的工作流中。给定一个目标区域和视野范围，把关卡布局和相关特征输入预测器，就能返回预估的性能优化数据和热点。关键在于，创作者在大规模试玩前就能收到反馈，把优化环节大幅提前，甚至在放地形和实体的时候就能看到“此区域有风险”的预警。

为了让预测结果更直观，我们把它可视化。我们在关卡网格上布置基准点（比如每隔50米一个），在每个点评估六个沿坐标轴方向的视锥体。每个视锥体会捕获一个代表性视野范围内的资源、光照和特征，运行预测器，如果超过设定阈值就发出警告。创作者可以点击热点查看具体是哪些资源、哪些特征消耗了性能优化。这种方法潜移默化地培养了性能优化直觉：创作者慢慢理解了密度和可见性模式是如何实际影响设备性能优化消耗的。

我们还支持试玩过程的运行时剖析。一旦检测到热点，就会抓取屏幕截图，以及当时视锥体内内容的结构化数据——哪些对象、哪些特征，成本集中在哪。这就形成了一个闭环：创作者能把具体的游戏瞬间和底层的性能优化贡献关联起来，从而更有针对性地迭代优化，而不是靠猜。

把预测器、编辑时可视化和运行时剖析结合起来可以说是一举两得：第一，可以帮助创作者及早发现并解决问题，特别是对于大型密集地图，人工分析极其困难；第二，逐渐在整个创作者社区中建立起性能优化意识。像“提瓦特冒险：碎域秘境”这样的大型项目，既有大规模的密集关卡，又有动态的Roguelike战斗逻辑，创作者就是利用这些工具提前识别关键热点，最终在上线时也没有出现性能优化意外。我们不想逼迫创作者都变成优化专家，而是给出明确的反馈，帮他们做出更明智的决策。

总而言之，千星奇域的经验告诉我们：完全可以在一个持续运营的大型游戏中构建强大的UGC平台，前提是能确保安全性和可持续性。数据分离和沙盒确保“地基”；深度复用原生系统确保开发周期可控、内容质量可靠；而强大的编辑器、验证、调试、优化指导等工具让UGC生态能够惠及更广泛的创作者，而不仅限于少数专家。

展望未来，我们的核心目标是：在不叠加复杂度和成本的前提下，持续拓展创作者的创作边界。这意味着我们会提供更多模板和更高级别的构建块以减少重复劳动，比如标准化的操控模板（如载具），以及更强大的UI框架供创作者使用。工作流方面，我们会持续投入能缩短迭代时间的工具，例如程序化生成助手、更便捷的批量操作、更清晰的调试界面。我们还在探索多用户协同编辑，因为进入多人协作领域后会有更多变数，所以我们希望平台原生支持多人协作，而不是让创作者再通过外部工具协调。

我们也在谨慎地探索AI的潜力，比如AI辅助节点图脚本编写与调试、性能优化分析，乃至逻辑实体和关卡的原型设计。目标是帮助创作者更快地把想法变成可玩的原型，释放他们的创造力。同时，确保AI始终只是辅助工具，服务于创作者的构想。

最后，我想用贯穿这个项目的一个信念来收尾：游戏行业的未来，必将由玩家驱动——他们不仅是消费者，更是创作者。我们身为工程师要做的，就是为他们提供强大、安全且可扩展的工具，让创造力得以尽情绽放，同时不牺牲稳定性和性能优化。感谢大家的聆听，下面开始提问环节。

Q：感谢你的精彩分享。UGC生态系统成功的一部分也在于帮助创作者实现盈利。我没有在你的演讲中看到关于外观商业化或其他能让创作者获得收益的机制。我想问一下，未来是否有这方面的规划？

A：今天这个演讲主要聚焦于「千星奇域」的技术层面。刚才我们提到的都是长期设计和未来规划，我目前并不适合谈论具体的未来计划。

Q：您刚才提到你们为实现这些UGC功能发布了一个独立的编辑器。这个编辑器有多少是基于你们团队用于开发游戏内容的内部工具，又有多少是完全从零开始为玩家构建的？

A：我们从内部工具中吸取了很多经验，比如我们的设计师使用什么功能、觉得什么好用等等。但整个应用程序是为了创作者从头开始构建的，以便更好地聚焦于他们的需求。

Q：「千星奇域」使用了什么样的网络代码架构？是确定性输入同步（帧同步）架构，还是更传统的、同步动画和其他个体数据的网络架构？

A：对于「千星奇域」，我们使用的是与原生《原神》完全相同的网络同步机制。我们基于状态同步，即同步的是实体和角色的状态，而不是输入本身。

Q：您刚才提到了一个用于检测关卡性能热点的机器学习技术。你们会用这个模型来拒绝内容发布吗？还是说它更多只是一个编辑器内的参考工具？如果有热点最终还是通过审核发布了，你们会怎么做？

A：我们只会使用神经网络预测来提示创作者他们设计的区域存在较高性能风险，并且用空间热点的形式展示出来，而不会用它来拒绝任何的发布。

Q：UGC平台一个核心挑战是：玩家如何在成千上万的作品中找到最好玩、最有趣的？你们是如何解决的？能谈谈这方面吗？

A：简单点说，我们正在为玩家构建一个资讯平台，上面会展示每周或每月最受欢迎、以及根据玩家兴趣推荐可能感兴趣的UGC作品，这也是我们「千星奇域」生态建设的一部分。

今天是一个技术向的分享，到周五我们还有一个关于游戏设计的分享，届时会更详细地讨论这个问题。

Q：我注意到在运行中热点的幻灯片上，性能警告的部分似乎包含了神经网络模型的图表。所以我想问，你们是使用相同的神经网络模型来做预测和运行时警告吗？

A：这个模型会用在两个地方。一个是在开发过程中使用编辑器的时候，就像那张幻灯片里的那样。另一个是在真正运行关卡试玩的时候，我们也会用这个神经网络来预测游戏在多个平台上的实际性能表现。

在测试结束后，查看性能分析数据时，你可以看到屏幕截图，预测数据会告诉你哪些地方可能存在性能问题。运行时警告的依据是这个预测，但运行时剖析数据本身（比如具体的物体列表）是更静态的数据收集，是用来解释预测结果的，所以这是两种不同的分析方式。

Q：千星奇域支持开放世界游戏式的创作吗？有没有做过这方面的测试？

A：目前来说，它是一个迷你沙盒空间的独立关卡，不是无缝大世界，创作者创建的也是单个关卡。

Q：你提到了给玩家提供“构建块”，让他们像搭积木一样制作游戏。但如果有个创作者技术很强，想要修改这些构建块本身的工作方式去做实现更多功能，你们会支持这种深度的修改吗？还是说你们会自己来做这些扩展？

A：这样他可以使用节点图，节点图的脚本系统可以实现大部分构建块的功能。实际上，很多创作者正通过节点图实现了许多连我们都意想不到的创意。周五的设计演讲中会展示一些这样的例子，如果你感兴趣，可以关注一下。

今天的分享以及问答环节就到此结束了，感谢大家的到来。如果有任何问题，欢迎随时发送邮件联系我们。