View Full Version : Entities and UI

09-28-2011, 06:54 PM
Your examples with UI screens are fairly static (C functions, no Entity or Component inherited classes for each screen). I'm curious if that's how you author your games? I run into situations in many of my screens where I'd like to have base layout functions and private pointers to individual Entities for efficiency.

* Keeping static pointers for this just seems messy
* Calling GetParent()->GetParent()->GetParent() is also messy
* GetEntityByName("redundant string in code") can be inefficient because it searches recursively through a list (not a hashtable)

What do you do to get around these annoyances? I'm inclined to create AppUIComponent (inherits from EntityComponent) and [MainMenu, AboutMenu]Component child classes which all hold their own Entity member variables... but I know that polymorphism is something we're trying to avoid with a component-based engine.

Your thoughts?

09-28-2011, 10:11 PM
I tend to use GetEntityRoot()->GetEntityByName("redundant string in code") a lot. :sweatdrop::sweatdrop: (The compiler will notice duplicate const strings like that and optimize them to one in the final binary)

I figure if this uses on average 100 operations to find the Entity in a game doing 500,000 operations a frame, this just isn't enough to care about it, especially not for things like a main menu. An under-the-hood manager could be added for hashed entity name lookups but I'm not convinced it's needed for normal usage. I'd profile before worrying about that.

In my Proton stuff I don't have any classes that house menus, the menu is more like a generic chunk of clay that gets molded by static functions. I house variables I need inside of entities or components. If you play any of my Proton games (Dungeon Scroll, Tanked, Dink Smallwood, etc) and see a menu you are curious about the code to let me know and I'll post it.

Not to say adding a AppUIComponent etc is a bad idea, just not how I've done it. It would even be possible to put each menu into its own tree, not even part of GetEntityRoot(), there is nothing in Proton that forces everything to even be in the same hierarchy. But my brain is hurting just thinking about that :wheelchair: