My HUD Redesign
Moderator: pyramid
-
- Confed Special Operative
- Posts: 360
- Joined: Tue Mar 02, 2004 9:34 am
- Contact:
-
- Bounty Hunter
- Posts: 243
- Joined: Mon May 05, 2003 7:16 am
- Location: Brisbane, Australia
charlie, yeah they are closable. you can close them all mate - mozilla just doesnt show right. infact, i like it BECAUSE you can choose how much info is displayed - you can turn as much or as little on/off as you like. close them all up and it takes up about 1/16th of the screen. so quit stressing about it what you seem to be complaining about is accounted for.charlieg wrote:be displayed when wanted/needed and no more than is required/requested. Even the central arcs are too thick and overbearing. I like the lovely wide view you get in VS that means you can see what is happening. It's much more fun to play by eye than to simply track the radar. With that HUD, you can barely see anything, 2/3 of the view is dedicated to the HUD. That's just too much.
Big thing about this is sure you'd turn most of it off for combat, but when doing slightly more difficult/complicated (and often non-combat-related) stuff we need a menu system like this. i've spoken about a system like this before - remember that with a menu system like this we have the flexibilty to add entirely new functions to custom components. eg add a menu to control a configurable scanner device, without having to map all new keys.
One gripe i do have is yeah those 'floating buttons' that remain when you close a menu need to be moved or re-moved. they're floating there just obscuring view. [edit - just found the HUD 1-3 button... wondering if there are still too many floating buttons - can these be moved somewhere else? or cramped further out (think high and thin rather than short and wide)]
-
- Elite
- Posts: 1671
- Joined: Fri Jan 03, 2003 12:46 am
- Location: Earth, Sol system.
- Contact:
-
- Confed Special Operative
- Posts: 360
- Joined: Tue Mar 02, 2004 9:34 am
- Contact:
Hello, and thanks for the developper of this .. gorgeous program for an old Elite Fan.
I'm sorry for my poor english, but I was always very intersted with pilot/spacecraft interface in many games.
I love an interface how look as "state-of-art" and the prcedent example (http://www.geocities.com/mikehorvath.ge ... egahud.png) is very interesting, but ... too much ?
In an old combat helicopter simulator, I had an option I loved :
You have 2 (or 3) MFD, and each had a keybord key assigned.
You choosed wich type of information you liked to display in each MFD, and each time you pressed the assigned keyboard key, you selected the MFD.
Once selected, each key press cycled beetwen the display.
As I see, it seems to need 3 assigned keyboard keys to choose one of the three suboption panel.
With this system, you don't need more than 2/3 MFD for all functions, and no more as 5/6 key assigned to access all.
I haven't tested the program until now, but two of the best interface idea I know are :
1) Microprose F19 stealth visual MFD display : the capacity to have in a MFD a direct view on targeted object, in real time movement. Very helpeful for making tactitcal decision at long distance.
In fact, I would like a miniature Camera-view in the MFD.
2) The Elite 3D radar system. No comment.
And one more time : thanks for all.
I'm sorry for my poor english, but I was always very intersted with pilot/spacecraft interface in many games.
I love an interface how look as "state-of-art" and the prcedent example (http://www.geocities.com/mikehorvath.ge ... egahud.png) is very interesting, but ... too much ?
In an old combat helicopter simulator, I had an option I loved :
You have 2 (or 3) MFD, and each had a keybord key assigned.
You choosed wich type of information you liked to display in each MFD, and each time you pressed the assigned keyboard key, you selected the MFD.
Once selected, each key press cycled beetwen the display.
As I see, it seems to need 3 assigned keyboard keys to choose one of the three suboption panel.
With this system, you don't need more than 2/3 MFD for all functions, and no more as 5/6 key assigned to access all.
I haven't tested the program until now, but two of the best interface idea I know are :
1) Microprose F19 stealth visual MFD display : the capacity to have in a MFD a direct view on targeted object, in real time movement. Very helpeful for making tactitcal decision at long distance.
In fact, I would like a miniature Camera-view in the MFD.
2) The Elite 3D radar system. No comment.
And one more time : thanks for all.
-
- Bounty Hunter
- Posts: 201
- Joined: Wed Jan 14, 2004 11:11 pm
- Location: londonengland, england
- Contact:
the MFD's in vegastrike actually do have alot of the functionality you're talking about. there's a key to switch them between damage readouts, weapons or navigational/target data...
also there is a minicam view just as you requested, a very flexible one able to view targets and locations or yourself...
i agree that the whole interface could be tidied away into a set of 3 or 4 modules, each able to display any of the required data or visuals, but it IS all there at the moment just a lil messily laid out.
i also want the entire hud to be modularised so you can upgrade it (2 MFD hud, 4 MFD hud, external cams etc) at the shipyard. this could also have excellent 3d representation (add MFD models to 3d cockpit layouts etc)
also there is a minicam view just as you requested, a very flexible one able to view targets and locations or yourself...
i agree that the whole interface could be tidied away into a set of 3 or 4 modules, each able to display any of the required data or visuals, but it IS all there at the moment just a lil messily laid out.
i also want the entire hud to be modularised so you can upgrade it (2 MFD hud, 4 MFD hud, external cams etc) at the shipyard. this could also have excellent 3d representation (add MFD models to 3d cockpit layouts etc)
- - above and beyond - -
-
- Elite
- Posts: 1671
- Joined: Fri Jan 03, 2003 12:46 am
- Location: Earth, Sol system.
- Contact:
-
- Confed Special Operative
- Posts: 360
- Joined: Tue Mar 02, 2004 9:34 am
- Contact:
I've completed my second HUD design.
You can find it here:
http://www.geocities.com/Area51/Quadran ... gahud2.htm
Note, that the fonts and icons are proprietary. So, they have to be replaced.
If anyone knows where I can find replacements, please let me know.
You can find it here:
http://www.geocities.com/Area51/Quadran ... gahud2.htm
Note, that the fonts and icons are proprietary. So, they have to be replaced.
If anyone knows where I can find replacements, please let me know.
-
- Site Administrator
- Posts: 478
- Joined: Thu Jan 02, 2003 10:05 am
- Location: Perth, Western Australia
- Contact:
-
- Elite
- Posts: 1671
- Joined: Fri Jan 03, 2003 12:46 am
- Location: Earth, Sol system.
- Contact:
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
-
- Confed Special Operative
- Posts: 360
- Joined: Tue Mar 02, 2004 9:34 am
- Contact:
This may be difficult. See this post:hurleybird wrote:Now if only that hud could get off of my browser, and into my game!
http://vegastrike.sourceforge.net/forum ... php?t=3116
-
- Merchant
- Posts: 45
- Joined: Wed Dec 29, 2004 11:10 pm
- Contact:
This HUD is pretty neat, but I think it may put a strain on some older sytems... I would prefer to use the oringal HUD just because my graphics card is older.
Also, that big X and some of the other features make it look like an win XP layout... there's no reason to perpetuate that OS' design issues any further.
The nice thing about VS cockpits now is that they are easy to modify. But the idea in this HUD to have more information on screen is a good idea. Just keep the layout separate from the content.
Also, that big X and some of the other features make it look like an win XP layout... there's no reason to perpetuate that OS' design issues any further.
The nice thing about VS cockpits now is that they are easy to modify. But the idea in this HUD to have more information on screen is a good idea. Just keep the layout separate from the content.
-
- Confed Special Operative
- Posts: 360
- Joined: Tue Mar 02, 2004 9:34 am
- Contact:
I was looking through the cockpit directory and was wondering...
Do the tag names in .cpt files need to be specific, or can they be arbitrary? e.g. can I keep adding as many tags as I want?
Why do so many tags reference "radar.spr", when they don't seem to be related in any way?
Where are the functions that define how the HUD actually works? All I can find are lists of objects (and key mappings).
How come all the HUD textures don't appear on the starting llama ship? e.g. the crosshairs and radar aren't the same as the ones in the medium_cockpit directory.
Do the tag names in .cpt files need to be specific, or can they be arbitrary? e.g. can I keep adding as many tags as I want?
Why do so many tags reference "radar.spr", when they don't seem to be related in any way?
Where are the functions that define how the HUD actually works? All I can find are lists of objects (and key mappings).
How come all the HUD textures don't appear on the starting llama ship? e.g. the crosshairs and radar aren't the same as the ones in the medium_cockpit directory.
-
- Confed Special Operative
- Posts: 286
- Joined: Tue Dec 21, 2004 3:11 am
- Location: Costa Pobre
- Contact:
-
- Elite
- Posts: 1832
- Joined: Sat Jan 15, 2005 10:21 pm
- Location: State of Denial
- Contact:
-
- Bounty Hunter
- Posts: 243
- Joined: Mon May 05, 2003 7:16 am
- Location: Brisbane, Australia
Ok, firstly just a quick background on me - i'm a qualified in Information Technology Interaction Design. This includes the design, implementation, and testing of human-computer interfaces.
just had a look at HUD 2 and something screamed out at me, so i thought i'd share some constructive criticism.
The shield diagram with the arrows. Redundant and too much brain power is required to interpret it. it's a classical problem/solution: Think of your stove top. Many 4-burner stove tops will have a row of dials down the side or front like this-
O O:
O O:
(':' indicates 2 dials)
Now, in this situation, how do we figure out which dial controls which element? Most companies will use a diagram on each button (like in the HUD design). However, this requires the user to either read the diagram each time or memorise the positions. Highly inefficient. There's a lot of cognitive processing here. In an emergency, you need to reduce the amout of processing needed (if your stove is on fire you dont want to have to recheck the dials!) There is a much simpler solution which instantly tells the user which is which which next to no processing and is extremely user friendly -
O O
O O ::
You dont even need to use labels anymore! This is now AT A GLANCE.
i.e. what i'm saying is 4 bars with arrows is extremely user UNfriendly. The bars are mapping to positions anyway, so it makes the most amount of sense to map those positions into the display. There are a number of ways you could do this, so play around with it. Something like shield control definitely needs to be readable AT A GLANCE. If you're getting laid into the back this should be immediately apparent without having to even think about it.
Also, you have a fair bit of redundancy in the bottom right display. Those buttons on the left of the box are the same as the buttons under the bars anyway, so why not just use them? The first thing i did was try to click on the buttons under the bars before realising the buttons ont he left did that. in the targetting mode, the screen actually changes. In the other 2 modes the highlighting changes, so there's no need to use page buttons. Or perhaps there's a different way to represent this.... (hmm the display immediately to the left seems to show these values anyway - why not adjust them there? save some real-estate at the same time. infact, that display to the left could appear three times in that space, showing power, shields, and whatever xyz is at the same time, perhaps)
Just my 2 cents. I could probably offer help on other areas too, but i don't understand what a lot of the stuff is anyway (maybe another usability issue but probably mostly due to lack of context on a web page)
just had a look at HUD 2 and something screamed out at me, so i thought i'd share some constructive criticism.
The shield diagram with the arrows. Redundant and too much brain power is required to interpret it. it's a classical problem/solution: Think of your stove top. Many 4-burner stove tops will have a row of dials down the side or front like this-
O O:
O O:
(':' indicates 2 dials)
Now, in this situation, how do we figure out which dial controls which element? Most companies will use a diagram on each button (like in the HUD design). However, this requires the user to either read the diagram each time or memorise the positions. Highly inefficient. There's a lot of cognitive processing here. In an emergency, you need to reduce the amout of processing needed (if your stove is on fire you dont want to have to recheck the dials!) There is a much simpler solution which instantly tells the user which is which which next to no processing and is extremely user friendly -
O O
O O ::
You dont even need to use labels anymore! This is now AT A GLANCE.
i.e. what i'm saying is 4 bars with arrows is extremely user UNfriendly. The bars are mapping to positions anyway, so it makes the most amount of sense to map those positions into the display. There are a number of ways you could do this, so play around with it. Something like shield control definitely needs to be readable AT A GLANCE. If you're getting laid into the back this should be immediately apparent without having to even think about it.
Also, you have a fair bit of redundancy in the bottom right display. Those buttons on the left of the box are the same as the buttons under the bars anyway, so why not just use them? The first thing i did was try to click on the buttons under the bars before realising the buttons ont he left did that. in the targetting mode, the screen actually changes. In the other 2 modes the highlighting changes, so there's no need to use page buttons. Or perhaps there's a different way to represent this.... (hmm the display immediately to the left seems to show these values anyway - why not adjust them there? save some real-estate at the same time. infact, that display to the left could appear three times in that space, showing power, shields, and whatever xyz is at the same time, perhaps)
Just my 2 cents. I could probably offer help on other areas too, but i don't understand what a lot of the stuff is anyway (maybe another usability issue but probably mostly due to lack of context on a web page)
-
- Merchant
- Posts: 59
- Joined: Tue Oct 05, 2004 10:25 pm
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
you can use wget -r -l1 to get it all from here
http://www.geocities.com/Area51/Quadran ... gahud2.htm
wget -r -l1 http://www.geocities.com/Area51/Quadran ... gahud2.htm
wget is avail for both windows and linux google it
http://www.geocities.com/Area51/Quadran ... gahud2.htm
wget -r -l1 http://www.geocities.com/Area51/Quadran ... gahud2.htm
wget is avail for both windows and linux google it
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Merchant
- Posts: 59
- Joined: Tue Oct 05, 2004 10:25 pm
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
note that the cockpit listed there isn't necessarily the end-all be-all of cockpit formats...
incorporating an HTML renderer in the game for the sake of making cockpits isn't necessarily the right answer...it just might help figure out what sort of things are necessary to make good 2d (and/or) 3d cockpits that are more extensible than what we have in our game
for instance even something as simple as...one guy wanted a gauge that moved in 2 directions for blaster power (i.e. grew from the middle rather than from the right or the left...)
this could be done if I allowed 2 blaster power sprites...but 1 was hard coded in... most of it probably will be in C++ code rather than in changing the format... keeping our current format isn't half bad if it were just adequately extensible...
maybe writing cockpits in python is the way to go... we already have the base interface in python and that feels fairly flexible...again C++ representation is key here
incorporating an HTML renderer in the game for the sake of making cockpits isn't necessarily the right answer...it just might help figure out what sort of things are necessary to make good 2d (and/or) 3d cockpits that are more extensible than what we have in our game
for instance even something as simple as...one guy wanted a gauge that moved in 2 directions for blaster power (i.e. grew from the middle rather than from the right or the left...)
this could be done if I allowed 2 blaster power sprites...but 1 was hard coded in... most of it probably will be in C++ code rather than in changing the format... keeping our current format isn't half bad if it were just adequately extensible...
maybe writing cockpits in python is the way to go... we already have the base interface in python and that feels fairly flexible...again C++ representation is key here
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/
-
- Merchant
- Posts: 59
- Joined: Tue Oct 05, 2004 10:25 pm
I was too impetuous perhaps. Let me see if I understand what you are saying.
We change the existing C++ code. Instead of having all the displays hard wired into cockpit.cpp etc., we move the actual implementation of the individual meters/radars/vdu's into python, giving them a fairly uniform interface. C++ looks up in a config file (probably XML), decides which version of python vdu to use and then asks the correct python vdu to draw itself, however that may be?
Let me know if I'm on the right track.
We change the existing C++ code. Instead of having all the displays hard wired into cockpit.cpp etc., we move the actual implementation of the individual meters/radars/vdu's into python, giving them a fairly uniform interface. C++ looks up in a config file (probably XML), decides which version of python vdu to use and then asks the correct python vdu to draw itself, however that may be?
Let me know if I'm on the right track.
-compughatt
-
- Developer
- Posts: 3980
- Joined: Fri Jan 03, 2003 4:53 am
- Location: Stanford, CA
- Contact:
I was thinking reverse...
we could have a python code for the cockpit that calls into C++ and creates textures and gauges that C++ later renders
this really may be no better than our XML solution though... because you could just define an XML file to do that---
we could have a python code for the cockpit that calls into C++ and creates textures and gauges that C++ later renders
this really may be no better than our XML solution though... because you could just define an XML file to do that---
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
http://vegastrike.sourceforge.net/