Does Entity need to know all possible components?

[JKarneeb]

Based on the examples, it looks like the base Entity type that all entities of a World have expects it to enumerate all of the possible components it could have? Is this right?

I suppose in practice, its not that big of a deal to enumerate all of the possible types, but it feels odd from an ECS perspective. I like how lightweight this library is compared to libraries that are more hyper-focused on the performance aspect of ECS, but I can't shake the feeling that having a monolithic object that can store 1 of each possible component just feels off.

How do you all tend to use your Entity class? Do you leave it totally untyped? Fully specified? What is the expected best practice here?

[hamzakubba]

The library is fully typed (it infers correctly in the relevant use cases), I'm not the author but I believe that was the hardest part of building the library. Did you open and try to edit the example code in a typescript-capable editor?

[hamzakubba]

I'm not sure I understand the concern; you can do a lot to organize things if the concern is about organization, e.g.

// one way, break into sub-types or interfaces and compose them
type Instanced = {
  instanced: {
    // ...
  }
}
type Entity = Partial<Instanced & AnotherThing & YetAnotherThing>

// another way:
interface Entity {
  instanced?: InstancedComponent;
  anotherThing?: AnotherComponent;
  yetAnotherThing?: YetAnotherComponent;
}

You don't need an Entity class, it's just types. If specifying types seems like a downside overall for your project then that project can just be vanilla JS. I have been putting most types in a single file which has zero implementation, and that has worked well for me. In my case most things are inline, whereas a few are pulled out into their own interfaces (like the second example above).

[hmans]

It feels to me that the original question is not as much a question about how Miniplex expects entity types to be set up as much as it is about the overall design of the library (@JKarneeb, please correct me if I'm wrong.)

Miniplex chooses to express entities as plain JavaScript objects, with components being properties on those objects. This has the obvious limitation that you need to know in advance which components you want them to support if you want to prevent namespace clashes (you can't have two different components of the same name, because they'd fight for the same property name within entity objects.) This is why the up-front typing might feel a little awkward, but it's really just a function of you having to make decisions about what components to support.

Other (more "true") ECS implementations do not have this issue because there typically isn't an entity object, but just a collection of independent arrays (or other structures) storing component data, with the entity merely acting as the ID within those arrays.

Miniplex chooses this design because its primary intention is to be simple to use, especially for users who're familiar with state store patterns in JS, but new to ECS thinking. It's an extremely short jump from something like Zustand or Statery to Miniplex, and for many people who enjoy using Miniplex, that's one of the major reasons why.

[JKarneeb]

You are mostly correct. My intention wasn't to complain or to claim there was an issue, but more so to feel out how larger (non-demo projects) tend to handle this particular aspect. It isn't particularly unreasonable for there to be upwards of 50+ component types in a game, depending on how you use them and how large your game is, especially if you make heavy use of tags. On top of that simply being a rather verbose object, it also means that wherever you define your Entity and World objects, you need to import every component type definition you plan to use. I'm a strong believer in decoupled code logic -- my intuition is to separate the initialization of things like my engine from specific mechanics. Front-loading everything its just counter to my general design style.

I think you mostly answered my question though @hmans. Miniplex is designed where it is expected that you will up-front type your Entity/World for the benefit of ease of use throughout the rest of the code-base. I'm currently still just prototyping various patterns in the system to decide if miniplex is right for my coding style -- however there is no denying that it is extremely simple to use and provides many of the design benefits that ECS grants while still allowing the developer extreme freedom. This is something I value a lot, as I've found that, especially in THREE.js, trying to do pure ECS is a bit nightmarish. At least so far, I've not run into those issues with miniplex (but I'm still early in the honeymoon phase of a new tool heh)

Additionally, yes, the nature of the way Entity is structured implies that you cannot by default have duplicates of components, but I think that can be designed around easily enough.

[hmans]

So, one thing to remember is that there are many ways to actually compose the Entity type, instead of defining it monolithically. I've had projects where I did something like the following:

type IPosition {
  position: Vector3
}

type IHealth {
  health: { current: number, max: number }
}

type Entity = Partial<IPosition & IHealth & ...>

There are, of course, many variations on this.

In a similar vein, remember that Miniplex expects entities to be objects, but doesn't really care what these objects actually are. I've had at least one project where I actually implemented entities as class instances to explore this. It might feel far removed from typical ECS thinking, but I was enjoying it as yet another nice pattern bridging the gap between the relaxed, classy JS world, and ECS design.

There's probably lots of fun and/or interesting patterns to discover!