gamedevlists-design — List for discussing game development design

[GD-Design] Game UI's

[<ham...@tm...>]

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

Please note that 3 can have an extra advantage, depending on precisely how much the implementation fits within the mores of whichever OS(es) it runs on: thanks especially to nVidia, an awful lot of "normal" games-playing people now have two or more monitors on their PC - it's no longer the preserve of professional graphic artists etc - and number 3 allows them to actually take advantage of that extra monitor, without the GUI designer having the headache of designing specifically for multi-monitor.

Straw poll indicates that many people running mulit-mointor have different size monitors and/or different max resolutions (usually they run their current monitor and whichever mointor they had before that, which was sitting on a shelf gathering dust until they bought a GeForce xxx MX/etc). In these cases, allowing the user to resize the available sub-windows to fit their own personal uniquely weird shaped desktop is fantastic.

[confession: I tend to get really pi**ed off when a game with loads of dialogues refuses to play nice with multi monitor - I've got the hardware, I got it working under windows/X11/whatever, and its extremely frustrating not to be bale to use it].

Adam M 

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
> 

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

[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

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

[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

[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

[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

[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

[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: Re[2]: [GD-Design] Article on 'Evolutionary Game Design'

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

Yep, the lostgarden.com link is down for about another week or so.  The
gamedev.net link should work for a while though.

Thanks for the interest. :-)
-Danc.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Kerim Borchaev
Sent: Wednesday, March 13, 2002 11:54 AM
To: Martin Gladnishki
Cc: gam...@li...
Subject: Re[2]: [GD-Design] Article on 'Evolutionary Game Design'


Try this one:

http://www.gamedev.net/reference/design/features/evolution/

or this:

http://www.google.com/search?q=evolutionary+game+design


> I'm afraid the link is broken, dude?
>
> Cheers,
> Martin
>
> ----- Original Message -----
> From: "Daniel Cook" <dan...@an...>
> To: <gam...@li...>
> Sent: Wednesday, January 16, 2002 11:04 PM
> Subject: [GD-Design] Article on 'Evolutionary Game Design'
>
>
>> For your reading pleasure:
>> http://www.lostgarden.com/evolutionary_game_design.htm
>>
>> This article looks at creating a design 'process.'  There are dozens of
>> methodologies for creating great code, or streamlining the creation of
>> suitable art assets.  Designers can ask a related question, "What are a
> set
>> of rational step-by-step activities that can be followed in order to
> create
>> a more playable game?"
>>
>> Enjoy,
>> Daniel Cook
>>
>>
>> _______________________________________________
>> Gamedevlists-design mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
>>
>
>
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556



_______________________________________________
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[2]: [GD-Design] Article on 'Evolutionary Game Design'

[Kerim B. <wa...@st...>]

Try this one:

http://www.gamedev.net/reference/design/features/evolution/

or this:

http://www.google.com/search?q=evolutionary+game+design


> I'm afraid the link is broken, dude?
> 
> Cheers,
> Martin
> 
> ----- Original Message -----
> From: "Daniel Cook" <dan...@an...>
> To: <gam...@li...>
> Sent: Wednesday, January 16, 2002 11:04 PM
> Subject: [GD-Design] Article on 'Evolutionary Game Design'
> 
> 
>> For your reading pleasure:
>> http://www.lostgarden.com/evolutionary_game_design.htm
>>
>> This article looks at creating a design 'process.'  There are dozens of
>> methodologies for creating great code, or streamlining the creation of
>> suitable art assets.  Designers can ask a related question, "What are a
> set
>> of rational step-by-step activities that can be followed in order to
> create
>> a more playable game?"
>>
>> Enjoy,
>> Daniel Cook
>>
>>
>> _______________________________________________
>> Gamedevlists-design mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
>>
> 
> 
> _______________________________________________
> 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] Article on 'Evolutionary Game Design'

[Martin G. <bz...@wi...>]

I'm afraid the link is broken, dude?

Cheers,
Martin

----- Original Message -----
From: "Daniel Cook" <dan...@an...>
To: <gam...@li...>
Sent: Wednesday, January 16, 2002 11:04 PM
Subject: [GD-Design] Article on 'Evolutionary Game Design'


> For your reading pleasure:
> http://www.lostgarden.com/evolutionary_game_design.htm
>
> This article looks at creating a design 'process.'  There are dozens of
> methodologies for creating great code, or streamlining the creation of
> suitable art assets.  Designers can ask a related question, "What are a
set
> of rational step-by-step activities that can be followed in order to
create
> a more playable game?"
>
> Enjoy,
> Daniel Cook
>
>
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
>

RE: [GD-Design] Action game and 'sandboxes'

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

Yes, just do a 2D top-down version of the game. If you really need 3D (e.g.
jumping puzzles, do an isometric version). Very quick, very simple.

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: Awen Limbourg [mailto:ali...@ed...]
> Sent: 13 March 2002 09:02
> To: 'Gamedevlists-Design@Lists. Sourceforge. Net'
> Subject: [GD-Design] Action game and 'sandboxes'
> 
> 
> Hello to you all out there,
> 
> It's a technician inquiry:
> 
> I'm presently working on a platform game, a-la-Jack&Dexter: 
> has any of you
> succeeded with quickly prototyping such a kind of concept and 
> game rules,
> without waiting for the loud technical artillery ?
> I remember a conference where Peter Molyneux explained that 
> he worked on a
> very old-almost-2D version of its (Populous ?) engine as a 
> sandbox to build
> 'Black&White'. The benefits and feasibility is ok for a Rts 
> game. It's more
> blurry with action game, where quick interactivity and 
> adrenalin punches
> seem to rule.
> Anyway, are you (designers) living well with untested unclear 
> unsure arcade
> game situations until 'it's done' in the game ('glp. ok, it 
> fells horrible
> to play, but i have many other marvelous idea, let's throw 
> this away & let's
> do it in another manner' -> hainous glance from technicians) ???
> Or do you force yourself to sandbox these marvelous ideas ? And How ?
> 
> Thank you for reading me,
> 
> Awen
> 
> 
> 
> _______________________________________________
> Gamedevlists-design mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-design
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=556
> 

[GD-Design] Action game and 'sandboxes'

[Awen L. <ali...@ed...>]

Hello to you all out there,

It's a technician inquiry:

I'm presently working on a platform game, a-la-Jack&Dexter: has any of you
succeeded with quickly prototyping such a kind of concept and game rules,
without waiting for the loud technical artillery ?
I remember a conference where Peter Molyneux explained that he worked on a
very old-almost-2D version of its (Populous ?) engine as a sandbox to build
'Black&White'. The benefits and feasibility is ok for a Rts game. It's more
blurry with action game, where quick interactivity and adrenalin punches
seem to rule.
Anyway, are you (designers) living well with untested unclear unsure arcade
game situations until 'it's done' in the game ('glp. ok, it fells horrible
to play, but i have many other marvelous idea, let's throw this away & let's
do it in another manner' -> hainous glance from technicians) ???
Or do you force yourself to sandbox these marvelous ideas ? And How ?

Thank you for reading me,

Awen

[GD-Design] Article on 'Evolutionary Game Design'

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

For your reading pleasure:
http://www.lostgarden.com/evolutionary_game_design.htm

This article looks at creating a design 'process.'  There are dozens of
methodologies for creating great code, or streamlining the creation of
suitable art assets.  Designers can ask a related question, "What are a set
of rational step-by-step activities that can be followed in order to create
a more playable game?"

Enjoy,
Daniel Cook

Re: [GD-Design] Design Documents

[J C L. <cl...@ka...>]

On Tue, 13 Nov 2001 19:04:17 -0000 
Andrew Perella <aj...@eu...> wrote:

> I have been trying out zwiki (a wiki built in Zope - a python web
> server).  Does anyone have suggestions for producing printable
> and/or self contained linked electronic format documents from such
> wikis?

PhpWiki has some crude tools in this direction (zipdump).  IRRC
there was a project a while for TWiki to be able to export PDFs, but
I don't know what, if anything happened to that.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

RE: [GD-Design] Design Documents

[Andrew P. <aj...@eu...>]

I have been trying out zwiki (a wiki built in Zope - a python web server).
Does anyone have suggestions for producing printable and/or self contained
linked electronic format documents from such wikis?

Regards,
Andrew


_____________________________________________________________________
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. No communication sent by e-mail to or from Eutechnyx is intended to give rise to contractual or other legal liability, apart from liability which cannot be excluded under English law. 

This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. 

www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

RE: [GD-Design] Re: Design Documents

[Philip H. <ph...@me...>]

> Let's see.  Current stuff is under wraps, but here's a pretty good
> approximation

[Very useful example deleted]

Cheers, that's very interesting. I can certainly how this sort of approach
could work very well for games development (at least from the developers
point of view).

> Also, the feature card database is an idea database that many people can
> contribute to. We have a go-to person who makes sure the language is
> coherent, but other than that anyone can add their concepts.  Since the
> final product is derived iteratively from high priority features, there is
> no need to maintain the 'monolithic perfect design doc'.  Someone has an
> cool idea?  Add it to the database.  The prioritization and development
> process ensure that it is given it's proper due consideration.

I take it there's one or more people responsible for the overall vision of
the project? I've worked on several projects where the 'design' was very
informal but they suffered because there wasn't anyone who really accepted
responsibility for the design.

> The other realization is that many details in design docs are unimportant
> tidbits placed there by anal retentive world builder types. ;-) (I suffer
> from this myself)

:) Someone once said that a piece of writing isn't complete until everything
that can be removed, has.

> You are correct in assuming in that most of the knowledge is human
> knowledge, not documented knowledge.  The basic philosophy is "Record as
> little as practically possible.  Rely on the creative capabilities of your
> team combined with a common vision to fill in the details in a
> cohesive way"
> Most developers are not assembly line workers and it seems a shame to use
> them as such.

Does this approach go down well with the developers, I would have thought
most of them would love such a freeform, creative environment.

> Another way of looking at it: If your team leaves, no design document will
> save the project. :-)

:) And of course having a design document doesn't guarantee success even if
they don't leave.

> >>Do you also use the two programmer approach to Extreme Programming?<<
>
> Not yet. :-) A lot of the problems the XP guys say we'd have if we didn't
> use pair programming have indeed surfaced.  One of these days I hope we'll
> give it a shot.

