在游戏开发中,有一个实体系统的概念,旨在通过获得灵活的架构来简化游戏循环.有关详情,请参阅以下链接:
http://www.richardlord.net/blog/what-is-an-entity-framework http://shaun.boyblack.co.za/blog/2012/08/04/games-and-entity-systems/
现在我想知道如果在C++中添加Nodea时可以实现自动创建？请告诉我识别可以从特定产生什么的原则,即你应该有聚合组件的列表和类.您应该了解可以使用数据列表创建哪些类.ComponentEntityNodesEntityComponent
例如,我有Components:
class PositionComponent
{
int m_x;
int m_y;
int m_rotation;
};
class VelocityComponent
{
int m_vX;
int m_vY;
int m_vAngular;
};
class RenderableComponent
{
Sprite m_view;
};
和节点:
class MoveNode
{
PositionComponent m_position;
VelocityComponent m_velocity;
};
class RenderNode
{
RenderableComponent m_rend;
PositionComponent m_position;
};
现在,如果我创建Entity这样的:
Entity * e = new Entity;
e.add(new PositionComponent);
e.add(new VelocityComponent);
然后我想要一个MoveNode自动创建的代码,如果我还添加这个:
e.add(new RenderableComponent);
然后我想知道它也RenderNode被创造了.因此,当我删除它时:
e.remove(new RenderableComponent);
对RenderNode应予以删除.而这一过程,当然,不应该被绑定到特定的Nodes和Components我已经定义.
如何在C++中实现这一点？
rio*_*oki 16
我有点困惑,因为它似乎混合了概念.我将尝试阐述这两个概念.
实体组件系统在游戏引擎中非常常见,例如Unity非常明显地实现它.它试图解决简单继承在许多情况下不能很好地工作的问题,例如混合渲染和碰撞信息; 是Collidable也Renderable？由于多重继承对许多人来说是一件可怕的事情而且在许多语言中都不受支持,因此唯一的出路是实体/组件设计.(实际上不是唯一的解决方案,但这是一个不同的问题.)
实体组件的设计非常简单,您有一个类Entity,它接受多个类型的对象Component.将有多个组件"做"的东西,就像一个MeshRenderer,TriMeshCollision或RigidBodyMotion.如文章所述,实际逻辑不需要在组件本身中实现.该组件只是"标记"特定逻辑的实体.将实际工作委托给系统中的紧密循环是有意义的,甚至可能在不同的线程中,但稍后会更多.
然后组成实际实体.在代码或数据中有两种基本方法可以做到这一点.
例如,您在代表一个"真实世界"对象的代码中组合对象; 类型的对象Goblin存在,它是从类派生的Entity.然后,构造函数Goblin将创建所有组件并将其注册到自身.现在,继承仅针对高级逻辑进行,例如,FastGoblin派生自Goblin且仅具有不同的材料和速度设置.
创建对象的第二种方法是通过数据,即你有某种形式的对象描述语言.(使用XML或JSON中的内容)然后,这将在工厂方法中创建基于给定模板的内容,该模板在此对象描述语言中定义.
拥有完全定义的对象,但逻辑没有被执行可能是有意义的.考虑服务器或编辑器中的对象.在服务器上,您不希望渲染代码妨碍.因此,基本方法是创建不包含数据的组件.要解决的问题是,如何在不迭代整个场景的情况下高效完成任务并对周围的对象进行类型转换？
您的第二个链接描述的基本上是设计并行游戏引擎框架的拙劣版本
需要有一种方法来有效地安排工作.建议的解决方案是具有每个执行特定任务的"节点".然后通过将节点提交给工作调度程序或特定系统来调度节点.
以渲染为例.你有一个实体,它有一个MeshRenderer组件.该组件将创建一个RenderNode并将其提交给RenderSystem.然后,当需要渲染帧时,RenderSystem将简单地遍历每个RenderNode并调用其显示方法.在显示方法中,完成实际渲染.
或者,系统,引擎或实体可以基于特定组件配置来创建节点.以物理学为例.实体具有TriMeshCollision和RigidBodyMovement组件.在PhysicsSystem看到该结构中创建RigidBodyNode,是以两种成分作为输入,并且由此实现刚体运动.如果实体只有一个TriMeshCollision组件,PhysicsSystem那么它将创建一个StaticColliderNode实现该行为的组件.
但是,与数据组件的构造机制一样,也可以通过工厂函数创建节点并将其附加到实体.这可以是对象定义或基于规则的系统的一部分.
将此设计映射到C++应该是直截了当的.相当困难的一点是找出不同位如何连接的方式; 例如,如何MeshRenderer访问,RenderSystem以便它可以提交它RenderNode.但是,这可以用一个单来解决(颤动)或通过传递Game/ Engine对象周围在的建筑Entity或Component.
但我想在这里讨论的问题是:这个好设计吗？
我的第二个链接(游戏和实体系统)遇到了麻烦,因为我认为设计会很快落到它的鼻子上.这对于物理学等其他方面也是如此,但在考虑现代3D渲染时,这将变得非常低效.
当您需要在空间上组织场景以有效地剔除隐藏对象时,将对象组织成批次以进行照明并减少资源切换,然后整个"节点列表"概念都没有实际意义,因为您无论如何都需要单独的组织结构.
此时,您可以让组件直接与系统"对话",每个系统都有自己独特的特定API,适合其特定用途.渲染,声音和输入的要求各自显着不同,并且将它们塞进API上是徒劳的.