# Entity/Component System and UI “Entities”

I'm still green to entity/component systems. I find that since I have useful components for drawing sprites (or spritesheets) and handling input (mouse/touch clicks), I naturally want to reuse these to create UI components (like buttons, eg. level-select screen).

This strikes me as very odd. I always understood entities as "game model" things like players, enemies, power-ups, etc. On the other hand, from a code-reuse perspective, reusing compnents for UI makes perfect sense.

How (and where) do UI/GUI concerns fit into an entity/component system?

(Note: this question is platform agnostic since it applies to multiple platforms/languages)

• I think it seems logical for you only because you are making 2d game. Imagine you would make 3d game (with 2d gui) almost none rendering logic could be reused, and 2d gui components inside 3d world wouldnt make much sense. You should build GUI on top of component system. Like have your GameplayScreen create entity world with components, and one of the components will be camera with "canvas" that your renderer will draw to. And that canvas will become background of that screen. – Kikaimaru Sep 11 '13 at 11:03
• @Kikaimaru you have a point about 2D. Maybe I'm too much into MVC, but it seems like a mix of "model" (game entities) and view/controller (UI components). It works, sure, but is this the way it should work? Are there better ways? How do others do it? – ashes999 Sep 11 '13 at 13:35
• @ashes999 your comment and initial question is from deep inside my heart :) – Narek Apr 19 '14 at 10:29
• @Armen I never did get a satisfactory answer to this. – ashes999 Apr 19 '14 at 10:32
• @ashes999 me to. Everywhere people say that you should not mix MVC with ECS, but why? Whouldn't it be nice? Different weapon for different tasks, don't you agree? – Narek Apr 19 '14 at 10:39

After using several entity-component systems, especially CraftyJS, I more or less got the answer to my question: yes, you can reuse components (especially sprites or images and mouse-click handlers in 2D games) for the GUI.

Much of the time, you only have access to the ECS, and not the underlying systems (eg. drawing system). In this case, it's okay to use components, since you have no other choice.

If you do have access to the underlying system (eg. Ruby roguelike with direct access to Curses), you may find that drawing/rendering directly on that system is more effective (less code, less fragile, more natural) than using a bunch of entities and components.

• Where do you put the logic of advanced UI elements? Ie. a health bar that needs to know when the player get hit and how much to decrease the bar. I can't realize if it needs a specific system, or a script or something else... – Emir Lima Jan 4 '16 at 17:45
• @EmirLima for something like that, I would put most of the UI logic in the health bar (changing health-bar size), and make the player generate an event when he's hit, indicating what the new/changed health value is. (The health bar can capture this event and react appropriately.) – ashes999 Jan 4 '16 at 20:48
• But what is the health-bar object in that architecture? Is it an entity with a "health bar" component? A class that inherits from Entity? A normal object with update calls hard coded? – Emir Lima Jan 4 '16 at 23:57
• @EmirLima I would model the health bar as an entity and the player as an entity. You can do whatever makes sense to you. – ashes999 Jan 5 '16 at 4:55

In 2D or 3D, an entity component system (ECS) should at least have access to the GUI system, if it's not part of the same ECS.

Personally, I wouldn't mix the two. The reusability of code for a GUI only really happens at the top level. Responding to the mouse/keyboard, rendering, and so on. The functions that different buttons take, or the information that certain lists display isn't really something that can be made generic enough to reuse.

For example, I would imagine the components for GUI entities would be something like position, render and gui. Where the GUI component would define the type of action the GUI entity takes. However, that action is going to be pretty unique and context specific. This results in the system that handles GUI components being very large and essentially designed to handle each of the GUI functions (load game, save game, find server, etc). Sounds messy.

I'd prefer to do a standard class file for each GUI "screen". Have all the functionality for that screen in one place (with references to a common functionality class). It's a lot neater and easier to manage.

However, as I said, the ECS should have access to the GUI system. It needs to be able to supply information to the GUI based on entities in its systems. For example, hovering over an allied unit would pop up a GUI window with all the information about that unit. Where hovering over a enemy unity would pop up a GUI window with limited information. You likely don't want to program the GUI to know the difference between the two, you want to ask the entity to display its information.

So, entities will still likely have some kind of GUI component, but they'll be "in game" entities, not GUI entities. This component will use the external GUI system to create their GUI interface.

• Sounds like the system I have is quite different from the one you described. I have entity classes like TouchButton which are composed of a spritesheet and an touch-click-listener. For the unit popup, I would probably implement that as a combination of sprite component + mouse listener component. Hmm. – ashes999 Sep 11 '13 at 14:03