[Freeciv-Dev] Re: non-smallpox idea

[Reinier Post <rp@xxxxxxxxxx>]

On Sun, Nov 25, 2001 at 04:00:47AM -0500, Mike Jing wrote:
> Reinier Post <rp@xxxxxxxxxx> wrote:
> 
> [...]
> >same magnitude.  So the real problem is that the per-city intermediate
> >values, such as 'number of content citizens', 'trade points', etcetera,
> >should have more precision.  The lower precision causes the need for
> >cutoff values.  This means the user will need to remember a whole list
> >of cutoffs, e.g. the fact that the distance cutoff is 12, or the fact
> >that the first citizen in a city is no longer in exactly the 15th city
> >under democracy, or exactly the 12th under Monarchy (if I looked that
> >up correctly - the computation is more complicated).
> >
> >So for a more playable game you'd want 5 or 6 bits more precision
> >and the more continuous effect of variables that this allows.
> 
> More precision alone won't cure the cutoff blues.  The underlying mechanism 
> would have to be drastically different.  I must have been too accustomed to 
> how things work now that on top of my head I can't think of how it would 
> work "smoothly", without annoying cutoffs.  May be you could elaborate a 
> little bit on that?

As a general rule, the computations should be analytical, expressible in
terms of simple algebraic formulas, without any tests and cutoff values.
Continuous, differentiable functions are easier to understand than the
cascades of if statements and tests against cutoff values we have now.
Cutoff values can be scale factors.  E.g. cityfactor is a very useful
parameter but it can be used as a scale factor; cityfactor == 14 would
mean that at 14 cities we have 1 discontent citizen, but its effect would
be continuous: at 7 we would already have 0.5, at 21 we would have 1.5.
Or if you want to use the square root of the number of cities, that's fine
with me, too - everything better than a constant function with jumps at
the threshold points.  Similarly for distance to capital: in this case,
the computation itself already applies the distance as a proportion, but it
effectively works as a cutoff threshold value for small cities because
the target value (number of trade points) has such a low precision.

> >For 'realistic' simulation you need more.  A size 1 city is supposed
> >to have 10,000 inhabitants, so 'the first citizen' really stands for
> >5,000 people.  In order to be consistent with the listed population
> >numbers of cities, effects related to unhappiness should have about
> >16 bits of precision.
> 
> I don't see how counting individual people would help.  For one thing, you 
> can't put 0.5 citizen to work, and make the other 0.5 specialist.

There is nothing against this in principle, but I wasn't assuming
that this would be allowed.  But I can see nothing in Freeciv that
fundamentally relies on the fact that the number of citizens,
or any other city attribute, is an integer.

> As for 
> happiness, you will have to change the rules, e.g. for civil disorder, 
> otherwise you gain nothing from the added precision.

Yes, for local city effects it wouldn't change much.  The differences
only add up when the sum over all cities is used, e.g. for the speed of
technological progress or the total tax raised.  Even then, the net total
probably wouldn't be very different, but the contribution of individual
cities would no longer depend on threshold values, so planning would be
easier.

> Maybe we should just 
> implement the auto-elvis feature and banish civil disorder once and for all. 
> Or maybe we should just get rid of unhappiness altogether.  I know that 
> would make a LOT of people VERY happy.  ;-)

That would make it too easy to play under Democracy, I think.
You also have to take the opponents' happiness into account :)

> [...]
> >2) It simplifies the user interface.
> >
> >This is questionable.  It is not much harder to visualise 22.45% content
> >citizens than it is to visualise 2 out of 5 citizens being content.
> 
> Probably not.  However, as I said above, citizens can't really be split.
> Until that is changed, precision doesn't help anything.  The change from 
> peace to civil disorder will still be a discontinous jump, whether it is 
> from 2 unhappy citizens to 3 or from 44.499% to 44.500%.

Yes.  It doesn't have to be, of course, but if you would make *every*
effect and value in Freeciv continuous in this way, the game would be
totally different.  That's not what I have in mind.

> >It doesn't make the data harder to understand.  Making effects such as
> >distance continuous will make the game easier to understand.
> 
> But distance itself is discontinuous, and can be calculated in different 
> ways (see below).  If you mean the roundoff problem, then it should be 
> easily fixed, as you have pointed out.

Yes - what I meant was to make the effect of distance more continuous,
by reducing the impact of rounding errors.
 
> [...]
> >>Currently under Despotism, the 100% corruption distance is 12 (this is
> >>map_distance, which is the sum of the distances in x and y direction, i.e.
> >>diagnal is counted as 2).
> >
> >Is this a bug?  Units can move diagonally, after all.
> 
> Well, then you can use real_map_distance, if you prefer, where diagnal is 
> counted as 1.  It is counted as 1.5 in Civ2.  Maybe we can just add a 
> civ2_map_distance function.

  civ2_map_distance(args) = AVG(real_map_distance(args),map_distance(args))

[...]

> Again, it can't be really "proportional" until you can count fractional 
> science points.  I can see here more precision would really help, especially 
> during the early game.  The roundoff really makes it tricky when you are 
> trying to balance 1 or 2 trade per city.

Yes, and the same problem appeared in your attempt to cure smallpox,
which turned cityfactor into a variable of great importance.

> For the record, in Civ3 unhappiness no longer depends on the number of 
> cities, but corruption does.  I think it is an improvement since civil 
> disorder is far more devastating and annoying than corruption and waste, at 
> least until you realize how devastating corruption and waste can be in Civ3. 
>   :-)

Well, that's just a matter of tuning variables such as cityfactor, isn't it ...
 
> Mike

-- 
Reinier