[Freeciv-Dev] Re: Ruleset Development - improvements

[Ben Webb <ben@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, 4 Dec 2001, Petr Baudis wrote:

> Dear diary, on Tue, Dec 04, 2001 at 02:01:57PM CET, I got a letter,
> where Ben Webb <ben@xxxxxxxxxxxxxxxxxxxxxx> told me, that...
> > I'm not sure if the sabotage field is used, but I _think_ it isn't.
> pasky@machine:~/src/freeciv/aiciv/freeciv/ai$ grep -r -- "->sabotage" 
> ../server/
> ../server/ruleset.c:    b->sabotage = secfile_lookup_int(file, "%s.sabotage", 
> sec[i]);
> ../server/ruleset.c:    packet.sabotage = b->sabotage;

        No... that's just reading it from the ruleset. All of the 
necessary information is currently read from the ruleset and then sent to 
the client - it's just that many fields (such as the "effect" field) 
aren't acted upon.

> > the unusual terrain requirements of the Hydro Plant are now read from 
> > the rulesets).
> Shouldn't gates for Hoover Dam be the same, BTW?

        I don't know, not having played the original Civ. As far as I 
recall, wonders can be built anywhere, no matter how silly that may sound 
(e.g. you can build Lighthouse in an inland city). This may have been 
fixed with the inclusion of the part of impr-gen that Sebastian committed, 
however.

> >     With this, most of the Alpha Centauri buildings work in 
> > FreecivAC. (Some Wonders are still non-functional though.)
> That sounds great. Reasons why it wasn't accepted?

        I forget exactly why (I announced the patch back in April). Lack 
of interest mainly, I believe. I think some parts of the code need a bit 
more work anyway, but it'd be nice to have some feedback. ;)

> If it's just lack of review, can you please re-send the patches? (it 
> would be nice to have them splitted into pieces).

        I will attempt to do this at some point over the next week - I'll 
take another look at the code and try to split it up (it's not easy, 'cos 
a lot of parts are interdependent). My aim will be to split the patches 
into a) those which shouldn't "break" anything and could be committed 
immediately and b) those which alter important behaviour (e.g. the 
implementation of happy/content bonuses, etc. alters the way unhappiness 
and disorder is calculated, and could cause problems).

> > - AI support; it should really consider building effects, rather than 
> >   considering building types directly
> That's very nice to say, but much harder to implement. Basically, it's pretty
> hard to tell it universally what granary does, what leonardo workshop does
> and what magellan's does. Not mentioning city walls or even palace.

        No, it's not that hard really (he says confidently). Just rather 
than, when the AI decides it wants extra food, weighing up the cost of 
building a granary, it should instead weigh up the cost of building any 
improvement that confers the "Growth_Food" effect. Since this effect also 
includes an "amount" subfield, it should be trivial to include this amount 
into the weighting without any hard-coding. (I guess a pessimistic way of 
looking at it is that you're replacing hard-coded buildings in the AI with 
hard-coded building effects, but at some point the AI needs to be told 
this stuff in code anyway.)

Oh, and consider the following snippet from advdomestic.c:-

  if (could_build_improvement(pcity, B_LIBRARY))
    values[B_LIBRARY] = sci/2;

  if (could_build_improvement(pcity, B_MARKETPLACE))
    values[B_MARKETPLACE] = (tax + 3*pcity->ppl_taxman +
     pcity->ppl_elvis*wwtv)/2;

        What this is essentially saying is "we want to build a Library if 
we already have plenty of science" and "we want a Marketplace if we have 
plenty of tax income". This assumes that Libraries boost science and 
Marketplaces boost tax. Isn't it more flexible (and more readable!) to 
weight science against the "Science_Bonus" effect and tax against the 
"Tax_Bonus" effect? I think it is. ;)

> You need either a heap of capabilities similiar to the ones units have

This is what the "effect" field in buildings.ruleset does.

> > - Client and server have different ideas of the world (e.g. islands can be 
> >   different in the client, due to unexplored territory) and this can give 
> >   the client incorrect effects
> > - Handling of population size limits (e.g. Aqueduct, Sewer System)
> > - Code optimisation; many algorithms are still O(N**2) in number of 
> >   cities, and we iterate over effects too frequently for my liking
> Anyway, this isn't something so fatal IMHO and can be adjusted on the fly.

        Well, the first problem is the only major one. There's nothing to 
stop you from setting up a building which (for example) acts as a Bank in 
every city in the world (for all civs) but, since the client and server 
calculate effects independently, if you can't see the enemy civ that has 
the "magic" building, your cities will display the wrong luxury score, and 
you'll wonder why the server keeps giving you buckets of gold every turn. 
(Although, maybe you could consider this a "feature".)

Solutions:
1. Have the server inform the clients of all active effects (fiddly)
2. Have the server tell the clients what the luxury production (etc.) of 
   each city is (probably not so bad, since it sends cityinfo packets 
   anyway)
3. Reveal cities that have "global" effects (in the same way that global 
   wonders are currently revealed)

        Thoughts? I'm inclined to go for (2) and make the client more 
dumb than it is presently. It'll increase the bandwidth required, but not 
by an enormous amount, surely. (1) would require extra network traffic 
too, anyway.

        Ben
-- 
ben@xxxxxxxxxxxxxxxxxxxxxx           http://bellatrix.pcl.ox.ac.uk/~ben/
"The Belle of New Orleans tried to show me once how to tango"