实体/组件系统和UI“实体”

我对实体/组件系统仍然很满意。我发现，由于我具有用于绘制精灵（或精灵表）和处理输入（鼠标/触摸点击）的有用组件，因此我自然希望重用这些组件来创建UI组件（例如按钮，例如，级别选择屏幕）。

这让我感到非常奇怪。我一直将实体理解为“游戏模型”，例如玩家，敌人，道具等。从代码重用的角度来看，为UI重用组件是很有意义的。

UI / GUI关注点如何（以及在​​哪里）适合实体/组件系统？

（注意：此问题与平台无关，因为它适用于多种平台/语言）

在使用了多个实体组件系统，尤其是CraftyJS之后，我或多或少地得到了我的问题的答案：是的，您可以为GUI重用组件（尤其是2D游戏中的sprite或图像和鼠标单击处理程序）。

在很多时候，您只能访问ECS，而不能访问底层系统（例如，绘图系统）。在这种情况下，可以使用组件，因为您别无选择。

如果您确实有权访问底层系统（例如，直接访问Curses的Ruby roguelike），则可能会发现，直接在该系统上进行绘制/渲染比使用一堆系统更有效（代码更少，更脆弱，更自然）。实体和组件。

在2D或3D中，如果实体组件系统（ECS）不是同一ECS的一部分，则它至少应有权访问GUI系统。

就个人而言，我不会将两者混为一谈。GUI的代码可重用性仅在顶层发生。响应鼠标/键盘，渲染等。不同按钮所采用的功能或某些列表显示的信息并不是真正可以通用而重用的东西。

例如，我会想象GUI实体组件会是这样的position，render和gui。GUI组件将定义GUI实体采取的操作类型的位置。但是，该操作将非常独特且特定于上下文。这导致处理GUI组件的系统非常大，并且本质上被设计为处理每个GUI功能（加载游戏，保存游戏，查找服务器等）。听起来很乱。

我希望为每个GUI“屏幕”做一个标准的类文件。将该屏幕的所有功能都放在一个位置（并引用通用功能类）。它更加整洁并且易于管理。

但是，正如我所说，ECS应该可以访问GUI系统。它需要能够基于其系统中的实体向GUI提供信息。例如，将鼠标悬停在同盟单位上会弹出一个GUI窗口，其中包含有关该单位的所有信息。将鼠标悬停在敌方单位上会弹出一个GUI窗口，其中包含有限的信息。您可能不想对GUI进行编程以了解两者之间的区别，而是想让实体显示其信息。

因此，实体仍然可能会具有某种GUI组件，但它们将是“游戏中的”实体，而不是GUI实体。该组件将使用外部GUI系统创建其GUI界面。