Priority and Predicate changes

Loading Order

By default ViewResolverSystem and ISetupSystem would be registered first however there was no distinction, so it was down to whichever was registered first, however in this release we now have it so ViewResolverSystem classes load first, as they generally just create views there is rarely an issue with them running first. Once these are all registered then the other ISetupSystem. This generally just means when you register a new component, or add an entity it will run in the above order, so your views can be registered first then your setup systems can make use of them.

Priority Attribute

This adds the [Priority(1)] attribute where you can hint to automatically loaded systems/view resolvers that they should load, so as mentioned in the previous point the underlying order of which things would be resolved when dealing with new entities and components has changed. This works as a more explicit way to set what should run first, so if you set a priority of 1 and another with a priority of 2, the lower priority would be run before the other, this can help when you have systems which depend upon other systems doing something before hand. It is optional and does not NEED to be used with systems, but as most people will automatically register them it will assist with managing the order of invocation on entities.

Group Predicate Changes

This release also adds some more logic to help with setup systems, so for example if you were to have a ViewResolverSystem which required another system to setup what prefab name should be used, you could have this as part of your group's predicate and the Setup of that entity for that system would be delayed until the predicate was met. In previous versions setup systems which did not match the predicate of an enitty would simply ignore it, whereas now it will just defer the setup until the entity passes the predicate, it will still only be run once though, and would be re-run if you were to remove components required for a system and then add them back in.

Improved Editor Inspectors

Improved Custom Inspectors

Due to some brilliant work by @tbriley we have now got some functional inspectors to allow you to work in a more scene first manner. This allows you to add and remove components as well as setting primitive values within components at editor and runtime. This will hopefully pave the way for runtime support for blueprint editing and setup as well as improving some of the helper inspectors which need an overhaul.

Plugin System

So there is not an IPlugin interface that if adhered to you can load plugins within your AppContainer instances, plugins are not automatically loaded as you may not want them in every scene, but they will allow you to replace/add custom dependency injection bindings, and pre-register systems, so that you can create and share chunks of logic using your events and components as the contract between your plugins and the consumers systems.

Example Updates

The examples have been updated to use the simpler AutoRegisterSystemsInstaller for most cases as well as the consistent ViewComponent for anything in the examples which has a view associated. There is also a few more examples showing how to do things such as manual setting up of systems and how to use a scene first approach to entities.

Breaking Changes

This release introduces some breaking changes from previous versions.

• Removed IMessageBroker dependency from framework classes and moved to use abstracted IEventSystem
• RegisterAsEntity is now known as SetupView
• EntityBinding is now known as EntityView
• AutoRegisterSystemsInstaller now registers the concrete types against themselves AS WELL as against ISystem

View Conventions & Blueprints

Blueprints

This release brings in support for blueprints which all you to pre-define component setup logic for entities as well as exposing configuration based detail for allowing re-useable setups, these can be applied to an entity via extension methods, applied via the blueprint, or passed to the pool to create an entity pre-configured.

View Conventions

There is also an addition to the unity layer to add support for ViewComponent and ViewResolverSystems which basically provide a streamlined way to give your entities views and a consistent way to create the game objects for them. It also adds basic support for view first paradigms where you can create a game object in the scene and provide it the RegisterAsEntity MonoBehaviour which will automatically create an entity to back the GO and bind it to the entities view component.

InjectableMonoBehaviour class

This is more of a simple convention class which automatically provides an instance of the IMessageBroker to the mono behaviour to raise and listen for events as well as adding a DependenciesResolved method which acts as the entry point for the class when all its dependencies have been resolved. This is primarily here to save time for MBs which will be injecting dependencies.

Initial Release

Core ECS Paradigm

This is the first and basic release which contains core ECS functionality as well as unity layer with AppContainer and basic examples.

Dependency Injection

All systems and MonoBehaviours will get Dependency Injection for free via Zenject allowing systems to just adhere to IoC and get their dependencies via the constructor. MonoBehaviours unfortunately cannot do this and will need to adhere to an [Inject] method and properties.

Reactivity & Events

This also introduces the notion of reactive systems of varying types such as IReactToGroupSystem, IReactToEntitySystem and IReactToDataSystem. There is also a default IMessageBroker singleton within the DI layer which can be added to anything that wants to send events around for other systems or MonoBehaviours to listen to.