Re: fixes to advance.g

[Hans Ronne <hronne at pp dot sbbs dot se>]

>> Well, yeah, something needs to be done about construction.
>
>OK, try #1 was to nuke acp-independent and set "(add places
>acp-per-turn 1)".  This was basically a failure.  One gets the same
>kind of exponential growth in units, it is just that the currency is
>the number of cities rather than ore (and ore becomes completely
>irrelevant, although I didn't try also tweaking
>unit-consumption-per-cp).  Interestingly, the AI seems particularly
>bad at this one (either that or I'm just getting better at advances.g
>in general).

No surprise. The AI runs into problems because it uses the mplayer build
code in that case, which is not very good at handling advanced units. The
acp-independent units use the special AI build code at the end of run.c
instead, which was written for this kind of games. It will be moved to the
mplayer eventually.

>Try #2 will be to set unit-consumption-per-cp to 5 or 10.

Because of the way the acp-independent build code works, I would rather try
increasing the total number of cps, particularly for more advanced units.
As I said, 10 cps was an arbitrary value, just like the 10 rps for each
advance. In fact, both of them were picked to give faster than normal
progress (i started with 20 of each) which I needed when I debugged the
code.

>Try #3 will be to set base-consumption of all units to 1 food, the
>in-length on movers to a positive value (9999?), and the out-length on
>cities to the same.  Note no in-length on cities; don't want to share
>food and ore around.  This is an attempt to implement Stan's
>suggestion of how (pay)CivII does it.

Interesting idea, but I wonder if it would do the job. The whole idea of
unit supply was left out of this game on purpuse, in order not to mess up
the population growth code. What it would do is drain off food so that the
cities do not grow as quickly. However, for things to work as in civ2, one
would have to have the notion of each unit belonging to a home town, which
is not supported right now. Not sure how the supply code would work with an
in-length of 9999. Would it stick with the same city, or always drain the
closest one?

>Idea #4 is the same as #3, but with a new material instead of food.

Maybe we should put back cash again, and use it to pay the troops :-).

Of the above, I think increasing the cps would work best. It would give the
kind of flexibility we need (more advanced units should be harder to make).
Alternatively, one could try to reduce the speed of city growth by
tinkering with unit-consumption-per-size and unit-consumption-to-grow.
These values were also chosen to give faster than normal growth in order to
facilitate debugging. You may have noticed that cities reach their maximal
size rather early in the game, unlike civ2. In fact, I think a combination
of the two (slower city growth and somewhat harder to build more advanced
units) is the way to go.

Hans







Hans Ronne

hronne@pp.sbbs.se