Weird fuel behavior

Weird fuel behavior

[Robert Goulding]

I've just noticed this in the last few days, while I've been playing a very
long Modern game (latest WinTCL from CVS).  When it is time to move a bomber
in mid-flight, I often find that it has fuel 30/30, even though it has been
out from base for at least a turn.  Also, just now I moved an infantry which
was down to 1/6 fuel; the next turn it had 2/6 (and no other units were
nearby to transfer fuel).

One other thing about the modern game.  I find that mines repeatedly
disappear, so I have to keep re-laying them again and again with an engineer
or mine ship.  And no, no enemy units are bumping into them.

R.

Re: Weird fuel behavior

[Hans Ronne]

>I've just noticed this in the last few days, while I've been playing a very
>long Modern game (latest WinTCL from CVS).  When it is time to move a bomber
>in mid-flight, I often find that it has fuel 30/30, even though it has been
>out from base for at least a turn.  Also, just now I moved an infantry which
>was down to 1/6 fuel; the next turn it had 2/6 (and no other units were
>nearby to transfer fuel).

What you are seing is simply my new resupply code, which is actually
working, unlike the old code. From modern.g:

(table out-length
  (u* food 4)
  (coal-mine coal 4)
  (iron-mine iron-ore 4)
  (cities coal 4)
  ((oil-field oil-platform) oil 6)
  (cities oil 6)
  (refinery petrol 6)
  (cities petrol 6)
  (sawmill lumber 6)
  (steel-mill steel 6)
  )

(table in-length
  (u* food 4)
  (steel-mill coal 4)
  (steel-mill iron-ore 4)
  (cities coal 4)
  (oil-tanker oil 6)
  (refinery oil 6)
  (cities oil 6)
  (u* petrol 6)
  (engrs lumber 6)
  (engrs steel 6)
  )

What this means is that any unit can (and now will) resupply petrol if it
comes within 6 cells of a city or refinery. It is a little strange that
airplanes are allowed to resupply in mid-flight, but this is how the modern
game works.

>One other thing about the modern game.  I find that mines repeatedly
>disappear, so I have to keep re-laying them again and again with an engineer
>or mine ship.  And no, no enemy units are bumping into them.

Your poor miners are probably starving to death because you neglect to feed
them:

