Hello everyone. Let me say in advance that I am quite pleased to be able to contribute to ExecBase - an online magazine by Amiga programmers, for Amiga programmers. It is something that I have been waiting for myself for a long time.
This is the first in (hopefully) a long series of articles on creating Artificial Opponents (referred to hereafter as AOs). Just as there are many kinds of games there are many kinds of AOs - with perhaps the most famous of them being the chess programs (e.g. Deep Thought) that appear from MIT or CalTech to challenge the world chess champions. But there are AOs for platform games, for combat games, for DOOM-clones, etc.
I will be covering a particular kind of AO - that for a strategic wargame (most similar to the old Empire game by Intersel, or the more recent Civilization games). It is what I myself am currently working on, and has very specific requirements and restrictions. However, I hope that some of the principles and techniques that I write about will find application in other types of games.
In this series of articles I will endeavor to explain how to get started writing an AO, what special needs an AO has, go over the subject of "cheating" by AOs, and get into some advanced topics such as Best Path algorithms, Neural Nets, Emergent Behavior, and Fuzzy Logic. The last items are classified as Artificial Intelligence (along with many others I won't begin to get into).
Now, how is an AO different from Artificial Intelligence? That is a very good question and one that is difficult to answer. Partly it is difficult because the definitions of Artificial Intelligence have been changing over the years - some things which were once considered cutting edge AI are now thought of as simple 'game theory' techniques. In my mind, AOs differ from AI in that AOs attempt to (at best) simulate a human playing the game along with you. That means the AO must appear to be creative (to hit you with something unexpected at times), and have fallibilities (to let you succeed by taking advantage of the opportunities). The ultimate goal (some feel) for an AO is to appear to learn to play the game, becoming a better challenge as time goes by.
All of the techniques and code that I will talk about are
implemented in the Invasion Forces program. There are two web sites
devoted to the game: the first is the author's web page - Tony Belding.
The second is my own - the AOs for the game are an ongoing project that
will become ever more complex (and competitive) as time goes on. Look to
these web pages to get background on the game itself and to download the
latest versions (so you can try it out for yourself). Looking through the code
as it expands over time will hopefully aid in understanding (the very first AO
for the game exists in only a single, 600 line file) as the AO evolves in a
modular manner.
Probably the best place to get started coding an AO is to lay down the 'ground rules' - basically, how you need the AO to act.
The 'ground rules' for the Invasion Forces game are the following:
Next time I'll introduce the overall scheme for the Invasion Forces AO,
and show how it gets implemented to produce AO#1. By no means is it supposed to
show the only way to satisfy these ground rules. In fact, ambitious readers with
other schemes for an AO may find better solutions than mine (hows that for a
challenge?).