星火 2.0 开发文档

主题

理解星火：从地图编辑器到游戏引擎 ​

星火提供单位、技能、物品和场景等现成系统，也开放 Node 与组件级的引擎能力。你可以用现成系统组织适合它的玩法，用引擎能力补充局部功能，或者直接构造自己的游戏结构。选择的依据是你想做的游戏，以及哪些能力能减少实现和后续修改的成本。

这篇文章面向有地图编辑器或游戏引擎经验的读者，以及协助开发的 AI。 如果你还不熟悉数据、事件、节点和组件，可以直接从快速开始创建项目，先做出一个可玩的目标；不需要先学完本文。已经知道具体需求、只想查 API 时，直接阅读单位、表现、场景与 GameGraph 的桥接。

从你已有的经验开始 ​

你的经验或目标建议起点
魔兽争霸 III、星际争霸 II 地图编辑器，或星火 1.0先读“用数据、事件和场景组织玩法”
Unity、Urho 或类似游戏引擎先读“用 Node 与组件组织游戏对象”
已有星火项目，某项功能超出现成系统的表达范围读“在已有游戏里组合能力”，然后按需查桥接参考
希望主要由 AI 实现游戏读“让 AI 协助选择”，向 AI 描述玩法和希望保留的编辑方式

这些是理解入口，不决定项目必须采用哪条技术路线。熟悉地图编辑器的人可以开发自由物理沙盒；熟悉 Unity 的人也可以复用星火的单位、技能和物品系统。

用数据、事件和场景组织玩法 ​

如果你开发过暴雪地图，你已经熟悉一种有效的组织方式：在场景中布置内容，用数据定义对象和规则，再用事件与触发逻辑把它们连接起来。星火的集成玩法系统延续了这种思路，并提供 C# API、类型化数据和可以按需使用的引擎接口。

熟悉的工作星火中的入口负责什么
在地图中布置地形、区域和对象场景编辑器、SCE Scene场景内容、加载、切换和运行空间
定义兵种、英雄、技能、物品等数据编辑器、GameData可复用的内容定义、配置和引用
游戏开始、单位死亡、进入区域后执行逻辑触发编辑器、事件与 C# 逻辑连接条件、行为和玩法流程
管理移动、技能、属性、Buff、装备等Unit、Ability、Buff、Item 等集成的玩法机制
配置模型、动画、特效和声音表现系统与 Actor把玩法状态呈现给玩家

这些能力可以在适合它们的游戏中形成完整开发流程。例如塔防的建塔、刷怪、索敌、伤害、升级和奖励，可以围绕单位、技能、数据和事件组织，不必先实现一个通用对象系统。场景编辑器、数据编辑器、触发编辑器和运行调试共同支持这条创作路径。

类比用于迁移经验，不代表暴雪地图数据、脚本或星火 1.0 API 可以直接运行。2.0 的具体类型和接口应以当前 SDK 为准。图形化创作和 C# 开发都可以使用这套玩法系统；使用 AI 或增加底层功能，也不要求把已有的图形化数据、触发逻辑全部改写成手写代码。

高层系统有自己的机制和适用范围。如果大量工作变成关闭单位默认行为、绕过技能规则或重复维护同一份状态，就值得重新评估那部分功能的实现方式。

用 Node 与组件组织游戏对象 ​

GameGraph 提供底层 Urho 场景图的 C# 访问方式。Node 组织空间变换、父子关系和组件；组件提供模型、动画、物理、声音或脚本行为。你可以直接构造这些对象，也可以访问星火场景和单位已经使用的底层对象。

熟悉的概念星火中的对应入口需要保留的区别
Urho Scene / 场景图GameGraph SceneGraph与管理地图流程的 SCE Scene 分工不同
Unity GameObject + Transform / Urho NodeGameGraph Node这是职责类比，不是 Unity API 兼容层
Renderer、Animator、物理组件等模型、动画、物理等 Node 组件公共接口为 INodeComponent，原生组件包装通常继承 EngineNodeComponent
挂在对象上的脚本ScriptComponent 等具体生命周期按星火 API，不直接套用 MonoBehaviour 回调
自己搭建角色属性、技能、背包框架可评估 Unit、Ability、Item 等现成系统适合时复用，不适合时可以自己组织

引擎经验能够帮助你理解这些接口，但坐标系、资源路径、客户端与服务端职责、复制与发布流程仍需按星火约定处理。星火使用 Z 轴向上、XY 地面的坐标系；GameGraph 也不是所有 Urho API 的逐项绑定。

直接使用 Node 与组件可以实现独立小游戏、物理机关、场景预览或其他自定义对象。现成的单位战斗机制不会因为创建了 Node 而自动出现；同样，客户端创建一个可见对象也不意味着其他玩家会看到它。需要联机时，应为相关状态选择明确的同步方式。

在已有游戏里组合能力 ​

SCE 高层对象把玩法机制和底层引擎对象连接起来。单位的客户端模型表现由底层 Node 与组件承载；已就绪的 SCE 场景可以取得其底层 SceneGraph；脚本通过桥接 API 访问这些对象。高层 C# 类型并不继承 Node，一个单位也可能关联多个用途不同的节点。

mermaid
flowchart TD
    Authoring[场景编辑、数据定义、触发事件或 C# 逻辑] --> Gameplay[SCE 场景与单位、技能、物品等玩法系统]
    Gameplay --> Bridge[按需访问已有节点与组件]
    Direct[直接使用 GameGraph 开发] --> Engine[SceneGraph / Node / 组件]
    Bridge --> Engine
    UI[GameUI / Canvas] --> View[界面与交互]
    Gameplay --> View
    Engine --> View

这表示可以组合的能力，不是固定的创建顺序，也不是底层对象树。你可以只使用其中适合当前游戏的部分。

想增加的功能可以保留什么按需增加什么
塔防英雄的武器挂点和骨骼细节Unit、技能、伤害、升级与事件从单位的动画接口访问模型、骨骼和动画状态
RPG 场景里的自定义物理机关原有场景、任务、战斗与物品GameGraph 节点与物理组件；会影响联机结果时明确权威与同步
已有单位角色的物理移动和跳跃单位属性、技能与玩家归属评估现成 UnitMovementController，并让移动控制与空间模型一致
技能瞄准提示、地图标记或特殊视图原有玩法对象和数据根据显示位置选择 GameUI、Canvas 或场景内组件
独立物理小游戏里的耐久值已有 GameGraph 对象结构先评估轻量业务状态；需要单位机制时再考虑 Unit 集成

局部下钻的价值在于继续利用已有内容。它也有边界：直接改动画可能与高层动画调度冲突，直接写坐标可能与单位移动或物理模拟冲突，销毁底层节点可能破坏高层对象。具体写法与控制归属见桥接参考。

让 AI 协助选择 ​

你可以告诉 AI 玩法、当前项目已有的内容，以及哪些部分希望继续在编辑器里调整。例如：

> 我已经用数据和触发器做了塔防。请保留现有单位、技能和升级逻辑，帮英雄增加跟随右手骨骼的武器。我希望以后仍能在数据编辑器里换武器资源。

> 我熟悉 Unity，想做一个联机 RPG。请先评估星火已有的角色、技能和装备能力能复用多少，再实现最小战斗循环。

> 我没学过引擎开发，想先做出能放塔、刷怪、攻击的小游戏。请带我完成这个目标，遇到需要我决定的玩法再解释选项。

AI 应按功能选择能力，保留已经合适的项目结构，并核实接口是否存在。用户经验用于决定解释方式，不是选型条件。影响玩法效果、联网方式、性能或后续编辑能力的取舍应让用户理解；例行接口选择则由 AI 处理。用户没有表达过的假设，例如“这是单机游戏”或“以后不需要图形化修改”，不能被悄悄写成项目约束。

如果用户希望将更多实现交给 AI，AI 也仍应依据实际需求和当前 API 判断；现成系统、局部桥接、自定义实现都只是完成游戏的手段。文档和示例帮助 AI 做好判断，不代表每种组合已经自动实现或验证。

接下来读什么 ​