RE: [GD-Design] Configurable GUIs

[Tom F. <to...@mu...>]

Go for #4, but have a "quick hide" and "quick show" buttons that hide all
the non-essential windows such as chat, etc.

StarTopia came quite close to what I consider to be an ideal UI for an RTS -
small moveable panels, sections that you don't need can be collapsed, and we
managed to have purely modal windows - only one at a time. The only window
that needs to be up for any length of time is the trading window - that was
a bit tricky, since things might be happening while you were trading, but we
just made that part of the game. You can trade, or you can fight, but you
have to decide which you want to do. We didn't actually need quick-show and
quick-hide because of this (and there's no chat window - it's all
instant-messenger type stuff rather than stream-of-consciousness).

Most importantly, we managed to stop the artists using large areas of screen
space for pretty graphics. Buttons and displays - that's all you want in
these windows. Obeying the old adage that the interface is an _obstacle_ to
gameplay, not a feature. Less is more (ommmmmm).


#3 is actually pretty cool for some games (though you always have at least
one view full-screen). Check out Transport Tycoon and Rollercoaster Tycoon
(all hail Chris Sawyer) for excellent examples of this. We wanted to do this
for StarTopia, but basically forgot about it all until too late in the
project :-(


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 25 June 2002 04:20
> 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
>