问题标签 [entity-system]

我正在使用 Artemis 并尝试扩展EntityProcessingSystem<SpatialForm, Transform>. 但是，它告诉我The non-generic type 'Artemis.System.EntityProcessingSystem' cannot be used with type arguments；但是，它必须与类型参数一起使用。知道这里发生了什么吗？

我正在使用 Artemis - https://github.com/thelinuxlich/artemis_CSharp 和 StarWarrior 作为我的教程 - https://github.com/thelinuxlich/starwarrior_CSharp

我找不到一个对 CPU 缓存友好的框架实现，这意味着系统在每个游戏循环周期中遍历的数据都存储在连续的内存中。

Let's see, systems traverse on specific entities that satisfy their conditions, i.e. the entity should contain A, B, C components to be processed by X system. This means that I need a contiguous memory that contains all entities and components (not references, as far as references are not cache friendly, and you will have lots of cache misses) in order to obtain them from RAM as much fast as it is possible during the processing of X system. But right after the processing of X system, Y system starts to operate on a set of entities that satisfy to its conditions e. g.all entities containing A and B. This means that we deal with the same set of entities as X system plus some other entities that have A and B. This means that we have two contiguous memories which have duplicate data. First of all data duplication is very bad for known reasons. And also this, in its turn, means that we need a synchronization, which again is not CPU cache friendly as far as you need to find some entities from one vector and update with the new data which is contained in another vector.

This is just one of my thoughts. There are other, more realistic, thoughts for Entity Component System Framework data model, but in each model I could figure out there is the same problem: during each game loop cycle you can not prevent lots of cache misses because of not contiguous data.

Can anyone please suggest an implementation, article, example just something on this topic, that can help me understand what data model should be used to obtain cache friendly design, as this is one of the most critical things in game performance.

我正在探索 Go 和实体组件系统。我了解 ECS 的工作原理，我正在尝试复制似乎是 ECS 的首选文档，即http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

出于性能考虑，该文档建议使用每种组件类型的静态数组。也就是说，不是组件接口数组（指针数组）。Go 中的问题是循环导入。

我有一个包ecs，其中包含Entity、Component和System类型/接口以及EntityManager的定义。另一个包ecs/components包含各种组件。显然，ecs/components包依赖于ecs。但是，要在EntityManager中声明特定组件的数组，ecs将依赖于ecs/components，因此会创建循环导入。

有没有办法避免这种情况？我知道通常高级系统不应该依赖于低级系统。我还想指出，对于我的目的而言，使用指针数组可能足够快，但我对可能的解决方法感兴趣（供将来参考）

谢谢您的帮助！

我正在尝试使用 JRuby 的Artemis 实体系统框架。这是我试图转换为 JRuby 的 Java 代码：

当我执行这个输出是：

ConsoleOutputSystem.process() 方法被调用十次。这是我的 JRuby 代码：

输出是：

所以 ConsoleOutputSystem 构造函数被调用，而不是 ConsoleOutputSystem.process()。我尝试同时使用 @world.initialize 和 @world.java_send :initialize 并且输出是相同的。我尝试的另一件事是将 java_signature 'protected void process(Entity)' 添加到 ConsoleOutputSystem.process() 方法中。

Artemis 包中的其他几个类具有名为 initialize() 的受保护方法，但我不确定这是否与我的问题有关。

[编辑]

自从我发布问题以来，我已经取得了一些进展。@world.java_send :initialize 有效并调用了正确的方法。不起作用的是 Aspect.get_aspect_for_all()。在 Java 中 Aspect.getAspectForAll() 期望

作为论据。在 JRuby 中，这些都不能作为 Aspect.getAspectForAll() 的参数：

唯一可行的是预先创建一个 Position 实例并将其类传递给 Aspect.getAspectForAll()：

这是它工作的代码，但感觉就像一个杂物：

的输出

是：

所以，我的问题是如何在不创建 Position 类的实例的情况下访问 org.jruby.proxy.com.artemis.Component$Proxy0 ？

[编辑 2]

感谢 Namek 在这里的回答是有效的代码。它用

所以我不需要创建一个 JRuby 类的实例来访问它的 Java 类：

我正在为组件创建实现工厂模式，并希望为工厂创建的每种类型的所有实例实现一个单例容器。理想情况下，这将是工厂中创建的每种类型的一个向量。

如果我可以将基类指针保留在向量中，这将非常容易，但是我的用例非常希望所有实例都连续存储，而不是 new 将它们放在任何地方以获得尽可能多的缓存命中。

我正在考虑为工厂地图做这样的事情：

这具有丢失派生类中的数据的问题，因为它被强制转换为基类。

我还认为将指向向量的指针作为该对的第二个成员将是一个很好的方法，但我不确定如何在每个向量中存储不同的数据类型的同时实现这一点。我认为这是不可能的，因为模板化的向量在技术上都是不同的类。

有什么办法可以做我想做的事吗？在过去的几天里，我一直试图弄清楚一些事情，但没有运气。

或者，如果有另一种存储向量的好方法（即作为组件类的静态成员），我也愿意接受任何类似的建议！

最近几天我学到了很多关于 Erlang 的知识，并且熟悉组件实体系统。

