I’m interested in developing an RPG game using real-time strategy (RTS) elements. My preliminary idea involves using a transparent Object-Oriented Programming (OOP) approach for the user interface (UI), where I’d use GameObjects to implement it. For example, to display a unit’s health, I’d have a UI component called “textA” that’s a Text UI element. As for the in-game units, I’m considering using an Entity-Component-System (ECS) approach. When a player clicks on a unit, I’d like the “textA” UI component to display the selected unit’s health. Is this idea feasible? Can traditional GameObjects and ECS coexist?
2 Likes
They can coexist, but communicating between them can be challenging for beginners. Everyone has their own way of doing it.
1 Like
Most (all?) DOTS-based games are currently doing this to some degree. It’s convenient to use GameObjects for features like UI instead of reinventing the wheel. Packages such as Entities Graphics are also using GameObjects under the cover (eg. when you place lights, volumes, visual effects, decals, etc in a subscene).
2 Likes
Upon further consideration, I’ve come up with an idea. Perhaps I could create a SelectionSystem to represent the player’s current selection (holding a collection of unit entities). I could use something like var selection = SystemAPI.GetSingleton<SelectionSystem.Singleton>(); to make it accessible in other systems (let’s say the SystemUI). It seems like this approach could help me retrieve values. However, when it comes to displaying textures or icons, such as the current unit’s portrait (which could be a 3D model or a texture image), I find myself a bit perplexed. Should these textures be stored within components, or is there a more effective way to organize this data?
1 Like
Yes, they can. Add required MonoBehaviour to the Entity (via EntityManager.AddComponentObject).
Use managed systems logic to “notify” MonoBehaviour side by querying required MonoBehaviour and calling into required methods (via Entities.ForEach). And its about as simple as that.
Basically, try to do:
System => MonoBehaviour
Not
MonoBehaviour => System (goes against DOD, but sometimes unavoidable)
or
MonoBehaviour => Data (can mess up execution order)
Just make sure to move execution of managed systems related to the MonoBehaviours outside of SimulationGroup to avoid job stalls. E.g. BeforeSimulationGroup / AfterSimulationGroup, or even LateSimulationGroup will do.
If you want some more advanced authoring directly from the MonoBehaviours without major headache - you can check out EntitiesExt (link in the sig, also available via OpenUPM). Take a peek at EntityBehaviour on how to do it.
As for the UI, you can just use default Unity’s uGUI with this approach.
2 Likes