Game AI
Andy Owen
Copyright Jan 10, 2000
Page 1
Firstly, what this article isn't
This article is NOT a how to guide. It isn't tried and true, this
article is written by a teenager who has some experience in game AI but
not a lot. Anyway it is a collection of my thoughts on the issue of
designing AI for games and different ways of going about the problem.
Step 1.
What is the computer trying to achieve? Is it trying to defeat your
army? Is it trying to get more points than you? Is it trying to
checkmate your king? This question must be answered before you progress.
Step 2.
How do you/would you achieve the goal? If you were given the same task
as the computer, what would you do? Would you defend your base until
you had built a large army and then send it out to take down the human?
Step 3.
This step is VERY useful but often overlooked. Modify your game so that
when a player is killed then the location of the killer and the player
is logged into a file. After playing the game lots of times you should
start to see a pattern in the map of safe spots and danger spots. You
can either allow the AI to view this file when making it's strategies
or you can find the general rule regarding safe spots, e.g. open areas
are less safe than closed in areas. This technique can also be applied
for level editing and works quite well there for first person shooters
and other games like that.
Step 4.
Make a flow chart. Yep, like the ones they force you to make when you
do programming in year 9 at school. Write down the steps that you take
so you know what you'll need to code. After this, look at all the boxes
and decide which steps are harder to do. Put them in a list. Can any of
them be broken down into smaller steps? Are they possible to do using
your programming knowledge? If not then try and run through in your
mind how you do it. If you look at a simple maze then it is easy to see
a solution but hard to work out exactly how you did it. Using the
example of a maze (or pathfinding) a good way to find the shortest path
from Point A to Point B (although not too memory efficient) is to
create 3 arrays the same size as the map each storing integers; one
called lX one called lY and another called lD. AX and AY are
co-ordinates for A. lD(AX, AY) = 0. All other numbers in the lD array
are equal to something big. Now start a loop which cycles through every
square on the map and if the lD of a square is at least 2 bigger than
any of its neighbours and it (the first square not the neighbour) is
traversable (not a wall) then let its lD value equal the neighbours lD
+ 1 and let lX and LY equal the co-ordinates of the neighbouring square
which had the low value. Continue doing this to each square until all
the arrays remain static after an iteration. Then by starting at B you
can work back to A by following the co-ordinates in lX and lY. Simple
(almost). Did I lose you? I hope so because then it sounds like I'm
smarter (or I have no idea what I'm on about). If your flowchart has
been broken down into manageable parts then move on to step 5 otherwise
here are my suggestions: Do the step lots of times in different
situations (e.g. jump off a lot of cliffs) Watch someone else play. Ask
them why they did what they did. Eat some food and go outside and take
a run. (Always works for me) Have a look around for other people who
have written articles/programmed AI like yours. That's all I can think
of for those but everyone has their own little secret way of
intellectual inspiration.
Step 5.
Have a long hard look at the flow chart. Does it allow the AI to learn
as it plays? Although this isn't necessary, if done well it can mean
you just have to play a few games and soon it will be smart enough to
not shoot a bullet into its own foot. Are the priorities correct? If
the computer puts making money ahead of saving its own life then you
have a problem. Priorities are usually quite easy to work out as they
apply to humans too.
Step 6.
List all the subs and functions you will need. DO NOT make one sub
called AIDoEverything. You will finish coding it after 5 weeks, run it
and the computer will just sit there and do nothing. Back in my Qbasic
days, everything I did was usually put into 1 sub with a few GOSUBS
around the place. I'd write my AI and voila, nothing would happen. Then
I'd get angry and delete the program.
Step 7.
Code the subs and functions that you can test first. If you write too
much code with out debugging it, you will have to get rid of it all and
start again. Start small, think small, get bigger, think bigger.
Step 8.
Give it a whirl. One of my favourite things is seeing a character of
mine walk across the screen do something semi-intelligent. If this
happens for you then you've got a winner.
Notes and other stuff I forgot to say.
The Pathfinding Algorithm is also quite slow and there is probably some
fancy name for it too. I'll take any credit if it works well and isn't
someone else's though. Avoid using numbers, use constants so you can
easily tweak the AI once it is done. There are no right or wrong
answers in AI.
AI is also different for most games, this article
tried to be non genre specific although some parts won't apply to your
game. Other parts will (hopefully) When you find all the things I said
which are wrong or if you just have some general comments, send me an
email here with your
ideas as I'm sure I've stuffed up a lot