(table base-consumption
  (u* food 1)

If they are within 4 cells of a city thet will get their won food (see the
above table) but otherwise you have to resupply them in some other way.

Hans

Re: Weird fuel behavior

[Robert Goulding]

From: "Hans Ronne" <hronne@comhem.se>
To: "Robert Goulding" <Goulding.2@nd.edu>
Cc: <xconq7@sources.redhat.com>
Sent: Saturday, July 17, 2004 4:47 AM
Subject: Re: Weird fuel behavior


> >I've just noticed this in the last few days, while I've been playing a
very
> >long Modern game (latest WinTCL from CVS).  When it is time to move a
bomber
> >in mid-flight, I often find that it has fuel 30/30, even though it has
been
> >out from base for at least a turn.  Also, just now I moved an infantry
which
> >was down to 1/6 fuel; the next turn it had 2/6 (and no other units were
> >nearby to transfer fuel).
>
> What you are seing is simply my new resupply code, which is actually
> working, unlike the old code. <snip>
> What this means is that any unit can (and now will) resupply petrol if it
> comes within 6 cells of a city or refinery. It is a little strange that
> airplanes are allowed to resupply in mid-flight, but this is how the
modern
> game works.
>
OK

> >One other thing about the modern game.  I find that mines repeatedly
> >disappear, so I have to keep re-laying them again and again with an
engineer
> >or mine ship.  And no, no enemy units are bumping into them.
>
> Your poor miners are probably starving to death because you neglect to
feed
> them:
>
OK, but when I click on a mine in survey mode or it's active in mood mode,
there is no indication that food is running short.

> If they are within 4 cells of a city thet will get their won food (see the
> above table) but otherwise you have to resupply them in some other way.
>
How do I feed them?  I tried hitting 't' when there were other units close
by, but it had no effect.

Robert (who, despite the dying mines, managed to win the game late last
night),

Re: Weird fuel behavior

[Hans Ronne]

>OK, but when I click on a mine in survey mode or it's active in mood mode,
>there is no indication that food is running short.

You mean it doesn't say SupplyLow in the unit info pane? Then food or
petrol shortage is not the reason why they disappear.

>> If they are within 4 cells of a city thet will get their won food (see the
>> above table) but otherwise you have to resupply them in some other way.
>>
>How do I feed them?  I tried hitting 't' when there were other units close
>by, but it had no effect.

Try moving a mobile unit that has plenty of food and petrol adjacent to the
mine, and then just let it sit there for a turn or two.

Hans

Re: Weird fuel behavior

[Robert Goulding]

----- Original Message ----- 
From: "Hans Ronne" <hronne@comhem.se>
To: "Robert Goulding" <Goulding.2@nd.edu>
Cc: <xconq7@sources.redhat.com>
Sent: Saturday, July 17, 2004 9:12 AM
Subject: Re: Weird fuel behavior


> >OK, but when I click on a mine in survey mode or it's active in mood
mode,
> >there is no indication that food is running short.
>
> You mean it doesn't say SupplyLow in the unit info pane? Then food or
> petrol shortage is not the reason why they disappear.
>
Nope, I just tried it again and they really do seem to be just disappearing.
I tried starting the modern game, put all cities asleep except one, then
started building engineers and laying mines.  Sure enough, after you get a
few in the area (that seems to be required) they start disappearing; and so
far I don't see any supply problem and there is no indication of what has
happened in the messages pane.  (BTW, after you make a mine, they are
highlighted in move mode to take a command - I always just 's' them - is
that right?).

Robert.

Re: Weird fuel behavior

[Hans Ronne]

>----- Original Message -----
>From: "Hans Ronne" <hronne@comhem.se>
>To: "Robert Goulding" <Goulding.2@nd.edu>
>Cc: <xconq7@sources.redhat.com>
>Sent: Saturday, July 17, 2004 9:12 AM
>Subject: Re: Weird fuel behavior
>
>
>> >OK, but when I click on a mine in survey mode or it's active in mood
>mode,
>> >there is no indication that food is running short.
>>
>> You mean it doesn't say SupplyLow in the unit info pane? Then food or
>> petrol shortage is not the reason why they disappear.
>>
>Nope, I just tried it again and they really do seem to be just disappearing.
>I tried starting the modern game, put all cities asleep except one, then
>started building engineers and laying mines.  Sure enough, after you get a
>few in the area (that seems to be required) they start disappearing; and so
>far I don't see any supply problem and there is no indication of what has
>happened in the messages pane.  (BTW, after you make a mine, they are
>highlighted in move mode to take a command - I always just 's' them - is
>that right?).
>
>Robert.

Well, since you are one of the few who use the Mac interface, maybe we can
take advantage of the recently discussed History window. Does it say
anything about your mines, like "mines at (x,y) starved to death"?

Hans

Re: Weird fuel behavior

[Robert Goulding]

----- Original Message ----- 
From: "Hans Ronne" <hronne@comhem.se>
To: "Robert Goulding" <Goulding.2@nd.edu>
Cc: <xconq7@sources.redhat.com>
Sent: Saturday, July 17, 2004 3:28 PM
Subject: Re: Weird fuel behavior


> >----- Original Message -----
> >From: "Hans Ronne" <hronne@comhem.se>
> >To: "Robert Goulding" <Goulding.2@nd.edu>
> >Cc: <xconq7@sources.redhat.com>
> >Sent: Saturday, July 17, 2004 9:12 AM
> >Subject: Re: Weird fuel behavior
> >
> >
> >> >OK, but when I click on a mine in survey mode or it's active in mood
> >mode,
> >> >there is no indication that food is running short.
> >>
> >> You mean it doesn't say SupplyLow in the unit info pane? Then food or
> >> petrol shortage is not the reason why they disappear.
> >>
> >Nope, I just tried it again and they really do seem to be just
disappearing.
> >I tried starting the modern game, put all cities asleep except one, then
> >started building engineers and laying mines.  Sure enough, after you get
a
> >few in the area (that seems to be required) they start disappearing; and
so
> >far I don't see any supply problem and there is no indication of what has
> >happened in the messages pane.  (BTW, after you make a mine, they are
> >highlighted in move mode to take a command - I always just 's' them - is
> >that right?).
> >
> >Robert.
>
> Well, since you are one of the few who use the Mac interface, maybe we can
> take advantage of the recently discussed History window. Does it say
> anything about your mines, like "mines at (x,y) starved to death"?
>

Actually, I'm playing this on the WinTCL interface (being also one of the
few who plays on Windows...); my beloved Mac is at work.  But will try it
out next time I'm in the office.  BTW, on the Win interface, is there any
way to get this information (eg via the debugging output)?

Robert.

Re: Weird fuel behavior

[Hans Ronne]

>Actually, I'm playing this on the WinTCL interface (being also one of the
>few who plays on Windows...); my beloved Mac is at work.  But will try it
>out next time I'm in the office.  BTW, on the Win interface, is there any
>way to get this information (eg via the debugging output)?

You have the event log in the saved game file. It looks like this:

