Blog


Thoughts on Gamedev UI – or why I think layouts and tables suck July 11, 2015

I was thinking about UI. a lot. On how we do it now, and what can be done better.
As I work on Overlap2D, UI kinda matters for me.

Because it’s a topic worth debating about, I made a blogpost, and also put it up on reddit
to get some opinions on this matter. It’s going to be a long post though, so bring up popcorn.

In particular we are going to talk about how we make UI for video games. Not websites or enterprise software,
but Games. As there is a difference in what game developer needs more frequently compared to others.

And just to clarify, when we say Game UI, we usually mean things like: Main menu, dialogs, buttons, progress bars, scroll bars, inventory tables, hud’s and so on.

There are many ways people approach making UI:

a) Absolute Positioning – The most terrible and obviously unpopular
Pros:
1) Easy to make, just put things up where you want them to be.
2) Things don’t end up where you didn’t plan, and behavior is very predictable.
Cons:
1) Not good for when you don’t know the size of your container (Screen or other). Which results in inability to resize without stretching, and to support multiple screen aspect ratios. (terrible for mobile games)

b) Relative Layouts and Tables – current most popular.
This method includes doing most of things with list and tables. That resize to their parent. Aligning things and such.
Pros:
1) Works great for any aspect ratio or screen or container (big plus)
Cons:
1) Time consuming – you have to setup an entire layout hierarchy.
2) Unpredictable – while mostly things end up the way they should, in real life it takes hours of tweaking and trying to understand why this thing ended up on top of the other. In short – there is no way to describe to layout “exactly what you want” it usually takes several trial and error iterations, and building up a good intuition. I experienced it. You experienced it. While it seems that most problems come from not
understanding well the UI system, it actually is more deeper then that.

For me the main problem of this system is the – domino effect. So many things are depending on each other, that if you move just one
it all falls apart. Tables changing their row widths depending on content, that changes entire table size, that changes other in table item positions and so on. Yes sometimes you want exactly that. But in MOST cases you don’t. And in my opinion UI system should work well with things that are common, saving up on precious developer time.

I Also noticed so many people using tables, where they are not necessary. The most common one is “the form” case.
You know when you have to make this “form” for user to fill. ask for login and password. First row goes for login, and second for password.
left column for label, and right column for input boxes. We already talk in rows and columns It just so makes perfect sense to
put it up in 2×2 table right? WRONG. Think about it. What you actually try to achieve is to have an imaginary central line,
labels on the left, input boxes on the right. that’s it, no other fancy table self aligning/resizing functionality is required here.
Yet so many of us end up making tables for this simple scenario, suffering the side effects and wasting time.

As a matter of fact, the only case where table is actually really required, is a grid views with dynamic content – see things like inventory and such. In most cases. your UI content is not dynamic. But container size is. So how can we better serve the “most cases”

The Alternative
(While previous was just an observation of current reality, what goes next is completely made up and could be plain stupid. I warned ya :-P):

The alternative should be an approach that takes pros from both previous approaches, and tries to avoid cons. Obviously.
Take some good ideas from “web world”, a bit from absolute positioning, and a bit from layouts.

Here are some core base rules:

  1. UI is hierarchical, it has containers that have containers inside, then they finally have items.
  2. Sizes of items (including container items) is either based on their parent container size (percents), or is fixed.
  3. Positions can be magnetized directly to any side of container
  4. Positions can be aligned relative to container
  5. Positions can be also offset from their current position by fixed size.

That’s all. This should be enough to visually describe almost any UI situation. Having things positioned in predictable manner,
While still keeping the rubber logic for different container sizes.

The following rules can be made into so called “mutators” that are set to an item, and apply to it in a set order on every iteration.
(example: width 50%, magnet to horizontal center with right edge, offset left by 10 pixels)

With this method. You can make up very responsive widgets like progress bars and buttons.
While keeping practical process similar to absolute positioning. As in: you will be just drag and dropping things. It will result
in “mutator list” that apply to items, and make them be where they have to be, no matter the container size.

Based on this it is possible to make a data structure to save. and a editing environment to easily build.

Let me know what you guys think in the comments. I am trying to figure out if this all makes sense or not, and would love to actively participate in discussion :)

Thanks for reading till the end. Means you care.

  • I’m OK with new positioning approach. But I would like to point out that we shouldn’t abandon libGDX UI completely because there is active development in community. Especially Nate is constantly polishing things here and there as Spine is using the framework in their UI. Everybody can benefit from pull requests then.