For the power users

Summary

This contains some breaking changes hence the version bump, but this is mainly around slimming down IEntity and moving a lot of helper calls to extension methods (this way they can be applied to any implementation).

Fixes

Big thanks to @JayPavlina for helping with testing and bugs around component removal and duplicate events in Observable Groups have now been fixed and test cases updated accordingly. So now your ITeardownSystem implementations should only trigger once per entity, and your entity remove calls will verify the components exist and raise events accordingly.

Application Module Override

This release exposes the underlying application paradigm further so by default it will install all needed framework components, however if you are a power user you may want to add your own implementations for different things, such as adding your own component type lookups, your own entity implementations, collection factories etc.

Historically it was a pain to unbind everything and re-bind your own stuff, but now there is a GetFrameworkModule virtual method in the application which lets you inject your own bootstrap module, there is an example of this in the optimized performance test examples.

DONT WORRY you dont need to use any of this stuff, and by default you will be fine, but for those who want to build upon this framework further with their own conventions and implementations this goes a long way to helping them.

Optimizations

So as part of the previous performance improvements there was underlying potential to bypass entity interactions by type and provide the raw component type id. This has now been exposed further so IEntity implementations how allow you to Get/Has/Remove by both Type and int (componentTypeId).

Now in most common scenarios component types are cached ahead of time and automatically assigned ids, so when you call GetComponent with a Type it actually looks up the id of the component and then passes that to the underlying database to resolve it. However now you are able to bypass this type lookup if you need to and use the ids directly but to do this you need to explicitly set your component type ids and manage that yourself within the project.

You can potentially add your own codegen to do some of this for you or hand roll your own approach, but if you look at the example performance tests which are optimized you will see that they are overriding the default framework module and providing a hardcoded version of the component lookups.

There are a few different ways to approach the management of ids, you could set them as an enum, or a static class full of properties, or even extension methods which have hardcoded ids like GetHealthComponent() which internally knows HealthComponent is id 54 etc.