(evt 0 log-started all)
(evt 0 game-started all)
(evt 1 unit-created 2 1 204)
(evt 1 unit-captured 3 -2 -32 1)
(evt 1 unit-created 4 2 205)
(evt 1 unit-created 8 3 -46)
(evt 1 unit-captured 9 -3 -57 3)
(evt 1 unit-created 16 4 207)
(evt 1 unit-captured 17 -4 71 4)
(evt 1 unit-damaged 8 -5 2 1)
(evt 1 unit-killed 8 -5 -1)

So if you know how to read raw event data you can figure out what happened
to your mines. But reading the History window is a lot easier.

Hans

Re: Weird fuel behavior

[Robert Goulding]

> You have the event log in the saved game file. It looks like this:
>

Well, sure enough, I saved a game straight after a mine disappeared and
found in the event log:

(evt 5 unit-starved 2 -3 -1)

which is indeed the turn that the mine disappeared.  But I still think
something weird is going on here.  I've never seen a 'supply low' message on
a mine.  I guess it may have come up the turn before the mine disappears,
but the mines themselves often only last 2-3 turns - it's hardly possible to
be constantly checking every mine you make as soon as you make it.  Also, I
have seen mines disappear as one of my fully-supplied ships goes past it.
Finally, it seems strange to me that food should be such a crucial part of
the Modern game, but nowhere in the unit information are you told how much
food any unit has.  (Actually, could this be a bug with the TCL interface -
levels of food are not being displayed, nor warnings of low food supply?
What happens in the Mac interface (which I will check on myself at work)?).

Last couple of things - I've still seen infantry being refuelled when there
were *no* other units or towns nearby.  And (this may be normal - I haven't
played enough to know) I find that some of my towns get completely exhausted
of fuel (usually 1 or 2 towns per game) while the others apparently have
inexhaustible supplies, their fuel level never dropping from full no matter
how many bombers I refuel there.

Robert.

Re: Weird fuel behavior

[Hans Ronne]

>> You have the event log in the saved game file. It looks like this:
>>
>
>Well, sure enough, I saved a game straight after a mine disappeared and
>found in the event log:
>
>(evt 5 unit-starved 2 -3 -1)
>
>which is indeed the turn that the mine disappeared.  But I still think
>something weird is going on here.

First, to clear up some confusion, I assume you are not playing modern.g
("Modern Times") but lhs.g ("Modern Game") since only the latter game has
mines. My previous comments were about modern.g, but most of them apply
also to lhs.g.

>I've never seen a 'supply low' message on a mine.

The critical material for mines is ammo:

(table hp-per-starve
  ((i f b) fuel 1.00)
  ;; Immobilized tanks eventually rust...
  (armor fuel 0.05)
  (ship fuel 0.10)
  (places fuel (0.05 0.05 0.05 0.0))
  (m ammo 0.25)
  )

Now, what this table means is that the mine has a 25% chance each turn of
loosing one hp if it is out of ammo. Since it only has 1 hp (and room for 1
ammo) it is either filled up with ammo and safe, or empty and subject to
random destruction. This may be why you don't see a SupplyLow warning.

>Last couple of things - I've still seen infantry being refuelled when there
>were *no* other units or towns nearby.

I don't know about infantry, but tanks are able to refuel themselves in
this game:

(table base-production
  (ground fuel 1)
  ;; This is not too realistic, but otherwise keeping tanks fueled
  ;; is a major hassle.  This is supposed to be a game, not an
  ;; exercise in logistics (play "empire.g" if you want that).
  (a fuel 2)
  (places fuel (10 20 50 0))
  (places ammo (5 10 20 0))
  )

If you really saw an infantry unit refueling my guess is still that it got
the fuel from a nearby unit.

  And (this may be normal - I haven't
>played enough to know) I find that some of my towns get completely exhausted
>of fuel (usually 1 or 2 towns per game) while the others apparently have
>inexhaustible supplies, their fuel level never dropping from full no matter
>how many bombers I refuel there.

The productivity of a town depends on where it is located:

(table productivity
  ;; Plains are assumed to be settled and have fuel stocks.
  (i (swamp desert mountains) 0)
  ;; It Tis* worthwhile to make players think about logistics
  ;; when operating in the desert.
  (a desert 0)
  (B land (0 100 50 20 20))
  (T land (0 100 50 20 20))
  (@ land (0 100 50 20 20))
  )

Hans

Re: Weird fuel behavior

[Eric McDonald]

Hans Ronne wrote:

> First, to clear up some confusion, I assume you are not playing modern.g
> ("Modern Times") but lhs.g ("Modern Game") since only the latter game has
> mines. My previous comments were about modern.g, but most of them apply
> also to lhs.g.

With the Tcl/Tk interface, I get a warning when trying to load lhs. 
Xconq says that it cannot find the image for 'radar'. I don't know if 
this is related to the image-loading changes that were recently made, or 
if this has been there all along. I haven't investigated what the cause 
of the problem is yet, However, I do note that the image for 'radar' 
does show up in the unit list once that game has finished loading.

