As part of my ongoing C++/OpenGL hobby project to develop a (free) game, engine and tools, I am beginning to develop the HUD (Heads Up Display) editing tool.  Aside from delivering a game, one of my primary objectives is to encourage creativity by providing tools that allow gamers (i.e. non-programmers) to customise the game in numerous ways, from simply building new levels, all the way to modifying the game mechanics and importing their own assets (models, textures, sounds, etc.).  A part of such customisation is allowing a user to design their own HUD.

Please bare in mind that I'm not creating a World of Warcraft HUD or anything complex like that; this is just a hobby project for arcade style games, so I'd like to keep things relatively simple..

So here's a summary of what the HUD editor will need to be capable of:

• WYSIWYG viewing and editing of the game's HUD layout.
• Adding components to the screen.  There are several different types of HUD components, such as panels, icons, decorations, and values (such as scores, item counts, time remaining, etc.).
• Deleting components.
• Arranging the layout of components, such as moving and resizing components.  It would be nice to have features to make such editing easier/quicker, e.g. grouping related components.
• Arranging the order of components from front to back.
• Specifying properties of each component (e.g. fonts, colours, value to show).  I guess it also might be useful to be able to view and edit properties of the component layout directly too?
• Define how the layout reacts to different screen aspect ratios.  I think this is the most tricky part.  One of my goals is for the HUD to gracefully handle different aspect ratios like widescreen (TV/PC) and portrait (phone/tablet), so I think it would be nice if the user could a design HUD that could dynamically accommodate any arbitrary aspect ratio.  So rather than say "if 16:9 use layout A, else if 9:16 use layout B", etc. or just stretching a layout to fit an unexpected aspect ratio (thus distorting text, images, dimensions, etc.), the HUD should look as nice as reasonably possible when a user decides to do something crazy like running the game in a 32:9 resolution.

Here are my design ideas so far:

• Viewing the HUD:  The HUD is displayed at 100% by default.  The HUD can be panned by left-click and dragging anywhere not on a component.  The HUD can be zoomed in and out using the mouse wheel.  Selecting "Reset View" from the "View" menu resets the view to the default.
• Adding components:  There is an expandable panel showing the various component types that can be added.  The user drags a component he wants to the screen.  A new component of that type is created and placed on the screen.
• Selecting components:  The user can click a component to select it.  The selected component is highlighted.  One thing that always annoys me in other apps is being unable to select a component that is behind another one.  So I had the idea of holding Control while clicking to select the component that is behind the currently selected one (thus, you could do this multiple times to get to the component that is furthest back).
• Deleting components:  Pressing the 'Delete' key deletes the selected component (alternative:  Select "Delete" from "Edit" menu or right-click context menu).
• Moving components:  The user can left click and drag to move a component.  Movement snaps to a visible grid.
• Resizing components:  Eight "Edit Handles" appear on a selected component as small squares.  Edit Handles on the edge of a component can be dragged to resize the component in one direction.  Edit Handles on the corner of a component can be dragged to resize the component in two directions.
• Ordering components:  Like MS Office and other apps.  Right-click, context menu, "Move Forward", "Move Backward", "Bring to Front", "Send to Back".  Affects the selected component.
• Component properties:  An expandable VB-style property panel shows properties of the selected component.  Properties can be specified via usual means (e.g. text fields, number fields, check-boxes, drop-down lists, and so on).  For resources like Fonts, Colours, Textures, Models, Values, etc.. the engine already has support for these things, so it should be easy to support them as properties in a generic way.  I already started developing a property sheet for the game objects, so I think I will reuse that one for the HUD components too.
• Linking components to the screen:  To accommodate changes in aspect ratio, rather than laying out the HUD entirely relative to the screen, I had the idea of supporting a mix of relative and absolute values.  So for example, the user can place a square score icon in the top-left corner of the screen with an equal distance from the left and top.  If the game is played on a different aspect ratio, the icon remains square (not stretched), and the distances between the left and top of the screen remain equal.  For this, I thought of perhaps middle-click dragging a component to a screen edge or corner, but I'm not really sure if that's the best way to accomplish this, since I don't recall encountering middle-click drag in other apps before.
• Linking components to other components:  Following the previous point, let's say you want to place the score component adjacent to the score icon.  You could middle-click and drag your score component to the right edge of the score icon to attach it, like before with the screen.  Then you just need to resize the width and perhaps offset the component slightly from the icon (in case you want a small gap between the two components).  The trick here is that the offset and width are both absolute, so a change in aspect ratio won't throw the component out of whack.
• Copy and Paste Components:  I think users will expect standard features like this to be supported.  Standard procedure:  "Edit" menu or context menu.
• Undo/Redo:  Same again.  I think users will reasonably expect all of the above actions to be undoable.  Standard procedure again:  "Edit" menu or context menu.

This is what I have so far.  I'd be interested to hear from others who have tackled this problem and how they approached it, or just anyone who has any ideas on the subject.  I'm especially interested in how to handle the problem of variable aspect ratios and screen resolutions, but any insights into designing an intuitive and efficient editor for video game HUD's would be great!

Cheers!

I think you covered well what you want to offer. Let me talk about how you could offer it.

For a game, I would start by limiting and defining clearly which components can be added and what they do, or else you would end with a generic UI/HUD editor. List what components you want the player to be able to add and what they do, and program accordingly. As I understood, each one will only act in only aspect, so it doesn't seem too hard to list that

Right now, on a project, I'm trying something similar, but for a development tool only. It's a small 2D engine. This article helped me to understand some things about UI design. Some things that helped me:

