设计视角游戏引擎：概念架构与可行性分析当前主流游戏引擎（如Unity、Unreal Engine）遵循"技术优先"的设计

摘要

当前主流游戏引擎（如Unity、Unreal Engine）遵循"技术优先"的设计哲学，其核心抽象围绕程序员的技术概念构建，而游戏设计师（策划）往往需要依赖程序员的配合才能完成工作。本报告作为一篇概念性架构设计提案，旨在提出一种"设计视角"游戏引擎的设计范式，通过数据驱动、声明式逻辑、关系图谱等技术创新，降低设计意图的表达门槛，提升设计师自主完成逻辑设计工作的能力。报告以Unity和Unreal的技能系统作为案例分析对象，既肯定其在特定目标下的合理性，也指出其与"设计视角"范式存在的根本性错位。报告深入分析了这一理念的技术架构、实现路径与局限性，并以Godot平台和Photon Quantum引擎作为技术参照，探讨其作为长期探索方向的可行性。

关键词：游戏引擎设计；数据驱动架构；声明式编程；设计工具；工作流优化

引言

1.1 研究背景

游戏开发是一个复杂的系统工程，涉及策划、程序、美术、音效等多个专业领域的协作[来源: Game Engine Architecture | Gregory, Jason | A K Peters/CRC Press | 第1-3章 | 2019]。在当前主流游戏引擎中，技术工作主要通过编程语言（如C++、C#）和脚本语言（如Lua、Python）进行，游戏设计师需要考虑玩法设计、关卡构建和规则制定等创意工作，而程序员则负责确保游戏在技术层面完美实现。

游戏引擎的核心功能是提供渲染、物理、音频等基础子系统，使开发者无需从零实现这些功能[来源: SyDRA: An Approach to Understand Game Engine Architecture | Ullmann et al. | ScienceDirect | DOI:10.1016/j.sysarc.2024.202402003 | 2024]。然而，现有的游戏引擎架构在设计上往往以程序员的思维方式为核心，这种"技术优先"的范式在大型商业开发团队中可以有效运作，但在设计师与程序员之间形成了显著的沟通鸿沟与迭代瓶颈。

1.2 研究问题

本报告试图回答以下核心问题：

描述性问题：当前主流游戏引擎在支持游戏设计师工作流方面存在哪些设计局限？这些局限的根源是什么？
设计问题：如果以游戏设计师为核心用户来重新设计游戏引擎的抽象层次和交互范式，其架构应该是怎样的？
可行性问题：这种设计视角的引擎在现有技术条件下是否可行？其实现路径和潜在风险是什么？

1.3 研究范围与方法

研究范围：本报告聚焦于游戏引擎中与游戏逻辑设计相关的工具链部分，涵盖规则系统、技能系统、属性系统、状态机等核心模块。报告暂不深入讨论渲染引擎、物理引擎、网络同步等底层技术域，尽管它们在某些场景下与设计工具存在交互。

研究方法：本报告采用以下研究方法的组合：

文献综述：梳理游戏引擎架构、数据驱动设计、声明式编程等领域的相关文献，包括学术论文（GDC技术演讲、ACM/IEEE论文）和权威技术文档（Unity/Epic官方技术博客，白皮书）。
案例分析：通过分析现有游戏引擎（Unity、Unreal、Godot）的技能系统设计，识别其在支持设计师工作流方面的优势与局限。
概念设计：基于分析结果，提出"设计视角引擎"的概念架构，并通过逻辑推演验证其内部一致性。
可行性评估：参照现有技术实践（Photon Quantum、ECS架构等），评估概念设计的技术可行性。

技术参照说明：本报告在第八章引入函数式响应式编程（FRP）作为学术参照，以展示声明式编程范式在游戏领域的学术探索。FRP并非本报告推荐的技术栈选择，其引入旨在拓展读者对声明式设计思想的理解边界。

研究定位：本报告是一篇概念性架构设计提案，而非实证研究报告。报告中的设计主张将通过逻辑论证和现有技术实践的比照来支撑，而非通过实验数据或用户研究来验证。

核心术语界定

为避免概念混用导致的理解歧义，本节对本报告涉及的核心术语进行明确界定。

2.1 "设计师"的角色界定

本报告中的"设计师"（或"游戏设计师"、"策划"）特指以下角色：

系统策划：负责游戏机制、数值体系、规则系统的设计
关卡策划：负责游戏内容（关卡、遭遇、任务）的设计与配置
数值策划：负责游戏中数值（属性、伤害、概率等）的平衡与调优

本报告不涉及以下角色的工作流优化：

美术设计：角色、场景、UI等视觉内容的创作
音频设计：音效，音乐等听觉内容的创作
叙事设计：剧情、对话、世界观等叙事内容的创作

需要指出的是，不同子角色的需求存在显著差异。系统策划最关注规则和逻辑的表达，关卡策划更关注空间布局和事件序列，而数值策划需要频繁调整和比较数值。设计视角引擎的抽象层次需要能够同时满足这些差异化需求，这是设计中需要权衡的复杂性来源。

2.2 "数据驱动"的层次区分

本报告在两个不同层次使用"数据驱动"概念，需要明确区分：

数据驱动配置（Data-Driven Configuration）：指将游戏参数（数值、阈值、概率等）从代码中提取到外部配置文件中，允许非程序员通过修改配置而非代码来调整游戏行为。这是当前主流引擎普遍支持的工作模式，如Unity的ScriptableObject、Unreal的DataAsset。这一层次的实现相对简单，但本质上并未改变"代码定义规则，配置填充参数"的基本范式。

