Questions tagged «component-based»

在我当前的项目中，我实现了一个基于组件/实体的系统，基本上遵循了大多数最佳实践，但是这个未定义的领域却存在。 因此，我得到了（略微扩展的）实体，它们基本上是一个intID，一个人类可读的名称，一个std::map组件和一个long“类型指示符”，用于显示存在哪些组件（我enum对所有组件有2的幂类型，并且每当将一个组件添加到Entity时，我都会通过按位操作自动更改该长度，比较此答案）。 然后是Components，也很简单：intID，enum作为组件类型，父Entity指针以及std::map该组件拥有的所有属性。 最后，一些处理实际逻辑处理的系统/管理器。他们首先检查当前处理的实体是否具有匹配的long“类型指示器” =该系统的所有必需组件都已存在。然后，如果需要，它将访问一些属性，并直接调用相应组件中的某些函数或发送一些消息（通过消息分发程序）。 底线：到目前为止，一个相当标准的事件驱动的基于组件/实体的系统与数据驱动的方法相结合（比较，组件没有硬编码的数据变量，而是作为（某些）组件的通用映射组件的/ archetypes将在以后从文件中读取，并且可以选择添加其他数据，这不是实际组件代码的一部分。 现在，我还要在该项目中引入“ 行为树”（基于AiGameDev BTSK），但是我不确定是否以及如何将它们链接到现有组件，或者通常如何集成这些设计。 我想到了几个相关的想法/观点/问题： 我的BT将再次从文件中读取。目前，我很难理解如何最好地BT Action在该树中的a和应用程序中的实际编码之间建立联系。是否应该在BT文件中使用的动作名称和指向实际逻辑实现的函数指针之间建立某种映射？解决该问题的通常方法是什么？ 我假设我必须为所有不同Entity类型创建BT （因此，对于我多次提到的长“类型指示器”所指示的每种与游戏逻辑/人工智能相关的组件组合）。结果，将BT Action实现放入组件中没有意义，因为每个动作很可能会涉及许多组件，不是吗？ 那么BT Action逻辑是否应该位于一个/多个单独的系统中（想法1的映射所指向的系统指向的方法）？然后，系统将根据我的long“类型指示器” Entity检查当前是否已检查BT并被告知执行特定操作（=系统中的方法）的BT（实际上具有必需的组件）。但是，如果不是这样（例如，因为BT创建者确实忽略了特定情况，即在运行时可能不再将必要的组件附加到Entity），则什么都不会发生。 问题： 是否有经过验证的集成概念？ 您对我上面的三点有何看法？ 在我的基于组件/实体的设计方面，还有其他需要考虑的事情吗？

9 ai  component-based  entity-system  behavior 

我对实体系统这个概念还很陌生，已经阅读了很多东西（最有用的是这个很棒的博客和这个答案）。 尽管我在理解如何通过不确定数量的源操纵对象的位置这样简单的事情上遇到了一些麻烦。 也就是说，我有我的实体，该实体具有职位组成部分。然后，我在游戏中发生了一些事件，告诉该实体在给定时间内移动给定距离。 这些事件可以随时发生，并且具有不同的位置和时间值。结果是将它们混合在一起。 在传统的OO解决方案中，我会有某种MoveBy类，其中包含距离/时间，以及在我的游戏对象类内部的数组。每帧，我都要遍历所有MoveBy，然后将其应用于该位置。如果a MoveBy已达到结束时间，请从阵列中将其删除。 对于实体系统，我对如何复制这种行为感到有些困惑。 如果一次只有一个，而不是能够将它们复合在一起，那将是相当简单的（我相信），并且看起来像这样： PositionComponent 包含 x, y MoveByComponent 包含 x, y, time Entity同时具有a PositionComponent和aMoveByComponent MoveBySystem查找具有这两个组成部分的实体，并将的值添加MoveByComponent到中PositionComponent。当time到达，它会从该实体的组件。 我对于在很多情况下如何做同样的事情有些困惑。 我最初的想法是我会： PositionComponent，MoveByComponent与上述相同 MoveByCollectionComponent其中包含MoveByComponents 的数组 MoveByCollectionSystem查找具有PositionComponent和的实体，并在MoveByCollectionComponent其中的MoveByComponents中进行迭代，并根据需要应用/删除。 我猜这是一个更普遍的问题，具有许多相同的组件，并且希望有一个相应的系统对每个组件起作用。我的实体将其组件包含在组件类型->组件的哈希中，因此每个实体严格只有一种特定类型的组件。 这是看待这个问题的正确方法吗？ 实体是否应该始终始终只有一种给定类型的组件？

9 architecture  component-based  entity-system 