•  make UI scaling relative, but independent of resolution. Define a "base unit size", (which changes with the resolution), and a "base resolution" (which does not change with the resolution), and have the components be sized based on this base unit. This unit need to be based on a certain base resolution, and you need it to scale only with width or height of the screen resolution (height is better, as it is generally smaller). So, if a component is 10pt tall and 100pt wide , and your base unit is 1px for 1280x720 base resolution, when scaled to 1920x1080 the base unit will be 1.77pt, and the component will now be 17x170px (I generally round it down to integers). The underlying system will need a callback for the change on the screen resolution, so you can change the base unit when the resolution changes;
•  have a layout management option, and allow components to be placed relative to the screen and other components (I call this "anchoring" in my project). For example, if a component is aligned "left", and its X position is 10pt, that means it is 10px far from the left side of the screen (using the base resolution above). If the resolution changes, the X changes also (to 17px, in this example), so the position keeps relatively constant to the screen. It's way better than fixed/absolute positioning. In my case, this is intended to keep the UI controls inside of the screen. So, if I use "right" alignment, and a component has a width of 50 and a X position of 20, his final position is the screen width minus 70. The X position is the offset from the screen;
•  check other tools and engines and see what they're doing. That helped me to decide to use a parenting approach to certains components, and relative positioning. So, for example, if you have a TextComponent (with only display texts, nothing else) and you need a ButtonComponent (which can have a text or image inside), the button does not have a "internal text" property. Instead, it has a TextComponent as a child component, and the TextComponent position is relative (a simple offset of X and Y, based on the anchoring method I described above). For simplistic reasons, I use a parent for each component, so they can get its parent position directly.

Right now, my UI tool is not WYSIWYG, so no things like selection and moving components. I don't know it these techniques have names, bu they probably do, and should be easy to search for them.

Thanks for the input!

Regarding component types, I'm currently only focussing on the types that I actually need for the game I'm currently developing.  The requirements for that are pretty simple; just to show text/numbers, icons and panels.  More component types can be added later.  The engine also supports a plugin framework, so it's possible to add more component types without recompiling the base project.

With regards to UI scaling, my current approach has been to define the vertical space of the screen as -1.0 (bottom) to +1.0 (top).  The horizontal space is then defined relative to the vertical distance based on aspect ratio, for example

• 4:3 = -1.333 (left) to +1.333 (right)
• 16:9 = -1.777 (left) to +1.777 (right)
• 9:16 = -0.5625 (left) to +0.5625 (right)

In this approach, (0.0, 0.0) always represents the center of the screen.  The problem is that while the heights always stay fixed regardless of aspect ratio, the widths and horizontal distances between components can change.  So for example, if I anchor components to the two top corners of the screen, each with a width of 0.4, there is a gap of 2.756 between them on a 16:9 screen, but on a 9:16 portrait display, the components get pushed much closer together, so the gap is only 0.325 in that case.  For that reason, I'd like to be able to somehow have the components scale to become smaller as the screen becomes more vertical.  On the other hand, I don't want the components doubling in size if someone decides to run the game in 32:9.  Maybe I'm just over-thinking this.

Everything else you've described (layout, anchoring, etc.) sounds similar to what I already had in mind, although your terminology and explanations are better than mine (not sure why I didn't think of using the term "anchoring" for example).

Anyway, the topic was more about functional design rather than technical implementation.  I'm really interested in what kind of functionality people expect in such an editor; what kind of features would be intuitive and what to avoid.

I do have some experience in designing and developing similar tools, but it wasn't a video game related project, and the resolution and aspect ratio was typically known beforehand.  Also, this past project was based on Java, whereas now I'm developing my tools in pure OpenGL.  I'm not using any GUI toolkits like QT, GTK, etc., so any components like dialogs, text fields, combo boxes, etc. are being developed in pure OpenGL as required.

Ideally, I'd like the end result to be something that wouldn't look or feel too out of place if running on a games console.  So it would be something more along the lines of say, LittleBigPlanet rather than something like Unity.

I'm not really sure if I'm heading in the right direction for that though considering what I already have at the moment is pretty heavily mouse-based, with conventional GUI components like menus, dialogs, etc.  This might be something I need to look into more detail later, and just focus on finishing what I have for now.

On 01/02/2018 at 7:23 AM, Martin Brentnall said:

For that reason, I'd like to be able to somehow have the components scale to become smaller as the screen becomes more vertical.  On the other hand, I don't want the components doubling in size if someone decides to run the game in 32:9.  Maybe I'm just over-thinking this.

Maybe overthinking a bit, yes. But what you can try is do the scaling using the smaller ratio, not just height (which is normally the smaller one, but it's no always the case, as you point). That way, if the screen is vertically bigger than horizontally, your UI will adjust by width, not height.

On 01/02/2018 at 7:23 AM, Martin Brentnall said:

Anyway, the topic was more about functional design rather than technical implementation.  I'm really interested in what kind of functionality people expect in such an editor; what kind of features would be intuitive and what to avoid

On 01/02/2018 at 7:23 AM, Martin Brentnall said:

Ideally, I'd like the end result to be something that wouldn't look or feel too out of place if running on a games console.  So it would be something more along the lines of say, LittleBigPlanet rather than something like Unity.

Well, you have good references. Look what these games offer, check other games like Mario Maker, or even simulators like SimCity and Cities: Skilines, which rely heavily on editors.

In general, I think you're in a good direction. Better feedback would require a some screenshots or a working prototype, but try some things before it. Make the tool good enough for you, and then show other people and see have they like and what they struggle with. Get theyr feedback directly, as it can be faster.