Bjorn Buchner has a very good article up at Gamasutra on design concepts for building user interfaces that respond dynamically to changes in gameplay context.

Not a lot of specific practical tips, but some excellent concepts for understanding when and how a UI can better fit into the world of a game while delivering control and information utility.

I think this is a good start on brainstorming about when do we need which UI elements where.

Do we need the crosshairs all the time?

Do we need the system status display all the time?

When we need a UI element, to which fidelity do we need it?
Do we need full blown system status wn its shown in combat or is a rough overview suffecient?

All good questions.

We tend to think in terms of of UI elements for specific screens or activities. But games are played as fluid movements in a real-time dance of information and control. So it makes sense to think of UI design in that way -- of visual elements that deliver what the player needs, when needed, and are otherwise unobtrusive, as gameplay shifts rapidly among many systems.

I'd start with: what UI elements are used by most of LT's game systems?

Flatfingers wrote:All good questions.

We tend to think in terms of of UI elements for specific screens or activities. But games are played as fluid movements in a real-time dance of information and control. So it makes sense to think of UI design in that way -- of visual elements that deliver what the player needs, when needed, and are otherwise unobtrusive, as gameplay shifts rapidly among many systems.

I'd start with: what UI elements are used by most of LT's game systems?

Good point. It makes me think of the old adage, "form follows function." It might be worth considering. UI elements would probably need to be categorized as to function. In other words, you would probably need to define exactly what uses would be involved, sort of a broad general outline of basic functions.

Also, UI can take on different forms, such as a HUD, or of a more textual sort, like system info etc. That being said, I think having many options as to what or how to display various UI elements, could be a critical aspect. For example, I have seen many an argument between people who like having a cockpit type view/HUD, and others who don't. Solution, have the ability for the player to choose which he wants to play with. Even having just one or two basic cockpit type views with the ability to choose whether to use it or not, could have a huge impact on how the game is reviewed once released.

My point is, that whatever path Josh chooses, I think that having many options in regards to what and how information is being displayed, will greatly enhance the overall acceptance of the game, to the broadest audience. The reason I say this, is because I have seen quite a few debates over various game mechanics that, if the devs had only given the players an option for those various things, it never would have been an issue for debate.

So it might be nice to have the ability, at least for some of the UI elements, to perhaps be able to pick or check boxes from a list of what stuff to show and in what form. Of course it would depend on whether the info would lend itself to that sort of thing. Flexibility, flexibility, flexibility.

Flatfingers wrote: I'd start with: what UI elements are used by most of LT's game systems?

For just flying almost nothing is needed, everything could fade out, besides a general radar/sensor widget.

As you always need to know if something interesting is in the area (and i dont assume that the game is intelligent enough to infer whats interesting)

maybe we need to differentiate between 2 general usecases:
the player is flying around and interacts with the world directly:
The world is the primary concern and the UI should limit itself to the minimum amount necessary.

And the player is managing something, for example reading the map, where the world is secondary and the UI takes up as much screen space as possible (as you can never have a too big map)

One thing that sort of annoys me in some games, is the inability to resize and move around info windows. I guess in some cases it's because they are using an overlay. Being able to open, resize, pin and move around a window is something I really like, as well as being able to decide what information is in it as well of course.

Poet1960 wrote:So it might be nice to have the ability, at least for some of the UI elements, to perhaps be able to pick or check boxes from a list of what stuff to show and in what form. Of course it would depend on whether the info would lend itself to that sort of thing. Flexibility, flexibility, flexibility.

Besides the flexibility, there is another point to look after. Handling. It is not just important to customize the UI, it should be also be easily doable. Clicking through hundreds of Check Boxes might be flexible, but not practical (unless you love CheckBoxes).

Regarding to everyones personal taste i suggest a "complexity slider". This setting works global for all UIs/Situations (for elements which are not exactly defined) and shows accordingly more or less information:

Example:
Slider to the left: Minimalism style; None or just a few icons/numbers
Slider to the right: Overload: Every possible information for this situation

which is completely missing the point of the thread, which is Dynamic interfaces.

a complexity slider is a workaround for static interfaces.


the questions are:

what information do we need?

when do we need it?

and in which fidelity do we need it?


that the UI can adapt to the situation and the task on its own, and not according to some slider

Eh, no. Careful that you don't miss the point of the discussion. Handling is an important issue as well, even, perhaps especially, for dynamic interfaces.

