1. 项目概述为什么游戏对象需要一个“灵魂”在游戏开发的世界里屏幕上那些活灵活现的角色、四处滚动的宝箱、甚至是一盏随风摇曳的路灯它们都不是简单的贴图或模型。它们是一个个拥有独立生命周期的实体需要响应玩家的输入需要与环境互动需要按照既定的规则“思考”和“行动”。这个赋予它们“生命”的核心机制就是Actor组件模型。今天我们不谈虚幻引擎里那个庞大的AActor类也不谈Unity的GameObject我们来点更“硬核”的用纯C从零开始亲手打造一个属于我们自己的、轻量级且高效的Actor系统。为什么是C因为性能。在游戏开发尤其是对性能有极致要求的领域如大型MMO、动作游戏、模拟游戏C提供了对内存和计算资源的直接控制能力。一个设计良好的C Actor系统可以避免高级语言运行时如C#的GC、脚本语言的解释开销带来的不确定性让成千上万个游戏对象在同一帧内高效地更新、交互。这不仅仅是“造轮子”而是深入理解游戏引擎底层运作原理的绝佳实践。通过这个过程你将彻底明白一个游戏对象从“数据”到“行为”的完整生命周期是如何被管理的。2. 核心架构设计Actor与组件的共生关系一个健壮的Actor系统其核心在于清晰的责任划分。我们借鉴成熟的ECS实体-组件-系统思想和面向对象的设计模式但进行简化使其更贴近传统游戏对象的管理方式。我们的系统将围绕两个核心类展开Actor演员和Component组件。2.1 Actor类游戏世界的身份证与容器Actor代表游戏世界中的一个独立实体。它本身不直接定义具体行为比如移动、渲染而是作为一个容器和协调者存在。它的核心职责包括生命周期管理负责自身的创建、更新每帧逻辑和销毁。组件管理以列表形式持有多个Component实例负责组件的添加、查找和移除。空间变换维护实体在世界中的位置position、旋转rotation和缩放scale信息这是几乎所有组件行为的基础。状态与标签可以拥有激活active状态、标签tag或名称便于游戏逻辑进行筛选和批量处理。一个基础的Actor类头文件可能长这样// Actor.h #pragma once #include string #include vector #include memory #include glm/glm.hpp // 使用glm数学库处理向量和矩阵 class Component; // 前向声明 class Actor { public: // 生命周期 Actor(const std::string name Actor); virtual ~Actor(); // 每帧更新由游戏主循环调用 virtual void Update(float deltaTime); virtual void Render(); // 如果需要立即模式渲染 // 组件管理 template typename T, typename... Args T* AddComponent(Args... args); template typename T T* GetComponent(); template typename T std::vectorT* GetComponents(); // 空间变换 void SetPosition(const glm::vec3 pos) { m_Position pos; } glm::vec3 GetPosition() const { return m_Position; } // ... 类似地实现Rotation和Scale // 状态 void SetActive(bool active) { m_IsActive active; } bool IsActive() const { return m_IsActive; } private: std::string m_Name; bool m_IsActive true; glm::vec3 m_Position {0.0f}; glm::vec3 m_Rotation {0.0f}; glm::vec3 m_Scale {1.0f}; std::vectorstd::unique_ptrComponent m_Components; // 注意使用unique_ptr表示Actor拥有组件的所有权生命周期绑定。 };注意这里使用了glm数学库它是一个在图形编程中广泛使用的头文件库处理向量、矩阵运算非常方便。你需要通过vcpkg或直接下载头文件集成到项目中。如果追求极简也可以自己实现一个简单的Vec3类。2.2 Component类可插拔的行为模块Component是具体行为的载体。它的设计精髓在于“单一职责”和“可插拔性”。一个组件只做好一件事比如MoveComponent负责移动SpriteRenderComponent负责渲染一个2D精灵。组件通过附着在Actor上来获得上下文如位置信息并发挥作用。// Component.h #pragma once class Actor; class Component { public: Component(Actor* owner); virtual ~Component() default; // 虚析构函数确保派生类正确释放 // 生命周期函数由所属Actor调用 virtual void Update(float deltaTime) {} virtual void Render() {} Actor* GetOwner() const { return m_Owner; } protected: Actor* m_Owner; // 指向所属Actor的指针非拥有关系。 };关键设计决策为什么Component持有的是Actor*原始指针而不是shared_ptr因为组件的生命周期严格由其所属的Actor管理unique_ptr。组件不需要也不能决定Actor的生死它只是Actor功能的一部分。使用原始指针可以明确表达这种“非拥有”的依赖关系避免循环引用。只要确保在Actor的析构函数中先销毁所有组件这个设计就是安全的。3. 实现细节与核心代码解析有了骨架我们现在来填充血肉实现最关键的部分组件管理的模板函数和Actor的更新流程。3.1 组件管理的模板魔法在Actor.cpp中实现组件管理函数这是整个系统的粘合剂。// Actor.cpp #include Actor.h #include Component.h Actor::Actor(const std::string name) : m_Name(name) {} Actor::~Actor() { // 关键组件必须按添加的逆序销毁吗通常不需要但确保所有组件都被销毁。 m_Components.clear(); // unique_ptr会自动删除其管理的对象。 } void Actor::Update(float deltaTime) { if (!m_IsActive) return; // 先更新Actor自身的逻辑如果有的话 // OnUpdate(deltaTime); // 可以定义一个虚函数供派生类覆盖 // 然后更新所有组件 for (auto comp : m_Components) { if (comp) { comp-Update(deltaTime); } } } void Actor::Render() { if (!m_IsActive) return; for (auto comp : m_Components) { comp-Render(); } } // 核心添加组件 template typename T, typename... Args T* Actor::AddComponent(Args... args) { // 静态断言确保T是Component的派生类 static_assert(std::is_base_ofComponent, T::value, T must be derived from Component); auto newComp std::make_uniqueT(this, std::forwardArgs(args)...); T* rawPtr newComp.get(); m_Components.push_back(std::move(newComp)); // 可以在这里调用组件的初始化函数如OnStart() // rawPtr-OnStart(); return rawPtr; // 返回原始指针供外部使用 } // 核心获取第一个匹配类型的组件 template typename T T* Actor::GetComponent() { for (auto comp : m_Components) { T* derived dynamic_castT*(comp.get()); if (derived) { return derived; } } return nullptr; } // 核心获取所有匹配类型的组件 template typename T std::vectorT* Actor::GetComponents() { std::vectorT* result; for (auto comp : m_Components) { T* derived dynamic_castT*(comp.get()); if (derived) { result.push_back(derived); } } return result; } // 必须在.cpp文件中显式实例化模板否则链接器会找不到定义。 // 这是一个权衡要么把实现全放在头文件要么在这里为所有可能用到的组件类型实例化。 // 这里采用后者更清晰但需要手动维护。 // 例如 #include “MoveComponent.h” // 假设我们有这些组件 #include “SpriteRenderComponent.h” template MoveComponent* Actor::AddComponentMoveComponent(); template MoveComponent* Actor::GetComponentMoveComponent(); template std::vectorMoveComponent* Actor::GetComponentsMoveComponent(); // ... 为其他组件类型添加实例化实操心得关于模板函数定义的位置。一种常见做法是将这些模板函数的实现直接写在Actor.h中内联这样可以避免复杂的显式实例化。但代价是Actor.h会包含所有可能的组件头文件或者要求使用者在使用前包含所需组件头文件增加了编译依赖。我将实现放在.cpp并显式实例化虽然麻烦一点但使得Actor.h非常干净编译防火墙效果更好。对于中小型项目内联实现更简单对于大型项目显式实例化更利于编译速度和管理。3.2 编写具体组件以MoveComponent为例让我们实现一个具体的组件看看它如何与Actor协作。// MoveComponent.h #pragma once #include “Component.h” #include glm/glm.hpp class MoveComponent : public Component { public: MoveComponent(Actor* owner, float speed 100.0f); void Update(float deltaTime) override; void SetVelocity(const glm::vec3 vel) { m_Velocity vel; } glm::vec3 GetVelocity() const { return m_Velocity; } void SetSpeed(float speed) { m_Speed speed; } float GetSpeed() const { return m_Speed; } private: glm::vec3 m_Velocity {0.0f, 0.0f, 0.0f}; float m_Speed; };// MoveComponent.cpp #include “MoveComponent.h” #include “Actor.h” // 需要获取Owner的位置 MoveComponent::MoveComponent(Actor* owner, float speed) : Component(owner), m_Speed(speed) {} void MoveComponent::Update(float deltaTime) { if (!GetOwner() || !GetOwner()-IsActive()) return; // 计算位移 glm::vec3 movement m_Velocity * m_Speed * deltaTime; // 应用到位移到Actor的位置上 glm::vec3 newPos GetOwner()-GetPosition() movement; GetOwner()-SetPosition(newPos); // 可以在这里添加边界检查、碰撞检测回调等 }这个MoveComponent完美诠释了组件的单一职责它只关心如何根据速度和速度方向来移动其所属的Actor。它不需要知道这个Actor是玩家、敌人还是子弹它只做移动计算。Actor的位置是共享状态组件通过GetOwner()来读写。4. 游戏循环与Actor管理单个Actor和组件无法构成世界。我们需要一个World或Scene类来管理所有Actor并在游戏主循环中驱动它们。// Scene.h #pragma once #include vector #include memory class Actor; class Scene { public: Scene(); ~Scene(); Actor* SpawnActor(const std::string name “Actor”); void DestroyActor(Actor* actor); // 标记销毁非立即删除 void Update(float deltaTime); void Render(); private: std::vectorstd::unique_ptrActor m_Actors; std::vectorActor* m_ActorsToDestroy; // 待销毁队列 };// Scene.cpp #include “Scene.h” #include “Actor.h” Scene::Scene() default; Scene::~Scene() { m_Actors.clear(); } Actor* Scene::SpawnActor(const std::string name) { auto newActor std::make_uniqueActor(name); Actor* rawPtr newActor.get(); m_Actors.push_back(std::move(newActor)); return rawPtr; } void Scene::DestroyActor(Actor* actor) { if (actor) { m_ActorsToDestroy.push_back(actor); } } void Scene::Update(float deltaTime) { // 1. 更新所有活跃的Actor for (auto actor : m_Actors) { if (actor actor-IsActive()) { actor-Update(deltaTime); } } // 2. 处理待销毁的Actor延迟销毁避免在迭代中修改容器 if (!m_ActorsToDestroy.empty()) { auto it m_Actors.begin(); while (it ! m_Actors.end()) { // 查找当前actor是否在待销毁列表中 auto destroyIt std::find(m_ActorsToDestroy.begin(), m_ActorsToDestroy.end(), it-get()); if (destroyIt ! m_ActorsToDestroy.end()) { it m_Actors.erase(it); // unique_ptr自动释放内存 m_ActorsToDestroy.erase(destroyIt); if (m_ActorsToDestroy.empty()) break; } else { it; } } m_ActorsToDestroy.clear(); } } void Scene::Render() { for (auto actor : m_Actors) { if (actor actor-IsActive()) { actor-Render(); } } }关键点解析为什么需要m_ActorsToDestroy这个待销毁队列这是游戏开发中一个经典的“延迟销毁”模式。在Update循环中我们正在遍历m_Actors向量。如果某个Actor在更新过程中或其某个组件中直接调用DestroyActor(this)并立即从m_Actors中删除会导致迭代器失效引发未定义行为崩溃。因此我们只做标记在每帧更新的最后安全地清理这些被标记的Actor。5. 实战演练构建一个会移动和旋转的方块现在让我们把所有部分组合起来在一个简单的控制台或图形窗口例如使用SFML、SDL或OpenGL中创建一个演示。// main.cpp #include “Scene.h” #include “MoveComponent.h” // 假设我们有一个简单的RenderComponent用于在控制台打印位置 #include “ConsoleRenderComponent.h” int main() { Scene mainScene; // 创建主角Actor Actor* hero mainScene.SpawnActor(“Hero”); // 添加移动组件设置速度 auto* moveComp hero-AddComponentMoveComponent(50.0f); moveComp-SetVelocity(glm::vec3(1.0f, 0.0f, 0.0f)); // 向右移动 // 添加一个渲染组件用于在控制台输出位置 hero-AddComponentConsoleRenderComponent(); // 创建另一个Actor Actor* enemy mainScene.SpawnActor(“Enemy”); auto* enemyMove enemy-AddComponentMoveComponent(30.0f); enemyMove-SetVelocity(glm::vec3(0.0f, 1.0f, 0.0f)); // 向下移动 enemy-AddComponentConsoleRenderComponent(); // 简单的游戏循环 float deltaTime 0.016f; // 模拟60FPS for (int frame 0; frame 100; frame) { std::cout “\n--- Frame “ frame “ ---“ std::endl; mainScene.Update(deltaTime); mainScene.Render(); // ConsoleRenderComponent会打印位置 // 模拟一些游戏逻辑50帧后让敌人改变方向 if (frame 50) { enemyMove-SetVelocity(glm::vec3(-1.0f, 0.0f, 0.0f)); std::cout “[Logic] Enemy changed direction!” std::endl; } // 80帧后销毁英雄演示延迟销毁 if (frame 80) { std::cout “[Logic] Hero destroyed!” std::endl; mainScene.DestroyActor(hero); hero nullptr; // 避免野指针 } } return 0; }这个简单的循环展示了Actor系统的核心Scene管理Actor的生命周期Actor通过组合不同的Component来定义行为。你可以看到改变enemy的速度方向只需要操作其MoveComponent而销毁hero则通过Scene接口系统会自动处理其所有组件的清理。6. 性能优化与高级特性探讨一个基础的Actor系统已经成型但要用于真实项目我们必须考虑性能和扩展性。6.1 组件缓存与快速查找频繁使用GetComponentT()并通过dynamic_cast遍历查找在组件数量多时效率较低。一个优化方案是为每个组件类型分配一个唯一的类型ID并在Actor内部使用std::unordered_mapComponentTypeId, Component*进行缓存。添加组件时注册查找时直接O(1)查询。这增加了复杂度但提升了高频查找场景的性能。6.2 更新顺序与依赖某些组件更新有顺序要求。例如InputComponent应该在MoveComponent之前更新以便MoveComponent能使用最新的输入数据。我们可以在Component基类中引入一个UpdateOrder更新顺序整数属性Actor在更新时根据此值对组件列表进行稳定排序。更复杂的依赖关系可以考虑使用图来管理。6.3 序列化与场景持久化如何将游戏场景保存到文件下次运行时加载这就需要序列化。我们可以为Actor和每个Component类实现序列化接口如ToJson()和FromJson()。Scene负责遍历所有Actor和Component将它们的状态位置、速度、属性值保存为JSON、二进制或其他格式。加载时根据类型名动态创建组件实例并还原状态。这通常需要配合一个反射或注册系统。6.4 消息/事件系统组件之间如何通信比如一个CollisionComponent检测到碰撞后如何通知同一个Actor上的HealthComponent扣血硬编码耦合是糟糕的设计。引入一个轻量级的消息系统是优雅的解决方案。Actor可以提供一个SendMessage(const Message msg)函数所有组件都可以重写一个ReceiveMessage(const Message msg)虚函数。或者使用更松散的观察者模式让组件订阅特定的事件。避坑指南在实现消息系统时要特别注意性能。避免每帧发送大量消息。对于像“位置更新”这类高频事件更适合通过直接访问Actor的公共数据如位置来实现而不是通过消息。消息系统应主要用于低频、重要的逻辑事件如“受到伤害”、“拾取物品”、“死亡”。7. 与现有引擎架构的对比与思考我们实现的这个简易Actor模型其思想与主流商业引擎是相通的。与Unity的GameObject/Component对比Unity的组件模型更完善有强大的编辑器集成、序列化和完整的生命周期Awake, Start, OnEnable, Update, OnDisable, OnDestroy。我们的系统是一个核心原理的简化版。与虚幻引擎的AActor/UActorComponent对比虚幻的Actor功能更强大内置了网络复制、详细的生命周期、子Actor等高级功能。其组件也分为场景组件处理变换和逻辑组件。我们的设计更接近其核心思想。与纯ECS架构对比纯ECS如Unity DOTS EnTT库将数据Component、行为System和实体Entity仅为ID彻底分离旨在极致利用CPU缓存和多核并行。我们的Actor-Component模型可以看作是面向对象与ECS之间的一个折中更符合大多数人的思维习惯易于理解和上手在对象数量不是天文数字时性能完全足够。选择哪种架构取决于项目规模、团队习惯和性能目标。从零开始实现这个简易系统最大的价值在于理解。你理解了组件如何被添加、查找和更新理解了对象生命周期如何管理理解了数据与行为分离的好处。未来无论你使用Unity、Unreal还是其他引擎你都能更深刻地理解其底层运作机制从而写出更高效、更优雅的代码。
从零实现C++ Actor组件系统：游戏对象生命周期的核心架构
发布时间：2026/8/2 19:35:53
1. 项目概述为什么游戏对象需要一个“灵魂”在游戏开发的世界里屏幕上那些活灵活现的角色、四处滚动的宝箱、甚至是一盏随风摇曳的路灯它们都不是简单的贴图或模型。它们是一个个拥有独立生命周期的实体需要响应玩家的输入需要与环境互动需要按照既定的规则“思考”和“行动”。这个赋予它们“生命”的核心机制就是Actor组件模型。今天我们不谈虚幻引擎里那个庞大的AActor类也不谈Unity的GameObject我们来点更“硬核”的用纯C从零开始亲手打造一个属于我们自己的、轻量级且高效的Actor系统。为什么是C因为性能。在游戏开发尤其是对性能有极致要求的领域如大型MMO、动作游戏、模拟游戏C提供了对内存和计算资源的直接控制能力。一个设计良好的C Actor系统可以避免高级语言运行时如C#的GC、脚本语言的解释开销带来的不确定性让成千上万个游戏对象在同一帧内高效地更新、交互。这不仅仅是“造轮子”而是深入理解游戏引擎底层运作原理的绝佳实践。通过这个过程你将彻底明白一个游戏对象从“数据”到“行为”的完整生命周期是如何被管理的。2. 核心架构设计Actor与组件的共生关系一个健壮的Actor系统其核心在于清晰的责任划分。我们借鉴成熟的ECS实体-组件-系统思想和面向对象的设计模式但进行简化使其更贴近传统游戏对象的管理方式。我们的系统将围绕两个核心类展开Actor演员和Component组件。2.1 Actor类游戏世界的身份证与容器Actor代表游戏世界中的一个独立实体。它本身不直接定义具体行为比如移动、渲染而是作为一个容器和协调者存在。它的核心职责包括生命周期管理负责自身的创建、更新每帧逻辑和销毁。组件管理以列表形式持有多个Component实例负责组件的添加、查找和移除。空间变换维护实体在世界中的位置position、旋转rotation和缩放scale信息这是几乎所有组件行为的基础。状态与标签可以拥有激活active状态、标签tag或名称便于游戏逻辑进行筛选和批量处理。一个基础的Actor类头文件可能长这样// Actor.h #pragma once #include string #include vector #include memory #include glm/glm.hpp // 使用glm数学库处理向量和矩阵 class Component; // 前向声明 class Actor { public: // 生命周期 Actor(const std::string name Actor); virtual ~Actor(); // 每帧更新由游戏主循环调用 virtual void Update(float deltaTime); virtual void Render(); // 如果需要立即模式渲染 // 组件管理 template typename T, typename... Args T* AddComponent(Args... args); template typename T T* GetComponent(); template typename T std::vectorT* GetComponents(); // 空间变换 void SetPosition(const glm::vec3 pos) { m_Position pos; } glm::vec3 GetPosition() const { return m_Position; } // ... 类似地实现Rotation和Scale // 状态 void SetActive(bool active) { m_IsActive active; } bool IsActive() const { return m_IsActive; } private: std::string m_Name; bool m_IsActive true; glm::vec3 m_Position {0.0f}; glm::vec3 m_Rotation {0.0f}; glm::vec3 m_Scale {1.0f}; std::vectorstd::unique_ptrComponent m_Components; // 注意使用unique_ptr表示Actor拥有组件的所有权生命周期绑定。 };注意这里使用了glm数学库它是一个在图形编程中广泛使用的头文件库处理向量、矩阵运算非常方便。你需要通过vcpkg或直接下载头文件集成到项目中。如果追求极简也可以自己实现一个简单的Vec3类。2.2 Component类可插拔的行为模块Component是具体行为的载体。它的设计精髓在于“单一职责”和“可插拔性”。一个组件只做好一件事比如MoveComponent负责移动SpriteRenderComponent负责渲染一个2D精灵。组件通过附着在Actor上来获得上下文如位置信息并发挥作用。// Component.h #pragma once class Actor; class Component { public: Component(Actor* owner); virtual ~Component() default; // 虚析构函数确保派生类正确释放 // 生命周期函数由所属Actor调用 virtual void Update(float deltaTime) {} virtual void Render() {} Actor* GetOwner() const { return m_Owner; } protected: Actor* m_Owner; // 指向所属Actor的指针非拥有关系。 };关键设计决策为什么Component持有的是Actor*原始指针而不是shared_ptr因为组件的生命周期严格由其所属的Actor管理unique_ptr。组件不需要也不能决定Actor的生死它只是Actor功能的一部分。使用原始指针可以明确表达这种“非拥有”的依赖关系避免循环引用。只要确保在Actor的析构函数中先销毁所有组件这个设计就是安全的。3. 实现细节与核心代码解析有了骨架我们现在来填充血肉实现最关键的部分组件管理的模板函数和Actor的更新流程。3.1 组件管理的模板魔法在Actor.cpp中实现组件管理函数这是整个系统的粘合剂。// Actor.cpp #include Actor.h #include Component.h Actor::Actor(const std::string name) : m_Name(name) {} Actor::~Actor() { // 关键组件必须按添加的逆序销毁吗通常不需要但确保所有组件都被销毁。 m_Components.clear(); // unique_ptr会自动删除其管理的对象。 } void Actor::Update(float deltaTime) { if (!m_IsActive) return; // 先更新Actor自身的逻辑如果有的话 // OnUpdate(deltaTime); // 可以定义一个虚函数供派生类覆盖 // 然后更新所有组件 for (auto comp : m_Components) { if (comp) { comp-Update(deltaTime); } } } void Actor::Render() { if (!m_IsActive) return; for (auto comp : m_Components) { comp-Render(); } } // 核心添加组件 template typename T, typename... Args T* Actor::AddComponent(Args... args) { // 静态断言确保T是Component的派生类 static_assert(std::is_base_ofComponent, T::value, T must be derived from Component); auto newComp std::make_uniqueT(this, std::forwardArgs(args)...); T* rawPtr newComp.get(); m_Components.push_back(std::move(newComp)); // 可以在这里调用组件的初始化函数如OnStart() // rawPtr-OnStart(); return rawPtr; // 返回原始指针供外部使用 } // 核心获取第一个匹配类型的组件 template typename T T* Actor::GetComponent() { for (auto comp : m_Components) { T* derived dynamic_castT*(comp.get()); if (derived) { return derived; } } return nullptr; } // 核心获取所有匹配类型的组件 template typename T std::vectorT* Actor::GetComponents() { std::vectorT* result; for (auto comp : m_Components) { T* derived dynamic_castT*(comp.get()); if (derived) { result.push_back(derived); } } return result; } // 必须在.cpp文件中显式实例化模板否则链接器会找不到定义。 // 这是一个权衡要么把实现全放在头文件要么在这里为所有可能用到的组件类型实例化。 // 这里采用后者更清晰但需要手动维护。 // 例如 #include “MoveComponent.h” // 假设我们有这些组件 #include “SpriteRenderComponent.h” template MoveComponent* Actor::AddComponentMoveComponent(); template MoveComponent* Actor::GetComponentMoveComponent(); template std::vectorMoveComponent* Actor::GetComponentsMoveComponent(); // ... 为其他组件类型添加实例化实操心得关于模板函数定义的位置。一种常见做法是将这些模板函数的实现直接写在Actor.h中内联这样可以避免复杂的显式实例化。但代价是Actor.h会包含所有可能的组件头文件或者要求使用者在使用前包含所需组件头文件增加了编译依赖。我将实现放在.cpp并显式实例化虽然麻烦一点但使得Actor.h非常干净编译防火墙效果更好。对于中小型项目内联实现更简单对于大型项目显式实例化更利于编译速度和管理。3.2 编写具体组件以MoveComponent为例让我们实现一个具体的组件看看它如何与Actor协作。// MoveComponent.h #pragma once #include “Component.h” #include glm/glm.hpp class MoveComponent : public Component { public: MoveComponent(Actor* owner, float speed 100.0f); void Update(float deltaTime) override; void SetVelocity(const glm::vec3 vel) { m_Velocity vel; } glm::vec3 GetVelocity() const { return m_Velocity; } void SetSpeed(float speed) { m_Speed speed; } float GetSpeed() const { return m_Speed; } private: glm::vec3 m_Velocity {0.0f, 0.0f, 0.0f}; float m_Speed; };// MoveComponent.cpp #include “MoveComponent.h” #include “Actor.h” // 需要获取Owner的位置 MoveComponent::MoveComponent(Actor* owner, float speed) : Component(owner), m_Speed(speed) {} void MoveComponent::Update(float deltaTime) { if (!GetOwner() || !GetOwner()-IsActive()) return; // 计算位移 glm::vec3 movement m_Velocity * m_Speed * deltaTime; // 应用到位移到Actor的位置上 glm::vec3 newPos GetOwner()-GetPosition() movement; GetOwner()-SetPosition(newPos); // 可以在这里添加边界检查、碰撞检测回调等 }这个MoveComponent完美诠释了组件的单一职责它只关心如何根据速度和速度方向来移动其所属的Actor。它不需要知道这个Actor是玩家、敌人还是子弹它只做移动计算。Actor的位置是共享状态组件通过GetOwner()来读写。4. 游戏循环与Actor管理单个Actor和组件无法构成世界。我们需要一个World或Scene类来管理所有Actor并在游戏主循环中驱动它们。// Scene.h #pragma once #include vector #include memory class Actor; class Scene { public: Scene(); ~Scene(); Actor* SpawnActor(const std::string name “Actor”); void DestroyActor(Actor* actor); // 标记销毁非立即删除 void Update(float deltaTime); void Render(); private: std::vectorstd::unique_ptrActor m_Actors; std::vectorActor* m_ActorsToDestroy; // 待销毁队列 };// Scene.cpp #include “Scene.h” #include “Actor.h” Scene::Scene() default; Scene::~Scene() { m_Actors.clear(); } Actor* Scene::SpawnActor(const std::string name) { auto newActor std::make_uniqueActor(name); Actor* rawPtr newActor.get(); m_Actors.push_back(std::move(newActor)); return rawPtr; } void Scene::DestroyActor(Actor* actor) { if (actor) { m_ActorsToDestroy.push_back(actor); } } void Scene::Update(float deltaTime) { // 1. 更新所有活跃的Actor for (auto actor : m_Actors) { if (actor actor-IsActive()) { actor-Update(deltaTime); } } // 2. 处理待销毁的Actor延迟销毁避免在迭代中修改容器 if (!m_ActorsToDestroy.empty()) { auto it m_Actors.begin(); while (it ! m_Actors.end()) { // 查找当前actor是否在待销毁列表中 auto destroyIt std::find(m_ActorsToDestroy.begin(), m_ActorsToDestroy.end(), it-get()); if (destroyIt ! m_ActorsToDestroy.end()) { it m_Actors.erase(it); // unique_ptr自动释放内存 m_ActorsToDestroy.erase(destroyIt); if (m_ActorsToDestroy.empty()) break; } else { it; } } m_ActorsToDestroy.clear(); } } void Scene::Render() { for (auto actor : m_Actors) { if (actor actor-IsActive()) { actor-Render(); } } }关键点解析为什么需要m_ActorsToDestroy这个待销毁队列这是游戏开发中一个经典的“延迟销毁”模式。在Update循环中我们正在遍历m_Actors向量。如果某个Actor在更新过程中或其某个组件中直接调用DestroyActor(this)并立即从m_Actors中删除会导致迭代器失效引发未定义行为崩溃。因此我们只做标记在每帧更新的最后安全地清理这些被标记的Actor。5. 实战演练构建一个会移动和旋转的方块现在让我们把所有部分组合起来在一个简单的控制台或图形窗口例如使用SFML、SDL或OpenGL中创建一个演示。// main.cpp #include “Scene.h” #include “MoveComponent.h” // 假设我们有一个简单的RenderComponent用于在控制台打印位置 #include “ConsoleRenderComponent.h” int main() { Scene mainScene; // 创建主角Actor Actor* hero mainScene.SpawnActor(“Hero”); // 添加移动组件设置速度 auto* moveComp hero-AddComponentMoveComponent(50.0f); moveComp-SetVelocity(glm::vec3(1.0f, 0.0f, 0.0f)); // 向右移动 // 添加一个渲染组件用于在控制台输出位置 hero-AddComponentConsoleRenderComponent(); // 创建另一个Actor Actor* enemy mainScene.SpawnActor(“Enemy”); auto* enemyMove enemy-AddComponentMoveComponent(30.0f); enemyMove-SetVelocity(glm::vec3(0.0f, 1.0f, 0.0f)); // 向下移动 enemy-AddComponentConsoleRenderComponent(); // 简单的游戏循环 float deltaTime 0.016f; // 模拟60FPS for (int frame 0; frame 100; frame) { std::cout “\n--- Frame “ frame “ ---“ std::endl; mainScene.Update(deltaTime); mainScene.Render(); // ConsoleRenderComponent会打印位置 // 模拟一些游戏逻辑50帧后让敌人改变方向 if (frame 50) { enemyMove-SetVelocity(glm::vec3(-1.0f, 0.0f, 0.0f)); std::cout “[Logic] Enemy changed direction!” std::endl; } // 80帧后销毁英雄演示延迟销毁 if (frame 80) { std::cout “[Logic] Hero destroyed!” std::endl; mainScene.DestroyActor(hero); hero nullptr; // 避免野指针 } } return 0; }这个简单的循环展示了Actor系统的核心Scene管理Actor的生命周期Actor通过组合不同的Component来定义行为。你可以看到改变enemy的速度方向只需要操作其MoveComponent而销毁hero则通过Scene接口系统会自动处理其所有组件的清理。6. 性能优化与高级特性探讨一个基础的Actor系统已经成型但要用于真实项目我们必须考虑性能和扩展性。6.1 组件缓存与快速查找频繁使用GetComponentT()并通过dynamic_cast遍历查找在组件数量多时效率较低。一个优化方案是为每个组件类型分配一个唯一的类型ID并在Actor内部使用std::unordered_mapComponentTypeId, Component*进行缓存。添加组件时注册查找时直接O(1)查询。这增加了复杂度但提升了高频查找场景的性能。6.2 更新顺序与依赖某些组件更新有顺序要求。例如InputComponent应该在MoveComponent之前更新以便MoveComponent能使用最新的输入数据。我们可以在Component基类中引入一个UpdateOrder更新顺序整数属性Actor在更新时根据此值对组件列表进行稳定排序。更复杂的依赖关系可以考虑使用图来管理。6.3 序列化与场景持久化如何将游戏场景保存到文件下次运行时加载这就需要序列化。我们可以为Actor和每个Component类实现序列化接口如ToJson()和FromJson()。Scene负责遍历所有Actor和Component将它们的状态位置、速度、属性值保存为JSON、二进制或其他格式。加载时根据类型名动态创建组件实例并还原状态。这通常需要配合一个反射或注册系统。6.4 消息/事件系统组件之间如何通信比如一个CollisionComponent检测到碰撞后如何通知同一个Actor上的HealthComponent扣血硬编码耦合是糟糕的设计。引入一个轻量级的消息系统是优雅的解决方案。Actor可以提供一个SendMessage(const Message msg)函数所有组件都可以重写一个ReceiveMessage(const Message msg)虚函数。或者使用更松散的观察者模式让组件订阅特定的事件。避坑指南在实现消息系统时要特别注意性能。避免每帧发送大量消息。对于像“位置更新”这类高频事件更适合通过直接访问Actor的公共数据如位置来实现而不是通过消息。消息系统应主要用于低频、重要的逻辑事件如“受到伤害”、“拾取物品”、“死亡”。7. 与现有引擎架构的对比与思考我们实现的这个简易Actor模型其思想与主流商业引擎是相通的。与Unity的GameObject/Component对比Unity的组件模型更完善有强大的编辑器集成、序列化和完整的生命周期Awake, Start, OnEnable, Update, OnDisable, OnDestroy。我们的系统是一个核心原理的简化版。与虚幻引擎的AActor/UActorComponent对比虚幻的Actor功能更强大内置了网络复制、详细的生命周期、子Actor等高级功能。其组件也分为场景组件处理变换和逻辑组件。我们的设计更接近其核心思想。与纯ECS架构对比纯ECS如Unity DOTS EnTT库将数据Component、行为System和实体Entity仅为ID彻底分离旨在极致利用CPU缓存和多核并行。我们的Actor-Component模型可以看作是面向对象与ECS之间的一个折中更符合大多数人的思维习惯易于理解和上手在对象数量不是天文数字时性能完全足够。选择哪种架构取决于项目规模、团队习惯和性能目标。从零开始实现这个简易系统最大的价值在于理解。你理解了组件如何被添加、查找和更新理解了对象生命周期如何管理理解了数据与行为分离的好处。未来无论你使用Unity、Unreal还是其他引擎你都能更深刻地理解其底层运作机制从而写出更高效、更优雅的代码。
)
