Hiya, to improve my movement code I wanted to use a hardcoded graph of the map. I ended up doing that, and spent quite some time on it so figured the data I collected it may be of use to someone else perhaps for some sort of pathfinding or movement algorithm. You can get the file here: https://www.dropbox.com/s/v96opzewh0...tices.txt?dl=1 The file contains a chunk of lua code that can fill a table with the data you need upon loading the game, just find&replace the table name with whatever you want to use.

So I basically just made a list of vertices since that's all I needed. If you want to use edges too, you can use the vertices and calculate which other vertices are within a distance of 500. I made sure the entire graph would be connected at a distance of 500 and that (almost) all of the edges are sensible paths to take for bots. So for example in the river, I made sure to have a distance of at least 500 between the nodes in the river, and those on the ground above it. If you use other distances to generate the edges, you'll probably end up with either a disconnected graph or with weird edges leading over cliffs.
There should be no dead ends in the graph, every node has at least 2 neighbours and only those (juke) paths which actually allow you to exit through another exit (without cutting a tree) are mapped.

Every entry has an x and y location, plus an extra boolean. The boolean basically indicates how much walkable space there is around the node, to my bots if the closest node has 'true', it means they can be a little more flexible with positioning. Obviously you can just discard those booleans if you don't find that useful. It's by no means consistent anyway.

The data is obviously not perfect/perfectly streamlined by any means, but the quality is definitely much higher than what you can obtain through IsLocationPassable, and theoretically an algorithm using these should be more effective than the one baked in the API using the square grid, which doesn't fit the map that well.


The density of the nodes is perhaps relatively high if you want to pathfind to the other side of the map or something. You can delete the section containing added density if you want a lighter graph. I don't think this affects whether the graph is totally connected etc. though I'm not 100% sure. It may also be worth deleting the 'juke paths' section if you only care about long distance movement. The density of vertices also isn't completely uniform, my algorithm works better with more nodes, so the density is higher in important, commonly used areas, such as around the creep meeting points.

Obviously since this is all hardcoded, if you rely on it too much, sections will have to be redone after map changes, we may be good for a while now with the recent path. The graph also doesn't take things like cutting trees down into account.

It may be worth using a datastructure that allows you to easily find close nodes. I store them all in a 500x500 based grid datastructure and only look at the neighboring grid squares, which seems fast enough.


To make the graph, I used a technique that should be useful if you want to make your own graph, or redo changes later. I was too lazy to find and copy all the coordinates by hand, so I made a little function that allowed me to make the graph by moving around in game. Basically I tracked my players hero (shadowfiend) through a bot, and then inserted a node at my heroes current locations whenever I cast shadowraze. I used Q and W razes for creating the nodes (open/non-open terrain), the E raze to undo node creation. Then I drew the nodes to screen, and printed generated code to the console, which I later copy pasted out. So then I just spend a couple of hours running around the map casting shadowrazes in -wtf mode, and boom, a full graph of the map.

If anyone needs any of the support code let me know.