Complete.Org: Mailing Lists: Archives: freeciv-ai: February 2003:
[freeciv-ai] CLIPS for client-side AI

[freeciv-ai] CLIPS for client-side AI

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] CLIPS for client-side AI
From: "Martin Hill" <martinh@xxxxxxxxxxx>
Date: Sun, 09 Feb 2003 21:34:58 -0500


This is my first post to a freeciv list. I'm interested in developing a
client-side AI using CLIPS. For anyone unfamiliar with CLIPS, its name
means C Language Integrated Production System, and it is a free
(public-domain) embedable expert system shell. My goals are similar to
the goals in README.AI, plus to create an environment for learning expert
system development, and freeciv could be perfect for that.

CLIPS has many advantages over procedural programming approaches,
including powerful pattern matching and inference chaining. Users could
easily modify rule-sets, much more so than C code. It would also make the
client "scriptable", though not in a procedural way. See for more info.

All that should be required is to define constructs in CLIPS to reflect
the current state of the game, as seen by the client, and write the
necessary glue C code to push the game state, load/execute rules, and
CLIPS extension functions to further query the game state and send

So far I have the following parts:

- CLIPS module containing constructs to describe most freeciv elements:
players, cities, units, governments, techs, improvements & effects.
- C glue to drive the CLIPS engine, implemented as a freeciv client
agent, and implement action request functions. Based on the 1.14.0 code
base. I had to add a few callbacks to the agent API.
- gtk 1.2 dialog to provide command line interaction with CLIPS.

I'm new to freeciv hacking and CLIPS, so many important features may be
missing or poorly implemented, but it seems to be quite stable. I haven't
had time yet to write the actual rules to win the game :-)

Unfortunately, the clips code is rather large and integration nearly
doubles the size of the client binary. Long term it should be made into a
dynamic library that could be optionally loaded, and packaged separately.

I'd like to know if the maintainers would be interested in adopting
something like this. I'll make my code available to anyone who is


[Prev in Thread] Current Thread [Next in Thread]