数据驱动架构（Data-Driven Architecture）：指将游戏逻辑本身建模为数据（而非代码），引擎的核心职责是解释和执行这些数据化的逻辑。这一层次要求对"什么是数据"、"什么是逻辑"进行根本性的重新定义，是设计视角引擎的核心技术特征。

本报告在第四章讨论的"中心化数据仓库"即属于数据驱动架构层次。

2.3 "声明式"与"命令式"的对比

命令式编程（Imperative Programming）：描述如何达成目标的一系列步骤。示例："如果玩家按了E键，并且与门距离小于2米，则播放开门动画，然后切换关卡。"

声明式编程（Declarative Programming）：描述目标本身及其约束，由系统推断达成方式。声明式逻辑关注的是"是什么"（门具有锁定/解锁状态）而非"怎么做"（如何检查锁、如何播放动画）。

声明式设计的优势在于让设计师能够表达高层意图，而将具体实现细节委托给引擎。然而，声明式并非万能——高度动态或需要精细控制的行为可能仍然需要命令式逻辑。设计视角引擎不需要完全排斥命令式，而是需要在两者之间找到合适的平衡点。

2.4 "关系图谱"的定义

本报告中的"关系图谱"（Relationship Graph）是一种数据结构，用于显式存储和管理游戏设计元素之间的依赖关系。节点代表设计元素（属性、技能、状态），边代表它们之间的关系（影响、触发、依赖）。关系图谱的关键特征包括：

显式性：所有设计关系都是可查询、可追踪的，而非隐式散布在代码中
双向性：每个元素既知道它依赖什么，也知道什么依赖它
动态性：随着设计操作实时更新
语义丰富性：边携带类型信息（影响、触发、依赖、展示），而非简单的指针引用

关系图谱与代码中的"对象引用"或"指针"不同——它是一种更高层次的设计意图表达，可以跨越组件和系统的边界。关于关系图谱与现有引擎依赖管理系统的差异，详见第五章第一节的对比分析。

主流引擎的案例分析

本节对主流游戏引擎的技能系统进行案例分析，识别其在支持设计师工作流方面的设计选择与局限性。需要特别指出的是，本节的案例分析并非对相关系统的全面评价，而是聚焦于其与"设计视角"范式的契合程度。

3.1 Unreal Engine Gameplay Ability System

Unreal Engine的Gameplay Ability System（GAS）是Epic官方提供的技能框架，被广泛应用于《堡垒之夜》《帕利亚》等大型商业项目[来源: Gameplay Ability System Documentation | Epic Games | dev.epicgames.com/documentati… | 2024]。从技术角度，GAS是一个功能完备、高度可扩展的框架。

3.1.1 设计目标与技术特征

GAS的核心设计目标是解决以下技术问题[来源: Gameplay Ability System Documentation | Epic Games | dev.epicgames.com/documentati… | 2024]：

网络同步：通过AbilitySystemComponent和GameplayTag机制，实现复杂技能在多人环境下的可靠同步
架构一致性：为大型团队提供统一的技能开发框架，避免实现方式的碎片化
性能优化：通过C++实现和高效数据结构，支撑大量单位和效果的实时运算

从这些设计目标来看，GAS的首要服务对象是程序员和大型技术团队，这与其设计目标一致，并非缺陷。其核心抽象（Ability、AttributeSet、GameplayEffect）虽然功能强大，但对于不熟悉C++和Unreal网络架构的设计师来说，存在较高的认知门槛[来源: Gameplay Ability System - Best Practices | Epic Games | dev.epicgames.com/community/l… | 2024]。

3.1.2 与"设计视角"范式的错位

尽管GAS在技术上高度成熟，其抽象层次与"设计视角"范式存在以下根本性错位：

抽象模型的技术导向：GAS的核心概念（GameplayAbility、GameplayEffect、GameplayTag）是以程序员的技术理解为基础构建的。以GameplayTag为例，它采用层级枚举的方式组织，需要程序员在代码中预先定义标签体系，设计师只能在既定的标签空间内进行配置[来源: Gameplay Ability System Documentation | Epic Games | dev.epicgames.com/documentati… | 2024]。这种设计确保了类型安全性和性能优化，但也限制了设计师表达超出预设范畴的新概念。

配置复杂度的认知负担：一个典型的GameplayEffect可能包含多个Modifier，每个Modifier可设置不同的Attribute、运算方式和数值来源。这种配置方式虽然灵活，但也意味着设计师需要理解一系列技术概念（Instant/Duration/Infinite效果类型、叠加规则、Gameplay Cue触发等）才能有效工作。

工作流中的依赖关系：在GAS的标准工作流中，程序员首先需要定义AttributeSet、编写Ability基类、建立GameplayTag层级，然后设计师才能在框架内进行配置。这种"框架先行"的模式在大型团队中可以有效协调工作，但也意味着设计师的创作自由受到程序员预先定义的系统边界的约束。

3.1.3 客观评价

GAS的"学习曲线陡峭"和"依赖程序员配合"并非设计缺陷，而是其设计目标的自然结果。GAS面向的是需要处理复杂多人技能系统的大型商业项目，在这类场景下，网络同步的可靠性和架构一致性比设计师的独立工作能力更重要，与其设计目标一致。

