[Freeciv-Dev] Re: AI strategy

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Dec 03, 2001 at 04:20:20AM -0800, Raahul Kumar wrote:
> 
> --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> <snip>
> > > > > 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.
> >
> 
> I read this statement. I'm not sure I know what you are driving at here.
> It's not a problem that the normal players can find out stuff like where
> all enemy units are located? If we implement cheating in ais, there's bound
> to be an upsurge in hacks. 

There is a new server command "cheat <flag> <player>" where flag is:
 - "sees_whole_map" or
 - "sees_all_units" or
 - "sees_all_city_stats" or
 - "unlimited_rates"

All invocations of such a cheat command are broadcasted to all players
like this: 

 "Server: Player xyz has set the sees_whole_map cheat for player abc"

So there is control.

> > > 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.
> > 
> 
> Can you post the newer versions of the patch if they exist? I'll review it.
> I didn't comment before because your patch would take lots of testing to make
> sure no bugs crop up.

Attached. It still applies cleanly.

> > > 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).
> > 
> 
> Do you want to thrown some nos around? The client side AI will need at a
> minimum
> 
> for N = no of ai players
> 
> N * initial maps
> N * initial tech_tree and change in tech_tree
> N * unit change in pos and/or enemy unit within visual range
> 
> I'm sure there is other stuff I missed. What do you think will be an approx 
> figure?

I don't have an exact feeling for what info uses how much
bandwidth. So I will not post any wild guesses.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "How about the new language C&? No, that's not 'c ampersand', 'c reference', 
  'reference to c' or 'c and'. It's pronounced 'campersand', to confuse the 
  hell out of people who are unfamiliar with it, and it will, of course, 
  have no pointers."
    -- Xazziri in comp.lang.c++ about C#