The Fodderbot Project

An Empire AI Client

About

The purpose of the Fodderbot Project is to create an AI player for the game Empire. For those of you don't already know, Empire is a multiplayer wargame and empire simulation. It is typically played over the internet, with a server handling all the game maintenance and actions, and clients acting as the player's user interface and transmitting commands to the server.

This setup makes for a very fun multiplayer  experience. However, it has to be multiplayer. The server has no built in AI for running computer-controlled countries. Players who can't or don't want to join an internet game, or those who would like more opponents than they can find players for, are out of luck.
 

Goal

This is where the Fodderbot Project comes in. The goal is to create an AI client for empire that is able to create and manage a country, based on interaction with an empire game server. It should be able to Strategy game players do not generally expect much from an AI opponent (and they usually don't get it). Similarly, my skill at Empire is currently fairly pathetic. The Empire slang for players at this level is "fodder". If the AI is capable of creating a moderately efficient country and putting up at least some resistance against attacks from non-expert players (such as myself) I would consider it a success. For this reason the AI project has been dubbed Fodderbot.
 

Downloading

Currently available here for download are:

AI Details

Since fodderbot will have to run its country independently of user input, most parts of the system would be described as an AI Control system. However, some parts of the system may have to formulate and carry out plans. Fodderbot will mostly rely on inductive reasoning. However, it will have to use non-monotonic reasoning as well, since the environment changes based on updates from the empire server.

For knowledge sources I have mostly been using the information in "The Empire User's Guide" which comes with the server. This contains very detailed strategies for early exploration, as well as lots of tips and strategies for the rest of the game. As secondary sources, I may use some of the other information available in the game's online help, along with my own insights (slim as they are). I also plan to monitor the Empire newsgroup, rec.games.empire. The Wolfpack Empire website also has lots of good information and links available.

 As the AI should run the country autonomously, no interface to the "user" is strictly necessary. In fact, such an interface could be used by a local player in the same game to cheat. However, for the purposes of debugging I plan to send command output to a console window. This will include territory maps that fodderbot requests from the server.
 

Current State

Currently Fodderbot only performs the first three tasks listed in the Goal. That makes it a fairly decent player's aide, particularly for blitzes. But it is not capable of playing a full game itself yet. As the project for my class is over, updates may be slow in comming. But I will post the full source code here. The system I built it on is a P-233MMX with Windows NT. It should run on a Windows 95 or 98 machine as well. Porting to other platforms will require code changes, I'm afraid. Most of this is due to the decision to deveolp parts of the system in C.

Development Details

Fodderbot has 4 main parts. The Empire client, the Expert System engine, the Expert System rules, and the procedural controller.

For the Empire client, rather than try to develop my own, I took the basic text-based Wolfpack client and hacked in a couple of routines to allow communication through program control instead of just via the console. Since there is no port of this client to cygwin32, I had to compile it into a DLL in order to link it with my gcc-based compiler.

For the Expert System engine, I used the freely-available CLIPS system. Having already wasted a day in a futile attempt to compile the client with my gcc, I opted to use the prebuilt DLL version of CLIPS.

The Expert System rules were of course written in CLIPS source files. These are text files that are loaded into the system by the controller at startup. Because of this, any minor changes that users may want to make to Fodderbot's decision logic can be made without having to recompile anything (as long as new services are not required from the client).

The controller code has the task of initializing and tieing together the other three parts of the system. It provides the interface between the client and the CLIPS system. It also parses return strings from the client and makes fact assertions based on the results. It was written in Ada, mainly because Ada is the best general systems programming language I know. Development and debugging in C takes up to 2/3 longer by some estimates, and my experince certinaly bears that out. One side benifit to using Ada is that that portion of the code should be completely source-portable to any platform that has an Ada compiler. (To be more specific, it would need an Ada95 compiler that supports annex B).

Unfortunately the situation with C, which the Empire client and the CLIPS Expert system were written in is quite different. So I'm afraid porting those portions of fodderbot to a non-wintel platform would be a challenge.