本报告的批评并非判定GAS"失败"，而是指出其与"设计视角"范式存在不同的优化方向。这种区分对于理解设计视角引擎的适用边界至关重要。

3.2 Unity技能系统生态

Unity平台本身不提供内置的完整技能系统，而是通过Asset Store插件或社区方案来满足相关需求。这种生态策略使得Unity在技能系统层面存在更大的设计多样性，但同时也缺乏像GAS那样统一的官方标准。

3.2.1 Unity数据驱动配置的局限

Unity的ScriptableObject系统提供了一定程度的数据驱动能力，允许设计师创建可配置的数据资源[来源: Unity ScriptableObject Documentation | Unity Technologies | docs.unity3d.com/Packages/co… | 2024]。然而，Unity的数据驱动主要停留在"数据驱动配置"层次，即允许设计师配置参数值，而非"数据驱动架构"层次，即允许设计师以数据方式定义规则本身。

以Unity的Physics Material为例，设计师可以配置摩擦系数和弹性系数，但无法以数据方式定义"当物体A接触物体B时，根据双方材质类型触发特定行为"这样的跨对象规则。这类规则仍然需要通过脚本来实现。

3.3 Unity Histera的ECS实践

如果说GAS展示了"程序员视角"设计的技术完备性，那么《Histera》的ECS实践则提供了一个观察"数据驱动架构"在生产环境中表现的窗口。

3.3.1 项目背景

《Histera》是由荷兰独立工作室StickyLock Games开发的免费多人FPS游戏[来源: Histera Case Study | 80.lv | 80.lv/articles/hi… | 2024]。该工作室最初仅有5人，专注于XR项目，目前已发展到约70人，在荷兰和西班牙均设有办公地点。选择Unity作为引擎的主要原因是其较低的技术门槛、C#作为入门语言、多平台发布能力以及移动开发优势。

3.3.2 "Glitch"机制与动态内容切换

《Histera》的核心卖点是"Glitch"机制——游戏中地图区域会在过去、现在、未来三个时代之间实时转换[来源: Unity DOTS | Unity Technologies | unity.com/dots | 2024]。这一机制为游戏引入了独特的混乱感和战术多样性：玩家可以在战斗中获得特殊道具来触发Glitch事件，从而改变地形布局和视觉风格。

这种动态内容切换的实现依赖Unity的SubScene技术。SubScene允许将不同时代的地图保存为独立的子场景，美术团队可以并行编辑而不会产生文件冲突。更重要的是，SubScene中的内容在构建时会被序列化为Entity数据，在运行时可以快速整块加载或卸载，实现近乎无缝的场景切换。

3.3.3 Unity DOTS的技术收益与代价

《Histera》重度依赖Unity DOTS（Data-Oriented Technology Stack）技术栈，包括ECS（Entity Component System）、Job System和Burst Compiler[来源: Unity DOTS | Unity Technologies | unity.com/dots | 2024]。团队从早期DOTS版本逐步升级到Unity 2022 LTS，以获得更高的性能潜力和更好的稳定性。

DOTS架构为《Histera》带来了以下技术收益：

运行时性能优化：ECS的数据布局优化使大量实体的更新更加高效
多线程支持：Job System允许将密集计算分配到多个CPU核心
并行编辑协作：SubScene的独立性支持团队并行工作流

然而，DOTS也带来了显著的代价。开发团队在访谈中明确建议："在学习DOTS之前，先掌握Unity基础和面向对象编程"[来源: Histera Case Study | 80.lv | 80.lv/articles/hi… | 2024]。对于设计师而言，理解"实体转换"和"SubScene状态"等概念仍然需要技术背景支持。

3.3.4 对设计视角引擎的启示

《Histera》案例揭示了"数据驱动架构"实践中的几个重要观察：

数据驱动架构确实能支持复杂的运行时动态内容：SubScene技术使得在不同时代地图之间无缝切换成为可能，这与报告第五章"关系图谱"中"原子化变更"的理念存在共鸣——都强调将内容分解为可独立管理、可动态加载的单元。

技术门槛发生了转移，而非消失：DOTS将性能优化的复杂性封装在ECS架构中，但设计师仍然需要理解"实体"、"组件"、"系统"等概念。数据驱动架构并非消除了技术门槛，只是将其从"运行时优化"转移到"架构设计"层面。

并行协作需要约定与规范：《Histera》中SubScene能够支持并行编辑，依赖于明确的子场景边界划分。这提示设计视角引擎的关系图谱维护也需要类似的约定——哪些依赖关系需要显式声明，以支持增量构建和并行编辑。

3.4 案例分析的启示

通过对GAS、Histera和Unity技能系统的案例分析，可以得出以下启示：

启示一：技术完备性与设计友好性之间存在张力。 GAS在网络同步和性能优化方面高度成熟，但这些技术优势需要通过复杂的抽象层次来实现，客观上增加了设计师的理解门槛。

启示二："数据驱动"存在不同深度。 多数引擎支持"数据驱动配置"（参数可调整），但较少支持"数据驱动架构"（规则可定义）。Histera的SubScene实践表明，即使在"数据驱动架构"层面，设计师仍需理解底层抽象概念。

启示三：数据驱动架构的优势在于并行协作与动态内容。 Histera的Glitch机制展示了数据驱动架构如何支持复杂的运行时动态内容切换。SubScene的独立性也使得并行编辑成为可能，与设计视角引擎"原子化变更"的理念存在共鸣。

