Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

up vote 13 down vote accepted

Maybe you're thinking too much in entity systems. Entities are meant to scope objects in game, like characters, enemies, scripts, bullets, triggers, etc.

Maybe if you make your UI separated, it will be way better and easier. You don't have to make EVERYTHING inside the entities scope.

share|improve this answer
    
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). –  user8363 Sep 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. –  Sylpheed Sep 16 '12 at 8:35
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.