Real time strategy games like OpenRA have a built in game AI. But how exactly is this computer generated force working in reality? Sometimes, the principle is described as scripting AI but this definition isn't clear enough. The more elaborated explanation has to do with abstraction. The transition between no AI into an autonomous system is a soft one.
Let us go into the details. A realtime strategy game is usually programmed for the human player in mind. The underlying physics engine provides to the player some actions. For example he can select the units and let them walk to a target position. This abstraction layer can be formalized as grammar. The human player can interact with the game with a controlled vacabulary. He has some actions which are mapped to the GUI and after activating the actions the physics engine is doing something.
This baseline abstraction has nothing to do with an ingame AI but it's supporting the normal game play. It defines the game itself and it's rules. A sideeffect is, that the game AI can use the same layer as the baseline. That means, the AI doesn't move the cursor to a button and clicks with the mouse, but the AI has access to underlying API with all the allowed actions. The only thing what is missing is which of the around 100 actions should be activated next.
A naive approach would be to use a random generator. Such an AI Would become very weak. The more interesting technique is to create a second layer which allows the AI engine to plan the movement. A cpu efficient way in doing so is called GOAP (goal oriented action planning). This is some kind of textadventure which is forming an additional layer on top of the physics engine. In the GOAP model all the actions are available but they can be activated without running the normal physics engine.
Let me give an example. In every Real time strategy game the player can build a powerplant. But why should somebody do so? Because the effect of the action is, that the energy level gets increased. The relationship between the action and the effect can be stored in a textadventure in a compact representation. This allows the planner to execute the action and without a delay he gets the result that the energy level is higher. Or let me give another example.
Formalizing all the allowed actions into a textadventure is equal to building a goal model. It's a headless game which can be played in a much faster time. In this textadventure a complicated game tree can be built. The solver is trying out possible action sequences and he will see the result.
The next step contains the AI itself which is not hard to explain. The solver gets a goal, for example, maximize the energy level and the AI will figure out by it's own which actions are needed. The generated action sequence from the textadvanture is executed in the real time and for the human player a lifelike game AI is visible. Creating the GOAP model from scratch is a bit trickey, but with trial and error it's possible.
From a birds eye perspective the AI contains of a abstract actions which are searched by a solver to fulfill a goal. The resulting action sequences gets executed in the game. The advantage of this technique is, that the amount of needed cpu ressources is low, and the AI can become very strong. Let us go back to the example with the powerplant. If the GOAP model is available it's possoble to send to the planner a high level request. For example a goal can be: maximize the energy level. Another goal is to build as much units as possible. A more general goal would be to increase the overall strength. The interesting point is, that from an algorithm perspective it is very esay to fulfill such goals. Because all the possible actions and the effects are formalized. A game tree can be generated which means, that the solver is testing out an action and determines what the result is. If the solver is doing so many times he can browse through the entire game.
In the AI literature, sometimes it was written that Real time strategy games are hard to solve because the state space is too large. Exactly this is the reason why many abstraction levels are needed to simplify the search process. If the solver would try out random mouse actions it is indeed not possible to figure out the next action. Because after a short amount of time, the possible combinations are endless. But if the game is structured hierarchically and if a goap model is used it's not very hard to build the entire game tree. Sometimes a third layer is used which is called Goal manager. On this layer, a dedicated manager is defining the next goal. The advantage is, that such goal definition can be realized on a very high abstraction level. It's possible to write down the following statement:
if the own base is under attack, play defensive.
else play offensive.
Such high level goals are only possible because the lower layer are available. That means, if the game is working great, the goap model is available and the solver accepts goals, it's possible to build on top of these layers a goal manager which contains of simple if-then-statements.
No comments:
Post a Comment