使用 Erlang 的以流程为中心的方法，我建议每个实体都是一个 Erlang 流程实例。至于 CES（组件实体系统）方法，对于拥有一个 MovementComponent（例如）的实体，我会有一个类似“MovementSystem”的过程。然后，我将使用尾递归“迭代”所有注册实体并向它们发送消息以让它们更新自己的进程状态，而不是由 MovementSystem 本身作为批处理......（我不会称之为不再是实体系统，因为据我了解，CES 拥有它正在处理的所有实体和组件的所有信息，这意味着“共享内存”，这在概念上不是 Erlang 的一部分）

这两种方法/范式 - Erlang 和“组件实体系统” - 是相互排斥的，还是我遗漏了什么？

（我什至不会在 GitHub ( https://gist.github.com/sntran/2986790 ) 上称这个原型为真正的组件实体系统。这种方法看起来更像实体系统，在我看来它更像是一个基于 gen_event 的 MQ 方法，我可能会使用 RabbitMQ 来代替......但这与这里无关......）

现在我看不出这两个概念是如何结合起来的......

如何解决由模板函数引起的循环依赖？

例如，我定义了一个 Engine 类，它存储一个实体列表，并负责创建实体并从中添加/删除组件。

然后，我还在实体类中添加了函数来“包装”这些函数，从而为向实体添加组件提供了一种很好的语法。

这使我可以编写这样的代码

不必在任何地方直接引用引擎对象

但是，由于引擎类包含实体实例，因此它必须包含实体类。然后实体类必须包含引擎类，以便模板函数调用方法，这会导致循环依赖。

如果函数不是模板，这很容易解决，因为可以将实现放在 Entity.cpp 中，然后我可以在其中包含 Engine 类。我正在努力了解如何使用模板函数完成相同的操作。

我正在尝试为我自己的小型 2D RPG 创建自定义地图格式，所以我的问题是如何正确灵活地管理阅读和创建自定义地图格式。首先，我正在用 Java 编写代码。这个想法是有一个名为“TileMap”的类。此类定义了一个二维整数数组，其中存储了我的所有实体（我正在使用实体系统来实现我的游戏）。我还想在实际读取过程发生之前保存和解析一些关于地图大小的信息。地图文件应如下所示：

其中 layercount 是 z 维度提供的层数。并且tilesize是每个tile的大小，以像素为单位。实体在括号之间定义。模式是：[entity_id;x_pos;y_pos;z_pos]。我已经编写了代码来解析这样的文件，但它不是很灵活，因为你只需在方括号前放一个小空格，地图就无法加载。我只需要一些有用的技巧就可以灵活地做到这一点。有人可以帮帮我吗？

I'm currently learning about "Entity Component System". After reading many tutorials and forum threads I still wonder where rendering logic has to go. I am not talking about actual OpenGL/DirectX-Rendering code that, for example, takes a sprite and renders it. What I mean is the logic that decides which sprite to render.

A visible entity requires three aspects:

1. Evaluating the AI (changing position, state, ...)
2. Evaluating the rendering state. For example which sprite cycle to use when the entity is walking, climbing, getting hit, ...
3. Actually rendering the sprite

Most tutorials propose to use something like an AISystem (1.) for logic and a RenderSystem (3.) to show a sprite (cycle) that is defined in a RenderComponent. What they do not say is where the RenderComponent is updated. It is my understanding that just putting (2.) into (1.), thus mixing character logic with rendering logic, would be bad design.

The straight-forward solution would be to add a specific render logic system for each enemy. So for example for a Gumba, I could add a GumbaLogicSystem, a GumbaRenderLogicSystem and for actual rendering, a generic SpriteRenderSystem that all sprite based entities use. However, this means creating two components* and two systems for every entity type, which does not seem to be a good solution.

Is there a good solution that separates character logic and rendering logic while keeping the number of systems small?

Thank you

(* = in a simple approach, a system processes an entity depending on its component. In order to have the GumbaRenderLogicSystem work on the entity, it needs a GumbaRenderingLogicComponent in order to be recognized by this system. The same is true for the character logic.)

Edit1: I am aware that ECS is an abstract pattern. My question aims at best practices on how to keep the number of systems small. My example is motivated from game programming but not restricted to this area. Let me explain with a more abstract example:

Imagine I had some entity that is visible. In a hierarchy based architecture I would have something like:

• SomeModel (inherits from AbstractModel)
• SomeController (inherits from AbstractController)
• SomeRenderer (inherits from PixelRenderer which in turn inherits from AbstractRenderer).

In ECS I would need a whole bunch of new classes:

• SomeModelSpecificDataComponent (i.e. data that is specific to this semantic entity)
• SomeModelSystem (that does the logic)
• SomeModelSpecificRenderComponent (i.e. rendering data that is specific to this semantic entity)
• SomeModelSpecificRendererLogicSystem (system that decides how to render)
• PixelRendererSystem

Is there any way I can reduce the number of new system that need to be introduced? One solution might be to add "agents" or "behavior objects": a general RenderingComponent is attached an instance of some "RenderingAgent" class that has a single method "Update" which is called in the RenderSystem. So technically the component does not contain logic itself. I fear this might be overengineered, though.

我应该在每个具有父级的实体上添加一个所有者组件吗？如果是，该组件的正确术语是什么。目前我正在使用AttachmentComponent由 owner 组成的组件Entity，并像下面的代码一样使用它。