> (table hp-per-starve
>   ((i f b) fuel 1.00)
>   ;; Immobilized tanks eventually rust...
>   (armor fuel 0.05)
>   (ship fuel 0.10)
>   (places fuel (0.05 0.05 0.05 0.0))
>   (m ammo 0.25)
>   )

We shouldn't have to resort to quoting GDL when explaining a game's 
behavior.

I see that this table is not described by the help system. I will add it 
once I get back into the utype descriptions as part of the help system 
overhaul.

I probably would already be working on the utype descriptions again, if 
I hadn't ended up spending part of this weekend in the Rockies. Now that 
I am back down to only 1 mile above sea level again, I suppose I should 
get back to some Xconq hacking....

Eric

Re: Weird fuel behavior

[Hans Ronne]

>With the Tcl/Tk interface, I get a warning when trying to load lhs.
>Xconq says that it cannot find the image for 'radar'.

This seems to be a bug in the game module, which lists an empty string as
the image name:

(unit-type radar (image-name "") (char "r")
  (help "looks for units"))
(unit-type artillery (image-name "pz-how") (char "A")
  (help "blows things up at a distance"))

However, the correct image is eventually loaded using the unit type name as
a backup, so the warning is a little premature.

>We shouldn't have to resort to quoting GDL when explaining a game's
>behavior.

Well, one purpose of this list is to teach those who are interested how to
use GDL, which is why I frequently give examples. But more documentation
would also be helpful.

>I see that this table is not described by the help system. I will add it
>once I get back into the utype descriptions as part of the help system
>overhaul.

Good.

Hans

Re: Weird fuel behavior

[Robert Goulding]

>
> First, to clear up some confusion, I assume you are not playing modern.g
> ("Modern Times") but lhs.g ("Modern Game") since only the latter game has
> mines. My previous comments were about modern.g, but most of them apply
> also to lhs.g.

Yes, should have been more exact - it is lhs.g.

>
> >I've never seen a 'supply low' message on a mine.
>
> The critical material for mines is ammo:
>
> (table hp-per-starve
>   ((i f b) fuel 1.00)
>   ;; Immobilized tanks eventually rust...
>   (armor fuel 0.05)
>   (ship fuel 0.10)
>   (places fuel (0.05 0.05 0.05 0.0))
>   (m ammo 0.25)
>   )
>
> Now, what this table means is that the mine has a 25% chance each turn of
> loosing one hp if it is out of ammo. Since it only has 1 hp (and room for
1
> ammo) it is either filled up with ammo and safe, or empty and subject to
> random destruction. This may be why you don't see a SupplyLow warning.
>

All right, last question then I'll shut up about this.  The mines are all
produced with ammo 0/1; do I need to get a unit onto their hex and 'g'ive
them some ammo each time I create one?

Thanks for the information about cities etc; there is a lot to learn about
this game!

Robert.

Re: Weird fuel behavior

[Jim Kingdon]

> We shouldn't have to resort to quoting GDL when explaining a game's 
> behavior.

A nice ideal to have.

Better documentation/help is always good, but there's also the
question of the user interface showing the user what happened.  Right
now, you kind of need to know the rules of xconq (and your particular
game) to understand it, and of course it would be better if xconq
helped you learn said rules by showing them in action as clearly as
possible.

It's not an easy problem.  Having a huge number of messages somewhere
of the sort ("unit xxx starved" etc) won't work (unless perhaps for
rare events, which starving might be).  Maybe being able to click on a
unit and issue a command saying "what's going on with this unit?"
(e.g. "tried to attack last turn, but didn't have ammo").  Or I guess
it would be a cell in the case of a now-vanished unit...

Re: Weird fuel behavior

[Hans Ronne]

>It's not an easy problem.  Having a huge number of messages somewhere
>of the sort ("unit xxx starved" etc) won't work (unless perhaps for
>rare events, which starving might be).  Maybe being able to click on a
>unit and issue a command saying "what's going on with this unit?"
>(e.g. "tried to attack last turn, but didn't have ammo").  Or I guess
>it would be a cell in the case of a now-vanished unit...

Interestingly, that feature is already available in the Mac interface :-).
If you ctrl-click on a unit, it brings up a small closeup (floating window)
where you can examine its plans etc. Basically the same information as in
the unit info pane. There are two advantages over the latter, however.
First, these closeups take much less screen space, and only when you need
them. Second you can open several of them and study how units interact with
each other.

Unlike the History window, this is an extremely useful feature. I use it
all the time while debugging new kernel code. It's the only way to grasp
what is really going on in a complex situation with several interacting
units. I have therefore given serious thought to porting the closeups to
the tcltk interface. The only thing that has held me off so far is the poor
support for floating windows in tcltk. It took a lot of work to get the
research popup window to behave the way it does, and it is still inferior
to a real floating window.

