Entitas Modules / Packs / Kits

I think that is actually the next big cool feature if I manage to find a solution. I was thinking about Entitas and modules / packs / Kits and how one could tackle this.

The goal

Someone writes a bunch of systems and components, packs them and calls it PathFindingKit or PhysicsKit or AnimationKit. Basically a self contained and tested module that you drop into your game and voila you have PathFinding, Physics or Animation.

---

Kits most likely come with their own contexts and components, so first of all I have to find a solution for #303 (Support for multiple contexts in ReactiveSystem).

---

Vision

You download a PathFindingKit. I comes with components, systems and contexts. You install / register this kit somehow with Entitas and declare that your own GameEntity is also a PathFindingEntity (defined in the Kit). Now your GameEntity supports methods like e.AddPath() and things like that.

---

It’s an interesting though which would enable the Entitas community to share Kits which solve certain problems. We basically could create small reusable building blocks and put them together in our games

[SanderMertens]

@sschmid the module/packs/kits idea is something I implemented with flecs modules, where just like you describe, there are a number of reusable modules that implement a feature, like rendering, collision detection, movement etc. Some of the projects created with these modules are this, this and this.

I’ll deposit some ideas on challenges I had to overcome here, in case it’s useful for the Entitas design:

Ordering One major challenge I had to address was how to order systems the right way. Some systems imported from a module should be executed at the beginning of a frame (like cleanup systems), while others needed to be ran after game logic was processed (collision detection). I addressed this with three mechanisms:

• Systems can be assigned to a “phase” (PreUpdate, OnUpdate, PostUpdate, Render etc)
• Within a phase systems are executed in the order of declaration
• Modules can import other modules (requires allowing for re-importing modules)

The guiding principle is: there should be no direct dependencies between systems in different modules, but there can be dependencies between modules. So far this seems to work, though I’m still refining the different phases. In Entitas this may be easier, as you could use the Unity execution order.

Module organization A second challenge was how to organize modules. I ended up creating separate modules for components and systems. The component modules establish a common interface for doing certain things, like expressing physics, geometry, or even something completely different like an HTTP server. The system modules only implement the systems that use these components. This lets you “easily” plug in different implementations for the same functionality. For example, an application could swap to a different rendering engine by just importing a different rendering system module, while still using the same components module.

Performance degradation because of redundant systems A third challenge was how to prevent systems that don’t do anything from impacting performance / RAM footprint. When importing a systems module there is a good chance that a number of systems won’t be used. In a normal application that’s ok, since the user has full control, but in a module a user may not have access to the systems. I addressed this in three ways:

• The ECS framework automatically removes systems that don’t match any entities from the critical path
• The application can pass a flags argument into the import statement to include/exclude certain features (for example, I want to import physics, but only for 2D)
• The import function returns a struct with handles to the imported systems, which an application can then manually turn on/off

UI clutter The fourth challenge I faced was more UI related. I have a web dashboard that shows all the loaded systems (similar to the Entitas panel in Unity) and when you import multiple modules, you can get a lot of systems in your UI. Even for a trivial Pong example, I had over 50 systems, most of which weren’t doing much. To address this, I added an EcsHidden tag to the framework which can be used to mark “framework” functionality that is not directly related to the application logic. An UI can use this information to automatically hide or flag these systems, so that a user can easily see which systems are “application logic”, like this (orange triangles are framework):

Anyway, that’s a blurb with some thoughts, hope it is helpful 😃

[jgj]

Seems to me if I’m going through the trouble of telling the code generator what context I want the kit to exist in that the code generator should generate code to integrate it transparently into said context. As an end user of a kit, do I really need to make the distinction at compile-time that a set of components/systems came from a kit?

It makes sense to me that the code generator would generate versions of the kit’s systems/components that function/appear the same as systems/components I’ve authored myself. Otherwise I’m taking on additional mental overhead to use a kit, which is contrary to the reason I’m using a kit in the first place.

Perhaps that means creating kit-authoring-specific types (Context, Entity, Matcher, etc) that can function for testing/building a kit and easily be replaced by the code generator with the end user’s types?