Overlays / UI

[bu...@itswright.com]

Looking for some best practices / advice again with melon... in a melon game, building a series of interfaces that pop up over the current state / screen (I want that state to continue updating, no problem there, etc)...

I'm creating this overlays -- such as an inventory UI, as extensions to which melon object? Originally I thought, well easy... me.Container. But as I'm doing most of the interface with HTML markup / CSS added to the DOM... is there really a need to use me.Container, or any other class? Should I simply use me.Object so I can get the "init" as an easy access point to the UI classes?

I don't really think these are "HUD" classes / UI... think RPG when you pull up several layers of menus/UI such as your character, then inventory, spellbook, etc.

(I tried searching here first for info, but I admit I have a hard time discerning what's still valid with the newer versions of melon, etc.)

Thanks for the input ahead of time! Everything I'm already doing WORKS by having HTML templates / CSS and using jQuery to simply clone and display it with the relative data... I'm just wondering if it's best practice with melon! (Thus far, I don't need draw/update functionality, but that could be one reason to eventually use a melon class, though I suspect in that case in one of these generic UI classes, it's a simply matter of creating a class inheriting Renderable or something like that and adding that to the me.game.world container, etc...)

[aaron.g...@gmail.com]

I think using html & css overtop of your game is fine. If the user cannot see the gameplay while the UI is showing/obstructing the view, it's probably worth while pausing it, so you have better UX. It's also worth noting that DOM operations do tend to be slow. Showing, hiding and animation UI elements themselves shouldnt be too bad. But updating a DOM hud for example with score & or accumulating resources, or whatever have the potential to be slow. We noticed that at work actually with React components and removed them from any screens that had a canvas with real time animations. Note that react components are a fair bit heavier than just calling el.innerHTML = 'Score: 100'; But it's something to keep in mind. Can always try it, and benchmark it to see.

[Jay Oster]

IMHO, Use HTML for GUI elements like buttons, check boxes, drop down lists, scrolling panes, etc. Use the canvas for anything that needs 60fps animations.

[bu...@itswright.com]

Thanks for the tips!

[bu...@itswright.com]

Darn... something I didn't think about using HTML overlays / DOM elements...

If I do then want to add say, an me.Entity or me.Renderable, to these overlays, they will appear under the HTML DOM element, since these are drawn to the canvas underneath, of course...

I don't suppose there's a way around that, other than creating the entity as another HTML DOM element and separately coding that (i.e., CSS animation, etc)... that 'works', but you lose any of the logic of the class you created for those entities, too...

Any ideas?

[Jay Oster]

You shouldn't be drawing animations on top of your GUI elements. ;) GUI elements are things like checkboxes and text input fields. There's no point in putting a giant div layer over top of your canvas and then trying to get parts of the canvas to shine through the div. But you can still integrate the GUI elements into the game convincingly, regardless.

[bu...@itswright.com]

I hear you, but let me run a scenario past you; you're playing an RPG, and you press a key to bring up your party screen -- say you can have 4 party members. Next to their names, stats, etc, you want to show their avatars, which you already have nice me.Entity-derived classes for.

This should all sit in an overlay sort of box (div), and with CSS, it's easy to do a little opacity in there to still show part of the game underneath just for aesthetics. But then, like you said, you really can't 'poke a hole' in your div to show canvas items through... and underneath it all in your scene, you still have all those party members in the actual game world, etc...

But now you also want to show them in your GUI... does that make any sense? Or at least, more sense? :)

I might be asking too much out of typical melonjs boundaries... in a traditional game outside of the web, they likely create all these GUI elements as renderables in the canvas/frame, right? And then there's really not this kind of issue at play?

[bu...@itswright.com]

I mean... I do have the spritesheets, and I could simply recreate the sprites in the GUI via CSS / DOM elements. I was just wondering if there was another alternative, if I was going about this all wrong, or if you could have multiple canvas elements (the others being on top of the GUI, etc), etc...

Fun stuff! ;)

[aaron.g...@gmail.com]

That is precisely how you do it. The game im working on for my full time job, are game is built react, using single page app patterns with react router. So #/battles/:uuid will load a react component that bootstraps the canvas and loads pixi. There are a number of assets we share in the canvas section with other parts of the game. The key is to share either your loader or at least your asset resources object with different parts of the code.

[bu...@itswright.com]

Sorry, Aaron -- do you mean that you guys use CSS spritesheets, or multiple canvas elements?

[aaron.g...@gmail.com]

We do use some sprite atlasses, but none of those are used in CSS. The main images shared across both right now are separate images, not atlased together. Our backend is using rails, so we have a clientside js helper for resolving assets from the server. We run that to resolve a given asset name. We name our images based on our id system. So if a sprite is called r1BattleEpicNess, the image will sit under assets/images/sprites/r1BattleEpicNess/100x100/1x.png and so on. We have different resolutions, as we use different sizes for different pages.

When the canvas is the main renderer, we have almost no html UI over top. There are some cases where we do, but they're simple buttons. We never instantiate a new canvas at all, we have one canvas tag that persists in the DOM. We use the gl.flush() method to ensure data gets cleaned up when we're done, but keep it around, as it's more expensive to re-create it. We just resolve the image, load it into our renderer, or an image tag, or it's referenced in css.

I would recommend the same thing here. Use the resources array to look up the image you need, and load it as an image tag inside html.

[Jay Oster]

Most of it sounds like it could be built in the canvas. The more complex elements like text fields and drop downs can be HTML, since they already have well-understood mechanics in mobile environments that you get for free. And they are just plain difficult to get right when rolling your own.

But things like a little translucent layer with animated icons and some text to show character stats or whatever is usually built as a handful of melonJS objects. (And FWIW, you control the HTML elements with melonJS objects, too.)