ECS Game Architecture with Unity and Entitas

[sschmid]

ECS Game Architecture with Unity and Entitas

This is my mental model based on which I decide where to put my code.
Feel free to comment so we can improve this model further

[sschmid]

If I strictly apply this model to Match One, I'd have to remove the EmitInputSystem and turn it to a MonoBehaviour that emit input entities.
I would have to remove the AddViewSystem and the ViewComponent and have a ViewController or ViewService that listens to AssetComponent, then creates a view and binds it to an entity. The View would update itself with position listeners and destroyed listeners.
If I'm really strict I'd also remove the AssetComponent and have a mapping from entity type to asset name in the View Service, eg. isPlayer -> "Views/Player.prefab"
In my other games I'd also have to replace the PlayAudioSystem with and AudioController or AudioService. There would be no audio context and no AudioComponent anymore.

How does this sound? Am I going crazy? :)

[sschmid]

UI and Views visualize the current game state. They don't affect the game simulation. They can emit input like button clicks, but the game simulation doesn't know if this input came from a button, from the network or from some other program. That's why we don't need Entitas systems for them and can decouple them from the core logic as observers of the game state. UI and Views know how to represent the current game state. This allows us to start with placeholder assets which later can be replaced with the real game assets without touching the game logic.

We are doing it exactly like shown in the graphic. Furthermore we splitted the game logic into different parts: Action -> Command -> Core -> View. The View or other external inputs are able to create actions. The systems there are doing checks if it's possible and emit commands. The command systems will change the state of the core. Core systems only change core state. View is reacting on core and creating view state. Listeners are getting called, because something changed directly in core or in view. We also have a meta context which is just loaded balance values (from json just for easier access). This is done because action and view are part of unity (client side). Command and core are part of the simulation and will run not only on the client, but also on the server (we have a simulation game).

[sschmid]

1st result of applying this strictly with TDD (Audio):
Before:

• AudioComponent
• PlayAudioSystem
• AudioService
• no abstraction, dependency to unity

After:

• No Component / System / IListener / EventSystem
• AudioService (half the code)
• Abstraction (IAudioService, IAudioClip)
• Testable and no dependencies to Unity

Less complex and almost certainly more efficient

I guess I'm going down this road further :)

[RomanZhu]

Can you post your experiments into some repository?

[chiuan]

i thinks it's good to use react system to tell ui & view logic.
by the way , sometimes good to use event + iListener to make it better right now. good !

[c0ffeeartc]

Model looks nice and very intuitive, should be in wiki somewhere 😄

I wouldn't place Physics Collision alongside Button Click, because Unity runs physics in separate cycle N times before Update FixedUpdate > InternalPhysics > OnTriggerXXX > OnCollisionXXX > yield WaitForFixedUpdate.
Bullet may bounce of wall during few physics cycles before it gets destroyed in Game Logic, if we mark Bullet as trigger it gives no collisionInfo, and if we add BounceComponent to Bullet marked as trigger, it will travel a bit inside objects before GameLogic corrects its direction.

[sschmid]

I also refactored my views now. All testable and very nice :)

• removed ViewComponent
• Removed all view systems
• Views updated themselves using the new Entitas events
• ViewService listsnes to asset event and creates view from object pool
• View reacts to destroyed and pushes itself back to the object pool
• Added IView and IViewInstantiator to wrap monobehaviours and view creation. This was a result of TDD with TestView impl and TestViewInstantiator impl. The game uses UnityView (wraps MonoBehaviour) and UnityViewInstantiator (loads from Resources but can be swapped with UnityAssetBundleViewInstantiator). This way you can simply swap from creating view from resources to creating views from asset bundles at a later point of time. Object pooling is in ViewService

[sschmid]

I really start loving the new events. It feels so clean now :)
(We introduced the idea in 2016, but now that we can generate it's even nicer)

[optimisez]

Awesome. Btw @sschmid does it support loading some game objects first at loading time? For example, I want to load 10 enemies into game object pool first before starting game. I expect there is an API to preload the game object first into game object pool.

[sschmid]

Yes :)

[sschmid]

Updated diagram to include commands.
External input should be checked first and if valid creates commands which affect the simulation.

Invalid input could be for example buying an item, but you don't have enough resources. Commands don't verify, they only act.