EPTI decided to take a small break from creating my StarCraft bot
LetaBot to see how well bots perform in other e-sport titles. While checking the subreddit, I found out that Dota 2 has an offline LAN mode. This got me interested in checking if it was possible to create a bot API for Dota 2 like the one that Matthew Fisher did for StarCraft 2 ( https://graphics.stanford.edu/~mdfisher/GameAIs.html ). The advantages for using this method over the build-in scripting language is that a build-in scripting language is significantly slower than C++ code, and you cannot store/retrieve as much information as your hard drive can handle ( haven't used Dota 2 script, so correct me if I am wrong about Dota 2 script limitations).The problem with using DirectX interception to create a bot for StarCraft 2 is that you have to use battle.net to play against other players, and Blizzard won't like it if you use DirectX interception on battle.net . After all, DirectX interception allows you to do stuff like this:
![[image loading]](https://graphics.stanford.edu/~mdfisher/Images/SC2TintPlayerColor.png)
Or even more outlandish stuff like this.
But with an offline LAN mode, you don't have to worry about this sort of stuff getting you banned and leaving you with no other options to play versus other players.
The first attempt to get the graphics interceptor was to use the Matthew Fisher's DirectX interceptor on Dota 2, since the interception part of the code doesn't care about the program it is used on ( placing the modified d3d9.dll in the dota2.exe folder makes it load that one instead of the one in system32 ). This doesn't seem to work since dota 2 crashes when it tries to start up the main menu ( probably something involving the shaders that dota 2 uses, as you will see in apitrace below. ). It did manage to store the load screen textures:
![[image loading]](http://i.imgur.com/Hm4PTiC.png)
So when I contacted Matthew Fisher, he directed me to a different program called apitrace. That one does manage to collect all the directX API calls, but for some reason it has problems with the shaders as well, causing the frame replay to look mostly black ( with only the top/bottom GUI, healthbars and some flame effects visible). So instead I switched to OpenGL. One driver update later I was capable of getting apitrace to record and replay the OpenGL calls.
Some pictures of the success below:
![[image loading]](http://i.imgur.com/nQGK2ZP.png)
This is the texture of
tiny IIRC.![[image loading]](http://i.imgur.com/sFhxnMB.png)
Scene rendering in progress. Notice the checkerboard textures below each hero (and the spells), and the fact that this image is flipped ( vertically, the original image was upside down ).
Since apitrace is open source, this can be use as an initial starting point to use the same technique that Matthew Fisher used to make his StarCraft 2 bot.
Very ( very very ) simply put, the following needs to be added to the apitrace to make it usable for a Dota 2 Bot API:
- Know which texture belongs to which hero. You can look at Matthew Fisher's texture table for StarCraft 2 to see an example of this.
- Know when these textures are drawn, and where on the screen the texture/hero is located ( as in, not on the XY coordinates of the dota 2 map, but the XY coordinates of your monitor ).
- Use the information above to determine when/where to click on the screen. You are basically sending click commands instead of using a physical mouse, just like AutoIt and other related programs do. The difference is that you aren't relying on the color of certain pixels like a simple runescape bot, but on the information that is send through the graphics pipeline (getting this information purely based on the pixels on the screen is too complex for a game like Dota 2: it would take too much time to process and dota 2 is too fast paced for that).
Besides hero location you ofc also need things like the location of creeps, your/ally/enemy health and all that sort of stuff.
Anyway, I am going back to my StarCraft bot now. I still have to wrap up my master thesis on it. If anyone is interested in already starting on developing such an API, you can pm me and I can give you some (OpenGL, graphic pipeline) guides that can help you get started. In general you will need to know about C++ and OpenGL ( general 3d graphics knowledge should suffice as well, it is mainly about extracting information, not programming OpenGL ). I myself will start digging more into this stuff next month (March).
