Do you build your UI's in MelonJS or DOM?

[Ian_]

Hey everyone,

I see various games using the DOM for certain elements, I was wondering about peoples experience on this, I have a pretty complex HUD designed and feel it would be much easier to maintain and manage in the DOM and use events from the game to update the HUD. Would you suggest using the DOM or MelonJS? Advantages/downsides would be appreciated.

[Parasyte]

Simple elements like buttons can be implemented with the melonJS GUI_Button class. The advantages with this are immediate feedback (DOM click events have a delay on mobile devices), and they use the WebGL compositor (great for all-in-one über textures)

For more complex UIs, use the DOM. DOM should definitely be in your toolbelt for rich GUIs. The advantages are obvious, and there are very few disadvantages (more like just caveats). It's great for any form input fields, scrollable areas, etc. DOM also has the advantage that the text rendering is really fantastic, especially with web fonts, and certain character sets (CJK, RTL, etc)

One of the caveats you might run into is that by default all DOM elements consume pointer events. There are some useful CSS properties that can help you workaround it if needed: https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events and https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action

[Ian_]

22 minutes ago, Parasyte said:

Simple elements like buttons can be implemented with the melonJS GUI_Button class. The advantages with this are immediate feedback (DOM click events have a delay on mobile devices), and they use the WebGL compositor (great for all-in-one über textures)

For more complex UIs, use the DOM. DOM should definitely be in your toolbelt for rich GUIs. The advantages are obvious, and there are very few disadvantages (more like just caveats). It's great for any form input fields, scrollable areas, etc. DOM also has the advantage that the text rendering is really fantastic, especially with web fonts, and certain character sets (CJK, RTL, etc)

One of the caveats you might run into is that by default all DOM elements consume pointer events. There are some useful CSS properties that can help you workaround it if needed: https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events and https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action

Thank you very much, would you say the same about in game content such as a Quest Log, Health Bars on enemies, Inventory etc?

[Parasyte]

For a quest log, yes. For other bits of status GUI, no, probably not. You want to avoid moving DOM elements as much as possible, since that will cause the UA to reflow the DOM. Status bars are easy to render in melonJS, using either the canvas context drawing methods (like fillRect()) or by clipping a texture. Using the melonJS font classes are also pretty decent performance-wise (except when you want to update the text on every frame, that doesn't work well with the WebGL compositor).

[Ian_]

2 hours ago, Parasyte said:

For a quest log, yes. For other bits of status GUI, no, probably not. You want to avoid moving DOM elements as much as possible, since that will cause the UA to reflow the DOM. Status bars are easy to render in melonJS, using either the canvas context drawing methods (like fillRect()) or by clipping a texture. Using the melonJS font classes are also pretty decent performance-wise (except when you want to update the text on every frame, that doesn't work well with the WebGL compositor).

Good to know, thanks

[obiot]

I think another point is what device you are targeting, I mean if you target at some point to release your game through a wrapper (e.g. Cocoon) on the Apple Store or Android market, then you cannot rely on DOM for the UI ?

[TomC]

8 hours ago, obiot said:

I think another point is what device you are targeting, I mean if you target at some point to release your game through a wrapper (e.g. Cocoon) on the Apple Store or Android market, then you cannot rely on DOM for the UI ?

Nearly all html5 mobile wrappers support the DOM fine, even CocoonJS has WebView+ if you need to use the dom. 

It won't be too long until wrappers aren't needed and you can just use native web-views in ios/andorid anyway, and again the DOM is perfectly supported.

As @Parasyte was saying, you just need to choose the right tool for the right job, and DOM UI's do not like to be moved around the screen performance wise.

Also make sure you don't modify the DOM mid cycle, just pre create any DOM UI that isn't always in view and display: none; it with css until needed.

[Ian_]

1 hour ago, TomC said:

Nearly all html5 mobile wrappers support the DOM fine, even CocoonJS has WebView+ if you need to use the dom. 

It won't be too long until wrappers aren't needed and you can just use native web-views in ios/andorid anyway, and again the DOM is perfectly supported.

As @Parasyte was saying, you just need to choose the right tool for the right job, and DOM UI's do not like to be moved around the screen performance wise.

Also make sure you don't modify the DOM mid cycle, just pre create any DOM UI that isn't always in view and display: none; it with css until needed.

Interesting, my UI will be fine then in the DOM as it's static other than some css animations.With pre creating the DOM, my idea would be once the game loads, it would create a template then when they open the quest dialog and click a quest it fills in the quest info into the template, does that make sense? For example you may have 2 divs side by side, one that lists current quests, the right side would contain information from whichever quest is clicked

 

Open Questbook

Click Quest on the left panel

Performs a request to the server to get the quest

Pushes this information into the pre generated DOM content (Quest Window), it would purely be text replacement, though it may generate new divs for styling.

 

Would this be ok?

 

[TomC]

Yes @Ian_ that would be the general way to go about it.

There is always going to be some DOM manipulation required, and obviously you need to change the text, images etc. 

Just leave as much of it already rendered as possible and hide/show it as required.

[Ian_]

31 minutes ago, TomC said:

Yes @Ian_ that would be the general way to go about it.

There is always going to be some DOM manipulation required, and obviously you need to change the text, images etc. 

Just leave as much of it already rendered as possible and hide/show it as required.

Thank you