Hans

Re: Weird fuel behavior

[Eric McDonald]

Jim Kingdon wrote:

> Better documentation/help is always good, but there's also the
> question of the user interface showing the user what happened.  Right
> now, you kind of need to know the rules of xconq (and your particular
> game) to understand it, and of course it would be better if xconq
> helped you learn said rules by showing them in action as clearly as
> possible.

I think that there a number of instances where notifications should be 
issued, but are not.

> It's not an easy problem.  Having a huge number of messages somewhere
> of the sort ("unit xxx starved" etc) won't work (unless perhaps for
> rare events, which starving might be).  Maybe being able to click on a
> unit and issue a command saying "what's going on with this unit?"
> (e.g. "tried to attack last turn, but didn't have ammo").  

That would be kind of like the battle summary in Strategic Conquest (c. 
1984), except for individual units instead of all of them.
I still remember that Macintalk-synthesized voice narrative:
   "Bat-tle sum-mar-ee. Click to con-tin-ue."
   "Your dee-stroy-er, strength 1, ree-pelled an at-tack-ing dee-stroy-er."
   "Dee-stroy-er dee-stroyed your dee-stroy-er."
Nostalgia...

>Or I guess
> it would be a cell in the case of a now-vanished unit...

Maybe an unit graveyard window would be useful for displaying pastunits 
and their associated event logs. Have the most recently deceased units 
displayed near the top of a list in the window. This would probably be 
more useful than trying to hunt down the cell where an unit died. (Of 
course, Hans will probably say that the Mac interface already has this 
feature, since it seems to have everything else.)

Eric

Re: Weird fuel behavior

[Jim Kingdon]

> I think that there a number of instances where notifications should be 
> issued, but are not.

I don't like the notifications as they exist now because there is also
lots of noise, as well as useful information.  So if we get rid of
some of the useless ones while we add new ones, I might be with you.
My favorite example of a useless one is when you hit "t" for take and
it says "unit got 5 fuel" - I can see telling the user somehow, but
not putting into a history along with unexpected occurrences.  Perhaps
an even better example is the "unit completed" messages at the start
of each turn - it isn't as if you need to see those messages so you
can hunt down each one and give it orders - the UI will prompt you for
what each of the new units should do, which is sufficient indication
of their having been created.  And the mess of "unit completed"
messages tends to obscure whatever the AI opponent did at the end of
last turn or the start of this one.

>   "Your dee-stroy-er, strength 1, ree-pelled an at-tack-ing dee-stroy-er."
>   "Dee-stroy-er dee-stroyed your dee-stroy-er."

Sort of, but with a "click for details" on each line.  So the summary
is "Your 15th bomber destroyed the Sudanese 132nd armor", the details
might be:

    Bomber versus armor hit chance starts at 25%.
    This armor is in a city, which gives it 50% protection.
    So the hit chance was 12%.
    The dice were rolled, and got a hit.
    Bomber versus armor damage is 1 hit point.
    The armor started with 1 hit point, so it was left with 0, and was
    destroyed.
    Its material was destoyed with it.... (or wrecking, or whatever
    consequences of destruction would be).

Obviously putting too much information in this window could just lead
to information overload, but I was hoping to at least have enough to
make it clear why something happened (especially to cover mistake or
quasi-mistake situations, like making attacks which have 0% or almost
0% chance of success, or perhaps defensive fortifications which were
useless in the particular situation, or something like that).

> Maybe an unit graveyard window would be useful for displaying pastunits 
> and their associated event logs. Have the most recently deceased
> units 

I like this one.

Units going away is one of the particularly distressing and
(potentially) surprising events, so having a window for it seems to
make sense.

Re: Weird fuel behavior

[Jim Kingdon]

> If you ctrl-click on a unit, it brings up a small closeup (floating window)
> where you can examine its plans etc. Basically the same information as in
> the unit info pane.

So you could open these for a few units and keep them open and they'd
get updated as the game proceeds?  If so, that sounds like the key
advantage - watching them change, rather than just getting a static
view of a unit.  The target audience for this feature is people who
don't understand how game events are affecting their units.  (This
includes game designers, kernel debuggers, etc, not just newbie
players).  That's why I proposed something which was more explicitly
about change and action than about unit state.  But having a unit
state window that you can see change might not be such a bad way of
getting at change (xconq could even boldface numbers which are changed
recently or something).

> The only thing that has held me off so far is the poor support for
> floating windows in tcltk. It took a lot of work to get the research
> popup window to behave the way it does, and it is still inferior to a
> real floating window.

Well, I understand the reluctance.  I think maybe the research window
has been improved since the last time I played a game which has
research, but I remember quirks (like not bringing it to the front
when desired or something, I don't really remember fully and some of
them might be related to how research interacts with turns and
movement, not just the floating-ness of the window as such).

