How To Make Games Play

Brannen Hough

<bhough@jlc.net>

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:

  1. Time is not a very critical factor - the game is turn based so that the amount of code that executes, and its speed, are not that important. NOTE: this is in contrast to many types of games, such as DOOM-clones, where the AO must react instantly to a human player's moves. A few milliseconds are not much time to perform extensive algorithms - something simple must suffice in these cases.
  2. No cheating. The AO must not have any more information than the human players (this is not a basic requirement for AOs, or a very usual one - in fact, one of the easiest ways to turn a mediocre AO into a challenging one is to give the AO more information than the human player).
  3. Since each player can have enhancements and handicaps placed on various aspects of the game (such as how well they fight, how fast new units are produced, etc.), and luck plays an important part, the AO must be flexible enough to 'roll with the punches' when bad luck occurs.
  4. No special abilities. The AO must not have access to any functionality that the human player doesn't have. This is also a favorite area where an AO can be made challenging - simply by giving the AO facilities that the human player doesn't have (stacking the deck so that the human player's talent and creativity are needed to offset the AOs advantages - sort of a David and Goliath approach. An example of this is Battle Isle for the Amiga - the AO is not very sharp, but it takes a lot of skill and luck to overcome the odds. In the one scenario with evenly matched forces I wiped out the AOs entire force without losing a single unit).
Why only four ground rules? The fewer ground rules the better - it leaves all the "how to"s to the code (one golden rule to designing good software: Don't specify solutions, only problems). There is usually more than one way to solve a problem.

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?).


About the author: Brannen Hough is a Senior Software Engineer / Senior Consultant for Seagate Software (Manchester). While working for several defense contractors over the past ten years he has contributed to such programs as the PATRIOT Air Defense System, the F-22 fighter, and C4I systems used by the Air Force and Navy - which worked out well with interests in wargaming and AI. Currently living and working in New Hampshire with his wife Renee and daughter Samantha, and still enjoying his '030 accelerated Amiga 1200 computer.
Brannen's web page is located at:http://www.jlc.net/~bhough/First.html
E-mail to: bhough@jlc.net (home), or hough@calsof.com (work)

Table of Contents