Custom Overlay Entities Only On Certain Scenes, ex: isRestartable

[Dead Duck]

Yo!

So only reason I was cycling through the demo's game scenes quickly before was so I could watch the overlay in action better.  

What's the best way to show things on the overlay for some scenes but not for others(logo, restart button, ect)?  The smoothest way I've found so far is adding isRestartable in my AScene.hx and checking that bool in Overlay.hx's hideButtons()(which was smooth and quick), but in order to do that I had to switch lines 117/118 with each other in ScenesManager.hx otherwise scene was null in hideButtons.  The official overlay buttons visibility looks like they're determined in the ScenesManager but that looks really complicated to extend and I read was only to be done in fringe cases.  hideButtons() seems perfect for it(even tho its technically showing buttons also) but when it's naturally called, scene is null(by one line grrr).  Is the fringe case of extending kernel/scenemanager the proper way, and if not what is? Thx!

  

[Rob Fell]

In this scenario I'd suggest having Scene call Overlay (rather than the reverse).

Options include (in order of how sensible I think they are):

1) use EOverlayButton.SUB_TYPE to communicate with the existing methods - e.g: showButton( SUB_TYPE( "logo" ) );

2) extend Overlay with new explicit public methods and cast - e.g: showLogo( true );

3) Don't use Overlay for this at all, and have a "Logo" Entity at the top of each Scene's view stack

4) Add "Logo" View (or "Logo" Entity via casting) directly to Overlay from anywhere at any time

5) Have different Agendas in Overlay showing different "Logo" configurations in each state, then change with setAgenda()

 

Those options that require casting are italicised - your call on whether that's a problem to your code's lifespan or not!

[Dead Duck]

Ah ok thanks!  It's obvious now that you went through all the options.  My mind was stubborn and thought to do it all in Overlay.  And before you said casting, I was scratching my head with the error message from IOverlay sent when I tried to call custom public functions in it from elsewhere.  Even tho it was right infront of me the whole time with some things being cast in AScene.  I'm using options 1 and 2, even tho 1 would just do very nicely with no casting.  Only reason I'm using option 2 also is so I can just have one line referencing overlay in my AScene instead of 2(for 2 showButtons).  In the future I"ll probably just stick to option 1 unless there's a ton of objects on the Overlay and I don't want to clutter up AScene.   showButton() from option 1 really makes it simple, and casting from option 2 really allows for anything.  Maybe in the future using Overlay also sort of as a HUD, if there's different scenes and don't want the HUD to disappear or take part in a scene transitions effects.  I'm not sure if thats what its intended use is or if there would be a better option or not but maybe what I'd end up using it for ^.^.  It's really just aesthetics at that point like having Gold # blur or not during a scene transition... ohhh those tough decisions that player wont even notice.

I thought of 3 but also thought maybe in future the border/chrome would be on top of the scene, and I might want logo or other buttons on top of a giant border/chrome.  Even the top of a scene's view stack is still behind overlay correct?

I've come across Agendas in some of the demos but I have avoided it for now.  I guess it has now jumped several spots up on my todo list.

Thank you sir for your thorough answers!!

[Rob Fell]

 

Great.  Btw I rarely use Agendas in real world projects.  Nobody else has mentioned them much either.  It seems they were one of the design choices that made sense at an architecture level, but rarely fit a real world need.  I guess they are "at risk" in awe6 v 3, so if you can find a way of doing things without them it is probably wisest to avoid them.  I'd put Messages on the "at risk" list too.  Of course I will poll before any major public API changes are made.

 

 

I have always kept HUD as a child of Game Scene and accepted SceneTransition will blur / modify "Gold#".

 

For a persistent HUD that is above SceneTransition consider option 4: adding a HudEntity to Overlay (from within Overlay).  This avoids casting because AOverlay extends Entity (whereas does not publicly implement IEntityCollection for external Entity addition).

 

HudEntity can then be publicly controlled via options 1 or 2 (no-casting or casting).

 

Advanced topic ... if wanting multiple Scenes inside of "Game", because awe6 avoids statics completely, there's no reason why a Scene or Entity can't contain a self contained SceneManager, or even an entirely new Factory + Kernel etc!  Lots of recursive options ...