A dynamic interface would be able to essentially shift between 'verbose mode' and 'minimalist mode' depending on the actions of the player. But as Poet pointed out, players are idiosyncratic, and may prefer different amounts of information. It may be that a player will never want a true verbose mode, no matter how much the situation is deemed appropriate - hence flexibility. But the player's access to that flexibility should be itself flexible - hence, potentially, sliders.

It would of course depend on the nature of the dynamic interface, and the game type, but if dynamicity is important, then so is flexibility and handling.

when we have defined what/when/how we need something, we can establish how it behaves, and how the player can influence this behaviour

as long as we havent defined how it acts, discussing how we modify those actions is kinda moot

I see where you're coming from. Discussing the role of flexibility and handling has an influence on a philosophical level on the construction of the dynamic interface, but a posteriori implementation of those concepts depend on the interface itself. Maybe the perfect dynamic interface would be one size fits all!

yes, i think the ideal dynamic interface wouldnt need any changes from the user

Cornflakes_91 wrote:yes, i think the ideal dynamic interface wouldnt need any changes from the user

Even if i did not hit exactly the point of the discussion it should be considered. Imo there is an ideal (dynamic) interface but it only fits for one person. Every person is different and has different habits and prefences. For example: Some people want to see the distance to the target in meters, other think: "hey i can see it, don't block my view to this wonderful nebula". And i see two major groups: Minimalists and Statistics-Guy

Ok, let's get it startet.

My first approach:
Event Listener fires => Rules for UI process them => Change in UI (widgets)

Some examples for Event Listeners

• An unknown ship enters radar range
• Shields drops from 100%
• Ship is under fire
• Thrusters fire up
• Waypoint set ..
• ... bla .. bla

The rules process these informations and if, for example shields drop from 100% and ship is under fire a widget "crosshair" will be displayed...

id roll it up from a different direction.

lets start from an empty screen, what do we need under which circumstances?

what event listeners and actions we need we can build from what effects we need


for example i think the map should always be shown (except when in a clear screen mode for screenshots)

sitting silently in the corner and increase in size/fidelity when something "interesting" happens

enemy contact in range, new jumphole detected etc

Cornflakes_91 wrote:id roll it up from a different direction.

lets start from an empty screen, what do we need under which circumstances? what event listeners and actions we need we can build from what effects we need

This, exactly.

Although to get there you might benefit from throwing a lot of different interface ideas at the wall to identify utility and commonalities. First, you need to understand what your full UI is capable of expressing.

After that is when you can lay out a clean piece of paper and define the aesthetics and functionality of a particular visual language that is specifically suited to the nature of the game you're making.

Cornflakes_91 wrote:for example i think the map should always be shown (except when in a clear screen mode for screenshots) ... sitting silently in the corner and increase in size/fidelity when something "interesting" happens

Ack. This one, I'm not so sure about.

Personal taste, probably, but I really don't want the UI elements I've selected to start changing their sizes and locations without my asking for it. That's likely to interfere with whatever I might be doing at that moment.

What I'd prefer are notifiers -- parts of the UI that tell me about things I might be interested in through visual and audio cues. These would be keyed to the importance and priority of the incoming information:

• INFORMATION: a sale in a distant system might merit only a scrolling green comment line that's normally minimized
• WARNING: a scout report of another faction's military ships accumulating on the border of one of my star systems might produce a steady amber button (with a distinctive "ding") that needs to be clicked on
• ALERT: getting shot at might cause a flashing red light at the top center of the screen with a very noticeable buzzer (that then shuts the hell up).

What would be great would be if I could then assign additional specific UI elements to these notifiers. Suppose I classify some piece of information as a warning. When that information event is received, and I click on the warning button (or punch an assigned hotkey), that's when my HUD would switch over to a UI setup that's appropriate for that warning. I take whatever steps are necessary using that interface, and then I switch back to my default interface (or the custom UI for whatever I was previously doing, if that's possible).

The idea here is that notifiers alert me to changes in the state of my gameworld in some way that's appropriate for the kind of information being received, and they allow me to decide how to deal with that information. What they don't do is get all up in my face, interfering with whatever I'm doing that seems more important to me. They tell me generally what's happened, and then let me decide how I want to react.

That doesn't preclude the use of dynamic UI effects, as described in the article at the start of this thread. It's probably OK for certain UI elements to change in form when something interesting happens -- just not in size or location.