Return to “Technical”

Post

Re: Dynamic User Interfaces

#16
Flatfingers wrote:
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.
Well, was just an idea.
We could as well just have it reduce its opacity.

I'd like to go all the way the article described.

Having an empty screen/hud per default and just show elements you need at that, keeping the hud minimal at all times.

Minimal information needed is different at different times.

All weapons/targetable equipment powered down?
hide the crosshairs

You are at full or zero speed and dont change it?
Hide the speedometer

Hull fully repaired, shields fully charged and in no combat situation?
Hide the health bars

sensors powering up to full power?
Show the frequency scanner widget and holographic system overlays on targetted ships
Doing the same in a combat situation?
only show the overlays and not the widget

Etc

This are of course examples of what i'd like and should be configurable
Post

Re: Dynamic User Interfaces

#17
I think we're seeing the same goal here: a context-aware HUD.

The question is how much intelligence needs to be built into it. Enough to automatically recognize the contexts you care about and dynamically reconfigure the HUD appropriately? Or just enough to provide signals to the player who then can manually switch to a preferred interface package?

The "observant HUD" is simpler/faster to code, but the "intelligent HUD" is faster to react... but it does require that the interface package the player really wants for a given context can always be selected correctly by the game logic.
Post

Re: Dynamic User Interfaces

#18
Well, a system that is noting you could be seen as a "pre stage" of a system thats actively acting on those notes.

Depending on how easy it is to configure, one player could set his UI to simply notify him after a trigger condition is met, or add some actions on this conditional trigger.


Event -> trigger -> notification
Or
Event -> trigger -> (notification) -> action
Post

Re: Dynamic User Interfaces

#19
Just as long as we can override the UI if need be. One thing that pisses me off to no end is when some games try to be smart and only show what is needed at the right time. This works great for 90% of everything, but that last 10% usually has me trying to stop the UI from doing something that I find incredibly unhelpful. Intelligence is great, but to the point where it almost forces me to act/play a certain way is not.
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Dynamic User Interfaces

#21
Cornflakes_91 wrote:Depending on how easy it is to configure, one player could set his UI to simply notify him after a trigger condition is met, or add some actions on this conditional trigger.

Event -> trigger -> notification
Or
Event -> trigger -> (notification) -> action
I'm assuming you've seen and are not unhappy with this part of Josh's devlog for today:
JoshParnell wrote:The UI messaging system is significantly more powerful than the object messaging system, because I had a nice insight: instead of defining a certain number of message types and then checking the type, why not let the type of the message be the type of the data contained therein?
...
I am already using this technique to allow the HUD widgets to communicate with the HUD itself. Very, very handy. Any widget can now send arbitrary data through the UI to other widgets.
:thumbup:

Online Now

Users browsing this forum: No registered users and 5 guests

cron