Questions tagged «component-based»

我阅读了很多有关实体组件和系统的文章，并认为将实体当作ID的想法非常有趣。 但是我不知道这在组件方面或系统方面是如何完全起作用的。组件只是由某些相关系统管理的数据对象。碰撞系统使用某些BoundsComponent以及空间数据结构来确定是否发生了碰撞。 到目前为止一切都很好，但是如果多个系统需要访问同一组件怎么办？数据应该存放在哪里？输入系统可以修改实体BoundsComponent，但是物理系统需要访问与某些渲染系统相同的组件。 另外，实体是如何构造的？我读到的很多优点之一是实体构造的灵活性。系统本质上与组件相关联吗？如果要引入一些新组件，是否还必须引入新系统或修改现有系统？ 我经常读到的另一件事是，实体的“类型”由其具有的组件来推断。如果我的实体只是一个id，我怎么知道我的机器人实体需要被某个系统移动或渲染并进行修改？ 很抱歉发布了很长的帖子（或者至少从我的手机屏幕看来如此）！

177 architecture  component-based  entity-system 

昨天，我阅读了GDC Canada上有关属性/行为实体系统的演示，我认为它很棒。但是，我不确定如何实践地使用它，而不仅仅是理论上的。首先，我将快速向您解释该系统的工作方式。 每个游戏实体（游戏对象）都由属性（=数据，可以通过行为，也可以通过“外部代码”访问）和行为（=逻辑，包含OnUpdate()和OnMessage()）组成。因此，例如，在Breakout克隆中，每个积木将由（例如！）组成：PositionAttribute，ColorAttribute，HealthAttribute，RenderableBehaviour，HitBehaviour。最后一个看起来像这样（这只是一个用C＃编写的无效示例）： void OnMessage(Message m) { if (m is CollisionMessage) // CollisionMessage is inherited from Message { Entity otherEntity = m.CollidedWith; // Entity CollisionMessage.CollidedWith if (otherEntity.Type = EntityType.Ball) // Collided with ball { int brickHealth = GetAttribute<int>(Attribute.Health); // owner's attribute brickHealth -= otherEntity.GetAttribute<int>(Attribute.DamageImpact); SetAttribute<int>(Attribute.Health, brickHealth); // owner's attribute // …

59 c#  component-based  entity-system 

在研究了几种游戏设计模式之后，我为我的游戏引擎选择了Entity-Component-System（ES System）。我正在阅读文章（主要是T = Machine）并查看一些源代码，我认为我已经足够入门。 我正在努力的只有一个基本想法。如何处理相互依赖的实体组？ 让我举一个例子： 假设我正在制作一个标准的空中射击游戏（例如Jamestown），并且我想构造一个具有多个不同但相互连接的部分的“老板实体”。分解可能看起来像这样： 船体：运动，渲染 大炮：位置（相对于舰体锁定），向英雄追踪\开火，受到伤害直到被禁用 核心：位置（相对于舰体锁定），向英雄追踪\射击，对伤害造成伤害直到被禁用，对舰组中的所有其他实体禁用（毁灭） 我的目标是将某些东西识别（并操纵）为独特的游戏元素，而不必每次我要构建新的聚合元素时都必须重写子系统。 如何在ES系统中实施这种设计？ 我是否实现某种父子实体关系（实体可以有孩子）？这似乎与实体只是空容器的方法相矛盾，并使其感觉更面向对象。 我是否将它们实现为具有某些连接组件（BossComponent）和相关系统（BossSubSystem）的单独实体？我不禁认为这将很难实现，因为组件之间的通信方式似乎是一个巨大的陷阱。 我是否将它们实现为一个具有一组组件（ShipComponent，CannonComponents，CoreComponent）的实体？这似乎改变了ES System的意图（这里的组件似乎太像重量级的实体），但是我知道这一点，所以我想我会把它放在那儿。 我是否将它们实现为我提到的其他内容？ 我知道在OOP中可以很容易地实现这一点，但是我选择坚持使用ES而不是OOP是我会坚持的。如果我需要打破纯粹的ES理论来实现此设计，我会（不像我以前没有折衷过纯粹的设计），但是出于性能原因，我宁愿这样做，而不是从糟糕的设计开始。 为了获得额外的荣誉，请考虑相同的设计，但是实际上每个“老板实体”都连接到由主体，主要核心和3个“老板实体”组成的更大的“ BigBoss实体”。这将使我看到至少3个维度的解决方案（祖父母-父母子女）...对我来说应该绰绰有余。

47 entity-system  component-based  entity-component-system 

让我们看看成功的历史。哪些流行的游戏（和游戏引擎）是使用基于组件的游戏对象系统构建的？每个答案应包含： 游戏标题（每个答案一个） 作者/公司 年 开发时间（可选） 链接到验尸（可选） 链接到文档/源代码（可选）

43 component-based  game-industry 

我正在使用C ++构建实体组件系统，希望遵循Artemis的风格（http://piemaster.net/2011/07/entity-component-artemis/），因为组件主要是数据包，包含逻辑的系统。我希望利用这种方法的以数据为中心的优势，并构建一些不错的内容工具。 但是，我遇到的一个难题是如何从数据文件中获取一些标识符字符串或GUID，并使用该标识符或实体来构造实体的组件。显然，我可以拥有一个大型解析函数： Component* ParseComponentType(const std::string &typeName) { if (typeName == "RenderComponent") { return new RenderComponent(); } else if (typeName == "TransformComponent") { return new TransformComponent(); } else { return NULL: } } 但这真的很丑。我打算经常添加和修改组件，并希望构建某种ScriptedComponentComponent，以便您可以在Lua中实现组件和系统以进行原型设计。我希望能够编写一个从某个类继承的BaseComponent类，也许将其扔进几个宏中以使一切正常工作，然后使该类可在运行时实例化。 在C＃和Java中，这将非常简单，因为您获得了不错的反射API来查找类和构造函数。但是，我正在用C ++进行此操作，因为我想提高自己在该语言中的熟练程度。 那么用C ++如何做到这一点呢？我已经阅读了有关启用RTTI的信息，但似乎大多数人对此保持警惕，尤其是在我只需要将其用于对象类型的子集的情况下。如果在那里需要定制的RTTI系统，该从哪里开始学习编写一个系统？

37 c++  component-based  entity-system 

我已经为FPS设计了一个实体系统。它基本上是这样的： 我们有一个“世界”对象，称为GameWorld。它包含一个GameObject数组以及一个ComponentManager数组。 GameObject拥有一个Component数组。它还提供了一个非常简单的事件机制。组件本身可以向实体发送事件，该事件将广播到所有组件。 Component基本上是赋予GameObject某些属性的东西，并且由于GameObject实际上只是它们的容器，因此与游戏对象有关的所有事情都发生在Components中。示例包括ViewComponent，PhysicsComponent和LogicComponent。如果需要它们之间的通信，可以通过使用事件来完成。 ComponentManager只是一个类似于Component的接口，对于每个Component类，通常应该有一个ComponentManager类。这些组件管理器负责创建组件，并使用从XML文件之类读取的属性来初始化它们。 ComponentManager还负责组件的大量更新，例如P​​hysicsComponent，我将在其中使用外部库（该库一次执行世界上的所有操作）。 为了实现可配置性，我将为实体使用一个工厂，该实体将读取XML文件或脚本，创建文件中指定的组件（这还将在正确的组件管理器中添加对它的引用以进行批量更新），以及然后将它们注入GameObject对象。 现在出现了我的问题：我将尝试将其用于多人游戏。我不知道该如何处理。 首先：客户从一开始就应该拥有哪些实体？我首先要说明单人引擎如何确定要创建的实体。 在关卡编辑器中，您可以创建“画笔”和“实体”。刷子用于墙壁，地板和天花板等事物，基本上是简单的形状。实体是我告诉过您的GameObject。在关卡编辑器中创建实体时，可以为其每个组件指定属性。这些属性直接传递给实体脚本中的类似构造函数的对象。 保存要加载的引擎的级别时，它会分解为实体及其关联属性的列表。画笔将转换为“ worldspawn”实体。 当您加载该级别时，它只是实例化所有实体。听起来很简单，是吗？ 现在，对于实体的联网，我遇到了许多问题。首先，从一开始就应该在客户端上存在哪些实体？假设服务器和客户端都具有关卡文件，则客户端可能会实例化该关卡中的所有实体，即使它们只是出于服务器上的游戏规则而存在。 另一种可能性是，客户端在服务器发送有关实体的信息后立即实例化该实体，这意味着客户端将仅具有其所需的实体。 另一个问题是如何发送信息。我认为服务器可以使用增量压缩，这意味着它仅在发生变化时才发送新信息，而不是在每帧都向客户端发送快照。尽管这意味着服务器必须跟踪每个客户端当前所知道的信息。 最后，应该如何将网络注入引擎？我在考虑一个组件NetworkComponent，它被注入到每个应该联网的实体中。但应该如何在网络组件知道什么变量网络，以及如何访问这些，最后如何在客户端上相应的网络组件应该知道如何改变网络变量？ 我在处理此问题时遇到了很大的麻烦。如果您能帮助我，我将不胜感激。我也欢迎有关如何改进组件系统设计的提示，因此不要害怕提出建议。

33 networking  component-based 

询问实体系统（两个问题后1，2），并阅读一些文章在他们身上，我想我理解他们比以前好多了。我仍然有一些不确定性，主要是关于构建粒子发射器，输入系统和相机。我显然在理解实体系统方面仍然存在一些问题，它们可能适用于其他所有对象，但是我选择这三个对象是因为它们是非常不同的概念，应该涵盖相当广泛的领域，并有助于我理解实体系统以及如何理解实体系统。我自己会在遇到这些问题时处理这些问题。 我正在用JavaScript构建引擎，并且已经实现了大多数核心功能，其中包括：输入处理，灵活的动画系统，粒子发射器，数学类和函数，场景处理，相机和渲染以及一大堆引擎通常支持的其他功能。我阅读了Byte56的回答，这使我对将引擎制作为实体系统感兴趣。它仍将是具有基本场景概念的HTML5游戏引擎，但它应支持从组件动态创建实体。 我现在遇到的问题是将我的旧引擎概念适合这种新的编程范例。这些是以前的问题中的一些定义，这些定义已更新： 一个实体是一个标识符。它没有任何数据，它不是对象，它是一个简单的ID，代表所有实体的场景列表中的索引（我实际上计划将其实现为组件矩阵）。 甲组件是一个数据保持器，但是具有可以对数据进行操作的方法。最好的示例是Vector2D或“位置”组件。它具有data：x和y，还有一些使对数据进行操作更容易的方法：add()，normalize()等。 一个系统的东西，可以对一组满足某些要求的实体的操作; 通常，实体需要具有一组特定的组件才能进行操作。系统是“逻辑”部分，是“算法”部分，组件提供的所有功能纯粹是为了简化数据管理。 相机 相机具有Vector2Dposition属性，rotation属性以及一些将其围绕点定中心的方法。每帧都将其与场景一起馈入渲染器，并且所有对象均根据其位置进行平移。然后渲染场景。 我如何在实体系统中表示这种对象？摄像机是实体，组件还是组合（按照我的回答）？ 粒子发射器 我的粒子发射器遇到的问题还是，应该是什么。我非常确定粒子本身不应该是实体，因为我想支持超过10,000个粒子，而且我相信创建这么多实体将对我的性能造成沉重打击。 我如何在实体系统中表示这种对象？ 输入管理员 我要谈的最后一个是如何处理输入。在我当前的引擎版本中，有一个名为的类Input。它是一个处理程序，订阅浏览器的事件，例如按键和鼠标位置更改，并且还维护内部状态。然后，播放器类具有一个react()方法，该方法接受输入对象作为参数。这样做的好处是可以将输入对象序列化为.JSON，然后在网络上共享，从而实现流畅的多人模拟。 这如何转化为实体系统？

31 javascript  entity-system  component-based 

我正在实现一个具有以下内容的实体系统变体： 一个实体类是多一点的ID结合部件一起 一堆没有“组件逻辑” 的组件类，只有数据 一堆系统类（又名“子系统”，“管理器”）。这些完成所有实体逻辑处理。在大多数基本情况下，系统只是遍历它们感兴趣的实体列表并对其进行操作 甲MessageChannel类对象被所有的游戏系统共享。每个系统都可以订阅特定类型的消息以进行收听，还可以使用该频道将消息广播到其他系统 系统消息处理的初始变体是这样的： 依次在每个游戏系统上运行更新 如果系统对某个组件执行了某些操作，而其他系统可能对此操作感兴趣，则该系统会发送一条适当的消息（例如，系统调用 messageChannel.Broadcast(new EntityMovedMessage(entity, oldPosition, newPosition)) 每当实体移动时） 订阅特定消息的每个系统都会得到其消息处理方法，称为 如果系统正在处理事件，并且事件处理逻辑要求广播另一条消息，则立即广播该消息，并调用另一条消息处理方法链 在我开始优化碰撞检测系统之前，这个变体是可以的（随着实体数量的增加，它变慢了）。首先，它只是使用简单的蛮力算法迭代每个实体对。然后，我添加了一个“空间索引”，该索引具有一个单元格网格，该网格存储特定单元格区域内的实体，因此仅允许对相邻单元格中的实体进行检查。 实体每次移动时，碰撞系统都会检查该实体是否与新位置的物体发生碰撞。如果是，则检测到冲突。并且，如果两个碰撞的实体都是“物理对象”（它们都具有RigidBody分量，并且打算彼此推开以免占据相同的空间），则专用的刚体分离系统会要求运动系统将实体移动到某个将他们分开的特定职位。这进而导致运动系统发送消息，通知已更改的实体位置。碰撞检测系统旨在做出反应，因为它需要更新其空间索引。 在某些情况下，这会引起问题，因为单元的内容（C＃中的Entity对象的通用列表）在进行迭代时会被修改，从而导致迭代器抛出异常。 那么... 如何防止碰撞系统在检查碰撞时被打断？ 当然，我可以添加一些“聪明” /“棘手”逻辑来确保正确地迭代单元格内容，但是我认为问题不在于碰撞系统本身（在其他系统中也存在类似问题），而是消息在系统之间传播时得到处理。我需要某种方式来确保特定的事件处理方法能够正常工作，而不会造成任何干扰。 我尝试过的 传入消息队列。每当某个系统广播消息时，该消息就会被添加到对该消息感兴趣的系统的消息队列中。当每帧调用系统更新时，将处理这些消息。问题是：如果系统A将消息添加到系统B的队列中，则如果系统B的更新要晚于系统A（在同一游戏框架中），则它工作良好；否则，它将导致该消息处理下一个游戏框架（某些系统不希望使用） 传出邮件队列。当系统处理事件时，它将广播的所有消息添加到传出消息队列中。消息无需等待系统更新被处理：在初始消息处理程序完成工作后，它们将立即得到处理。如果对消息的处理导致其他消息被广播，它们也将添加到传出队列中，因此所有消息都在同一帧中进行处理。问题：如果实体生存期系统（我用一个系统实现了实体生存期管理）创建了一个实体，它将通知某些系统A和B。当系统A处理该消息时，它将导致一系列消息，这些消息最终导致所创建的实体被破坏（例如，在与某个障碍物碰撞的位置处创建了一个项目符号实体，这会导致项目符号自毁）。在解析消息链时，系统B没有获得实体创建消息。因此，如果系统B也对实体破坏消息感兴趣，它将得到它，并且只有在“链”完成解析之后，它才会得到初始实体创建消息。这将导致销毁消息被忽略，创建消息被“接受”， 编辑-回答问题，评论： 碰撞系统迭代时，谁修改了单元格的内容？ 当碰撞系统正在对某个实体及其邻居进行碰撞检查时，可能会检测到碰撞，并且该实体系统将发送一条消息，其他系统立即对此进行响应。对消息的反应可能导致其他消息被创建并立即处理。因此，即使先前的碰撞检查尚未完成，其他一些系统也可能会创建一条消息，表明碰撞系统随后需要立即进行处理（例如，移动了一个实体，因此碰撞系统需要更新其空间索引）。 您不能使用全局传出消息队列吗？ 我最近尝试了一个全局队列。它引起新的问题。问题：我将储罐实体移动到墙实体（储罐由键盘控制）。然后我决定改变坦克的方向。为了将水箱和墙壁的每个框架分开，CollidingRigidBodySeparationSystem将水箱从墙壁上移开的最小可能量。分离方向应与水箱的移动方向相反（游戏图纸开始时，水箱应看起来好像从未移入墙壁）。但是方向变成了与新方向相反的方向，因此将储罐移动到与最初不同的另一侧。发生问题的原因：这是现在处理消息的方式（简化代码）： public void Update(int deltaTime) { m_messageQueue.Enqueue(new TimePassedMessage(deltaTime)); while (m_messageQueue.Count > 0) { Message message = m_messageQueue.Dequeue(); this.Broadcast(message); } } …

30 c#  component-based  entity-system 

我正在考虑如何实现基于组件的游戏，因为这似乎很热门，而且我喜欢这种灵活设计的想法。这种设计的特征之一是可以通过数据完成向游戏中添加新事物的过程，通常是通过XML之类的文本文件加载内容。这样做的好处是易于阅读，并且可以在任何文本编辑器中轻松编辑。不利的一面是，文本处理起来可能较慢，并且您必须管理大量数据文件。类似的基于文本的格式（如JSON或配置文件）将具有类似的好处。 另一方面，还有小型的可移植数据库，例如SQLite或Tokyo Cabinet。这些文件虽然不是直接可读的，但很容易与它们交互，并且我认为无论如何，对于游戏内容设计而言，某种编辑工具还是比较可取的。使用数据库可以一致地存储配置信息并易于检索。您也可以将数据序列化到数据库中以保存游戏。 在性能方面，我认为一般来说，小文件的XML速度更快，但是数据库可以更好地扩展到大量数据。我以为任何一款真正的游戏都会有很多游戏对象。 问题是：哪种方法更可取？我倾向于数据库，但是我想知道文本文件是否存在隐患或真正强大的优势。或者，如果除了这些之外还有其他选择（我猜要序列化为二进制格式吗？）

29 component-based  databases  xml  data  configuration 

我才刚刚真正开始着手基于组件的设计。我不知道这样做的“正确”方法是什么。 这是场景。玩家可以装备盾牌。盾牌被绘制为气泡围绕玩家，它具有单独的碰撞形状，并减少了玩家从区域效果中受到的伤害。 在基于组件的游戏中如何设计这样的盾牌？ 让我感到困惑的是，屏蔽罩显然具有三个与之关联的组件。 减少伤害/过滤 一个精灵 对撞机。 更糟的是，不同的防护罩变体可能具有更多的行为，所有这些行为都可能是以下因素： 提高玩家的最大健康度 健康再生 弹丸变形 等等 我在想这个吗？盾牌应该只是超级组件吗？ 我真的认为这是错误的答案。因此，如果您认为这是要走的路，请解释一下。 盾牌应该是自己的实体来跟踪玩家的位置吗？ 这可能使实施损害过滤变得困难。这也模糊了附加组件和实体之间的界线。 屏蔽是否应该是容纳其他组件的组件？ 我从未见过或听到过这样的消息，但也许很常见，但我还不够深入。 盾牌应该只是添加到播放器中的一组组件吗？ 可能还有一个额外的组件来管理其他组件，例如，这样它们就可以作为一个组全部删除。（偶然地留下减少伤害的部分，这很有趣）。 对于具有更多组件经验的人来说，还有其他明显的东西吗？

29 architecture  component-based  entity-system 

我正在开发具有基于组件的体系结构的游戏。一个Entity拥有一组Component实例，每个实例都有一组Slot用于存储，发送和接收值的实例。工厂功能，例如Player具有所需组件和插槽连接的生产实体。 我正在尝试确定组件的最佳粒度。例如，现在Position，Velocity和Acceleration都是串联的独立组件。Velocity并且Acceleration可以轻松地重写为统一的Delta组件或Position，Velocity并且Acceleration可以与诸如Friction和Gravity组成整体Physics组件。 一个组件应该承担最小的责任（以大量的互连为代价），还是应该将相关组件组合为整体组件（以灵活性为代价）？我倾向于前者，但我可以使用第二种意见。

26 architecture  entity-system  component-based 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 基于组件的游戏编程范例正变得越来越流行。我想知道，有没有提供可重用组件框架的项目？用任何语言，我想我都不在乎。不是为了我自己的项目，我只是很好奇。 具体来说，我的意思是说有一些项目包括一个基Entity类，一个基Component类，也许还有一些标准组件？如果您不想重新发明方向盘，或者想要GraphicsComponent使用Direct3D制作sprite 的游戏，那么开始游戏会容易得多，但是您认为它已经完成了十几次。 快速谷歌搜索出现了鲁舍尔。有人听说过吗/有人使用过吗？如果没有受欢迎的，那为什么不呢？使这种可重用的东西太难了，并且他们需要大量的自定义吗？在我自己的实现中，我发现很多样板都可以推入框架中。

25 component-based 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 3年前关闭。 状态机似乎在基于组件的体系结构中造成有害的依赖关系。 具体来说，如何在状态机和执行与状态相关的行为的组件之间处理通信？ 我在哪里： 我是基于组件的体系结构的新手。 我正在制作格斗游戏，尽管我认为这并不重要。我设想我的状态机将用于切换“蹲下”，“破折号”，“阻塞”等状态。 我发现这种状态管理技术对于基于组件的体系结构来说是最自然的系统，但是它与我读过的技术相冲突： 用于可变行为角色的动态游戏对象组件系统它建议所有组件都激活/停用通过不断检查激活条件来检查自己。 我认为像“跑步”或“步行”之类的动作在状态上是有意义的，这与此处接受的响应不同：https : //gamedev.stackexchange.com/a/7934 我发现这很有用，但是模棱两可：如何在基于组件的游戏架构中实现行为？它建议有一个单独的组件，其中仅包含状态机。但是，这需要在状态机组件和几乎所有其他组件之间进行某种耦合。我不明白该如何处理耦合。这些是一些猜测： A. 组件取决于状态机： 组件接收对状态机组件的引用getState()，该引用返回枚举常量。组件会定期进行自我更新，并根据需要进行检查。 B. 状态机取决于组件： 状态机组件接收对其监视的所有组件的引用。它查询他们的getState()方法以查看它们的位置。 C. 它们之间的某种抽象 使用事件中心吗？命令模式？ D. 使用引用组件状态模式的单独状态对象。创建了单独的状态对象，这些状态对象激活/停用一组组件。状态机在状态对象之间切换。 我正在将组件视为方面的实现。他们在内部完成使该方面实现所需的一切。看起来组件应该独立运行，而不依赖其他组件。我知道一些依赖是必要的，但是状态机似乎要控制我的所有组件。

23 architecture  ai  component-based  fsm 

我对基于组件的实体系统感兴趣已有一段时间了，并阅读了无数文章（Insomiac游戏，相当标准的Evolve Your Hierarchy，T-Machine，Chronoclast ...等）。 它们似乎都在某种东西的外部具有结构： Entity e = Entity.Create(); e.AddComponent(RenderComponent, ...); //do lots of stuff e.GetComponent<PositionComponent>(...).SetPos(4, 5, 6); 而且，如果您引入了共享数据的概念（这是到目前为止我所见过的最好的设计，因为这并不是在所有地方都复制数据） e.GetProperty<string>("Name").Value = "blah"; 是的，这非常有效。但是，它并不是最简单的读写方法。感觉很笨拙，而且对您不利。 我个人想做这样的事情： e.SetPosition(4, 5, 6); e.Name = "Blah"; 当然，获得这种设计的唯一方法是回到Entity-> NPC-> Enemy-> FlyingEnemy-> FlyingEnemyWithAHatOn这种设计试图避免的层次结构。 有没有人看到这种组件系统的设计既灵活又保持了用户友好性？就此而言，设法以一种很好的方式解决（可能是最困难的问题）数据存储？ 用户友好但仍然灵活的基于组件的实体系统有哪些设计？

23 c#  architecture  component-based  entity-system 

我开始在游戏中实现玩家和敌人的AI，但是对于如何在基于组件的游戏架构中最好地实现这一点感到困惑。 假设我有以下玩家角色，可以固定，奔跑和挥舞剑。玩家可以从静止状态和奔跑状态都转变为挥剑状态，但是随后必须完成挥杆，然后才能继续站立或奔跑。在挥杆过程中，玩家无法走动。 如我所见，我有两种实现方法： 创建一个包含所有播放器逻辑的AI组件（与实际组件分离或嵌入为Pla​​yerAIComponent）。我可以轻松地执行状态限制，而无需在组成播放器实体的各个组件之间创建耦合。但是，AI组件无法分解。例如，如果我有一个只能站立，四处走动或只能四处走动并偶尔挥舞剑的敌人，那么我必须创建新的AI组件。 将行为分解为各个组件，每个组件标识一个特定状态。然后，我得到一个StandComponent，WalkComponent和SwingComponent。为了执行过渡规则，我必须耦合每个组件。SwingComponent必须在挥杆期间禁用StandComponent和WalkComponent。当我有一个只会站着的敌人，偶尔会挥舞剑时，我必须确保SwingComponent仅在存在Walkwalk时将其禁用。尽管这允许更好的混合和匹配组件，但是当每次添加依赖项时，它都可能导致可维护性的噩梦，但必须更新现有组件以更好地满足依赖项对角色的新要求。 理想的情况是，设计人员可以通过将组件拖到容器中来构建新的敌人/玩家，而无需触摸任何一行引擎或脚本代码。尽管我不确定是否可以避免脚本编码，但我想使其尽可能简单。 总结一下：我应该将所有AI逻辑分解为一个组件，还是将每个逻辑状态分解为单独的组件，以更轻松地创建实体变量？ 编辑：我怀疑我对第一种和第二种情况的含义有些困惑。我试图在下图中解释它。 注意各个状态与实体之间的关系。在第一种情况下，会在将AI组件放入实体之前对其进行预先构建。设计人员只能从程序员提供的一组独特的AIComponent中进行选择。第二种情况具有与其他组件相同级别的不同状态。设计人员现在可以创建具有唯一AI的实体，而无需程序员的干预。 问题是，这是在基于组件的实体中构建AI的仅有的两个选择吗？如果是的话，什么将提供最大的灵活性？

21 architecture  ai  component-based