How to make Games Play

        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)