Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize the ECS API and UnitTest it. #134

Open
MakoEnergy opened this issue Mar 6, 2017 · 0 comments
Open

Stabilize the ECS API and UnitTest it. #134

MakoEnergy opened this issue Mar 6, 2017 · 0 comments

Comments

@MakoEnergy
Copy link
Member

MakoEnergy commented Mar 6, 2017

The Entity Component System in the Mezzanine is still undergoing a large number of refactors to get it to a place we want it to be.

Most recently the WorldObject class was refactored into something that actually managed the storage of Proxies, allowing us to implement over 30 of the previously pure virtual methods that existed on the class, and dramatically reduced the amount of overrides that were needed to derive from it.

Going forward, there are still a number of requirements before the ECS can be considered stable:

  1. WorldObjects should probably be renamed to include the word "Entity" somewhere, for clarity.
  2. WorldProxies should probably be renamed to include the word "Component" somewhere, for clarity.
  3. "Components" should come in transformable and non-transformable varieties.
  4. WorldObjects should probably store the two major types of components separately, to facilitate transform updates between components. This is really the only bit of meaningful logic on the WorldObject class. It's mostly a container.
  5. We need to be able to support offsets for transformable components in a lightweight manner.
  6. The WorldObject managers should probably be consolidated/merged into one WorldObjectManager.
  7. Spawners for WorldObjects need to be implemented.
  8. A pure interface for the WorldObject class needs to be created, for flexibility.
  9. Something to address the notion of a "Multi-WorldObject" needs to be created or at least investigated.
  10. Decide on a home for the more "generic" components that need to be created (such as a TimeToLiveComponent or AttachmentComponent).
  11. Address the need for some components that will inevitably rely/depend on the existence of other components.
  12. UnitTests.

In addition to these requirements the notion of ownership over the components has come up a few times and may want to change WorldObjects so they actually own their components rather than just store them. We may end up not needing to address this at all, however we may be able to clean up the system by reducing the number of raw pointers to various objects in the ECS system, as well as clean up our serialization scheme. This should be considered and properly assessed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant