When we started testing Obelisk and pathing mechanics, we grabbed what spare resources any gamer has lying around, Catan tiles and paper. We used this to construct crude first tests of the game. We soon realized that choosing how to tile the plane e.g. via hex tile, square tile, or triangle, was a critical decision. We knew that we wanted to keep the tower attack distance simple, which meant that in hex maps, towers placed on the corners could only touch / attack on three tiles. Square tiles could attack on four tiles, and equilateral triangles, six tiles.
Pretty immediately we realized that triangles wouldn't work, the pathing was just too weird. So then it was hex or square tiles. We liked the additional attack opportunity that square tiles offered so we proceeded to test with a paper version of square

The above pictures is one of the few of the original printed square tile version that was played in the beginning of January 2017. Later when I finally got back home after vacation, we affixed the printouts to square wooden tiles that I cut out by hand and sanded. We wanted to keep all the tiles locked together so we made a border. The art work was all scraped from GameIcons.net Much of that artwork we still use. Also note there is a castle (a destination for the monsters to walk to) in the bottom right of the picture on the right.

Tower defense games on the computer automatically determine the shortest path the monsters can travel using any number of mathematical methods. One of those methods is called Dijkstra's algorithm. The problem with computer pathing methods is that often times, they are testing lots and lots of potential paths, to find the one that is the shortest. The computer has lots of computational capability so this happens in an instant. However, humans are not so talented. In optimization speak: as the solution space increases (due to the game map getting larger), the number of possible paths to check increases, which increases the time it takes for people to calculate the shortest path the monsters could take. The more time spent calculating the monster path, the less fun the game is.
We spent two days trying all sorts of different pathing methods: Shortest path required lots of computation. In this variant you'd place walls to block the path and then you would have to recalculate the shortest path. Numbers on tiles, basically monsters have to go from a high number to a low number, when given a choice of where to move. So you would have to have preset maps and then place numbers Catan style, on top of those tiles to (optimization speak: form a gradient) make the monsters walk "downhill". Dials that point the way, these would be spinning dials twister style, that pointed which way the monsters could walk from each tile. I'm sure there were more methods. Eventually we were so engrossed in this adventure that my older sister KN, told us we had to stop and spend time with family. So much for fun holidays!
After months of testing, Asya and I finally settled on arrows, which is a variant of the Dials from above. The arrows would be printed on the tiles. This proved to be the most computationally efficient method for humans to solve while still providing some ability to change the monster path. So while Dijkstra's algorithm might provide a computationally efficient way of finding the shortest path for computers, we had developed a computationally efficient pathing method for human computers. We'll call it the AHN method (Aretskin-Hariton Norris).
AHN doesn't need a targeted end point that typical algorithms require. End points in tower defense games are usually "your base" which is at some fixed location and the monsters are trying to run there. We initially had a castle tile that the monsters were trying to get to, but when we left behind shortest path, we didn't need castle anymore. The side effect of getting rid of the castle is that we had to change the loose conditions: It doesn't matter where the monsters run as long as they don't run off the map or into a mountain or in a circle.
 The picture below is from about three months in. We have laser cut our first board (more on that later) and just figured out that we want pathing by arrows. Notice, there is not castle tile so there is not specific endpoint the monsters must walk to. We have a 4x6 map which can be resized to 6x6 based on the number of players. We are playing with blue monsters instead of purple monsters.

Everything starts with a crazy idea. This game is no different. In the end of December of 2016 we traveled to California to see family. It pulls at the heart strings to only see close family a few times a year. To bridge the gap between visits, I enjoy playing tower (td) defense computer games with JN, my brother in law. In December of 2016 as we are spending time with family and playing other board games, I start wondering if it's possible to harness some of that tower defense co-op magic that we enjoy and channel it into a table top game. JN suggests we do a lookup search to see what's already been done.
Christmas day, 2016, I'm sitting around with family and looking up tower defense board games. First stop board game geek, and I notice that almost all tower defense board games there have straight line pathing, that is, the monsters walking in a straight line. This immediately makes most tower defense board games lack a critical challenge, lets call it geometry puzzle. Half the fun of tower defense games is planning out how you want the monsters to run, what maze you'll make, and what towers you will place where (see picture of Sanctum computer game below). Without the ability to change the monster path, I felt like there was something lacking in these games. There was one game that did make an attempt to address the pathing issue, an that game had the users place path tiles as the game progressed. This still was not the same type of geometry puzzle that we really enjoyed from classic td games.
So we set to work figuring out how we could build a board game with better pathing...