Jump to content
  • Advertisement
Sign in to follow this  
Paragon123

Ecs Gui Systems

This topic is 723 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anyone have any tips, or articles about creating GUIs in an ECS system?

 

Would an interactive console fit well into a GUI system or would it be it's own thing?

 

I feel like, a sufficiently flexible GUI system should be able to handle a console... after all, it is only a text output and input control that triggers events based on input rather than button presses or some such...

 

I suppose I am looking for a starting point...

 

Currently I have a bunch of systems, plus the render system and the minimap system...

Each system has a priority... events are processed by systems in priority order as are updates... So I thought I might have to make two systems for the GUI, one to run after the renderer to draw the gui ontop of everything and another that updates before the playerinput control to catch input events.... which shouldn't be to bad... but I don't know what kind of components I'll need...

 

Share this post


Link to post
Share on other sites
Advertisement

ECS is the LAST pattern you'd want to use for GUI. GUI gets really complicated real fast. If you've never programmed one, I'd suggest taking a look at some libraries to see just how involved it can actually get.

 

Another issue is that ECS is normally designed when you know that elements can actually be separated and processed independently of other code. GUI can not do this very well. GUI usually needs to handle a lot of asynchronous event handling, and dependencies. This is not a dependency on data, that can actually be mitigated a bit. But this is an intercommunication dependency with other objects. To explain this a bit more, a GUI is normally split up into many different items. All these items will normally stack up in a window. These items will adopt their true screen space coordinates from the window, managed by some sort of hierarchy.

 

There will always be plenty of objects that must wait on events from other elements to do certain actions. For example, you can not write in something till you click it. An object is dragged from the world to an inventory slot, or vise versa. Several fields are initially locked, but ticking a check box unlocks them. Etc etc.

The point is that almost every single item in a GUI will depend on the same code that all other items do. To split this up into systems or entities would be like building a pittiful shelter by using a lit torch to set your sticks and leaves. You're going to burn yourself.

 

To be honest, the ECS pattern has a very tight niche on what it works great for, and it just plain out sucks at everything else that is not part of that niche.

 

I'd recommend looking into some other patterns. Typically the easiest and most common strategy for a GUI is to use Model View Controller.

Edited by Tangletail

Share this post


Link to post
Share on other sites

Yea, after searching around the net, talking to some friends and reading this here... the ECS Gui is pretty much a NO-GO... Not a big deal, It would be easier with std oop or oop applied to MVC... just wanted to make sure I wasn't "Taking the easy way out" and causing trouble in my code base by changing up design principals in the middle of it... but it seems like this is a case where that is exactly what is required.

 

Actually, I gueess thinking back on it... that is likely the root cause of most of the issues with Unities original GUI system.

 

Thanks

Edited by Paragon123

Share this post


Link to post
Share on other sites

I think it was meant that since unity was driven so thoroughly as an ECS and the GUI was created with the same tools, it was likely that Unity used their ecs for the gui.

Edited by AuthenticOwl

Share this post


Link to post
Share on other sites

While I would agree that a standard widget hierarchy is probably best for the GUI itself, there does need to be some manner of glue between the GUI and the object(s) it is intended to control. While the GUI itself (the windows, buttons, etc...) is probably best implemented using standard GUI techniques, you will probably need to write a component of some sort to act as the glue. The GUI might generate events,= which the interface component would pick up and pass along to the controlled object in some fashion.

 

For example, in my game a combat-enabled unit owns a command queue component that is used to execute commands (move here, attack that, etc...) in a turn-based environment. AI controlled units possess an AI controller component that sends instructions to this command queue, while player-controlled units possess GUI components that perform the same task. A player GUI component listens for the CombatEnable event that an object receives from the turn scheduler. Upon receipt of this event, the GUI is made visible and enabled. Buttons, hotkeys, etc... implemented as part of the GUI interface generate events which pass instructions along to the command queue for execution.

 

The GUI itself is implemented in a standard fashion, as a parent/child hierarchy of widgets. The widgets are instanced and owned by a PlayerGUI component attached to the unit, and the component is constructed such that it listens for certain events from the widget hierarchy, and interprets those events as commands to pass to the queue.

Share this post


Link to post
Share on other sites

I'd go down the IMGUI approach for the ui interface and ECS for all of your game objects etc.

Share this post


Link to post
Share on other sites

Actually, I gueess thinking back on it... that is likely the root cause of most of the issues with Unities original GUI system.

No, the original Unity GUI completely ignored their objects and components and instead was an IMGUI system, which are never a good idea in my opinion, and was especially poorly implemented in Unity.

Now, they have a system that follows their object/component system, and it's a mess in some very different ways. Trying to build a scrollable window is a nightmare of complexity, with a ton of components that are all interdependent and arguably should be part of the same object. And don't get me started on the way their layout and constraints systems clash over everything.

I'm not sure what the moral of the story is here, apart from that no GUI Unity have ever shipped is a model to emulate.

I recommend 'normal' retained mode UIs. Game developers whine about how awkward CSS is, but there's no in-game UI that provides as good a separation of structure, style, and behaviour as HTML, CSS, and Javascript.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!