[Freeciv-Dev] Client interface (was: how to improve the AI's attack (was: old/bad code in autoattack.c (PR#351)))

[Corin Anderson <corin@xxxxxxxxxx>]

Hi folks.

  I, too, would *really* like to see a clean, happy, client/server
interface that would allow for AI experimentation (and improvements!). I'd
like to put some serious effort into writing a better AI (or, at least, an
AI that is on a square footing with its human foes), and such an interface
is a prerequisite.  (As is free time, but free time is a prerequisite for
everything).

  A year ago, I took a seminar here at the UW in which we applied AI agent
technology to a real-world domain (ie, we wrote client-side AIs for
freeciv 1.8.0).  What we found then was the following:

* The implementation (on the client side) of the client/server interface
  of freeciv is actually pretty good. I don't think anyone minded having
  to build packets and stuff them down a TCP connection.  Moreover, I'm
  not sure that having a wrapper over the packet-level interface would
  have helped much.  In many ways, the lowel-level routines are /more/
  useful for building a client (esp. a client AI), b/c the client can
  build exactly the functionality it needs out of the smallest building
  blocks (as opposed to being limited to only high-level functions).

* The freeciv server trusts (trusted; my comments relate to
  freeciv-1.8.0) the freeciv clients -way- too much.  In the course of the
  class, everyone found that their AIs could cheat substantially by just
  not _ignoring_ the packets that weren't meant for them.  For example,
  the server would broadcast a PACKET_UNIT_INFO to *all* players, even if
  the recipient didn't know of the unit's existence.  I think this issue
  has been addressed by Thue's fog-of-war work, and perhaps others.  But,
  there's nothing like a good code audit (or packet sniffer) to verify
  that everything is okay.

* Building an AI from the ground up is a *lot* of work.  The end result of
  the class was 4 or 5 clients that competed with each other and the
  built-in AI. (I confess: my client was /not/ the winner.)  With a single
  exception, all our AIs were handily defeated by the easy level freeciv
  AI. (That's an understatement -- after a month's worth of work, our AIs
  really did little else than build cities and make units.  There was no
  work on military command, empire management, etc.  We were still just
  struggling to keep our empire going, much less actually interact with
  other players.)

* The exception was the AI of one group who effectively ported the 
  server-side AI to the client side.  The server-side AI did pretty
  well against our other AIs (which, as I mentioned, really didn't do that
  well to begin with), but was severely hampered because it couldn't cheat
  (ie, it didn't have access to the server's global map).  But, the
  server-side AI *could* function.


The desiterata that I have for the freeciv (AI) client interface is the
following:

* The interface should be the same as that for the human GUI clients.
  Everyone should be on the same footing.

* The interface should allow for selectively adding or restricting
  information or actions on a per-player basis.  (this idea has been
  discussed on the list before, but I don't recall when.)  The upside here
  is that an AI can be made harder by supplying it with privledged
  information, *AND*, a *human* player can be aided (or handicapped) in
  the same manner.

* Although a library of common routines would be useful (ie, compute
  influence maps, etc.), I don't think that such should be part of the
  client/server interface.  Maybe as part of a common client library, but
  not part of the runtime interface.


The bottom line is, I think the packet interface that already exists is
most of the way there.  An audit of what information is sent to which
clients would be of great use.  Extending the packet interface to allow
selective information or actions would nicely round things out.  And, of
course, a nice piece of documentation, and some sample client code, would
help a lot (surprisingly, both of which I probably already have).

So, who wants to start coding?  8)

Corey

P.S.  I doubt I'll take this project on by myself anytime soon; probably
not before mid-June.  If someone else wants to work on this, though, I'd
be happy to contribute code and comments whenever I can.