The additional implementation problem with FSMs is the selection process. If you have an integer value represent each possible state, then you need to have a case statement within your switch statement for each of the possible values. If you use comparisons of the form

if( (state = rand() % 100) < states[j] )  

then you have to redefine your states array whenever you add a new state (and probably alter values to maintain a coherent probability distribution).

It gets more complex the more types of states are included (multiple FSMs) are added. I'm trying to maintain a number of status variables as bitfields in a "register" and use the resulting integer value as a selector, but the number of potential situations (the combination of all the individual variables) is overwhelming. Is there a more efficient selection method? I was thinking of instead writing a responder function that evaluates various portions of the status register and executes specific code based on whether or not the bit is set. This would reduce to n non-mutually exculsive branches as opposed to nCn. Am I on the right track? I think so, but I'd like to know if there are other "better" methods. Thanks.

Edited by - Oluseyi on September 15, 2001 2:17:18 AM

Don't forget that the unit should respond to what happens around it. First, you should know where to escape to. Moreover between units of the same side (say goblins) there should be coordination. If there sevral goblins around our goblin, it would rather attack than run away, a step further would make bad goblins behave as flocks of birds, attack together, run away together.

hope it helps in anyway, probably it does not.

[EDIT]
The mechanism itself: You may want to consider an action matrix, say a matrix with four rows (attack,defend,run,heal) and many columns, each for certain situation you want to consider (say, a column for health<25%). In the cross point of each colum and row, there should be a number, a weight, say in the cross between "health<25%" and the row "heal" there would be 50. Now you sum the numbers along the row, adding the numbers in a certain column if the situation is valid (you add 50 to heal, iff health<25%). The action with the greatest weight at the end would be chosen. It is easier to maintain this way, I think, and you can make the matrix itself a class, for clean programming.

Edited by - rouli on September 15, 2001 2:22:16 AM

I''ve been implementing the AI in the real-time strategy game I''m working on (in fact, I just posted a version with my first attempt at the AI here). I''ll describe my method for AI, and then you all can go and check out the game and see how it turned out (I was quite impressed, myself )

Basically, the AI has a number of "needs". A need is something like "More factories", "More units", "Attack the enemy", etc. Associated with each need is a weight, between 0 and 1 which represents the probability that the AI will act on that need at any given time. Acting on a need involves two things, first, it may issue orders to various units/buildings (say, "attack this unit", "build this", etc) and it may also adjust the weights of other needs.

A quick example. At the start of the game, the computer starts with one construction unit. One of it''s needs is "More units", which, since there''s only one, starts off pretty high. So it gets acted upon almost straight away. Since there''s no factories for it to build units with, all it can do is adjust the weight of the "More factories" need. So, it won''t be long before that need is acted upon. Since there''s a construction unit doing nothing, it orders it to build a unit factory. Once it''s built, the "More units" need can be acted upon (it''ll still be as high as before). Once a few units are built (and it''s usually built a second factory by this stage as well) the "Attack enemy" need will be quite high, since we''ll have a lot of units standing around doing nothing. When that''s acted upon, a bunch of units are selected to go into the enemy base (that is, your base) and start attacking stuff.

All in all, it''s quite good. Adding new "needs" won''t be much of a problem, I just have to add to a list of classes which have a RecalculateWeight() and an Act() method. The RecalculateWeight() method is called every now and then to adjust the weight of the need (for example, the "Attack Enemy" need''s weight is increased as more units are produced). The Act() method is called whenever the weight of the need is sufficiently high (based on a random number).

For what I''ve implemented so far (and it''s actully quite a tough AI, but that''s really just because it can work a lot faster than a human player. I might cripple it a bit later on to make things fairer) there''s only a couple of pages of code, and it gives quite a good effect...

codeka.com - Just click it.