I think I already got the idea of the Entity System inspired by Adam Martin (t-machine). I want to start using this for my next project.

I already know the basic of Entity, Components, and Systems. My problem is how to handle UI / HUD. For example, a quest window, skill window, character info window, etc. How do you handle UI events (eg. pressing a button)? These are stuff that doesn't need to be processed every frame. Currently, I'm using MVC to code UI but I don't think that'll be compatible for Entity System.

I've read that Entity System is embedded on a larger OOP. I don't know if UI is outside of ES or not. How do I approach this one?

This is also what Adam Martin says in one of his posts or comments on t-machine. The ES is a solution for a specific problem. It can and should be used together with more 'traditional' solutions for other aspects of the game(engine).
–
user8363Sep 15 '12 at 14:10

Thank you. I'm just not sure what should be in ES. So how do you code an effective UI? I think MVC doesn't cut it because I'm having problems with hierarchy.
–
SylpheedSep 16 '12 at 8:35

I see you agree to use different architecture for UI. Then what is the problem with MVC?
–
NarekApr 19 '14 at 10:51

@Armen MVC has no problems, but putting it inside the entities scope has. It's just that its benefits won't beat its disadvantages. There's no need to be an Architecture Astronaut
–
Gustavo MacielMay 2 '14 at 16:18

While I think an Entity/Component UI might work, it would be difficult to make it so. Additionally, it's far enough removed from the components and systems you'd have for processing your game entities, it would essentially just be another entity/component system within your game. I can't imagine there would be a lot of overlap between the two.

Entity systems are awesome and it can be tempting to use them everywhere. After all, when you get a really sweet hammer, you're tempted to treat all your problems like nails. However, the EC system is just another tool in your programming bag. For the problems it's used to solve it works really well, but you have better tools for problems like UI.

The inheritance structure works really well for GUIs. Not only for creating the UI components but for laying them out too. It's really nice to be able to have UI components be children of other components so they can inherit properties like position, scale and opacity. If you were to try to set that up with a EC system, you'd have to break some rules of the EC system.

You can make a new interface function that is called whenever UI/HUD is drawn and allow custom/scripted components to implement that function. This requires an IMGUI system (there are lots of tutorials on it in Google, this is just the original presentation) to be used. With that, you can make windows as entities inside which you'll have your own UI-building component and a window frame renderer component.

As for not processing all of this every frame, you can render all UI to a different buffer which you'll update only on all kinds of input / data events. That is, whenever an event is received, it changes some variable to indicate that the window needs to be repainted the next frame. If that variable is true, it is then set to false and UI interfaces are called after that. If you want animations, it's important that you use this exact order of operations so that UI itself could trigger a repaint for the next frame.