我在确定如何处理实体中的状态管理时遇到了一些麻烦。 我对游戏状态管理没有任何麻烦，例如暂停和菜单，因为它们没有作为实体组件系统处理；只是带有实体/组件中的状态。 以“兽人必须死”为例，我有MainCharacter和Trap实体，它们只有诸如PositionComponent，RenderComponent和PhysicsComponent之类的组件。 在每次更新时，实体都会调用其组件的更新。我也有一个通用的EventManager，带有用于不同事件类型的侦听器。 现在，我需要能够放置陷阱：首先选择陷阱和陷阱位置，然后放置陷阱。 放置陷阱时，它应该出现在MainCharacter的前面，以不同的方式呈现并跟随它。放置后，它应仅响应碰撞并以常规方式进行渲染。 通常在基于组件的系统中如何处理？ （此示例是特定的，但可以帮助您确定处理实体状态的一般方法。）

9 component-based  state 

我不确定对象在基于组件的设计中如何精确地处理其他对象。 说我有Obj课。我做： Obj obj; obj.add(new Position()); obj.add(new Physics()); 那么，我又如何才能使另一个对象不仅使球移动，而且还要应用那些物理方法。我不是在寻找实现细节，而是抽象地讲对象如何通信。在基于实体的设计中，您可能只有： obj1.emitForceOn(obj2,5.0,0.0,0.0); 为了更好地掌握组件驱动的设计以及如何进行基本操作的任何文章或说明都将非常有帮助。

9 c++  architecture  component-based 

注意：我正在用Javascript编程，但是在大多数情况下，它应该与语言无关。 我正在考虑将引擎转换为基于ECS的引擎。 我有基本的想法（注意：这是错误的，请参见我的回答）： 实体是游戏对象。 组件是可以“粘合”到实体的功能（reactToInput()）或状态（position）的一部分。 系统具有它们管理和更新的实体的列表。 但是，我不确定我是否可以获得实现和一些细节... 问题：系统可以在不同种类的实体上运行吗？我通常以Scene在引擎中称为类的示例为例，它现在也将用于此目的。场景是所有可以渲染，更新，影响渲染（灯光）的对象的容器，甚至将来甚至可能是2DSoundEmitter对象。它具有一个高级界面，因此用户无需担心他正在播放的对象的类型scene.add()以及所有类似的东西。 我意识到这Scene可能是一个系统。它接受实体，进行存储，然后可以调用其更新方法，甚至可以进行一些状态更改。但是，有一个问题：如上所述，Scene可以为不同类型的对象喂食！例如，在场景中既包含可渲染对象（“可绘制对象”）又包含灯光的情况下，我该怎么办？互动之前，我应该让它进行类型检查吗？或者，我应该在更低的层次上解决它：制作一个LightSource可以添加到任何对象的组件，并且灯光将仅仅是具有LightSource和Position组件的实体。可以接受吗？ 另外，仍然使用常规继承和传统类是否是一个好习惯？例如，我只是不知道我Renderer会是什么！它不是一个系统，因为它的唯一功能是获取摄像机和场景，渲染所有内容并应用效果（例如阴影）。它还管理游戏的上下文，宽度和高度，进行翻译……但是它仍然不是系统！ 编辑：您是否可以链接在ECS上找到的任何资源？我很难找到好的。

9 software-engineering  javascript  component-based  entity-system 

我最近决定修改游戏架构，以摆脱深层的类层次结构，并用可配置的组件替换它们。我要替换的第一个层次结构是Item层次结构，我想了解一些有关我是否处在正确轨道上的建议。 以前，我的层次结构如下所示： Item -> Equipment -> Weapon -> Armor -> Accessory -> SyntehsisItem -> BattleUseItem -> HealingItem -> ThrowingItem -> ThrowsAsAttackItem 不用说它开始变得凌乱，而对于需要多种类型的物品来说，这并不是简单的解决方案（例如，某些设备用于物品合成，某些设备可抛弃，等等）。 然后，我尝试将功能重构并将其放置到基础项目类中。但是后来我注意到该物料具有大量未使用/多余的数据。现在，我尝试为我的其他游戏类创建至少一个类似于建筑的组件，至少要为我的物品做一个。 这是我目前正在考虑的组件设置： 我有一个基础项目类，该类具有用于各种组件的插槽（例如，设备组件插槽，修复组件插槽等，以及任意组件的映射），因此如下所示： class Item { //Basic item properties (name, ID, etc.) excluded EquipmentComponent* equipmentComponent; HealingComponent* healingComponent; SynthesisComponent* synthesisComponent; ThrowComponent* throwComponent; boost::unordered_map<std::string, std::pair<bool, ItemComponent*> > AdditionalComponents; } 所有项目组件都将从基本ItemComponent类继承，并且每种Component类型都负责告诉引擎如何实现该功能。也就是说，HealingComponent告诉战斗机械师如何将物品当作治疗物品使用，而ThrowComponent告诉战斗引擎如何将物品视为可扔物品。 …

9 c++  architecture  component-based