That bit always struck me as a good idea which is very hard to implement. On
a similar note there are advocates of a 1 Programmer=1 Tester approach to
development (Microsoft used to use this, maybe still do) which would be
equally difficult to get approved by the people with the money.

Phil

RE: [GD-Design] Design Documents

[Philip H. <ph...@me...>]

> As it turns out, it is a really easy job to write a "design sentence", and
> then a couple more days (average, sometimes shorter, sometimes longer) of
> "source code" to actually implement a design phrase.

That seems to imply that the design is developed alongside the code. Do you
have any sort of design before you start?

Phil

RE: [GD-Design] Design Documents

[Philip H. <ph...@me...>]

> Agreed.  Either SGML (DocBook?) or (La)TeX would seem the obvious
> choices and are the canonical solutions to this problem.

I'd have to disagree, far too techie for most uses.

Phil

RE: [GD-Design] Design Documents

[Philip H. <ph...@me...>]

I have to reiterate: Word is a very bad choice for what you're trying to
> do. It's way too heavyweight, gives the users too much control where you
> don't want them to have it. I have seen it many times, and heard of it
> many more times -- if you use Word as your spec creation tool, you end
> up adapting your processes to cope with its weaknesses. It's just a
> terrible way to create structured documents.

So I've noticed :)

> And in response to another query, you probably have created tools for
> art, testing, development, and production. Why not documentation?
> They're easy to build.

