Primitive Game AI
Published August 19th, 2004 in Programming ArticlesWell I’ve decided to switch focus… a little. In the migraineheartache. Weekly Schedules - Thursday is going to now become Programming Articles/Tips day. Today I’m going to start with a quick little one on Game AI:
A method for handling computer intelligence that I’m using is a little simpler to implement than neural-nets: not necessarily better or worse, maybe just “different.”
All units in any type of strategy game have limitted situations that they can be put into (the broader the definition, the smaller the number.) IE: If you have a game with 10 tanks on each side it could be said that there are only 11 possible situations: 1 situation for each number of tanks visible to the player and 1 situation where none is visible. Of course, that is too broad to really _do_ anything with. To be of any real value the situations must take into account strength, ranges and other aspects of the situation.
Since I have a smaller number of units in my game, I make little “situation objects” composed of all the various possible situations. Each situation object also contains the orders to give to the player. The orders are executed if it is determined that this particular “situation object” is the best match for the current state of the player. The higher the number of possibilites, the greater the intellect of the computer controlled player.
To me, this was much simpler than hand-coding a tree because I could make a move construction kit that builds these situations and the resultant decision and saves them into a library. Beta testers can help build them too.
In a SSI wargame it would not be a viable solution. However, in alot of games there are limitted types of units and limited quantities of units in each mission or scenerio.
For example, if there were only 5 units which can have various attributes (larger weapons, higher speeds etc.) then those factors are taken into each database, or “situation object” entry.
Only 30 or so data elements is needed for each unit type to give what appears to be nearly adequate responses. I also curb the results slightly by giving units commands like “move here stealthy” or “move here while attacking whomever you see” to stack the deck in the decision making.
Mind you, this idea of “situation objects” is purely one way to do it that may be practicle in some gaming situations. I’m not a big fan of simulations (like SSI games) and hence wouldn’t do a game like that. Those SSI games couldn’t use my idea, but Dune II could (and it would probably be smarter :))
The idea of finding the nearest “situation object,” isn’t nearly as difficult as you may think.
First off, these objects are based completely on “relative situations” i.e. if a guy is stronger and to the upper-left of the character then that would be one situation. So, thetree goes something like this:
1) How many opponents are visible?
( branch to the decision objects sorted for each answer )
- branch if 1 or more
2) How many can hit me within X moves
- branch if safe to not run
3) How many can I hurt?
- branch if any
4) SHOULD I try to hit him or run
- branch if try to hit
5) Which is most benefical to hit
- branch etc…
Now, in some games, each unit is also given priorities that factor into this decision. So, you may tell a unit to scout but give him the order to engage or hide, this of course adds weight to different tree decisions.
The major advantage of a system like this, as I said, is that you can make the AI as good or bad as you like.
Well I hope you enjoyed the first official Programming Article here at migraineheartache. If you have any suggestions for future artciles or tips, please let me know, peace out-
-b

























No Comments to “Primitive Game AI”
Please Wait
Leave a Reply