In SDL, I assume we'd get to write our own window code (or use one of
the many libraries out there which are designed to go on top of SDL).
I don't know whether that is better or worse than having (possibly
buggy or quirky) floating windows provided for us.

Re: Weird fuel behavior

[Hans Ronne]

>> If you ctrl-click on a unit, it brings up a small closeup (floating window)
>> where you can examine its plans etc. Basically the same information as in
>> the unit info pane.
>
>So you could open these for a few units and keep them open and they'd
>get updated as the game proceeds?  If so, that sounds like the key
>advantage - watching them change, rather than just getting a static
>view of a unit.

That is how it works. Very helful both for debugging and for game design.

>> The only thing that has held me off so far is the poor support for
>> floating windows in tcltk. It took a lot of work to get the research
>> popup window to behave the way it does, and it is still inferior to a
>> real floating window.
>
>Well, I understand the reluctance.  I think maybe the research window
>has been improved since the last time I played a game which has
>research, but I remember quirks (like not bringing it to the front
>when desired or something

This has been fixed now. But it took some work to get it right.

, I don't really remember fully and some of
>them might be related to how research interacts with turns and
>movement, not just the floating-ness of the window as such).
>
>In SDL, I assume we'd get to write our own window code (or use one of
>the many libraries out there which are designed to go on top of SDL).
>I don't know whether that is better or worse than having (possibly
>buggy or quirky) floating windows provided for us.

SDL doesn't support multiple windows at all. So I guess one would have to
implement something like a row of unit info panes in order to examin
several units at once.

Hans

Re: Weird fuel behavior

[Eric McDonald]

On Tue, 20 Jul 2004, Hans Ronne wrote:

> >In SDL, I assume we'd get to write our own window code (or use one of
> >the many libraries out there which are designed to go on top of SDL).
> >I don't know whether that is better or worse than having (possibly
> >buggy or quirky) floating windows provided for us.
> 
> SDL doesn't support multiple windows at all. So I guess one would have to
> implement something like a row of unit info panes in order to examin
> several units at once.

If this is true, then it is somewhat of a blow against SDL. 
However, I don't really intend to work on the "pure" SDL interface 
so much as an [appropriately ifdeffed] SDL/GUI toolkit (possibly 
GTK) hybrid, __sometime after 7.5 is released.

Eric

Re: Weird fuel behavior

[Hans Ronne]

>On Tue, 20 Jul 2004, Hans Ronne wrote:
>
>> >In SDL, I assume we'd get to write our own window code (or use one of
>> >the many libraries out there which are designed to go on top of SDL).
>> >I don't know whether that is better or worse than having (possibly
>> >buggy or quirky) floating windows provided for us.
>>
>> SDL doesn't support multiple windows at all. So I guess one would have to
>> implement something like a row of unit info panes in order to examin
>> several units at once.
>
>If this is true, then it is somewhat of a blow against SDL.

Being used to the Mac interface with its multitude of windows I thought so
at first. However, Stan long ago pointed out that professional games almost
never use multiple windows since "users don't like Office-type
applications". And I think he has a point here. You can go a long way with
just one screen and panes instead, provided that the interface code is fast
and not clunky, like Tcl unfortunately is. I think that the SDL interface,
though still in its infancy, proves this point.

What you can do with SDL, I believe, is transparent overlays and such. Not
the same thing as a floating window but a decent alternative.

Hans

Re: Weird fuel behavior

[Eric McDonald]

On Tue, 20 Jul 2004, Hans Ronne wrote:

> at first. However, Stan long ago pointed out that professional games almost
> never use multiple windows since "users don't like Office-type
> applications". 

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.

>And I think he has a point here. You can go a long way with
> just one screen and panes instead, 

Well, I think even panes should be kept to a minimum. Believe me, 
I like the "clean rectangle" concept that SDL offers, but there 
can (and should, IMO) be windows that can be popped up demand to 
display various useful summaries and sets of details. The Tcl/Tk 
interface is way too cluttered and some things, such as the unit 
list, have minimal usefulness (construction and change-type 
selections should be done through a popup dialog window, and not  
through the unit list).

The driving concept should be: which info is so useful that it 
should always be displayed, and which info is only occasionally 
useful (but useful nonetheless) so that it should be kept in an 
on-demand display?

> What you can do with SDL, I believe, is transparent overlays and such. Not
> the same thing as a floating window but a decent alternative.

This might be acceptable for a pure SDL implementation, if someone 
felt like taking the effort to make such "windows". My guess is 
that true popup windows could be much more rapidly implemented 
(with expected UI components) using something like GTK.

Eric 

Re: Weird fuel behavior

[Stan Shebs]

Eric McDonald wrote:

