The Bot Core

In this post I will talk about the bot itself. After having roughly covered the foundation of it (which isn’t too interesting), I’d like to get a bit closer to where I am now with the development of the bot.

botdiagram2The bot itself is divided into separate modules of different types. On one side are the “service” modules which get updated every n frames, defined by the module, on the other side are normal modules which are just there to encapsulate part of the functionality. A small explanation of the modules in the diagram on the right:

  • Mapper: The core of the map and path finding, records new walkable nodes and connects them to neighbors. At runtime a quadtree is filled with the nodes in order to easily and efficiently find nodes in a radius around a point. They are stored in a simple array, without any compression so far, but that isn’t very important right now, neither is it a big problem.
  • Navigation: Takes care of player movement and puts the map data gathered by the Mapper service to an use. It finds a path from the source to the destination and then follows that path until it arrives or the movement is cancelled.
  • Harvest: Finds suitable mining nodes, herbs, corpses, chests, etc. to harvest/loot and keeps an updated list of them.
  • Targets: Keeps an updated list of possible targets and their priority, which is determined with a bunch of weights for factors like health, aggressiveness, distance, etc.
  • State: The logic behind the bot, keeps track of the current and previous state, and another global state that is always run. A state can also be a “sub state”, in which case it doesn’t override the previous state, this is helpful for state transition situations like Roam -> Pull -> Combat -> Roam.
  • Routines: Provides a loose framework for class specific functionality used by the different routines, for example pulling, combat, resting, buffing…
  • Player: Will encapsulate some generic functionality required by the different modules and especially the routines regarding player functions like targeting the best target. Not much in there yet, since there hasn’t been much work on routines yet.
  • Hotspots: Keeps track of grind hotspots the “Roam” state follows with the help of the Navigation service. It basically just cycles between a set of spots. I might replace this module with something more generic later on, since I don’t like this very much.
  • GUI: Not shown on the diagram, this service takes care of the GUI updating and displaying, it retrieves the GUI elements of the different modules (if they have a GUI) and updates them.

That’s it for the modules so far, there’s probably going to be more in the future, but since I’m not that far with the development yet, the picture will change a lot. Going to go a bit into detail on the problems I have right now in the next post I guess.

A Blog

Well, first of all, welcome to my blog, I have no idea how you got here, and especially why, but I am glad you are nevertheless.

Second of all, please don’t expect any exceptional insights into anything here, I merely keep this blog for myself to get some writing practice in and write about things I do. It’s of course great if it’s useful for someone, but don’t expect anything :)

Alright, now that I got that over with, here’s what I’m doing right now:

WoW Bot

Yeah, a WoW bot, pretty mainstream, I know, but it has the property of combining several different fields into one, making it hard to get bored. First of all you have the difficulty of making the game do what you want, so you can actually know what’s going on in the world and make the player move, etc. To achive that you have to reverse engineer parts of the game client, find out where in memory the information you need is stored, how it looks, what functions you need to call in order to move the player, retrieve informations, and so on. Once you have enugh experience in reverse engineering this, for the most part, just requires lots of time and patience debugging code, taking notes, etc. Thankfully the reverse engineering community in World of Warcraft is rather big, so most of the work has been done already and can be collected from sites like MMOwned (which is arguably 90% full of mouthbreathing retards or spoiled high school kids) or Game Deception. Obviously going into more advanced areas like not getting banned through Warden/etc. is an entirely different topic.


For my project I decided to implement that part of the bot as a DLL that is injected into the WoW process. The advantage of this is that your own custom code is running in WoW’s address space, which means you can easily read or write anything in World of Warcraft’s memory, and most importantly, call functions inside the client. Some say that DLL injection is a rather intrusive method and easily detectable, but it is in fact a perfectly fine Windows feature used by many applications, making it impossible to ban solely for that – it completely depends on what you are doing inside the process.

Anyway, the path from nothing to bot is laid out in three parts for me. The first part is the DLL that gets injected into the process which registers several additional Lua functions to make that functionality available to interface addons. By building the bot itself as a WoW addon most of the required functionality is already there, for example events and requesting information about units, etc. These additional Lua functions I create are used to retrieve information about things that are not provided by the WoW Lua API, that includes surrounding objects, object positions, model names, animations, etc. In addition to these more passive functions, there is also the part that deals with things like clicking on the terrain for “click to move” functionality, or targetting units by their GUID. The DLL is injected into the game client by an external program that invokes LoadLibrary through a remote thread inside the client.

Part two is already a WoW addon and deals with API abstraction or convenience functions in Lua, for example a Lua iterator for iterating through all visible objects – something that’d take a lot more effort if done with the Lua C API. The Ace addon framework is a huge help for everything from here on, for example the core addon fires a few events when the hook gets loaded or unloaded.

The third part is the bot logic itself to which I will get in another post. Here’s an useless uninformative video, there’s just not that much to show right now since most of the work is hidden. Just some combat and running around going on here.