Help: How use Unity-ECS with UGUI?

The most examples i see has no complex UI module.
When I code traditional, Im usually split the Logic and View like this:

Logic -----> Event ----->View
View ------> Call ------>Logic

And when trans to Entitas, Its like this:

ECS ------> Event ------->UIListener(WindowScript bind components)
View ------> Add/Remove/Replace ------->ECS(This wrong? View is direct operate data?)

But when I started UnityECS, I take some doubt in my way.
UnityECS contains the View (Like mesh)

Its need 1 UI Control bind with 1 entity?There will be too more components.

Its my misunderstanding?
Now I need to use UnityECS in my project.
How do u do this???

Could you help me??
Thank u!!!
:(:(:frowning:

Maybe I need split Game(ECS) and others module(Traditional) in RPG game?
The flow control taked too many components.

I use ECS in the total game code.Its correctly?

You can do this in many ways.

One of them - just use MonoBehaviour for UI, and in ECS (which provide data) realize reactive system (on system state component) which call UI events.
From UI you can call system directly and attach system state components (by entity manager or entity command buffers), or can create new entities and handle them, or subscribe in system on UI change events and do stuff above in system (for more clear separation data from view)

2 Likes

A big advantage with ECS on UI is that you can finally put your UI in an another additive scene without worrying about connecting things cross-scene, because they connects via the shared World instead.

Your main scene create and update some data as entity, your UI system look for those entity to updates the appearance. No boundary of scene preventing you connecting exposed fields anymore.

2 Likes

I’d do it like this. Three layers:

The first layer is MonoBehaviour that receives UI events as usual via UnityEvents, and generates event Entities like NewGameButtonPressed, SoundVolumeChanged {float NewValue} and reads events from the ECS.

Second layer UI aware systems that can send event entities like OpenInventoryWindow, UpdateHP {int NewValue}. And receive events from UI like those listed in the first layer.

The third layer is the actual game logic systems that do not care about UI at all. They could receive some events directly from UI or UI could read directly from this layer, but those are events that are not specific to UI. Since it is ECS, they are completely decoupled it’s just happened so that UI reads and generates those events, but if you would replace UI with networking, this third layer wouldn’t change at all.

4 Likes

It’s worth to read this post(and links inside) since you mention about Entitas:
https://github.com/sschmid/Entitas-CSharp/issues/610

My practice is always follow MVVM for UI with plugins like zenject and unirx, but there’s nothing wrong about your approach if your game is not complex enough to migrate to MV*.
The major advantage of MV* is separate “view” from “model”, the “model” here is “contexts” or “worlds” in ECS, and “view” is gui components.
Like** eizenhorn** said, you’re able to react events or read data from model to view, and send command or modify data from view to model. But the reactive system of UnityECS is not mature as Entitas’ so far, so it may take time to migrate from Entitas.

1 Like