True, but only after we've made sure there isn't something already doing the
job.

Phil

RE: [GD-Design] Design Documents

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

Wikis do indeed rock for docs that are trivially easy to maintain and
update. I heartily recommend them for pretty much everything - coding docs &
specs, design docs, todo lists (both personal and company), etc.

http://www.c2.com/cgi/wiki for more info about Wikis and how they work and
stuff.

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: J C Lawrence [mailto:cl...@ka...]
> Sent: 07 November 2001 21:50
> To: Sellers, Mike
> Cc: 'gam...@li...'
> Subject: Re: [GD-Design] Design Documents 
> 
> 
> On Wed, 7 Nov 2001 14:08:07 -0600 
> Mike Sellers <Sellers> wrote:
> 
> > Yep.  And simplicity wins out *big* in areas like this.  Tools
> > that are way-cool but at all cumbersome to use just won't get
> > used; people will find it easier to circumvent the tools instead.
> > (FWIW, ours is a large team project too, so this doesn't seem to
> > have issues of scaling to support a large project or a large
> > team.)
> 
> Aye, this is specifically why I've installed WikiWikis (specifically
> TWiki) at three companies now.  The barrier to use factor is
> obscenely low, and its easy to create automated tools to
> mechanically inject and maintain relevant content (eg recent stats
> etc).
> 
> -- 
> J C Lawrence
> ---------(*)                Satan, oscillate my metallic sonatas.
> cl...@ka...               He lived as a devil, eh?
> http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-Design] Design Documents

[J C L. <cl...@ka...>]

On Wed, 7 Nov 2001 14:04:16 -0600 
Mike Sellers <Sellers> wrote:

> FWIW, I don't know anyone using SGML or LaTeX -- are people really
> still using these?

A lot of 'net related documentation is written in DocBook (which is
SGML-compliant).  Many (most?) technical journals require
submissions in TeX with several also accepting the LaTeX macro set
(all that I've run into).  As I'm a dinosaur I do all my letters,
reports, articles etc in LaTeX.  More specifically I refuse to use
page-layout styled word processors.  Useless things.  I want and use
markup languages for document authoring.

As to the size of the population?  Not sure.  LyX, a GUI front end
to LaTex is actively maintained and developed as is the auctex mode
for (X)Emacs, and per the mailing lists seems to have a reasonably
active user base.  A decent percentage of the technical
documentation sites I used are auto-genned by exporting HTML from
DocBook (they typically also export PS, and PDF).  A couple of the
companies I've worked for (most notably IBM) kept all their product
documentation under something that was very DocBook-like (different
name I forget).  Beyond that I've few/no impressions on their wider
use.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-Design] Design Documents

[J C L. <cl...@ka...>]

On Wed, 7 Nov 2001 14:08:07 -0600 
Mike Sellers <Sellers> wrote:

> Yep.  And simplicity wins out *big* in areas like this.  Tools
> that are way-cool but at all cumbersome to use just won't get
> used; people will find it easier to circumvent the tools instead.
> (FWIW, ours is a large team project too, so this doesn't seem to
> have issues of scaling to support a large project or a large
> team.)

Aye, this is specifically why I've installed WikiWikis (specifically
TWiki) at three companies now.  The barrier to use factor is
obscenely low, and its easy to create automated tools to
mechanically inject and maintain relevant content (eg recent stats
etc).

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.