What is best approach for in-game UI labels?

[Maciek]

Ash really speeds up my development process. However I find it hard to design good approach for in-game UI labels. Let's say I want to put 'score' label in my game. It should increment every time when collision is recognized in my PhysicSystem.

The natural way for me is to split it into some model and view, then update model and let the view know that there was some update and... but I want to use Ash ;).

Should I design a score label as an entity in my game? In short, I can add a ValueComponent (with score as an .value:Number property) and DisplayComponent (with TextField as a .displayObject:DisplayObject) to my 'score label' entity. I can pass the same ValueComponent instance to the PhysicSystem as a .scoreValue property. Then I can iterate through every LabelNode (containing DisplayComponent and ValueComponent) in my LabelSystem and update every TextField fetched from DisplayComponent with value fetched from ValueComponent.

However this looks bad for me. I see unnecessary calls when score dosen't change (adding some boolean flags can reduce the pain...). I think this is what entity frameworks were not invented for. How you deal with it?

[Ben Beaumont]

I wouldn't use an entity for UI elements as they are not part of the game world. An approach Ive used before is to have a system - say the collision system - perform all its calculations and increment a ScoreComponent value. Then at the end of the collision system loop, or in a different system, update a ScoreModel only if the value has changed. This in turn updates a label in a View.

In a way I can think of Systems as being a bit like Commands/Controller in MVC - they contain logic that manipulates data, which then updates properties in model.

[Richard]

I've used two methods before...

1. Make the UI object an entity. Update it as part of the game loop. Render it using the standard render system of your game. If appropriate, use flags to know when it needs updating. Along the lines you're thinking. This is what I did in Stick Tennis. I wasn't sure it would work when I started, but it turned out rather well. Benefits - you can layer the text within the game scene, you can use the game engine to drive animations and other time based effects in the display.

2. Use an event bus - a shared event dispatcher instance - for the game to communicate changes to the world outside it. Any system in the game can send events down the bus (e.g. eventBus.dispatch( new ScoreEvent( ScoreEvent.CHANGED, score ) ) and objects outside of the game can listen for these events. The code outside the game follows whatever pattern you want to use, so may use the score changed event to update the model, for example, or to draw the new score directly on screen, without maintaining any model. Whatever you wish. Benefits - you can use any UI code architecture independent of Ash.

Richard

[Neal Delfeld]

Thanks for posting this.  I have been asking for a few more details on using Ash for a while, and there is not much information out there. 

Also, this Google group does not show up in the Google search results -- which doesn't make too much sense -- so any significant advancements made here should probably be posted on someone's blog as well. 

[Richard]

Yes, I've got half a dozen topics for blog posts that I haven't had time to write yet. But I think the best way to illustrate UI integration is first to add a UI to the demo project. A blog post can come after that, using the project as an example. Maybe one day soon.

[Maciek]

Thanks for all comments. Now I see that my current approach have right direction. I look forward to see the ui-extended demo project.