This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Hex (hic!) menu interface?


From: Lincoln Peters [mailto:sampln@sbcglobal.net]
>
> I think that the problem is that there are so few people working on
> Xconq.

Xconq is a mature project, and that's to it's credit.  But I do agree it
has the characteristics of a small project.  Chiefly, I don't see it as
set up to incorporate the contributions of newbies.  Of course, without
some attention paid in this area, the project never grows beyond a few
core developers.  Maybe the core developers prefer it that way?

> And all of us have obligations outside of Xconq, which further
> reduces the amount of time we can spend on it.

Nothing different for me.

> And you really do sound hostile.

I want certain things discussed before I do a ton of work for Xconq's
benefit.  When things I need in order to make progress are ignored, it
makes me rather angry.  At least you responded and started a discussion.
Even responses like, "Dude, we have no idea what you're on about" are
better than shouting into the void.

What does "a ton of work" mean?  Well, it certainly means work in excess
of what Hans famously described as "a few minutes" to get a proper VS
2003 build together.  It actually took a week.  Not every hour of every
day, but realistically, the scope of the project was 1 week, not "a few
minutes."

Nontrivial GUIs are projects of multiple weeks' scope.  I must discuss
them with others before I proceed.  I'm not doing that much work to find
out in hindsight that it is not valued, won't get used because nobody
cares about Windows, won't make it into the source pool because CVS
checkins are often Rip Van Winkled, someone else really really feels
this steps on their toes, or whatever.

> Brandon Van Every wrote:
> >
> > Ok, I propose a hex menu interface, a "right click"
> > paradigm.  Instead
> > of all this screwing around with mousing over to some
> > static icon real
> > estate, you right click wherever your mouse is currently
> > at.  Up pops a
> > hex with radius of either 2 or 3, embodying either 7 or 19 selection
> > icons.  It is centered at your cursor so that movement to a
> > selection is
> > minimal.  I *hate* having to be coordinated with conventional
> > rectangular popup menus.
>
> I have no idea what you just said.

I guess I'll chalk that up to the drink.  I'll try briefly again.

A game requires a certain number of mouseclicks to be performed.
Mouseclicks can slow down the game in a few ways.  (1) too many
mouseclicks, such as having to pull up multiple layers of menus to get
some task accomplished.  (2) too much time spent scrolling across the
screen to get to the right button or icon.  (3) too much coordination
required to make selections, such as having to hold down buttons to
drag, while maneuvering through fairly narrow popup menu regions.  Make
a mistake, and you have to start over again.

Popup menus are a good strategy for dealing with (2).  If they don't
have multiple expanding components, i.e. if we KISS, then (3) is solved.
If the game mechanics are simplified, and a small number of icons in a
popup menu can implement the mechanics in a given context, then (1) is
solved.

So, my variation on the idea of a popup menu, is to create a hex of
icons right over wherever you mouseclick.  A hex of radius = 2 would
have 7 icons.  A hex of radius = 3 would have 19 icons.  But... on
second thought it may be better to just knock together a rectangle of
icons in a hurry.  So you'd have 4, 9, or 16 icons grouped in the popup
menu.  Also, it may not be desireable to cover up the area clicked upon.
Maybe the more conventional approach of having the popup appear "to the
right of what you clicked" will be better in practice.

A right-click popup menu paradigm means you'd "permanently reserve"
almost no screen real estate.  I'm thinking one might want a dedicated
zoom in / out control, but otherwise, nada.  Zip.  The screen is a pure
rectangle.  You'd have a hiding menu bar for pedestrian functions such
as file saving and loading.  All game mechanics are handled by
right-click popup menus.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]