In order to define a framework that allows us to specify what funcionality exactly a micro behavior should provide, we have to abstract from the tasks, a player has to accomplish. And I don't mean tasks live saving Sandy or getting the rest of those alien bastersd. I mean tasks like moving, dropping converters and activating upgrades.
Or even more abstract: pulling the right triggeer, clicking the left stick, and so on. And that's exactly the way I suggest: use your control scheme to go back to the very roots of what a player has to do! In Squar, you have to...
- Drop converters (LT)
- Fire your tank gun (RT)
- Activate converter upgrades (LB)
- Activate tank upgrades (RB)
- Move (LS)
- Aim (RS)
- Switch between tank gun and base weapon (Click RS)
- Aim with the base gun (RS)
- Fire the base gun (RT)
Considering things this way, we see that we unvoluntarily assumed a certain scheme when we implemented the micro behavior for the energy ray. (Ok that was not our headline when we did it, but I wrote in my last post that we could interpret our hitherto implemented AI that way.)
We integrated movement and firing, for example, in every of the states of our finite automaton:
What we called "building" was actually building-oriented movement with firing as a secondary task (i.e., at targets within line of sight).
What we called "hunting" was enemy oriented-movement with nothing as a secondary task. However, we could have dropped a converter once in a while!
In a first step we identify the questions that we have to answer (these are derived with little effort from the controls list above):
In a second step we reason which of these questions we should integrate in the macro behavior (what should we do?) and which of them belong to the micro behavior (how can we do it?).
Now we get to the meat of the matter: In order to allow for intelligent decisions, we need a lot of information about the environment. Let's introduce some parameters that describe our situation in the game (where for each object we want to have a value for all enemy and ally objects):
- chance that a tank is easily destroyed
- value of a tank
- chance that a tower is destroyed
- value of a tower
- chance that we will be able to build a tower
- value of a potential tower
- chance that we will be able to pick up a power-up before the enemy does
- value of a power up (for us and him)
Note that in the end, all that can happen in a game situation is that we (or the enemy) gain or lose a tower, gain or lose a tank, gain or lose a power-up.
On the other hand we have our current upgrades which we can consider our "bank account". For each situation we have to determine whether we want to save more power-ups or whether we prefer to spend them to enhance our chances to accomplish our present task.
Our next step will be to realize this parameter-guided concept. The very best example (respectively starting point) I can imagine for this purpose is the mighty converter upgrade together with the existence of blocked squares. Will we be able to describe with our paramters, that:
- A potential tower on a blocked square has (on an adequate map) a high importance?
- We should thus save our converter power-ups?
- We should protect our tank well once we have saved several power-ups?
Freitag, 2. April 2010
Abonnieren
Kommentare zum Post (Atom)
I have only recently found your blog from the msdn forums and your discussion on Squar, but I wanted to mention that it is one of the clearest discussions on the philosophy of game AI that I have seen. Thanks for taking the time to do this!
AntwortenLöschenDieser Kommentar wurde vom Autor entfernt.
AntwortenLöschen