[Freeciv-Dev] More on client AIs.

["Bobby D. Bryant" <bdbryant@xxxxxxxxxxxxxxx>]

Here is a synthesis of the current state of my ideas on client AIs.

First, you still have the client-server architecture.  The server would
be agnostic as to whether any particular client were a human or an AI.
You could also keep the existing server AI, though once you have one or
more good client AIs working, it might be preferable to remove the AI
code from the server to give a smaller server to be maintained.  The
server would then just launch an AI client for each AI player when the
game starts.

The clients, whether human or AI, would have a similar abstract design:
an infrastructure and an agent that "sits on top" of that
infrastructure.  Ideally, the infrastructure would be common between
human clients and AI clients.  That would be useful because it would
reduce the amount of code to be maintained.  It should be possible too,
since both kinds of clients will need common services (such as
sending/receiving packets, getting a list of what techs can be
researched, etc.) and will need to maintain a common "state" or "model"
of what that client knows about the world it is playing in.

On top of that common infrastructure will rest an "agent".  For human
player clients, the agent will again break down into two layers: a GUI,
and a person who uses that GUI.  Ignoring the possibility of helper
scripts, the GUI is entirely passive: it updates various displays when
it gets new information from the server (via the aforementioned
infrastructure), but it doesn't *do* anything unless the human player
clicks something or types something.

Viewed that way, the GUI is just a collection of callbacks.  The human
saves some high-level state ("What is my strategy for this sector?"),
but invokes "callbacks" in the GUI to get detailed information about the
game state saved in the infrastructure layer described above ("How much
money do I have?" --> look at the main display; "What am I researching?"
--> pop up the Science Advisor display, and look at that).

An AI client should be able to work the same way.  A script, neural
network, or whatever would maintain the high-level state, but would
invoke callbacks to find out particular details that it needed, just as
the human queries the GUI in a player client.

This *might* mean that the AI agents would need to have two levels like
the player agents: a high-level agent to make the decisions, and a set
of utilities, corresponding to the GUI, that the high-level agent would
invoke during the decision-making process.  However, it may be that the
common infrastructure could be accessed directly by the high-level AI
agent, without an intermediate layer.

The high-level AI would need to save some high-level state, just as a
human player does, but would rely on the common infrastructure layer to
save the lower-level state, just as the GUI clients do for human players
now.  The nature of the high-level state would depend entirely on how
you wanted to implement the AI (e.g., for a neural network the state is
maintained in the weights and the activation levels of any hidden
layers). The nature of the lower-level state would be common regardless
of the nature of the AI, and for that matter common between AI agents
and human agents, since the state is just details about what the server
is telling you about your world.


To give a somewhat concrete example:

In a recent message I suggested that things like determining what techs
can be reached within 11 steps should be moved out of the GUI code and
into the GUI-independent (GUII) code base.  Assume that this has been
done, so that a function named, say, get_researchable now exists in a
GUII layer which corresponds to my "infrastructure layer" above.  (You
might want to parameterize the hard-coded 11, but that's a completely
different matter.)

For a human agent, the human wants to pick something to research, so
s/he clicks up the Science Advisor and then clicks the button that pops
up the list of research choices.  The GUI, in the service of the human,
calls get_researchable in the GUII layer to create a list of valid
choices, and then posts the list of those choices to the screen.  The
human picks one, and the GUI uses utilities in the GUII layer to relay
the human's choice to the server.  The human now goes on to the next
decision.

For an AI agent, the high-level AI "wants" to pick something to
research.  It simply calls get_researchable in the GUII layer, examines
the list according to its own logic, picks one, and calls something in
the GUII layer to relay that decision to the server.  (That last step is
where it *may* be desirable to create an interface layer between the
high-level AI and the GUII layer, corresponding in function to the GUI
layer in the human agents.  It is not obvious that such an extra layer
would be needed, but it might prove to be so when it comes down to the
details of implementation.)

For a hybrid system where a human player is supported by scripting, the
decision would work pretty much the way it does for the AI agents, i.e.
the GUI does not directly need to be involved.  Of course a lot of
things go into this decision, so you may want to provide a mechanism for
the player to set some global state variables (at war, at peace,
expanding, perfecting, etc.) in a place where the helper scripts could
make reference to them in their decision making process.

For simplicity, I have portrayed the infrastructure layer (and GUI) as
being essentially passive.  In practice that would need to be modified
somewhat, as when a message from the server needs to trigger a new
action (e.g., "you need to pick something to research now").  For human
agents, that already works by having the GUI pop up a message.  For AI
agents it could be interrupt driven, but it might be simpler to just set
a flag and let the high-level AIs poll the flags each turn.

Also, the whole system will need a way to tell the AI agent "Make a move
now."  This could be done by having the AI poll the game state until it
sees an appropriate flag set, or else by some more elegant mechanism.
For hybrid systems, the helper scripts could behave the same way, i.e.
once per turn they would all wake up and do whatever tasks have been
delegated to them.

One concept springing from this model is that the common client
infrastructure layer should probably be rolled into a dynamically
linkable library.  This would let you create new player and AI clients
in the language of your choice by implementing bindings for that library
in your favorite language.  Also, the library could be shared at run
time by all the clients running on a given system.

Bobby Bryant
Austin, Texas