Tag: <span>mazes</span>

This entry is part 11 of 11 in the series Mazes For Programmers

Following on from my experiments in timing the algorithms in part 9 of this series, I was curious as to why my code for Wilson’s algorithm took so much longer than the code for the Aldous-Broder algorithm. Jamis Buck (the author of the book this is all based on) was foolish enough to leave his email address on his blog, inviting people like me to ask him questions! I asked if he had seen anything like this difference. Turns out he hadn’t actually tried timing them, so couldn’t comment. This got me curious, so I pulled up his code, and started searching around to find out how to time code in Ruby. This turned out to be fairly simple (as it should), giving me the following… This gave me 10 numbers, which enabled me to calculate an average, as well as check on the variation (standard deviation for the statistical…

This entry is part 10 of 11 in the series Mazes For Programmers

One of the idea he had for modifying the Aldous-Broder algorithm was to force it to pick an unvisited neighbour, if one exists. I think the idea was to cut down on the number of very short dead ends that the basic algorithm produces. If you look at the following sample, you can see that there are a lot of places in the maze where there are many short walls, making it pretty obvious which way to go… The plain algorithm picks a random cell from the current cell’s neighbours… It was pretty easy to change this so that it would always pick an unvisited cell if there were any… With a little thought, I could probably change the Where clause to include both cases, but it didn’t seem worth it at the time. Anyway, this simple change produced a marked difference in the quality of the mazes. Apart from…

This entry is part 8 of 11 in the series Mazes For Programmers

This was my first real challenge. I converted his code for the Binary Tree and Sidewinder two algorithms, and Aldous-Broder turned out to be pretty straightforward to implement, so my code looked a lot like his. However, Wilson’s algorithm was a different matter altogether. I had been reading the book at night, and didn’t have it by my side when I tackled this algorithm. I had read his description of the algorithm a few times, and it seemed easy enough. Ha, famous last words. My first attempt was pretty rubbish. The algorithm didn’t terminate, and what it produced along the way was not very impressive. Unsure what had gone wrong, I re-read his description (whilst avoiding the code) and realised that I had mis-read it, and had got two small, but significant points wrong. I could go into a lengthy discourse about how important it is to understand your requirements,…

This entry is part 7 of 11 in the series Mazes For Programmers

As mentioned in the previous post in this series, I decided not to convert his Ruby code into C#, but rather to read his description of the algorithm, then try and write my own code. This way I am forced to understand the algorithm, which is far more productive than simply copying out someone else’s code without really knowing what it does. I had actually seen his code for Aldous-Broder, so had a basic idea of how he went about it, but hadn’t looked at it very closely, so was mainly writing it myself. The end result was actually very similar to his. One thing I discovered when running it was that my mazes were anything other than non-biased. Pretty much every maze I generated had an empty corridor right across the top row, leading me to realise that I had done something wrong. Furthermore, every now and then, the…

This entry is part 6 of 11 in the series Mazes For Programmers

Having implemented Dijkstra’s algorithm, the next bit of fun was to use it to find paths through the maze. Although I had looked at his code in the book, I decided to have a go at writing my own method from scratch, rather than converting his code into C#. This is a better way to understand the algorithms, and saved me having to figure out some of the less obvious language Ruby features. The end result was actually very similar to his code, although I made use of Linq (yet again) to avoid a loop, making the code a little clearer… I called my method PathFrom, as you specify where you want to go from, and it gives you a path from there to the root of the Distances object. He called his path_to, presumably because it gives you a path to the specified cell from the root. I guess…

This entry is part 5 of 11 in the series Mazes For Programmers

The main part of Dijkstra’s algorithm is implemented in the Distances class. For the most part, my code didn’t look that much different from his. The main change was that I was able to use Linq to remove an if when traversing the frontier… I broke lines 6-8 into three to make it easier to read in this blog, but in the code, it’s just one line. Linq enabled me to avoid having to check if the next cell had already been linked. Adding the numbers to the text output was very simple, as I already added the facility to display cell contents (see part 2 of this series). The challenge was putting these numbers on the UI. This turned out to be much easier than I expected, and even worked first time, which surprised me! I added a method to the window’s code behind, passing in the distances collection…

This entry is part 3 of 11 in the series Mazes For Programmers

Part 3 in my ongoing series of how I implemented the code from Mazes For Programmers by Jamis Buck in C#.

The author rendered the mazes in graphical form using a Ruby library that allows you to create PNG images. This requires you to run the code, then open the saved image, then remember to close it before running the code again, otherwise you get a “File access denied” error, all of which seemed like hard work. As I work with WPF on a day-to-day basis, I decided to use that to render my mazes, as it was quicker and easier.

This post shows how I did it.