Java 如何在libgdx中使用实体组件系统进行游戏设计，在整个系统中使用舞台、团队和演员？

实体组件系统能够解决游戏开发中面向对象编程过程中可能出现的规模问题。我对ECS有一些疑问：

概述：有实体包括一些组件（有数据）和系统，它们有逻辑，如行走逻辑、战斗逻辑等。因此在任何游戏中，敌人是实体，英雄是实体，等等，它们有自己的系统。每个玩家/敌人成为一个实体

最初我使用的是stage、group和actors，stage使用层次结构将事件传递给actor，并基于我处理的事件。现在我有了实体，我的新演员是什么？是否每个实体都将是参与者？如果是，那么在每一个动作中，我都会调用所有组件更新函数和绘制函数，对吗

实体组件系统仅用于演员，还是我应该将其用于舞台、团体和摄影机？如果应该全部使用，有人能帮助理解如何使用吗

---

在OO中，这很简单，因为我在组中添加了参与者，并根据事件将事件传递给参与者，我会执行适当的任务。对不起，如果我错过了一些东西，因为在ECS中思考对我来说是新的。我开始编写代码，但在考虑整个系统时，我感到困惑。我知道如何为演员工作，但如何让它与团队、舞台、摄像机等一起工作。

实际上这个问题无法回答，因为舞台本身就是一种实体系统。

阶段可以解释为您的实体系统。
组
将是具有特定组件的所有实体，
参与者
是您的实体。将
Stage
和自定义实体系统一起使用没有多大意义

某些技术/独特的东西，如
摄像机
，根本不应建模为实体。没有必要将所有内容都压入实体系统，最终也不会真正适合

总之，您应该重新思考为什么您实际上需要一个实体组件系统。这种编程风格背后的主要思想是通过将内存中的所有组件组合在一起来优化内存布局。使用Java这将是非常困难的，因为您无法精确地控制对象的位置（就像在C++中一样）。另一个动机是拥有抽象的可重用组件，您可以将其用于实体，但实际上，您也可以使用标准的OO实体层次结构来实现这一点。对于移动设备的小型游戏，您可能没有足够的实体，无法真正感受到性能上的显著差异，在我看来，实体组件系统风格并不适合任何地方

如果你仍然想坚持下去，不要使用
阶段
非常感谢你的回答。我目前正在使用OO方法，但当我们进行大规模开发时，它开始崩溃，就像如果我想制作一个可以行走的演员，那么我需要继承walk类，它为我提供了我不想要的所有子类功能。我可以这样做：：我应该用OO方法和使用阶段，但是考虑演员的实体，在系统中做演员的每一个功能，并把它的数据存储在组件中。因为我的大部分代码都将交给actor，所以当我需要一个新的actor时，我只能获取所需的组件。这将是OO和ECS的混合。我不明白为什么从“
Walker
”类继承会在您需要步行实体时提供不需要的功能。但我知道，为实体创建一个良好的层次结构可能会遇到很多不同的实体，因为java只支持单一继承，不像C++。您描述的方法很有意义。我仍然会完全不用
阶段
，但是你可以这样做。非常感谢你的回复。我同意你们的观点，OO编程在某一点上是好的，但当规模增大时，它会面临灵活性问题。这就是为什么我想从一开始就尝试ECS。我想使用Stage，因为它提供了在组中发送命中和处理演员的内置功能。