EntityManager Singleton methods

[moonheart08]

These allow you to more easily work in scenarios where you only have precisely one of an entity, for, for example, global state management. As EntitySystems are meant to be ephemeral with no persisted state, this is the escape hatch, and there's several cases in the game code already making use of this as one.

Two methods are provided, for 1-4 components:

• Single (get a matching entity or throw.)
• TrySingle (get the matching entity, or none. throws if there's more than one.)

[slarticodefast]

A previous similar attempt here #5683 you might also want to look at.

[moonheart08]

A previous similar attempt here #5683 you might also want to look at.

I'd rather see anything akin to this experimented with in content while the engine API is kept simple for now.

[slarticodefast]

Conceptually I think I like the approach Tay took in his PR more for a couple of reasons (although the PR needed some more work from a technical standpoint).

The multiple component approach seems a little prone to user error to me, as you can have an arbitrary number of entities with component A, and arbitrary number of entities with component B, but only a single entity with both at the same time if any 2 or more component method is used. This is only validated when trying to find the entity, and not at spawn or with any modifications in-between.

This API leaves a lot of boilerplate to the user, which again seems error prone. In the PR linked above the singleton entities were automatically managed by the corresponding system on intialization.

The most common use case for singleton entities is as a sort of global, persistent datastorage for a specific system. So I think it makes more sense to tie the singleton status to an unique entity system corresponding to a component rather than a unique component. This may lead to some more flexibility in their use, and I don't see why the component itself has to be uniquely instanciated.

[moonheart08]

Conceptually I think I like the approach Tay took in his PR more for a couple of reasons (although the PR needed some more work from a technical standpoint).

The multiple component approach seems a little prone to user error to me, as you can have an arbitrary number of entities with component A, and arbitrary number of entities with component B, but only a single entity with both at the same time if any 2 or more component method is used. This is only validated when trying to find the entity, and not at spawn or with any modifications in-between.

This API leaves a lot of boilerplate to the user, which again seems error prone. In the PR linked above the singleton entities were automatically managed by the corresponding system on intialization.

The most common use case for singleton entities is as a sort of global, persistent datastorage for a specific system. So I think it makes more sense to tie the singleton status to an unique entity system corresponding to a component rather than a unique component. This may lead to some more flexibility in their use, and I don't see why the component itself has to be uniquely instanciated.

This API is a broad, general API meant to be used to scaffold a more specific one.

Tying anything to specific systems, or similar, is out of scope of this PR. Down the line I'll likely be implementing a Single<> query one can depend on, but right now I want this in the wild so I know what usecases end up actually looking like. I will not be designing an API for theoreticals when we do not have the power to then refactor and remove it easily later.