gamedevlists-design

Re: [GD-Design] Configurable GUIs

[brian h. <bri...@py...>]

> Remember Tribes?

Unfortunately, no, never got to play it.

> 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.

Did you click on these components?  Or were they strictly status 
displays?  If they were strictly status, then a large part of the 
problem is solved inherently in the genre -- you 'aim' instead of 
selecting and clicking.  That's the dissonance suffered from, say, an 
RTS where there's "clicking on GUI components" and "clicking on game 
components" and there is ambiguity between the two.

> Please, do NOT do your #3, where the game is just another window.

The only game I can remember that was like this was Harpoon I believe.

-Hook

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
> 

RE: [GD-Design] Configurable GUIs

[brian h. <bri...@py...>]

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

That's the direction I'm leaning towards.

> 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. 

Ah, but that's an easy way out!  If you make everything modal, then 
moving/resizing/selection is trivial because the primary concern I 
have is dealing with other things at the same time in other 
windows/the desktop.

If everything is modal, you don't have that concern, you're 
either "doing this" or "doing that" -- you're never in the ambiguous 
territory of "doing both".

At that point, the interface becomes much simpler to deal with.

-Hook

Re: [GD-Design] Configurable GUIs

[Filip J. <fi...@bl...>]

I'll try sending this to the list too - instead of just to Mickael Pointier
whose message I responded to (sorry).

> > 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.

I'm working on an RPG which has a top-down 3D view. For a GUI, I was
thinking about multiple text consoles. I currently have a global menu, which
freezes the game (for load, save, etc). But that kind of interface won't do
for interaction. So, I was thinking about having a tiny text console pop up
over the head of an NPC/PC when I click it. If I left-click, I initiate a
conversation with the NPC, if I right-click I get a stat window (telling me
what I have learned through conversation with the NPC, and what is apparent
about it - things like strength etc are only displayed for PCs). Attacking
is a double-click.

When one or more of these consoles are open, life in the world continues as
usual, and the console by default follows the NPC it belongs to. Therefore
consoles must be semitransparent (solid text and borders, background
semitransparent). I think I'll do a stenciltest on consoles so that they
can't cover each other, I thought that I'd rather let the overlapped part of
a console not be visible at all, though I could have them side by side too
(which would make the consoles rub against each other, and suddenly change
places, if two NPCs with open consoles cross each others paths). If I want
to reach through the console window when I click, I shift-click instead of
clicking ordinarily.

Output to the consoles, and input from them is piped through std::cin and
std::cout (so the consoles are set as output/input buffers), output supports
a simple markup langauge to embed controls in the console text. This
requires the player to make sure that s/he does not have more than one
conversation open at a time, or the s/he address the right NPC (with a bop^W
click on the head), (free text conversation is not implemented though, so it
may turn out as a clickable conversation tree, in which case there will be
no such problem).

This all comes pretty close to the FPS-like interface I guess. My idea
though, is that everything and everybody has an interactive interface. If I
left-click an object, I get an action menu instead of a conversation, and if
I right-click it, I get a help text (based on my PCs virtual visual input).
If OTOH, I view an NPCs stats for too long, they'll turn to the PC and yell
"Quit staring at me!" and walk out of sight.

If I want to keep track of one of these consoles for a while, I'll just grab
it by the window bar and pull it where I want it - then it'll stay there
until it's closed/reattached. To close it I left-click "X", to minimize I
click "_" (and all that'll be left is the bar). To close/minimize all
consoles, I double-click the "X"/"_" on one of the consoles. To resume an
action/conversation that was abruptly interupted, I was thinking to implment
a resume action/"now, where were we" conversation entry.

To make the console interface more feature rich, one could add image maps.
Then it'd work better for other kinds of implementations, that won't be
accomodated by a text-oriented interface.

Another thought about the consoles is to have a docking bar, which ought to
be the only place a detached console could stay while detached. It'd be the
perfect place to have a backpack, or other inventory items one wants handy.
The docking bar should have a "minimize all" and a "close all" button, the
docking bar would be a perfect place for a couple of chat consoles. A
minimized console should alert the player somehow, if its contents has
changed (eg start blinking red).

Many unstructured thoughts, but there you have my current ideas. ::)) (<= on
caffeine)

/Filip Joelsson

[GD-Design] GTA II Review

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

It's not everyday that mainstream news media actually reviews a game,
rather than reporting on it. NPR's All Things Considered presented a
rather interesting review of Grand Theft Auto III yesterday, well-worth
the listen.

http://www.npr.org/ramfiles/atc/20020709.atc.10.ram

I love hearing non-gamer viewpoints on games which are more-or-less
pegged as "hardcore" games. Perhaps this label we put on so many games
is becoming less relevant today.

Al

RE: [GD-Design] Configurable GUIs

[Daniel C. <dan...@an...>]

"At that point, the interface becomes much simpler to deal with."

Is this a bad thing? :-) In many cases, particularly games, fully =
customizable interfaces are overkill that add only a small amount of =
benefit for advanced users at the cost of a solid dose of confusion for =
new users.  But it depends on the game.=20

Perhaps a root question to answer first is 'What activities will the =
user be performing?"  List them out and then focus your UI around the =
activities the user spends 80% of their time.  You can almost think of =
this as requirements gathering.  Also list your secondary constraints.  =
These could include things like "Maximize view of playfield" or =
"Maintain basic UI conventions of RTS genre"=20

Now you have an optimization problem that can be solve with a series of =
mockups and user testing.  This sort of bottom up UI design usually =
results in some rather creative solutions that fit the exact game you =
are creating.  And as you've seen, its amazing how complex UI theory =
collapses into a bubbling heap under the harsh light of actual usability =
testing. ;-)=20

Some common patterns that useful when building your optimal UI:

- Moving UI elements into the environment.  Example: Speech bubbles over =
a character's head removes the need to have a dialog text palette.=20

- Context sensitive palettes:  A panel that shows the options that are =
available based on what the player character is looking at or has =
selected.  A single context sensitive palette can replace the vast =
majority of palettes in your typical program.=20

- Tabs:  Much of the time, a user needs to only look at a single pane at =
a time.  Using tabs hides much of the UI. Be careful of using too many =
of these or selection between tabs becomes a bit confusing.=20

- Docking panels.  These ensure that no part of the play field is =
covered and they can be resizable.  This is often useful if one of you =
constraint involves real-time control of the environment at all times.=20

You could combine tabs with docking panels.  If you set up tabs so it is =
possible to deselect all tabs, you have an intuitive method of hiding =
your docking panel.  Click a tab to pop up the panel.  Click a different =
tab to show a new panel.  Click the same tab again to deselect it and =
hide all the panels.=20

take care,
Danc.=20

RE: [GD-Design] Configurable GUIs

[brian h. <bri...@py...>]

> We use floating small panels in our game, and it seems to work fairly
> well. All panels can be dragged around just by gripping the border and
> dragging. All panels can also be hidden.
 
>         http://civil.sourceforge.net/screenshots/snapshot56.jpg

(BTW, looks neat!)
 
> This is a slow paced strategy game, where the player has time to 
arrange
> the "environment" to suit his/her taste.

Ah, that's the rub.  For a faster paced game, like an RTS or a real-
time RPG, I would imagine that the windows would get in the way.  
Nothing more frustrating that trying to target an enemy unit that 
crawled under one of your windows. =|

-Hook