Entity Component System for HUD and GUI

Question

This is a very rough sketch of how I currently have things designed. It should, at least, give an idea of how my ECS is currently designed.

If you notice in that diagram, I have basically split the HUD out of the ECS. They have their own set of things (HudLayer, HudComponent, etc) and are handled differently. This is where I'm struggling, though.

There are many different instances in which the HUD will need to know about entities. Not just data changing (I have an event dispatcher for that), but the actual entity and all it encompasses. There are also situations where entities will need to be able to query the HUD for data. Let's take a couple examples:

• First, my equipment screen. On here I can change the equipment on a character (Entity). In order for this to happen, I need to know about the entity. At least I think I do? How can I handle this?

• The second scenario involves my Systems needing to query a HudComponent for data. A specific example would be my battle system. Each "team" is given a 3x3 grid they can move around in. See here:

Skills target these cells, and not the player, so I would need a way for my systems to determine which cells are occupied and which are not. Basically I need a way for two way communication between Systems and my HUD. I know it's recommended (by some people, anyways) to take your HUD out of the ECS. Is that appropriate in my case?

Answer 1

It seems to me that you're mixing the visual representation with the logical representation of what you're trying to create. Lets discuss your two scenarios.

Equipment Screen

In this situation, I would simply have the Equipment UI be capable of querying the inventory system for the current player. This allows the inventory system and it's management to remain inside your ECS framework and you are simply allowing the UI system a means to ask the inventory system what it's contents are and visually represent the data for the user. When users move items around in their bags, the bags simply call methods on the inventory system that manipulate the components accordingly. This way, the Equipment UI screen really knows nothing about the ECS. It simply has a reference to a class that implements an Inventory System interface and through that instance, it can obtain the information it needs to draw itself.

Battle Screen

I believe this scenario again follows a similar premise. You can easily abstract the component, entity, and logic aspects of the battle system into a BattleSystem that is part of your ECS. This system again implements a specific interface that defines the contract between the UI and the system. Now, when a user performs a UI action, the UI simply calls the appropriate method in the BattleSystem and whatever interactions must occur between it, entities, and components happen.

One thing I would strive to do in either of these cases, is any information that feels as though it's leaking from the subsystem abstraction to the UI should be pushed into the system. The UI should be designed in such a way that perhaps these values could be tweaked in the system and the UI adapts accordingly. For example, the BattleSystem maybe has a method that tells you the grid size is 3x3 but in a later release you decide it should be 4x4 or 5x5. By allowing this to be data-driven, the UI no longer cares necessarily about it and just adapts, really allowing the UI to be as decoupled as possible from the system's logic and implementation.

The key take away is don't be hesitant to design a system or systems at one layer and then wrap those system(s) up into a larger system at a higher level until you reach the level of abstraction and generalization you need to keep things decoupled at their respective levels, but cohesive enough across layer boundaries without impairing design.

Answer 2

Your HudLayer could contain a System HUDSystem where your entities eventually register their components. The HUDSystem can then track changes from the registered entities.

Answer 3

You are on the right track about keeping the HUD out of the ECS. HUDs and game screens in general benefit greatly from inheritance, as the flow of gameplay is essentially one tree where you can branch out in different paths or backtrack in a manner that makes sense to the player. I use a variation of state pattern, where

However, the HudLayer and GameScene can be condensed (in the programmatic sense) into the same type of object. I consider HUDs to be GameScenes too, in that they can contain entities and a update->display loop that may await user input. Entities in HUDs are the background, icons and text, in a similar way that characters and backgrounds on the battle screen are entities composed of graphics and locations. While this means HUDs contain elements that are part of the ECS, the HUD screens themselves are not in the ECS.

Going back to inheritance, if the battle screen is considered the primary GameScene that is active, all the on-screen HUDs and menus can be children screens of the battle screen. When you open the inventory screen from the battle screen, the battle screen stops taking input and creates the inventory screen. The battle screen keeps track of the active character and what cell it is on, and any character-specific menus are loaded with this information. After making a selection and closing the menu, a value based on the selection is returned back to its parent, the battle screen, and the ECS would take care of making the character entity respond appropriately.