111 lines
4.6 KiB
Plaintext
111 lines
4.6 KiB
Plaintext
From: empath@umcc.umich.edu (Tim Triemstra)
|
|
Subject: Game AI posts:
|
|
To: jon@stekt.oulu.fi
|
|
Date: Mon, 12 Dec 1994 03:18:15 -0500 (EST)
|
|
|
|
<re-cap of Tim Triemstra's postings from rec.games.programmers>
|
|
<with respect to "situation objects" in designing an AI system>
|
|
<re-written for general availability on December 11, 1994>
|
|
|
|
<Tim can be reached at empath@umcc.umich.edu>
|
|
================================================================
|
|
|
|
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.
|
|
|
|
<... end of message #1 ...>
|
|
|
|
> Wait, so you build a (let's call it) a data base for each
|
|
> instance of tank vs other tanks and then a "good" solution for
|
|
> it??? Wouldn't that be huge?
|
|
|
|
Yes, in a SSI wargame it would not be a viable solution.
|
|
However, in my game (and I'm sure many other people's) there are
|
|
limitted types of units and limited quantities of units in each
|
|
mission or scenerio.
|
|
|
|
In my game, there are only 5 units (I may merge them down to 3
|
|
total types of units) which can have various attributes (larger
|
|
weapons, higher speeds etc.) but those factors are taken into
|
|
each database, or "situation object" entry.
|
|
|
|
In my early designs, 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 actually be smarter :)
|
|
|
|
<... end of message #2 ...>
|
|
|
|
Welp, the idea of finding the nearest "situation object," as I
|
|
sometimes refer to it, isn't nearly as difficult as you may
|
|
think.
|
|
|
|
First off, these objects are based completely on "relative
|
|
situations" ie: if a guy is stronger and to the upper-left
|
|
of the character then that would be one situation. So, the
|
|
tree 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 my particular game, 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. Quite frankly,
|
|
I'm under the opinion that a "game" does not need particularly
|
|
good AI to be a good game. Simulations (not my favorite) are a
|
|
different story. A game need only provide an enemy adequate
|
|
enough to give the player some fun and to enact the plot.
|
|
Dune II (my favorite example) has horrible AI, and anyone can
|
|
eventually beat the game, but it is unquestionably enjoyable to
|
|
play.
|
|
|
|
|
|
--
|
|
Tim Triemstra ... Empath Software .... Empath@umcc.umich.edu
|
|
<><><><> If'n you ain't the granddaddy of all liars <><><><>
|