>On Tue, 20 Jul 2004, Hans Ronne wrote:
>
>
>>at first. However, Stan long ago pointed out that professional games almost
>>never use multiple windows since "users don't like Office-type
>>applications". 
>>
>
>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.
Certain commands will pop up screen-filling lists, and there are
smaller popups for dialogs.

Partly this is evolutionary - PC games had to run on DOS for a long
time, and so people got used to it, but I think there are deeper
reasons, otherwise you'd have companies advertising "new, using
revolutionary multi-window interface!" Two reasons that I think
drive the trend:

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

* suspension of disbelief - A-list games, of whatever genre, always
work hard to get game-specific atmosphere into the rectangle of the
screen. Funny thing is, you always hear that users want interfaces
to be consistent "so they don't have to learn a new one", and yet
they'll never refuse to play a hot new game because its interface is
unlike any they've seen before. Players will do whatever it takes to
achieve that moment of sublime game satisfaction, and it's easier to
get to that moment if they're immersed in the game world.

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.

Stan

Re: Weird fuel behavior

[Eric McDonald]

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

Re: Weird fuel behavior

[Hans Ronne]

>Well, I think even panes should be kept to a minimum. Believe me,
>I like the "clean rectangle" concept that SDL offers, but there
>can (and should, IMO) be windows that can be popped up demand to
>display various useful summaries and sets of details. The Tcl/Tk
>interface is way too cluttered and some things, such as the unit
>list, have minimal usefulness (construction and change-type
>selections should be done through a popup dialog window, and not
>through the unit list).
>
>The driving concept should be: which info is so useful that it
>should always be displayed, and which info is only occasionally
>useful (but useful nonetheless) so that it should be kept in an
>on-demand display?

I certainly agree with that. The first thing I do when I launch a game,
whether we are talking about the Mac or tcltk interface, is to minimize or
get rid of most of the panes (you can turn most them off completely in the
Mac interface). The only thing I want on the screen is the map, a small
floating world map, and a small floating window with the Notices.

That being said, I do like to bring up stuff like the List or Help window
now and then. But when I do, I focus exclusively on those windows and don't
use the map. This is why I think you can actually do without multiple
windows.

So here is how I think the SDL interface should work eventually. You have
one big map that covers most of the screen (like now). Anything that you
need *together* with the map should be at the bottom, like it is now. This
would include the world map and the Notices feedback. I don't think you
need on-screen access to the unit info pane or construction buttons, which
are there now. But this need may differ from game to game and should
perhaps be configurable (as in the Mac interface today).

Anything else should be brought up by switching not to another window, but
to another screen. If you want to consult the Help node, you don't need the
map at the same time, so let it go and bring up a help sceeen that contains
nothing but help. Same for advanced unit closeups. If you want to
micro-manage a unit you don't need to use the map at the same time.

The difference between switching to another window and to another screen
may seem like a technicality, but I do think it is important for the game
experience. As Stan just pointed out, it's all about suspension of
disbelief. As long as you don't leave the game and its full-screen window,
you are immersed into the game and can forget about the rest of the world.
Once you start to navigate between windows you are back at your computer
desktop, and the spell is broken.

What is very important if this strategy is to work is that it is easy and
fast to switch between screens. A single keystroke should do the job. And
the switch should happen instantly.

Finally, I'm all for popup windows if they can be implemented. This is how
the Mac interface works, where not only research but also unit build tasks
are managed through popups, and I think it is easier to use than the tcltk
interface. It is multiple full-size windows that I think should be avoided.

Hans





















>> What you can do with SDL, I believe, is transparent overlays and such. Not
>> the same thing as a floating window but a decent alternative.
>
>This might be acceptable for a pure SDL implementation, if someone
>felt like taking the effort to make such "windows". My guess is
>that true popup windows could be much more rapidly implemented
>(with expected UI components) using something like GTK.
>
>Eric

Re: Weird fuel behavior

[Hans Ronne]

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

I doubt that. It was pointed out a long time ago that most computer games
have this stuff in arow at the bottom, just where the instrument panel in a
car is located, and probably for the same reason. I don't think most users
would prefer a square map window, but rather a wider "panoramic" view. This
is after all what we are used to since we live on a surface (the Earth) so
the human brain is probably hard-wired to like it.

Hans

Re: Weird fuel behavior

[Eric McDonald]

Hans Ronne wrote:

>>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?
> 
> 
> I doubt that. It was pointed out a long time ago that most computer games
> have this stuff in arow at the bottom, just where the instrument panel in a
> car is located, and probably for the same reason. 

Like the fact that the firewall separating the cockpit from the engine 
compartment is located there (in most cars)? ;-) Why put the dash board 
near the roof of the car or off to the side, if the bottom is already 
blocked? I think that could simply be a matter of not wasting viewable area.

