gamedevlists-design

[GD-Design] Configurable GUIs

[Brian H. <bri...@py...>]

Whilst toying with a simple RPG I've been working on in my spare time, I've 
run into a bit of a stumper when it comes to GUI design.

Originally I started out with the grand notion that the GUI would simply be 
a bunch of overlapping windows on top of a 3D desktop (i.e. the entire 
background was the local "situation" -- first person, top down, isometric, 
whatever, point being that it's not constrained to a smaller window).  This 
seemed to make intuitive sense.

Until, of course, it was implemented.  The control scheme is unbearable.

Most games I've seen fall under one of three GUI camps:

1.  effectively no GUI, the entire scene is 3D and interface elements tend 
to be non-interactive.  Most first person shooters are like this.

2.  hard coded GUI, where there's a display window and then a bunch of 
dressing that does things like show character stats, order units around, 
exit the game, bring up menus, etc.  Most RPGs and some flight sims are 
like this.

3. MDI style multiple-window system with tiling and overlapping windows, 
where the 3D view is "just another window"

The problem with #1 is that it's not a very friendly interface and it 
doesn't allow for a particularly rich interactive experience.

The problem with #2 is that, well, it's hard coded.  If you want a bigger 
chat window or a larger radar display, it's difficult to do within the 
constraints of a hardcoded layout (and make no doubt, the layout is 
hardcoded, because if it wasn't, it would be a #3 GUI).

The problem with #3 is that it becomes cluttered.  Quickly.  Overlapping 
windows make sense when you have a lot of documents that you toggle 
between, but by and large you're only operating on a single window at a 
time and the other windows can be ignored.  Works great for a word 
processor, but it's kinda sucky for a game.

So let's invent #4, the "central window with overlapping ancillary control 
panels" interface.  Basically imagine an RPG or flight sim where you can 
undock the chat, radar, health, etc. panels and move them and resize them 
at will.  For chat this is particularly nice (especially for an on-line 
game) where you want to make the windows nice and big (and possibly have 
several of them open) so you can interact with others.

The problem comes about due to the windows overlapping each other, which 
causes a point-and-click interface to go to complete hell.  Say your game 
is an RTS.  Your chat window is up because you're coordinating with your 
friends, but now an enemy unit appears under your chat window.  You try to 
click on the unit, but it simply "focuses" the chat window.  Bzzzt, that 
sucks.  But if clicking selects the unit under the chat window, how do you 
move the chat window -- by manipulating the title bar only?  That sucks too 
since it's unintuitive.  So do you force the user to dock/move the chat 
window out of the way?  That would seem cumbersome as hell (imagine 
constantly moving the chat window out of the way in order to click on 
various units on the screen).

I didn't realize that taking a simple UI and just extending it into "make 
it configurable" was so damn hard to design.

I'm leaning towards thinking that overlapping windows -- except for modal 
dialogs -- is a bad idea.  Alternatively, panels can be undocked and 
resized, but they are 'naturally' in a docked position so when the shit 
hits the fan, you can click on a "dock all windows" button and be back in a 
usable state.

Anyway, I'm curious what others think about this issue.

Brian

Re: [GD-Design] Configurable GUIs

[Kent Q. <ken...@co...>]

Brian,

Remember Tribes?

It was a 3D world, but there were overlays for all the UI components.
They were all done in shades of green on transparent, and they were
pretty usable. One of the cool things was that you could hit a key,
and the components all could then be dragged around with the mouse;
hit the key again and they freeze in place and become active again. So
you could configure your UI arbitrarily. I think there was also an
interface for removing stuff and placing things that were currently
missing.

I have come to the conclusion that you want to put as thin a wall as
possible between the user and the game. So first, get rid of
everything you can. Black and White was amazing -- the hand did
everything (of course, they made figuring out the interface part of
the game).

After that, if you can put interface elements IN the world, do so, as
long as they make sense.

Pretty much anything else, IMO, should go on the screen. Or on pullout
panels or something. But I say you should usually avoid the
rectangular-window-dialog-box interface if you possibly can. Certainly
you should avoid overlapping windows if at all possible.

Please, do NOT do your #3, where the game is just another window. Ick.
That would totally destroy any sense of immersion.

     Kent



Monday, June 24, 2002, 11:20:12 PM, you wrote:

BH> Whilst toying with a simple RPG I've been working on in my spare time, I've 
BH> run into a bit of a stumper when it comes to GUI design.

BH> Originally I started out with the grand notion that the GUI would simply be 
BH> a bunch of overlapping windows on top of a 3D desktop (i.e. the entire 
BH> background was the local "situation" -- first person, top down, isometric, 
BH> whatever, point being that it's not constrained to a smaller window).  This 
BH> seemed to make intuitive sense.

BH> Until, of course, it was implemented.  The control scheme is unbearable.

BH> Most games I've seen fall under one of three GUI camps:

BH> 1.  effectively no GUI, the entire scene is 3D and interface elements tend 
BH> to be non-interactive.  Most first person shooters are like this.

BH> 2.  hard coded GUI, where there's a display window and then a bunch of 
BH> dressing that does things like show character stats, order units around, 
BH> exit the game, bring up menus, etc.  Most RPGs and some flight sims are 
BH> like this.

BH> 3. MDI style multiple-window system with tiling and overlapping windows, 
BH> where the 3D view is "just another window"

BH> The problem with #1 is that it's not a very friendly interface and it 
BH> doesn't allow for a particularly rich interactive experience.

BH> The problem with #2 is that, well, it's hard coded.  If you want a bigger 
BH> chat window or a larger radar display, it's difficult to do within the 
BH> constraints of a hardcoded layout (and make no doubt, the layout is 
BH> hardcoded, because if it wasn't, it would be a #3 GUI).

BH> The problem with #3 is that it becomes cluttered.  Quickly.  Overlapping 
BH> windows make sense when you have a lot of documents that you toggle 
BH> between, but by and large you're only operating on a single window at a 
BH> time and the other windows can be ignored.  Works great for a word 
BH> processor, but it's kinda sucky for a game.

BH> So let's invent #4, the "central window with overlapping ancillary control 
BH> panels" interface.  Basically imagine an RPG or flight sim where you can 
BH> undock the chat, radar, health, etc. panels and move them and resize them 
BH> at will.  For chat this is particularly nice (especially for an on-line 
BH> game) where you want to make the windows nice and big (and possibly have 
BH> several of them open) so you can interact with others.

BH> The problem comes about due to the windows overlapping each other, which 
BH> causes a point-and-click interface to go to complete hell.  Say your game 
BH> is an RTS.  Your chat window is up because you're coordinating with your 
BH> friends, but now an enemy unit appears under your chat window.  You try to 
BH> click on the unit, but it simply "focuses" the chat window.  Bzzzt, that 
BH> sucks.  But if clicking selects the unit under the chat window, how do you 
BH> move the chat window -- by manipulating the title bar only?  That sucks too 
BH> since it's unintuitive.  So do you force the user to dock/move the chat 
BH> window out of the way?  That would seem cumbersome as hell (imagine 
BH> constantly moving the chat window out of the way in order to click on 
BH> various units on the screen).

BH> I didn't realize that taking a simple UI and just extending it into "make 
BH> it configurable" was so damn hard to design.

BH> I'm leaning towards thinking that overlapping windows -- except for modal 
BH> dialogs -- is a bad idea.  Alternatively, panels can be undocked and 
BH> resized, but they are 'naturally' in a docked position so when the shit 
BH> hits the fan, you can click on a "dock all windows" button and be back in a 
BH> usable state.

BH> Anyway, I'm curious what others think about this issue.

BH> Brian



BH> -------------------------------------------------------
BH> Sponsored by:
BH> ThinkGeek at http://www.ThinkGeek.com/
BH> _______________________________________________
BH> Gamedevlists-design mailing list
BH> Gam...@li...
BH> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
BH> Archives:
BH> http://sourceforge.net/mailarchive/forum.php?forum_id=556


-- 
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com

Re: [GD-Design] Configurable GUIs

[Mickael P. <mpo...@ed...>]

> So let's invent #4, the "central window with overlapping ancillary control
> panels" interface.  Basically imagine an RPG or flight sim where you can
> undock the chat, radar, health, etc. panels and move them and resize them
> at will.  For chat this is particularly nice (especially for an on-line
> game) where you want to make the windows nice and big (and possibly have
> several of them open) so you can interact with others.

It's a mix between "Dungeon Siege" and "Morrowind" ?

In dungeon siege most interface items can be expanded
or retracted using a small "<<<" or ">>>" click box.

In Morrowind, the character status, inventory, spell
list, merchant inventory, and world map are all fully
sorted and resizable windows. You cannot play (freeze)
when menus are active, but it's a full featured gui
anyway.

    Mickael Pointier

RE: [GD-Design] Configurable GUIs

[Albert R. <al...@de...>]

Keep It Simple.

As programmers, "hard coded" is one of those evil things that we're
supposed to avoid, and I don't think that's the right way to describe
option number 2. I prefer to think of it as doing it right so the user
doesn't have to. As Kent pointed out, most of the time gamers don't want
to see anything but the viewport anyways. When they are dealing with
inventory management or their stats, it makes sense to provide them with
a clean interface with which to work. Dark Age of Camelot, which has a
bunch of windows you can move around infuriated me with all the clutter
and confusion caused by the added ability to shift the UI components
around. It's hard to make an nice, compact UI when everything has to be
forced into a square box.

Diablo II's interface is incredible elegant and barely configurable.
There's basically no learning curve in getting started as everything is
just "right there". I want to be able to configure dev-studio and
outlook because there's just too many options and some I never use.
Games have fewer things that you need to be able to click on but
possibly more information that needs to be readily available. Because of
this, it seems best to "hard code" the UI so all the important
information is just there, and other things are neatly hidden away. The
super-hardcore crowd might like it, but the rest of the world would
rather just not think about it. 

Only catch to this method is that you have to do lots of testing and
refining to make sure that your way of doing it is the way users like
best. Taking in feedback and tweaking the hell out of it until it's just
right is key to making any UI work, but especially if you intend to take
away customization.

-Al

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Brian Hook
> Sent: Monday, June 24, 2002 11:20 PM
> To: gam...@li...
> Subject: [GD-Design] Configurable GUIs
> 
> 
> Whilst toying with a simple RPG I've been working on in my 
> spare time, I've 
> run into a bit of a stumper when it comes to GUI design.
> 
> Originally I started out with the grand notion that the GUI 
> would simply be 
> a bunch of overlapping windows on top of a 3D desktop (i.e. 
> the entire 
> background was the local "situation" -- first person, top 
> down, isometric, 
> whatever, point being that it's not constrained to a smaller 
> window).  This 
> seemed to make intuitive sense.
> 
> Until, of course, it was implemented.  The control scheme is 
> unbearable.
> 
> Most games I've seen fall under one of three GUI camps:
> 
> 1.  effectively no GUI, the entire scene is 3D and interface 
> elements tend 
> to be non-interactive.  Most first person shooters are like this.
> 
> 2.  hard coded GUI, where there's a display window and then a 
> bunch of 
> dressing that does things like show character stats, order 
> units around, 
> exit the game, bring up menus, etc.  Most RPGs and some 
> flight sims are 
> like this.
> 
> 3. MDI style multiple-window system with tiling and 
> overlapping windows, 
> where the 3D view is "just another window"
> 
> The problem with #1 is that it's not a very friendly interface and it 
> doesn't allow for a particularly rich interactive experience.
> 
> The problem with #2 is that, well, it's hard coded.  If you 
> want a bigger 
> chat window or a larger radar display, it's difficult to do 
> within the 
> constraints of a hardcoded layout (and make no doubt, the layout is 
> hardcoded, because if it wasn't, it would be a #3 GUI).
> 
> The problem with #3 is that it becomes cluttered.  Quickly.  
> Overlapping 
> windows make sense when you have a lot of documents that you toggle 
> between, but by and large you're only operating on a single 
> window at a 
> time and the other windows can be ignored.  Works great for a word 
> processor, but it's kinda sucky for a game.
> 
> So let's invent #4, the "central window with overlapping 
> ancillary control 
> panels" interface.  Basically imagine an RPG or flight sim 
> where you can 
> undock the chat, radar, health, etc. panels and move them and 
> resize them 
> at will.  For chat this is particularly nice (especially for 
> an on-line 
> game) where you want to make the windows nice and big (and 
> possibly have 
> several of them open) so you can interact with others.
> 
> The problem comes about due to the windows overlapping each 
> other, which 
> causes a point-and-click interface to go to complete hell.  
> Say your game 
> is an RTS.  Your chat window is up because you're 
> coordinating with your 
> friends, but now an enemy unit appears under your chat 
> window.  You try to 
> click on the unit, but it simply "focuses" the chat window.  
> Bzzzt, that 
> sucks.  But if clicking selects the unit under the chat 
> window, how do you 
> move the chat window -- by manipulating the title bar only?  
> That sucks too 
> since it's unintuitive.  So do you force the user to 
> dock/move the chat 
> window out of the way?  That would seem cumbersome as hell (imagine 
> constantly moving the chat window out of the way in order to click on 
> various units on the screen).
> 
> I didn't realize that taking a simple UI and just extending 
> it into "make 
> it configurable" was so damn hard to design.
> 
> I'm leaning towards thinking that overlapping windows -- 
> except for modal 
> dialogs -- is a bad idea.  Alternatively, panels can be undocked and 
> resized, but they are 'naturally' in a docked position so 
> when the shit 
> hits the fan, you can click on a "dock all windows" button 
> and be back in a 
> usable state.
> 
> Anyway, I'm curious what others think about this issue.
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/ 
> _______________________________________________
> Gamedevlists-design mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556
>