public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Eric McDonald <mcdonald@phy.cmich.edu>
To: Stan Shebs <shebs@apple.com>
Cc: Hans Ronne <hronne@comhem.se>,  xconq7@sources.redhat.com
Subject: Re: Weird fuel behavior
Date: Wed, 21 Jul 2004 00:47:00 -0000	[thread overview]
Message-ID: <40FDB97B.1090902@phy.cmich.edu> (raw)
In-Reply-To: <40FDA6C6.3000208@apple.com>

Hi Stan,

Stan Shebs wrote:

> Eric McDonald wrote:
>> I think this is true for 3D shooters (such as Unreal) or some simple 
>> (many things are highly automated) realtime strategy games (such as 
>> Warcraft), but not necessarily true for strategy games where there are 
>> multitudes of forces of different kinds to track and manage, and there 
>> is not heavy automation of their actions.
>>
> Theoretically you're right, but in practice nobody actually goes there.
> Consider TOAW (The Operational Art of War), probably the most like
> Xconq in terms of scope and intent. One screen with panes on the side.

I like the idea of panes on the side, as opposed to the bottom or top. 
Makes the aspect ratio of the main map closer to that of a square. 
Question is, are sides the most comfortable for the human eye?

> Certain commands will pop up screen-filling lists, and there are
> smaller popups for dialogs.

This is all I am proposing in terms of windows made from a GUI toolkit.

> * simplicity of play - if you're forced to make everything fit in one
> window, you think harder about how to design the interface for
> efficiency. For instance, instead of switching to another window, make
> a panel display an array of choices represented as icons small enough
> to all fit in the panel.

The problem is that a panel is going to be near the edge of the screen. 
If someone is using the mouse to move units, then he/she either has to 
move the mouse over to the panel (something I am too lazy to do), or 
else take his/her hands off the mouse and use keyboard shortcuts and nav 
keys to make a selection. Whereas, a dialog window can popup centered 
over the playing window, and minimal mouse movement is required.

> One of my expectations for the SDL interface was that module designers
> should be able to supply skins for the interface as well as the game
> images.

I agree wholeheartedly with that goal. I think that skins can be applied 
  to GUI toolkit elements just as readily as to a pane or overlay.

Look at all the folks out there who like showing off screenshots of 
their custom "desktop environments", complete with transparent eterms, 
translucent window title bars, colored log messages scrolling by in the 
root window, and whatnot. They just provide custom pixmaps for the 
windows or something like that. I think I saw somewhere that similar 
hackery can be done on Win32.

Eric

  reply	other threads:[~2004-07-21  0:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-17  9:50 Robert Goulding
2004-07-17  9:57 ` Hans Ronne
2004-07-17 14:16   ` Robert Goulding
2004-07-17 20:06     ` Hans Ronne
2004-07-17 20:31       ` Robert Goulding
2004-07-17 21:13         ` Hans Ronne
2004-07-17 21:31           ` Robert Goulding
2004-07-18 13:07             ` Hans Ronne
2004-07-18 20:20               ` Robert Goulding
2004-07-18 22:14                 ` Hans Ronne
2004-07-18 22:16                   ` Eric McDonald
2004-07-19  2:50                     ` Hans Ronne
2004-07-20  8:05                     ` Jim Kingdon
2004-07-20 13:38                       ` Hans Ronne
2004-07-20 19:19                         ` Jim Kingdon
2004-07-20 19:50                           ` Hans Ronne
2004-07-20 21:36                             ` Eric McDonald
2004-07-20 22:07                               ` Hans Ronne
2004-07-20 23:12                                 ` Eric McDonald
2004-07-21  0:32                                   ` Stan Shebs
2004-07-21  0:47                                     ` Eric McDonald [this message]
2004-07-21  1:11                                       ` Hans Ronne
2004-07-21  1:33                                         ` Eric McDonald
2004-07-24 23:19                                           ` Action-Notices list Elijah Meeks
2004-07-26  1:31                                             ` Eric McDonald
2004-07-21  0:55                                   ` Weird fuel behavior Hans Ronne
2004-07-24 20:50                                     ` Eric McDonald
2004-07-20 15:17                       ` Eric McDonald
2004-07-20 15:40                         ` Jim Kingdon
2004-07-19  3:07                   ` Robert Goulding
2004-07-17 12:47 Hans Ronne
2004-07-19  8:07 Robert Goulding
2004-07-19 18:14 ` Hans Ronne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40FDB97B.1090902@phy.cmich.edu \
    --to=mcdonald@phy.cmich.edu \
    --cc=hronne@comhem.se \
    --cc=shebs@apple.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).