Building in-game UI

[theoutlander]

I'm working on a game with a fairly complex UI. I was wondering about best practices to build an in-game UI.

 

Should I use Phaser to build the UI constructs in the canvas or surround the canvas with raw HTML to simplify things?

 

Are there any plugins for building UI's like a dashboard / console / command station type of UI elements? Thanks!

[romualdr]

You basicly have 3 ways to do UI :

• In canvas with Phaser
• Separate HTML / actual game (think like you have a router where #/menu displays only HTML and helps prepare initial state, then #/game who load Phaser with configuration from Menu)
• A mix of Canvas / HTML (difference with previous method, your UI is printed over your canvas / Phaser game)

To me, it really depends on your game needs.
 

As Phaser doesn't include UI, you will have to create by yourself some UI and controls. This can be painful for infinite lists or special things like this. If you need that kind of feature, i think you should go for sepearate HTML / canvas UI. You can have some basic UI on canvas too (like a health bar) but for pre-game configuration, go for HTML. Then load a page where JS script create canvas and load actual Phaser game.

If you don't need fancy controls or complex menu features, i would go for full canvas. Two buttons and a highscore feature for exemple can be easily done full canvas.

I would discourage last option, i built my first game like that (HTML over running canvas game) and syncing states between HTML / Game can be really hard if your game architecture wasn't designed for it.

BUT, it can be really powerful if you have the skill to do it.

IMO, a separate HTML / canvas is a good alternative if you need complex UI and don't want to bother with Canvas / HTML overlap and state syncing. If not, go for full canvas.

PS: I heard a lot of people using http://www.zebkit.com/ for their UI (in canvas) as it provides basic UI controls, never tried it though.

EDIT: I just thought about scaling too ! It's easier to scale game and UI if it's full canvas. On a mix or separate HTML / canvas UI, you still have to make your HTML scalable AND your canvas game as well.

[MattMcFarland]

Hmm tough call!  I don't think that using html instead of canvas causes scale issues though.  I guess that depends on your skill level though, if you're pretty good with HTML and front-end frameworks you shouldn't run into any issues, especially if you separate the concerns which is a good practice anyway and scales better than a monolithic app any day.

 

There are definitely good use cases for using canvas instead of html for UI (and vice versa) - may I ask what made you wonder which one to use??  What type of UI elements are you creating?   

[WombatTurkey]

This is basically how I have mine set up:

 

 

Set some div's outside of your main canvas window and use the dom for ui.

 

This seems like the best thing to do and it's fine as canvas is mostly unaffected by the dom css transitions (when moving around), although don't go overboard.

 

Edit: And creating your own UI in canvas is like the same logic as... creating HTML from scratch, it will take forever and just not worth it when dom is fine atm

[JakeCake]

Just wanted to drop my opinion here, as it seem like you have come to a conclusion that I am entirely against.

 

 

Anything related to the game should in my world stay inside Phaser's canvas, and this is for a bunch of reasons:

• Publishing to a game website. You will most likely be able to publish a canvas game or a flash game, but their system will almost certainly not enable you to publish a bunch of HTML.
• Publishing to mobile. Wave farewell to Canvas+ on Cocoon, hence a performance lose. This is because the DOM, besides the canvas element has been stripped away to maximize performance.
• Performance generally. The canvas, at least in WebGL mode, is faster at rendering graphics that is updated each frame than the DOM is.
• ​Unnecessary redrawing of the entire DOM is expensive. If you update anything on the DOM, you might - often depending on the browser - run into a scenario where the browser will have to redraw the DOM because something changed. Say you add a 1px border on hover on something on your GUI, then everything beneath it is pushed down 2px and everything has to be drawn again. This may give very high lack spikes depending on what's on your site and how complex that GUI is going to be.

I could probably go on for a while, but it's not entirely black and white, as there are of cause pluses to using the DOM for UI as well, but I think they are heavily outweighed. While the "don't reinvent the wheel" is always a good point, just remember that HTML was not meant to create game UIs, it was meant for mostly static websites. The canvas on the other hand was meant exactly for this kind of stuff, so use it.

 

I would love to point you somewhere where we can share our Phaser UI modules, but I don't know if such site exists. It would be awesome though

 

If you're good at constructing JavaScript and know basic programming far enough to extend classes and such, then creating the UI in game with Anchor-points, events and stuff is not a big deal. Phaser even has the Button class built in I believe, you can just extend that for the rest of the components.

[ForgeableSum]

• ​Unnecessary redrawing of the entire DOM is expensive. If you update anything on the DOM, you might - often depending on the browser - run into a scenario where the browser will have to redraw the DOM because something changed. Say you add a 1px border on hover on something on your GUI, then everything beneath it is pushed down 2px and everything has to be drawn again. This may give very high lack spikes depending on what's on your site and how complex that GUI is going to be.

 

I don't think this is an accurate description of what happens to the dom when it's altered with javascript. The dom isn't "drawn" in the sense that objects inside the canvas are drawn.