Re: time.g weirdness

[Hans Ronne <hronne at comhem dot se>]

>On Thu, 12 Aug 2004, Jim Kingdon wrote:
>
>> > /* Don't print out storage space if it is set to arbitrarily large
>> > (9999, 999 or 99) as in many games. */
>>
>> Well, that's more problematic, in that it doesn't check storage
>> against consumption, production, etc.
>
>I agree. This is one of the pieces of code I had in mind when I
>suggested that relative infinity would be useful beyond just the
>help system.
>
>> It does seem like an argument for some more real form of infinity
>> (maybe just TABHI).
>
>I agree.

I also agree that a real infinite instead of the bogus ones (99 etc) would
be nice, so if any of you want to give it a try, I'm all for it.

There was one other consideration with the above code, though, and that was
to save space and reduce the clutter in the unit info box (and Mac unit
closeup popup). This is what they would look like in most games before the
change:

Food: 4 / 9999    Minerals: 6 / 9999    Fuel:  2 / 9999    Ideas:  12 / 9999

Typically, the right half of this line would be truncated in the closeups
(which are smaller than the unit info boxes). Now it  says instead:

Food: 4    Minerals: 6    Fuel: 2    Ideas: 12

which is much neater.

Now, if the game designer sets capacity to a bogus infinite, it usually
means that he doesn't expect the ceiling to be hit in a real game. If 99 is
too low, he would use 999 or 9999 instead. This, in turn, means that the
player has no interest in knowing about the capacity. All he needs to know
is that there is no ceiling that he has to worry about. Which is why I
suppressed the printing of bogus infinites.

The weak point here is of course that the game designer may deviate from
this rule, by intention or mistake. Having a relative infinite that
defaults to TABHI, and which is suppressed in most outputs, is therefore a
superior solution.

Hans