What I'm building is a three dimensional rogue-esque game based on
playing ADVEN, ASYLUM (computers didn't have lower-case letters back
then), Rogue/LARN/Omega/MOIRA/Angband/HACK/Nethack and World of
Warcraft. The UI is mostly an annoyance to me, but an annoyance I
can't do without. I have an HTML based UI (source at
https://infohost.nmt.edu/~schlake/games/x31/index.txt and playable at
https://infohost.nmt.edu/~schlake/games/x31/index.cgi) but the back
end and processing has gotten large enough to make the web version
pretty much unplayable. If I had a GUI front end I wouldn't need to
reload the back end for every click, nor send the entire game state
across the network (yes, I could store it on the backend in a mysql
database, and earlier versions did that, but it turned out to be very
problematic for design purposes). There are a handful of buttons that
are static (the eleven cardinal directions), but most buttons come and
go based on the state of the game. If you are adjacent to a
characterClass object, then a "hello" button appears along with
whatever other actions that npc has available (currently my game only
has a money changer (because hookers only take exact change) and some
hookers (1 in 7 chance they rob you and dump you in the sewers). If
you are adjacent to a doorClass fill then you might get one or two a
variety of buttons (lock, unlock, open, close) depending on the state
of the door. Currently the map is just a flat omnipotent scan in x
and y around the player, with an adjustable z offset to look up and
down. Eventually I hope to pass back a smarter map with line of sight
and tooltips for items, and even more eventually, I want to provide a
first person view like ASYLUM did back on my TRS-80. But in the
meantime all I need is something to test the back end with. If you
look, you will notice that the buttons are created off interactions
with hints. The hints will eventually be used to group things
together, such as inventory interactions, combat interactions, etc.
Right now it only knows what movement interactions are, and it puts
those into a fixed table of movement with unavailable moves greyed
out.
To summarize so far, at every move there will be some number of
buttons that need to appear which have very little grouping and, aside
from movement, no fixed place in the GUI. The faster I can make a GUI
that lets me test the backend, the sooner I can work on my short term
goals of finding a way to implement NPC-movement, NPC-combat, adding
an inventory to the game, and expanding my map.
My GUI plan is to make a horizontal sizer that puts the map and
command-buttons (in a vertical sizer) next to a scrolling message
panel (that holds messages from objects and debugging information).
Attractiveness isn't an issue. I just need the buttons to appear when
a possible interaction is created.
Really, if I ever get this all sorted out (I'm on version 31 and I
started about 4 years ago) in Python I plan to rewrite it in C++ and
(probably) Qt. But I have pages and pages of concept ideas that are
far from being worked through, and I only do this in my spare time
when someone has just ninja-looted an item level 359 purple BoE drop
from a random instance and I'm too pissed off to play WoW.
Second summary: that was lots of things you probably didn't care about. 
···
On Tue, Apr 5, 2011 at 11:49 AM, Tim Roberts <timr@probo.com> wrote:
I, of course, don't know what you are building, so I can't be specific.
I'm just trying to point out that it's hard to get a user interface
right. We've learned an awful lot about what works and what doesn't in
the 25 years since Windows and the Mac first appeared, and you ignore
"best practices" at your own risk.
--
-- Schlake