Starcraft 2 bot based on interception and analysis rendering
Matthew Fisher from Stanford University wrote an interesting article about the implementation of the bot based on the interception of the flow API of the D3D9 library (Microsoft Direct 3D, which is part of the DirectX library).
As the author himself writes, the bot plays Starcraft 2 (SC2) by intercepting, understanding and reacting to the flow of D3D9 messages, sending keystrokes and mouse movements back to the game. It is not similar to other bots based on the SC2 editor and using a scripting language, or projects like BWAPI (works only with the original StarCraft), which is embedded in the address space of the game. Bots based on these methods often have the ability to circumvent the limitations that a person encounters when playing; for example, they can simultaneously give different orders to different units, they can see what is happening off-screen at any time, it is easy for them to get to the ground unit, closed by flying.
')
The article contains quite a lot of technical details and the source codes of the code that implement the bot are laid out. The main objective of the article is to show a simple program that works as an interceptor and interpreter of D3D9 commands. The advantage of this approach to bot implementation as compared to other methods (introduction to the address space, writing a bot in the SC2 scripting language) is obvious - the method is universal and can be applied to other programs, creating a bot using this method should be easier and more accessible. The disadvantages of the method are also quite obvious: it takes quite a lot of time and effort to analyze the scene and to achieve APM (number of actions per minute) comparable to other methods most likely will not work.
The bot is divided into three components:
1. Mirror Driver - storage of basic objects that are drawn on the map. Objects are textures, shaders, pixels, and other basic graphical information.
2. Scene Understanding - the data received by the Mirror Driver is input to this component, which converts them to the entities that are present in the game. That is, it transfers basic information to a higher level, with which it is already possible to build a game management strategy.
3. Decision Making - a component that is responsible for making a decision, or simply - the brains of a bot.
Since the call flow of the scene rendering is consistent, the result of the scene analysis is a table (a lot of traffic) that needs to be converted into information, on the basis of which you can make decisions and control the game. After making a decision on the basis of the graphic information again, one or another mouse click or keyboard key is sent.
The bot stores information about all the available game parameters: the number of units under its control, noticed enemies, etc. and makes a decision based on this information. The bot displays all the information about its actions in the console, which makes it easy to debug.
The decision-making algorithm is very similar to human actions. That or a certain command is given, the bot tries to execute it. For example: build a building, add a unit to the group, attack the enemy, etc.
The most interesting part of course is to observe the game of the bot and its actions. The author of the article recorded a video game under the control of the bot:
According to the analysis of the game, SC2 showed that in the “quiet” time the APM bot is within 500 actions, in battle mode from 1000 to 2000. Not all these actions are useful and micromanagement is difficult to implement; bot commands may be useless or even harmful compared to the default behavior of the unit.
Given that the author set the goal of the article to show exactly what tools can be used to write the “base” of the bot, and not the implementation of the bot itself, this is a pretty good result. After all, to improve the performance of the bot, you can change the decision-making component, such technical implementation does not impose special technical limitations for building a bot.
As the author himself writes, the bot plays Starcraft 2 (SC2) by intercepting, understanding and reacting to the flow of D3D9 messages, sending keystrokes and mouse movements back to the game. It is not similar to other bots based on the SC2 editor and using a scripting language, or projects like BWAPI (works only with the original StarCraft), which is embedded in the address space of the game. Bots based on these methods often have the ability to circumvent the limitations that a person encounters when playing; for example, they can simultaneously give different orders to different units, they can see what is happening off-screen at any time, it is easy for them to get to the ground unit, closed by flying.
')
The article contains quite a lot of technical details and the source codes of the code that implement the bot are laid out. The main objective of the article is to show a simple program that works as an interceptor and interpreter of D3D9 commands. The advantage of this approach to bot implementation as compared to other methods (introduction to the address space, writing a bot in the SC2 scripting language) is obvious - the method is universal and can be applied to other programs, creating a bot using this method should be easier and more accessible. The disadvantages of the method are also quite obvious: it takes quite a lot of time and effort to analyze the scene and to achieve APM (number of actions per minute) comparable to other methods most likely will not work.
The bot is divided into three components:
1. Mirror Driver - storage of basic objects that are drawn on the map. Objects are textures, shaders, pixels, and other basic graphical information.
2. Scene Understanding - the data received by the Mirror Driver is input to this component, which converts them to the entities that are present in the game. That is, it transfers basic information to a higher level, with which it is already possible to build a game management strategy.
3. Decision Making - a component that is responsible for making a decision, or simply - the brains of a bot.
Since the call flow of the scene rendering is consistent, the result of the scene analysis is a table (a lot of traffic) that needs to be converted into information, on the basis of which you can make decisions and control the game. After making a decision on the basis of the graphic information again, one or another mouse click or keyboard key is sent.
The bot stores information about all the available game parameters: the number of units under its control, noticed enemies, etc. and makes a decision based on this information. The bot displays all the information about its actions in the console, which makes it easy to debug.
The decision-making algorithm is very similar to human actions. That or a certain command is given, the bot tries to execute it. For example: build a building, add a unit to the group, attack the enemy, etc.
The most interesting part of course is to observe the game of the bot and its actions. The author of the article recorded a video game under the control of the bot:
According to the analysis of the game, SC2 showed that in the “quiet” time the APM bot is within 500 actions, in battle mode from 1000 to 2000. Not all these actions are useful and micromanagement is difficult to implement; bot commands may be useless or even harmful compared to the default behavior of the unit.
Given that the author set the goal of the article to show exactly what tools can be used to write the “base” of the bot, and not the implementation of the bot itself, this is a pretty good result. After all, to improve the performance of the bot, you can change the decision-making component, such technical implementation does not impose special technical limitations for building a bot.
Source: https://habr.com/ru/post/131357/
All Articles