启示四：技术门槛会发生转移，但不会消失。 DOTS将性能优化的复杂性封装起来，但引入了"实体"、"组件"、"系统"等新概念。设计视角引擎的目标不应是"消灭技术概念"，而是让这些概念更贴近设计意图的表达。

启示五：工具定位影响设计选择。 面向大型团队的工具（如GAS）倾向于提供强类型的、可扩展的框架，而面向独立设计师的工具可能更适合采用更灵活但约束更少的范式。设计视角引擎需要在这种权衡中找到自己的定位。

设计视角引擎的概念架构

本节提出"设计视角引擎"的概念架构，阐述其核心抽象、组件关系和技术特征。需要强调的是，本节的内容是对一种理想形态的概念描述，而非对现有系统的实现报告。

4.1 核心设计理念

设计视角引擎的核心设计理念可以概括为：以游戏设计师的思维模式为中心组织引擎抽象，而非以程序员的实现模型为基础。

这一理念包含以下子目标：

意图优先：设计师表达"做什么"而非"怎么做"
关系显式：设计元素之间的依赖关系可追踪、可查询
配置即逻辑：游戏规则以数据方式存储，而非代码方式实现
实时反馈：设计修改能够即时在运行时生效，减少迭代周期

4.2 系统架构概述

设计视角引擎的系统架构可以划分为以下层次：

flowchart TB
    subgraph Presentation["表现层"]
        UI["设计工作台 UI"]
        Graph["关系图谱可视化"]
        Debug["调试与回放面板"]
    end

    subgraph Meta["元层 - 关系图谱"]
        DG["设计关系图谱"]
        Q["查询引擎"]
    end

    subgraph Core["核心模拟层"]
        DR["数据仓库<br/>(反应式)"]
        SYS["系统群<br/>(无状态)"]
        SIM["确定性模拟器"]
    end

    subgraph Runtime["运行时层"]
        RE["规则引擎"]
        RV["渲染视图"]
        PH["物理引擎"]
    end

    UI --> DG
    Graph --> DG
    DG <--> Q
    Q --> DR

    DR -.->|"数据变化<br/>事件"| SYS
    SYS -.->|"读取/修改<br/>数据"| DR

    RE --> SIM
    SIM --> RV
    SIM --> PH

图1：设计视角引擎的层次架构

图注：虚线箭头表示数据流动方向。数据仓库与系统群之间的双向虚线表示：数据仓库通过反应式机制向系统推送变化事件，系统则通过标准接口修改数据仓库中的数据。

各层的职责如下：

表现层：提供设计师与引擎交互的界面，包括可视化编辑器、调试工具
元层（关系图谱）：维护设计元素之间的显式关系，支持依赖查询和影响分析
核心模拟层：运行确定性模拟，是引擎的"逻辑大脑"
运行时层：处理渲染、物理等与表现相关的功能

4.3 核心数据层

设计视角引擎的核心数据层是一个中心化的、类型安全的、反应式的数据仓库。与主流引擎中分散在各个对象实例中的数据不同，所有游戏状态都被存储为明确的、可查询的事实。

4.3.1 数据表示

实体[ID].属性 = 值
Global.全局变量 = 值

例如：

Entity[1024].Health = 150
Entity[1024].MaxHealth = 200
Entity[1024].Position = (10.5, 0.0, -3.2)
Global.Difficulty = 2

每个数据项都有明确的类型定义（而非动态类型的字典），这使得引擎能够：

为每种数据类型提供专用的编辑UI
进行网络同步优化（类型信息可用于生成序列化代码）
支持可视化调试（引擎知道哪些数据是"血量"而非"速度"）

与ECS架构的关系：本报告所述的"数据仓库"与ECS（Entity-Component-System）架构中的组件存储存在概念关联。ECS强调同类数据的连续存储以优化缓存利用率，而数据仓库更强调数据的中心化和可查询性。在实际实现中，数据仓库可以借鉴ECS的内存布局优化策略。

4.3.2 反应式机制

数据仓库的关键特性是其反应式（Reactive）能力：当某个数据项的值发生变化时，变化事件是引擎底层的原生机制。任何系统都可以订阅这些事件，而非在每帧的Update循环中轮询检查。

sequenceDiagram
    participant DS as 数据仓库
    participant SYS as 移动系统
    participant HPS as 生命系统

    DS->>SYS: 订阅 Entity[i].Health 变化
    DS->>HPS: 订阅 Entity[i].Health 变化

    Note over DS: Entity[1024].Health = 10
    DS->>HPS: HealthChanged(10)
    HPS->>DS: 修改状态 → 死亡
    DS->>SYS: 变化传播

图2：反应式数据流动示意图

这种机制的优势在于：

消除无意义的轮询开销
确保状态变化能够被所有相关系统及时感知
支持声明式规则的自然表达（"当X发生变化时，触发Y"）

4.4 运行时层

设计视角引擎的运行时由一系列独立的、无状态的系统组成，每个系统只处理特定类型的数据和逻辑。

4.4.1 系统示例

系统	输入数据	输出行为
移动系统	位置、速度	更新位置数据
生命系统	生命值、伤害事件	修改生命值，触发死亡
战斗系统	技能数据、目标选择	计算伤害，触发效果
状态系统	状态列表、持续时间	添加/移除状态
AI系统	感知数据、行为树	生成移动/攻击指令

4.4.2 配置驱动的系统连接

