VBGamer

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