2
\$\begingroup\$

I'm in the middle of separating logic and drawing of a 2D game, i.e. I'm moving from scenes/entities that draw themselves to scenes/entities that merely store and update data, getting drawn by a renderer.

This works pretty well for scenes and entities, but I can't figure out how the UI fits in. Right now, I draw widgets in the draw routines of some scenes. Scenes can currently also handle input, so it's relatively close to how UI toolkits do things. There are even scenes with nothing but UI, e.g. the main menu. But with the new approach where scenes don't draw themselves anymore, I need a new approach.

How could I do this? Are widgets even supposed to live in scenes, alongside entities? Or should they be in their own kind of scene, e.g. windows or dialogs?

\$\endgroup\$
3
  • 1
    \$\begingroup\$ This is kind of a subjective question. But WoW has UI on top of everything. And scene is rendered as background of one of the windows. \$\endgroup\$
    – Kikaimaru
    Jan 3, 2014 at 23:34
  • \$\begingroup\$ @Kikaimaru What, really? The game part of WoW is basically just a "scene window"? That surprises me. \$\endgroup\$
    – futlib
    Jan 4, 2014 at 0:46
  • 1
    \$\begingroup\$ wowwiki.com/UIOBJECT_WorldFrame Yes they called it WorldFrame. \$\endgroup\$
    – Kikaimaru
    Jan 4, 2014 at 2:02

2 Answers 2

1
\$\begingroup\$

It varies.

Many games have completely separate UI systems that don't use game objects at all.

Using game objects and components for widgets does make some sense, though you should still definitely have a separate hierarchy of UI elements outside of the game scene itself that walks the element tree and renders appropriately.

Note that aside from input, UI is just 2D rendering. It's quite feasible to allow any 3D object to have a 2D widget object hierarchy attached to it which renders into a buffer and then which is displayed on the 3D object as a texture. This can be used for in-game computer terminals, floating partially-3D HUDs (like in Dead Space), or so on. You can also then have special "fullscreen roots" to a 2D hierarchy to use for an overlay HUD or main menu.

The neat thing about integrating your UI widgets into your in-game objects is that you can use other components in your UI. For instance, you could attach a 2D physics components, or allow drag-and-drop of 3D objects onto 2D receptacles, or let your engine be trivially used for both pure 2D games and 3D games.

The rendering of the 2D nodes should - just like regular game object rendering - be handle by a separate render graph in either case, though. Especially for UI. UI is often made of a great many little tiny sprites and the like; having each object in that hierarchy draw itself is terrible for performance.

\$\endgroup\$
4
  • \$\begingroup\$ I've stressed above that I'm talking about a 2D game, I guess that simplifies this discussion quite a bit. So if I get that right, you suggest I render the UI onto game objects? So my menu would be a scene with a single entity that's basically a "window" and contains widgets? \$\endgroup\$
    – futlib
    Jan 4, 2014 at 0:51
  • \$\begingroup\$ Sure, with the "widgets" themselves being child game objects. I don't know if I'd say I "suggest" that, but it's a valid approach if you prefer to use game objects rather than a whole separate system. \$\endgroup\$ Jan 4, 2014 at 1:15
  • \$\begingroup\$ I'm really not sure what to use. It just seems kind of wrong to go with game objects here since widgets should be positioned in screen space, not world space, shouldn't have a velocity etc. I'd have to introduce a thin base class and another base class for "real" entities that actually interact with the game world. Doesn't feel right. But I don't know where else to put widgets, if not in a scene. \$\endgroup\$
    – futlib
    Jan 4, 2014 at 2:02
  • \$\begingroup\$ Thought about it some more and I think I'll just add widgets to my scene, a separate hierarchy. The main menu will then be a scene with only widgets and no entities. Still accepting your answer, since it makes some great points that just don't really apply to my game in particular. \$\endgroup\$
    – futlib
    Jan 5, 2014 at 3:45
1
\$\begingroup\$

For MOTES I had to completely develop a separate set of components for the user interface.

The thought crossed my mind that I could just use an orthogonal camera and ray-poly intersections to handle widgets, (because MOTES already features ray picking in the game), but I decided against that because point-in-rectangle is much more efficient than point-in-poly.

The underlying rendering subsystem is the same, but I branched my hierarchy roughly like so:

                   +----------------+
                   |   GameObject   |
                   | pos,vel,common props (verts, etc)|
                   +----------------+
                           ^     ^
                           |     |
                +-----------+   +------+
                + Touchable +   + Ship +
                + rect      +   +      +
                +-----------+   +------+

So there was some overlap in that each object has a position and a way to store its vertices and get rendered, so that part was shared.

So for that game, ships didn't need to be touchable, instead I placed an invisible touchable widget over the main window, and that intercepts touches and cast rays into the scene to pick things.

\$\endgroup\$
6
  • \$\begingroup\$ So how did you tackle fullscreen menus? Are all items GameObjects? Doesn't it seem weird that widgets have a position in world space, a velocity etc.? \$\endgroup\$
    – futlib
    Jan 4, 2014 at 0:52
  • \$\begingroup\$ I put screenfuls of Touchables in containers called Panels. (That's where this question came from). Multiple Panels can be overlaid on top of each other and they can each "transition in" and "transition out". Each menu screen is placed in a separate Panel. The ship dash controls and HUD are distinct panels as well. \$\endgroup\$
    – bobobobo
    Jan 4, 2014 at 0:57
  • \$\begingroup\$ Widgets are movable. There is an interface where widgets can be dragged. They also slide in, (messages from the top), so most of the props in the base class get used. \$\endgroup\$
    – bobobobo
    Jan 4, 2014 at 0:58
  • \$\begingroup\$ So, for a HUD, you simply keep updating the position of the touchables as the ship moves to have them stick to their position? It'd work, but it feels wrong somehow. That said, this is not a UI heavy game, maybe it's just fine. \$\endgroup\$
    – futlib
    Jan 4, 2014 at 2:04
  • \$\begingroup\$ I didn't implement say, text that can map to a 3d point. But if you wanted to, it would be a fairly simple projection (from 3-space, to a point on screen). You could then have the touchable track that point. \$\endgroup\$
    – bobobobo
    Jan 4, 2014 at 2:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .