[Freeciv-Dev] Re: AI strategy

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Dec 03, 2001 at 03:06:22AM -0800, Raahul Kumar wrote:
> 
> --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Sun, Dec 02, 2001 at 05:22:44AM -0800, Raahul Kumar wrote:
> > > 
> > > --- Petr Baudis <pasky@xxxxxxxxxxx> wrote:
> > > > > I suspect that having a reserve force of attacking units rather than
> > > > settlers
> > > > > would work well too. The AI builds far too many defensive units. 
> > > > I don't think so. AI will be still overmilitaristic, expansionistic is
> > better
> > > > IMHO. I prefer settlers more than attack units, as they can generally
> > > > increase
> > > > food (irrigation), production (mines) and trade (roads), and all this at
> > once
> > > > (building of new city). Attack units can't. They can only conquer 
> > > > foreign
> > > > cities, with much more effort put in than just building settler and
> > deploying
> > > > new city around.
> > > 
> > > The AI has only one function in life, and that is to make single player
> > games
> > > exciting. The only way to do that is military conquest, the AI expands 
> > > fine
> > as
> > > is. Curently, when I am attacking an AI opponent, they rarely attack the
> > bases
> > > (the cities I took from the AI). They just build/buy a lot of defensive
> > units,
> > > when for less than half the cost in offensive units, they could wipe out 
> > > my
> > > foothold.
> > > 
> > > There is a use for reserve settlers, but 1/3 is far too many settler 
> > > units.
> > > Settler units after a certain no have less and less utility. Once
> > everything is
> > > railroad and irrigated you need far fewer settlers.
> > > 
> > > 
> > > There is no reason a complete client side AI could not be built. Raimar?
> > 
> > (uhuh double negation). I see no general problems building a complete
> > client side AI. Smaller problems include cheating (how to allow it),
> > extra bandwidth usage and extra complexity (spawning civbot).
> > 
> >     Raimar
> 
> Allowing cheating is dangerous. All of a sudden we would return to the bad 
> old 
> days of players using packet sniffers. And I am not going to implement our own
> encryption standard.

If such a cheating flag is set it is broadcasted to all players. I
don't see a problem here.

> The extra bandwidth issue is the only really big problem.  Ideas?

It isn't a problem for the civbot scenarios.

> I've got the obvious compression of packets applying those patches
> like 

> short_worklist(have they been reviewed yet?)

No. I didn't got any comment.

> A smarter client - keeps some state info instead of all server
> side. This could be more hassle than it is worth.

For bandwidth saving it is best to do such a "do only send info if is
has really changed" solution. Maybe a compression can also be
used. With such code in place I think that a cheating client will not
need much more bandwidth than now (this is only a guess).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "#!/usr/bin/perl -w
  if ( `date +%w` != 1 ) {
    die "This script only works on Mondays." ;
  }"
    -- from chkars.pl by Cornelius Krasel in de.comp.os.linux.misc