在传统引擎中，系统之间的协作通过代码显式调用实现。在设计视角引擎中，这种协作通过配置而非代码来定义。

例如，"当玩家按下E键且与门距离小于2米时开门"这一逻辑，在配置层面的表示是：

{
  "trigger": {
    "type": "AND",
    "conditions": [
      {"type": "Input", "action": "Interact"},
      {"type": "Distance", "from": "Player", "to": "Door", "max": 2.0}
    ]
  },
  "effect": {
    "type": "SetState",
    "target": "Door",
    "state": "Open"
  }
}

这种配置化的系统连接使得设计师能够以可视化的方式（而非文本代码）定义跨系统的协作逻辑。

4.5 持久化与逻辑层

设计视角引擎的持久化层采用图结构来存储逻辑和状态，而非传统引擎的线性代码文件。

4.5.1 逻辑即数据

设计师在编辑器中创建的"技能行为树"或"状态机"，在底层直接就是可执行的数据图。行为树的节点（选择器、顺序器、条件节点）是存储在数据层中的静态资产，由通用的"行为树系统"在运行时遍历执行。

这与主流引擎形成对比。以Unity为例，行为树通常是运行在Update循环中的C#类实例，节点对象与执行逻辑耦合在一起。在设计视角引擎中，节点是数据，执行器是通用的——这使得同一个行为树可以在不同的上下文中复用。

4.5.2 确定性保证与商业参照

为支持"游戏回放"等功能，设计视角引擎的运行时必须具备确定性（Determinism）——相同的输入序列必须产生相同的输出序列。

实现确定性的关键技术包括：

固定时间步长：模拟以固定的帧间隔更新，而非依赖实际时间
种子化随机：所有随机数基于固定种子生成，确保可复现
浮点数消除：使用定点数或整数运算替代浮点数，避免跨平台精度差异
输入录制：保存从游戏开始到当前时刻的所有玩家输入，支持完美回放

商业案例参照：Photon Quantum是确定性游戏引擎领域的代表性商业产品[来源: Photon Quantum | Exit Games | www.photonengine.com/quantum | 2024]。其核心技术特征包括：视图-模拟分离（游戏逻辑运行在独立的确定性模拟中，表现层仅负责渲染）、确定性ECS（底层采用高性能ECS架构，无GC，支持固定时间步长）、内置回放（记录输入序列，支持1:1完美回放）、低网络开销（仅传输输入指令，无需同步完整游戏状态）。Quantum已被用于《Stumble Guys》（32人同场+物理）等对实时性要求高的产品，证明了确定性架构在商业游戏中的可行性。

关系图谱：核心创新与差异化分析

关系图谱是设计视角引擎的核心创新，它使得设计意图从隐式代码变为显式可追踪的数据结构。然而，"依赖关系图"并非全新概念——主流游戏引擎中已存在各种形式的依赖管理机制。本节首先进行差异化分析，明确关系图谱相对于现有实践的增量价值。

5.1 与现有引擎依赖管理系统的对比

5.1.1 Unity AssetDatabase依赖查询

Unity通过AssetDatabase.GetDependencies() API提供资源依赖查询功能[来源: Unity AssetDatabase API | Unity Technologies | docs.unity3d.com/ScriptRefer… | 2024]。该API返回指定资源依赖的所有资产路径，实现资源的引用追踪。

// Unity示例：获取资源的所有依赖
string[] dependencies = AssetDatabase.GetDependencies("Assets/MyScriptableObject.asset", true);

Unity的依赖查询存在以下特点：

以资产为中心：查询粒度是文件级别的资源，而非数据类型级别的属性
单向引用：仅追踪"谁引用了谁"，无法反向查询"谁被谁引用"
静态快照：在构建时或编辑器运行时获取，不支持运行时的动态关系追踪
语义盲区：仅反映代码层面的引用关系，不区分"影响"、"触发"、"依赖"等设计语义

5.1.2 Unreal DataAsset引用链

Unreal Engine的DataAsset系统允许创建结构化的数据资产，并支持资产之间的软引用和硬引用[来源: Unreal Engine Data Asset Documentation | Epic Games | dev.epicengine.com/documentati… | 2024]。UE的内容浏览器提供依赖关系查看功能。

Unreal的依赖管理存在以下特点：

以资产聚合为基础：强调数据资产的组织和打包
蓝图友好的引用追踪：支持通过蓝图可视化查看引用链
运行时引用限制：运行时引用解析有特定规则，非所有引用类型都支持运行时访问

5.1.3 社区插件的局限性