>I don't think most users
> would prefer a square map window, but rather a wider "panoramic" view. 

All those houses with square windows....

>This
> is after all what we are used to since we live on a surface (the Earth) so
> the human brain is probably hard-wired to like it.

The reason why I posed the question is because a similar evolutionary 
conjecture had crossed my mind as well. However, I was hoping that 
someone would chime in with an ergonomic or interface design study that 
would more strongly suggest a resolution to the wide rectangle vs. 
square question.

Eric

Re: Weird fuel behavior

[Eric McDonald]

Hans Ronne wrote:

>>The driving concept should be: which info is so useful that it
>>should always be displayed, and which info is only occasionally
>>useful (but useful nonetheless) so that it should be kept in an
>>on-demand display?

>  The only thing I want on the screen is the map, a small
> floating world map, and a small floating window with the Notices.

My desire is pretty much the same.

> That being said, I do like to bring up stuff like the List or Help window
> now and then. But when I do, I focus exclusively on those windows and don't
> use the map. This is why I think you can actually do without multiple
> windows.

Right. I am not suggesting that we have multiple windows operating at 
the same time. I think the key here is "modal operation".

> So here is how I think the SDL interface should work eventually. You have
> one big map that covers most of the screen (like now).

Yes.

> Anything that you
> need *together* with the map should be at the bottom, like it is now. 

Yes.

>This
> would include the world map and the Notices feedback. 

Yes.

>I don't think you
> need on-screen access to the unit info pane

I would suggest that hovering the cursor over an unit for a certain 
number of milliseconds should bring up something like a Windows tooltip 
that would display vital stats. Or, alternatively, one could right 
click, and perhaps get a "hex menu" (as suggested by van Every in his 
apparently inebriated state) surrounding the unit (possibly with a hole 
punched through the center so that the unit would be a cameo inside the 
menu), __where one of the options would be to bring up an unit info popup.

> or construction buttons, which
> are there now. 

I agree that the construction buttons are probably not needed. They are 
a waste of mouse movement. However, a newbie (who likely hasn't RTFM, as 
he/she ought to have) must have an obvious way to initiate construction. 
One idea that has been brewing in my head for about half a year now 
would be to allow game designers to designate which unit types would 
have construction auto popups. Meaning, whenever an unit is idle and can 
construct something, then a construction dialog would automatically 
popup. We would, of course, want to provide a "do not show this window 
again" checkbox for Xconq veterans.

> Anything else should be brought up by switching not to another window, but
> to another screen. If you want to consult the Help node, you don't need the
> map at the same time, so let it go and bring up a help sceeen that contains
> nothing but help.

In the case of help I would say that this is probably fine.
Things like construction, I am less sure about. One may still wish to 
view the world map (with a little blinking box indicating the 
constructors present location on the big scheme) to get a better feel 
for what types of units to create/build.

> The difference between switching to another window and to another screen
> may seem like a technicality, but I do think it is important for the game
> experience. As Stan just pointed out, it's all about suspension of
> disbelief. As long as you don't leave the game and its full-screen window,
> you are immersed into the game and can forget about the rest of the world.
> Once you start to navigate between windows you are back at your computer
> desktop, and the spell is broken.

If a window with the same theme as the game "root window"/screen pops up 
in the center, I don't think this would be "disenchanting".

> What is very important if this strategy is to work is that it is easy and
> fast to switch between screens. A single keystroke should do the job. And
> the switch should happen instantly.

I agree. Windows should popup just as fast, and be out of the way of 
anything that one might wish to reference while using the window.

> where not only research but also unit build tasks
> are managed through popups, 

These are both good examples of where popup windows would come in handy.

>and I think it is easier to use than the tcltk
> interface. It is multiple full-size windows that I think should be avoided.

I am not suggesting mutiple, full-size windows operating simulataneously.

Using a GUI toolkit does provide certain advantages however. To list two 
major ones:
(1) Pre-built GUI components.
(2) Layout management.

Eric

Action-Notices list

[Elijah Meeks]

The design manual doesn't seem to have any entries for
the various action-notices and event-notices.  I've
cribbed from games that use this feature but I was
wondering if anyone knew all the actions that could be
referenced, especially for event notices.


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: Action-Notices list

[Eric McDonald]

Elijah Meeks wrote:

> The design manual doesn't seem to have any entries for
> the various action-notices and event-notices.  I've
> cribbed from games that use this feature but I was
> wondering if anyone knew all the actions that could be
> referenced, especially for event notices.

I think the two best authorities, as of now, are the 'kernel/action.def' 
and 'kernel/history.def' files. They list the names of all possible 
actions and events, respectively.

In the case of actions, you will see the action's name in quotes right 
after "DEF_ACTION(".

In the case of events, you will see the event's name in quotes right 
after "DEF_HEVT(".

Eric