Unity Asset Store和GitHub上存在多个依赖图可视化插件（如Unity-AssetDependencyGraph[来源: Unity-AssetDependencyGraph | favoyang | GitHub | github.com/favoyang/Un… Editor内提供可视化的资产依赖图，但其功能边界与AssetDatabase类似：文件级别的引用追踪，不支持设计语义的区分。

5.2 关系图谱的增量价值

基于上述分析，关系图谱相对于现有依赖管理实践的增量价值体现在以下三个维度：

维度	现有引擎实践	关系图谱	增量价值
语义丰富性	仅表示"引用"关系	边携带类型（影响/触发/依赖/展示）	设计师可理解关系的设计意图，而非仅知道存在引用
双向查询	仅支持正向追踪（谁引用了X）	双向可查询（谁引用了X，X被谁引用）	支持影响分析和变更评估
运行时绑定	静态的构建时依赖	与数据仓库联动，实时反映运行状态	图变化可触发模拟更新，支持"断点检测"调试

简言之，关系图谱的创新不在于"有图"本身，而在于语义化的边类型、双向查询能力、与运行时模拟的反应式联动。

5.3 关系图谱的设计

5.3.1 节点与边的定义

graph LR
    subgraph Entities["实体节点"]
        HP["血量"]
        MP["魔法值"]
        ATK["攻击力"]
    end

    subgraph Effects["效果节点"]
        DMG["伤害效果"]
        HEAL["治疗效果"]
    end

    subgraph Entities2["状态节点"]
        BURN["燃烧"]
        FROZEN["冰冻"]
    end

    HP -.->|"影响<br/>(虚线箭头)"| DMG
    HP -.->|"影响"| HEAL
    ATK -.->|"参与计算"| DMG
    BURN -.->|"触发<br/>(点线)"| HP
    FROZEN -.->|"触发"| MP

图3：关系图谱示例（边类型可视化）

图注：图中虚线箭头表示"影响"关系，点线表示"触发"关系。不同边类型使用不同线型区分。

5.3.2 边的类型

关系图谱中的边可以表达多种语义：

边类型	含义	示例
影响	A的变化会影响B的计算结果	攻击力 → 伤害计算
触发	A的发生会导致B的执行	冰冻 → 减速效果
依赖	A的存在是B的前提条件	魔法值 → 技能释放
展示	A用于可视化B	血量 → UI血条

5.3.3 查询能力

基于关系图谱，设计师可以执行以下查询：

影响分析："哪些因素影响血量？" → 返回所有指向血量的边
依赖追踪："修改攻击力会影响哪些内容？" → 返回所有从攻击力出发的边
断点检测："为什么冰冻效果没有生效？" → 追踪从冰冻到目标属性的完整路径，识别缺失的连接

5.4 关系图谱的实现挑战

实现关系图谱面临以下技术挑战：

动态依赖的处理：某些依赖是运行时的、条件性的（如"当血量低于30%时触发狂暴"）。这类依赖在编辑时难以确定，需要设计师显式声明或通过静态分析推断。

性能考虑：大型项目可能有数千个节点和数万条边，实时查询和可视化需要优化。可能的解决方案包括分层图（只显示当前关注区域）、懒加载、使用图数据库作为后端。

与代码的集成：当某些逻辑仍然以代码方式实现时，关系图谱无法自动捕获这些隐式依赖。这需要在架构上进行约束（例如要求所有逻辑都通过配置而非代码定义），或在代码中添加显式的依赖声明API。

案例深化：Baba Is You的架构映射

本节通过Baba Is You这一具体案例，展示设计视角引擎如何处理动态规则修改问题。之所以选择这一案例，是因为其核心机制（玩家修改规则）与设计视角引擎的核心理念（规则是一等公民）存在直接的对应关系。

6.1 Baba Is You的机制概述

Baba Is You是一款以"规则修改"为核心机制的解谜游戏[来源: Baba Is You | Hempuli | Steam | store.steampowered.com/app/849740/… | 2019]。游戏中的规则以文字块形式呈现在场景中，玩家通过推动这些文字块来修改游戏规则。例如，将"WALL IS STOP"改为"WALL IS PUSH"后，墙壁从不可穿越变为可推动。

游戏的核心规则语法如下[来源: Baba Is You Wiki | Fandom | babaiswiki.fandom.com/wiki/Rule | 2024]：

X IS Y：将X赋予Y属性
X IS NOT Y：阻止X获得Y属性
X HAS Y：当X被销毁时生成Y
X ON Y：仅当X与Y重叠时生效

6.2 在设计视角引擎中的实现

6.2.1 规则数据结构

在设计视角引擎中，每条规则对应图谱中的一条边，采用以下简化数据结构表示：

// 规则数据结构示例
{
  "rule_id": "rule_001",
  "subject": "WALL",
  "predicate": "IS",
  "object": "STOP",
  "scope": "GLOBAL",          // 或 "ON_ENTITY"
  "condition": null,           // 或条件表达式
  "metadata": {
    "source": "level_03",
    "created_by": "designer_hempuli"
  }
}

当规则发生修改时，引擎执行以下操作序列：

# 规则修改伪代码
def apply_rule_change(old_rule, new_rule):
    # 1. 从图中移除旧规则边
    graph.remove_edge(old_rule.subject, old_rule.predicate, old_rule.object)

    # 2. 在图中添加新规则边
    graph.add_edge(new_rule.subject, new_rule.predicate, new_rule.object)

    # 3. 触发规则重新评估
    rule_engine.reevaluate()

6.2.2 语义解析机制

Baba Is You中"IS"的语义在不同语境下有所不同：

"BABA IS YOU"中的IS意味着"可被玩家控制"
"WALL IS STOP"中的IS意味着"阻止移动"
"FLAG IS WIN"中的IS意味着"定义胜利条件"

在设计视角引擎中，这种上下文相关的语义通过规则解析系统处理：

// IS语义的配置注册表示
{
  "IS_semantics": {
    "YOU": {
      "type": "CONTROL",
      "effect": "player_can_control_subject"
    },
    "STOP": {
      "type": "COLLISION",
      "effect": "subject_blocks_movement"
    },
    "WIN": {
      "type": "CONDITION",
      "effect": "triggers_level_completion"
    }
  }
}

当规则边发生变化时，规则解析系统查询语义注册表，将规则标签映射到对应的行为定义，并自动触发相关的行为更新。

6.2.3 复杂性考虑

Baba Is You的实现比简化描述要复杂得多：

规则优先级：当多条规则同时影响同一属性时，需要定义优先级和冲突解决策略。

递归依赖：如"BABA IS ROCK"且"ROCK IS STOP"意味着BABA也STOP。这种传递性需要通过图的遍历算法处理。

词块本身的递归性：词块本身也是可交互的游戏物体，需要与规则系统协调。

对于前两个问题，设计视角引擎的图结构和确定性模拟提供了自然的解决方案。对于递归性问题，可能需要在架构上进行特殊处理，例如区分"普通实体"和"规则实体"。

6.3 案例分析的局限性说明

需要承认的是，本案例分析目前停留在概念映射层面，缺乏以下维度的验证：

原型实现：尚未构建可运行的原型来验证架构设计的可行性
性能评估：未对复杂关卡（如包含数十条动态规则）下的性能表现进行评估
用户验证：未通过设计师测试来验证这种规则表达方式是否真的比传统方式更易理解

本案例分析的价值在于展示设计视角引擎的核心抽象如何可能应用于特定问题域，而非证明其已经有效解决了这些问题。

实践路径分析

7.1 基于现有引擎的扩展策略

鉴于从零构建完整引擎的巨大工作量，更务实的策略是在现有引擎基础上进行扩展。Godot引擎因其开源属性和灵活的插件系统，成为这一策略的首选平台[来源: Godot Engine | godotengine.org | 2024]。

7.1.1 Godot插件实现的可行性矩阵

Godot的插件系统允许添加自定义节点、资源类型和编辑器面板[来源: Godot插件文档 | docs.godotengine.org/en/stable/t… | 2024]。以下功能在插件层面的可行性评估：

功能	可行性	说明	备注
自定义Resource类型	高	Godot原生支持	Forge等插件已有实践
可视化规则编辑器	中	需要使用GraphEdit或自研UI	技术可行，需较多开发工作
关系图谱维护	中	可通过自定义Resource实现	难以覆盖引擎内部依赖，需约定
实时调参面板	高	通过EditorInterface可在运行时修改Resource	Godot原生支持
反应式数据仓库	低-中	需自定义数据更新机制	无法修改核心Update循环，但可建立订阅模式
确定性模拟	低	需修改SceneTree核心行为	确定性回放难以在插件层完整实现
回放系统	低-中	确定性模拟是前提	取决于确定性模拟的实现深度

关键判断：反应式数据仓库的核心概念（订阅-发布模式）可在插件层通过自定义中间层实现，但会引入额外的抽象开销。确定性模拟由于需要修改引擎核心循环，在插件层无法完整实现，但可通过外部模拟器（如专用确定性运行时）部分实现。

7.1.2 Fork改版策略

对于插件层无法实现的功能（如确定性模拟），可能需要Fork Godot源码进行深度修改。Godot Rapier Physics插件已经实现了确定性物理引擎集成[来源: Godot Rapier Physics | godot-rust | GitHub | github.com/godot-rust/… | 2024]，证明了这一路径的技术可行性。

然而，Fork策略面临以下风险：

需要持续合并上游更新，维护成本高
深度修改可能导致与社区版本的不兼容
确定性模拟需要修改核心循环，影响范围广

7.2 推荐实践载体

基于卡牌游戏的Roguelite是验证设计视角引擎核心理念的理想载体，原因包括：

规则密集：技能、状态、遗物等元素构成复杂的规则网络
确定性友好：回合制逻辑天然适合确定性模拟
迭代频繁：Roguelite需要频繁调整平衡性，实时调参价值凸显
开发成本可控：2D UI为主，无需复杂的3D资产

7.3 风险识别

7.3.1 技术风险

关系图谱的性能：大型项目的图规模可能影响查询和可视化性能
与引擎的集成深度：插件层的集成能力有限，某些设计可能需要引擎级别的修改
确定性覆盖范围：如果仅部分系统支持确定性，回放功能将不完整

7.3.2 范式风险

设计师接受度：并非所有设计师都习惯或偏好"规则定义"式的工作方式
技能迁移成本：设计师可能需要学习新的概念模型和工具操作
生态锁定：一旦采用特定架构，迁移到其他平台将面临成本

7.3.3 市场风险

商业引擎的竞争：如果Unity/Unreal推出设计友好型的新功能，自研引擎可能失去竞争力
技术演进：AI辅助设计等新技术的出现可能改变游戏工具的发展方向

7.4 时间线估计说明

以下时间线基于**最小可行原型（MVP）**的定义给出。MVP指在最小场景（如单一技能的完整设计-测试循环）下验证核心概念的原型，而非生产级工具链。

假设条件：

单人开发
每天投入4-6小时
开发者熟悉GDScript和Godot插件开发

阶段	目标	MVP最小范围	完整系统范围
核心战斗	实现卡牌系统的数据驱动框架	1-2周	3-4周
技能编辑器	可视化规则编辑器原型	1-2周	2-3周
关系图谱	基础的关系追踪和查询功能	2-3周	3-4周
回放系统	输入录制和确定性回放	-	4-6周
完整工具链	集成测试和迭代优化	-	4-8周

重要说明：上述时间线未充分考虑调试、文档编写、架构重构等隐性工作，实际开发时间可能显著更长。本报告将这一路径定位为探索性方向，而非经过验证的可行性计划。

局限性与适用范围

9.1 设计视角引擎的固有局限

9.1.1 表达能力的边界

任何抽象层次都存在其表达能力无法覆盖的边界。设计视角引擎的声明式、配置化范式可能在以下场景下面临挑战：

高度动态的行为：需要根据运行时上下文进行复杂判断的行为，可能难以用静态配置表达
性能关键的路径：对于每一帧调用数千次的底层逻辑，手工优化的代码可能优于通用解释器
创新的游戏类型：对于完全前所未见的游戏机制，可能需要代码级别的自由表达

9.1.2 迁移与学习成本

采用设计视角引擎意味着设计师需要学习新的概念模型和工具操作。对于已经习惯传统引擎工作流的团队，这种迁移成本是不可忽视的。

9.2 适用范围分析

基于上述分析，设计视角引擎可能最适合以下场景：

理想场景：

规则密集型的游戏类型（卡牌、Roguelite、策略）
设计师需要频繁迭代和调整平衡性的项目
小型团队，设计师需要承担更多实现责任

不太适合的场景：

需要精细物理交互的游戏（实时动作、物理模拟）
对性能要求极高的大型3A项目
团队中设计师与程序员已有成熟的分工协作模式

9.3 与主流引擎的关系

设计视角引擎并非要取代Unity或Unreal，而是提供一种补充性的开发范式。即使在传统引擎中，也可以借鉴其核心理念（例如强化数据驱动配置、建立设计关系追踪）来改善设计师的工作体验。

结论与展望

10.1 研究总结

本报告作为一篇概念性架构设计提案，探讨了"设计视角"游戏引擎的设计理念与技术架构。主要贡献包括：

问题定义：识别了当前主流引擎在支持设计师工作流方面的设计局限性，指出这些局限性源于"技术优先"的设计哲学
概念框架：提出以"关系图谱"为核心的设计视角引擎架构，阐述其核心抽象（数据仓库、无状态系统、配置化连接），并通过与现有引擎实践的对比明确其增量价值
案例分析：通过GAS和Unity技能系统的案例分析，展示"程序员视角"设计与"设计视角"设计的不同优化方向
可行性评估：基于现有技术实践（Photon Quantum、Godot插件生态），评估了概念设计的实现路径与潜在风险

10.2 研究局限

本报告存在以下局限性，需要在后续工作中加以完善：

缺乏原型验证：概念设计尚未通过可运行原型进行技术验证
用户研究缺失：未通过设计师测试验证其对"规则定义"式工作方式的接受度
市场分析不足：未深入分析设计视角引擎的商业潜力与竞争态势

10.3 未来研究方向

基于本报告的分析，以下方向值得进一步探索：

最小可行原型（MVP）构建：从最简单的可验证场景（如单一技能的完整设计-测试循环）开始，逐步扩展功能
设计师用户研究：通过访谈或可用性测试，了解目标用户（系统策划、关卡策划）的实际需求与偏好
与AI技术的结合：探索大语言模型在规则生成、配置建议等方面的应用潜力
工业工具链集成：研究设计视角引擎如何接入版本控制、CI/CD，性能分析等工业化工具

参考来源

序号	来源类型	标题/名称	作者/机构	具体位置	访问链接	日期
[1]	学术著作	Game Engine Architecture	Gregory, Jason	A K Peters/CRC Press	第1-3章	2019
[2]	学术论文	SyDRA: An Approach to Understand Game Engine Architecture	Ullmann et al.	ScienceDirect	DOI:10.1016/j.sysarc.2024.202402003	2024
[3]	技术文档	Using Gameplay Abilities in Unreal Engine	Epic Games	Unreal Engine Documentation	官方文档	2024
[4]	技术文档	Gameplay Ability System - Best Practices	Epic Games	Epic Developer Community	教程文档	2024
[5]	技术文档	Unity ScriptableObject	Unity Technologies	Unity Documentation	官方文档	2024
[6]	案例研究	Histera: Developing a Multiplayer FPS in Unity	McKenzie, Theodore	80.lv	技术文章	2024
[7]	技术文档	Unity DOTS	Unity Technologies	Unity	官方文档	2024
[8]	学术论文	Developing games with data-oriented design	ACM Digital Library	ACM	DOI:10.1145/3524494.3527626	2021
[9]	技术文档	Photon Quantum	Exit Games	Photon Engine	官方文档	2024
[10]	技术文档	Godot Engine	Godot Community	Godot Engine	官方文档	2024
[11]	开源代码	Godot Rapier Physics	godot-rust	GitHub	仓库	2024
[12]	开源代码	Yampa FRP	Yale Haskell Group	GitHub	仓库	2024
[13]	技术文献	Baba Is You	Hempuli	Steam Store	游戏介绍	2019
[14]	游戏资料	Baba Is You Wiki - Rule	Fandom	babaiswiki.fandom.com	Wiki页面	2024
[15]	学术著作	Data-Oriented Design	Fabian, Richard	Self-published	书籍全文	2018
[16]	开源代码	Unity-AssetDependencyGraph	favoyang	GitHub	仓库	2024
[17]	技术文档	Unity AssetDatabase API	Unity Technologies	Unity Documentation	API参考	2024

报告完成时间：2026年4月 *作者：本人(HAI-9000/友善邪恶法师) ，DeepSeek, MiniMax 报告类型：概念性架构设计提案

设计视角游戏引擎：概念架构与可行性分析

摘要

引言