Well, actually nothing significant in terms of the rules. There is a small addition to the API but this isn’t a major new feature. The addition of recharging last year was quite significant, and we want to allow more time for students to get used to it, and for us to see if it needs balancing. I may still add another maze type before the competition event, but that would be the extent of the changes for this year.

Instead, our focus this year is on opening the competition to other colleges! We feel this is the obvious next step in growing the competition.

For a couple years the prize money was provided by Mohawk, and under that situation we were understandably restricted to Mohawk students. But since last year we have independent sponsorship, and so we are now able to accept submissions from students at any Ontario college. For this first time we don’t expect to get many outside submissions, but we are hoping for a few at least. We’d like to set up a friendly rivalry among the colleges, to see who has the most dedicated and talented programmers!

What we are trying to do is create a snowball effect: by increasing our visibility and number of participants, we are hoping to attract more sponsors. With more sponsors we can offer a larger prize pool, which will then attract more participants and increase our visibility.

We are now in the process of communicating with some other colleges to spread the word. Promotion in general is a large task, one best undertaken by specialists. Professor Yendt and I aren’t particularly good at this; our field is mainly the technical side of things. So this is an opportunity to bring in some other volunteers to complement our efforts.

I’m not sure what we’ll do in upcoming years regarding new features in the rules/API. There was some discussion of possibly having multiple rechargers, and that seemed the only practical idea we had. Everything else seemed to be overly complicated, compromising our primary design criterion (keep it beginner-friendly). It may be that we have reached a plateau, or it may only be that we lack good ideas! If the latter is the case then perhaps our nascent community will direct us.

I do have a number of ideas for new features in the development tools, but they would require major rearchitecting of the code. I reckon we’ll tackle it eventually, but that’s beyond the horizon at the moment. Small steps!

The idea of the bots having a battery with a limited amount of energy was already present in earlier AMazeBots, though never explicitly stated or emphasized. The scoring was considered purely in terms of abstract “points”, but as each action cost a certain number of points it was analogous to energy usage. The bot that solved mazes using the least amount of energy won.

This year we have made this analogy explicit, and have added a device somewhere in the maze that a bot can find and pick up, which will allow it to recharge its battery by a small amount. Conceptually this is similar to having 2 goals, with one of them being optional. The main difference is that while bots know exactly where the goal is before they start, they have no idea where the recharger is. They have to find it, and the way they do this is by sniffing for it.

Well, not literally. We imagine that the recharger emits a radio signal, and bots can detect this signal. The signal penetrates walls, but gets weaker over distance, and beyond a certain distance it becomes too weak for the bot’s sensor to detect. Also, the sensor can’t determine the direction from which the signal originates—only its strength. From the strength it calculates the distance (and this is the information returned to the bot’s brain, i.e. the program that students write). Lacking the direction, multiple readings need to be combined to pinpoint the recharger’s location. Finally, we imagine that scanning is an active process that consumes a little bit of energy, and that picking up the recharger consume a little more energy. Together this means that bots have to be smart about how often to scan, and can’t hope to get lucky by just trying to pick up in every bar cell.

The beauty of this change is that it adds a layer of complexity, which can be ignored by beginners.  The primary design criterion for AMazeBot is that it must remain accessible to students who have no more than 1 semester’s experience in programming. Recharging being optional allows beginners to focus just on getting their bot to reach the goal, and leave the rest to tackle in subsequent years as their skill grows. At the same time, recharging provides enough subtle challenges to keep advanced students interested and occupied.

It was not easy choosing the values for the various parameters surrounding recharging, of which these are the main ones:

• The recharger capacity (currently set at 1000 units, which is 10% of bot’s on-board battery)
• The detection range (currently set at 11 cell units)
• The cost for scanning  (currently 3 units)
• The cost for attempting to pick up a recharger (10 units)

The energy costs were not too difficult to set; scanning had to be cheap but slightly more expensive than a regular look, and picking up just had to be expensive enough to make it prohibitive to try more than a few times.

The capacity and detection range were the primary points of contention. A larger capacity makes it more worthwhile to find the recharger, but if it’s too large it essentially becomes mandatory in order to win. This could discourage beginners by making it impossible for them to finish anywhere near the top of of the ranks. Too small a capacity makes it worthless for anyone to ever bother with it, in which case it was pointless to add the recharger at all. Similarly, too large a detection range makes finding the recharger a trivial affair, whereas too small a range makes it too much a matter of luck. For both parameters a balance is desired such that recharging is worthwhile but not always so, and just enough luck is involved to make it interesting but not so much that it’s intractable to optimize for it. There should be some decision making involved on a situational basis: if I have detected the recharger, should I try for it or forget it and continue on to the goal? This allows different strategies to be viable, and allows beginners at least a chance to be competitive.

Given that this is the first time we’re trying this, we don’t know whether our choices were balanced or not. The initial reaction of some people was that the capacity might be too small. I have done some very preliminary testing and I think the current values are not bad, but in order to avoid biasing the competitors I will say no more. The ultimate test will of course be the competition, and we’ll have to wait to see what happens.

One important point was raised by Nick Hobson (2nd place winner in 2007 & 2008). Originally I had the recharger being placed randomly anywhere in the maze (but on a floor cell, so as not to alter the topology). This would have meant that the recharger would sometimes be inside a completely sealed room. It could still be detected, but a bot attempting to retrieve it would find it impossible to reach. Although an intelligent bot could realize that and give up, Nick suggested that having to write code to deal with such hopeless cases would suck considerable fun out of the recharging concept, and make students less inclined to try.  I deemed this a valuable psychological insight, so I changed the system to ensure that the recharger will always be in a reachable cell. Of course it still may not be worth getting; for example the recharger may be in a cell near the bot but the only path to reach it is too… labyrinthine. Somehow that does not seem quite so egregious, whereas a completely inaccessible recharger feels like a deception.

When I first wrote the Batch Module for 2008 I didn’t have much time to polish it. As a result, although it was functional it was somewhat unfriendly. It’s an important tool for the students however, perhaps used more often than the Developer Module. I had always intended to make a number of improvements, but failed to do so for 2009.  Now for the upcoming 2010 competition I have finally given it the attention it deserves. Here are a few things that I’ve changed.

Cleaner Arguments

One nuisance with the old batch mode was the format of the command-line arguments. All the options were order dependent, so specifying one meant you had to first specify all the previous ones, even if you wanted to leave those other options at their defaults. The new format is much nicer; here is the usage information given by the program itself:

Usage: java -jar AMazeBot2010.jar batch <botname> [options]

Where options can be any combination of:
 -i <iterations>     Default 50,000.
 -s <sequence>       Default is random.
 -m <maze type>      One of GR, NS, RG, PR. Default is Automatic.
 -d                  Produce detailed action counts in csv output.

Note that the botname is case-sensitive; options are not.

Any items in angle brackets are required, and those in square brackets are optional.

Action Counts

In the early AMazeBots the GUI showed the number of looks, moves, and turns that the bot performed. This was deemed not particularly useful for students and removed in the 2008 rewrite. However we (the Professor and I) realized that we could actually make use of that information for planning purposes.

Mostly we wanted to know how often students were using the lookFarAhead function. This is an advanced function that allows the bot to determine the number of open cells in the direction it’s facing, as opposed to the regular look function which only indicates whether a single adjacent cell is open. If the cost for this function is too high then it’s never worthwhile to use it, so knowing the frequency of use could help us in adjusting its cost appropriately. Thus I’ve added the counts of all the various bot actions to the batch log. Perhaps in this easier-to-access format students may come to find it of some use after all.

By default all the actions of a particular type are combined—for example all the successful moves are summed together, regardless of whether they were forward or backward. Likewise for blocked moves, looks and turns. However in some rare cases it may be necessary to know the counts for each individual action; perhaps you suspect your algorithm is behaving oddly and doesn’t like to turn left, as an example. For discovering things like this the “detailed action count” option is provided.

CSV Output

The old module printed its output to the console in a human-readable table, like this:

Batch testing Bot "MotionTrout (alias "MotionTrout")
On 10 mazes from sequence 605023665 of type (Automatic)
==========================================================

   Maze                       Best              Final
  Number     Maze Type        Score   Result    Score  Perf
----------  ----------------  -----  ---------  -----  ----
1701561105  Pure Random        2165  FOUNDGOAL   9615   4.4
 331234850  Recursive Growth   2090  FOUNDGOAL   7410   3.5
1964692999  Nested Squares     2050  FOUNDGOAL  12870   6.3

This output could be redirected to a file for later inspection, and could also be imported into a spreadsheet for more elaborate analysis. The problem is that the fixed-width columns can’t be automatically parsed by the spreadsheet, requiring manual setup. Since this raw data is rarely inspected directly by humans, the new module produces output in CSV (comma separated values) format and furthermore always saves the output to a file. This makes it very easy to load the data into a spreadsheet, and a separate text file containing the summary only is produced for humans.

Interruptible Batches

Although previously a batch run could be interrupted with the usual Ctrl-C key combo, it would just end abruptly. No summary would be given of the mazes run so far, although if you were redirecting output to a file you could at least get the raw data up to that point. If one was doing this redirection, the program would periodically print a single-line progress report to stderr (which would still appear on the console when stdout went to a file). This showed the number of mazes run (both absolute and as a percentage of iterations requested), elapsed time and estimated time remaining:

    Completed: 10 (3%)    Elapsed: 1 s    ETR: 56 s
    Completed: 20 (6%)    Elapsed: 4 s    ETR: 56 s
    Completed: 30 (10%)    Elapsed: 5 s    ETR: 47 s
    Completed: 40 (13%)    Elapsed: 7 s    ETR: 48 s

Redirection is no longer necessary since a log file is always saved. However the progress indicator still remains, and I realized that it would be better if this included the average score and performance achieved so far. Also it would be easier to read if it remained on a single line rather than continually printing new lines. Both of these changes have been implemented, and additionally when interrupting a batch a summary is produced for the mazes run so far.

Previously because of the poor support for batch interruption the default number of iterations was set at a very low 10. Now the default is a huge 50,000 (since common spreadsheet programs are limited to 65K rows). You can watch the averages change as the batch proceeds, and whenever you’re satisfied that the numbers have settled down you can simply stop the batch and get the full data and summary up to that point. No need to specify the number of iterations ahead of time.

Conclusion & Future

I think the Batch Module is quite nicely polished now, being more functional and friendlier.  I hope the students find it makes the task of performance-tuning their bots easier.

I will mention one feature that I had in mind but did not implement this time: multi-core support. It isn’t of great importance, both because batch testing isn’t a huge time burden and because the average computer has only 2.2 cores. But it’s always nice to have things run faster, and I may eventually use this as a reason to properly learn the Java concurrency package.

It is unfortunate for me, as I had a number of ideas for improving the course and my framework that I wanted to try. On the other hand, it means I still have my free time—teaching required me to go to Mohawk twice a week for 4 hours in total (and transportation and preparation time on top of that) while still maintaining full hours at my primary job at Mac, which was draining. Not that I’m making much productive use of my free time, but still… it’s nice to have.

I think this may be the last time this course is taught at Mohawk, at least using the current platform (OpenGL via C++). I know that Mohawk is restructuring its Software Engineering program (for one thing I believe it’s going to be renamed to “Software Development” which is just as well; I don’t think we had much actual engineering discipline taught) and as part of that C++ is being phased out. Depending on when that happens (or happened) this course may yet be taught once more, but once only. After that, it will either have to change (perhaps to C#/XNA?) or be retired.

Incidentally, I taught Assembly Language the previous year and that too was phased out. I’m not sure if these changes are good or not. Although I feel C++ and even Assembly are important and worthwhile to learn (and I’m sure quality university programs will continue to teach them), Mohawk is focused very much on catering to the broad needs of Industry, and getting their graduates jobs. And the bulk of the jobs these days seem to be in Java or C#, and typically on a web platform. So perhaps overall it is the correct direction for the college.

Well ok, actually I am a programmer, in that I am employed to (among other things) write programs. But it’s not in the professional sense that I wish to be a programmer, it’s in the amateur sense. That is, the original meaning of “amateur”, one who does something for love, not money. (However I certainly am an “amateur” programmer in the more common sense, “novice” rather than “expert”–sometimes words can be so difficult.) I say this because although I love programming in the abstract, I just don’t do a lot of it! Ergo the conspicuous absence of posts about my programming projects, which is what this blog was ostensibly for.

I just haven’t been greatly motivated to do anything for quite some time, and I’ve been struggling to figure out why that is. I’ve identified a couple reasons:

Programming at work makes me disinclined to do programming at home. This is a feeling that a number of my programmer friends have reported also. For some it goes even further–they don’t even want to be on the computer at home. I don’t seem to have that problem; I’ve no difficulty spending much (and probably too much) of my time at home playing games, browsing the web, whatever. But focusing on projects, even when they are fun stuff compared to the boring stuff at work, is often difficult.

Programming alone is dull. When I was younger I learned programming by myself, and most of my early experiments and projects were done solo. It wasn’t a problem then, though I would have liked working with other programmers. I just hadn’t had many friends who were interested in it. But I find now that my disposition has changed, and I more strongly crave the interaction with others. I had the opportunity for it in college, and now prefer it. This is a major thing lacking from my job actually, the fact that I am not on a team of programmers.

Fortunately these factors don’t always prevail; sometimes I can manage to overcome them and get stuff done. Sometimes I can even reach the mood described by Nikola Tesla:

“I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success… Such emotions make a man forget food, sleep, friends, love, everything.”

All summer I did no programming at all, but when September came and I realized I had a lot of work on AMazeBot yet to be done, I managed to slowly get back into it. I’m not yet in the Tesla state, but I’m gaining some momentum.

Now if I can only find the motivation to write blog posts more frequently…

The notorious Conficker.C even made an appearance, and though the worm was ineligible to win prize money, it did put in a respectable performance, possibly frightening some of the other bots in the process. But in the end it was vanquished by a sleepy kitten, a Dalek, and a mouse.

I can now reveal a couple of the things I had been working on: the new design for T-shirts which were given to all competitors, and the title screen used in the show. Also, this was the first year in which a custom (i.e. hand-drawn instead of procedurally generated) maze was used, and it proved to be the most difficult of the 5, exhausting an astonishing 13 bots.

T-shirt design.

Title screen.

Concentric maze.

The complete final results are posted on the official website, and soon (eventually?) there will also be photos from the event.

Some of the competitors will be graduating this year, but  many will be able to enter again next year, including the current champion who has taken 1st place for 2 years. Will he be able to claim the title a third time, or will he be dethroned? Will some mutation of the worm or another of its ilk arise again to threaten all good hard-working bots? Will there be a custom maze so insanely convoluted as to foil every single bot? All shall be discovered in a year’s time!

As for what new features might appear in 2010, I cannot at this time make any comments, other than to dispel rumours that there will be a minotaur.

The original Amazebot system consisted of only a single module that was used both for writing bots and in the competition show. This module was contained in a library that could not be run independently, instead relying on students’ code for the main function. A compiled Amazebot program would create a window with a maze, run the bot through it while drawing its path, and then exit writing the results to a log file. The mazes were procedurally generated based on a seed value which was obtained from an ini file. For the show, a script was prepared which, for each of the 5 rounds, did the following: modify the ini file to specify the seed for the round, execute each bot program in turn, and process the log file to create an HTML file showing the bot rankings.

This system worked adequately, but there were a number of deficiencies. The solutions to these resulted in the system being split into 3 modules, each described below.

Developer Module

When testing a bot it’s desirable to run it on several different mazes. By omitting the seed from the ini file, it was possible to have the seed chosen randomly each time the program was run. However one problem was that not all generated mazes were actually solvable—due to the stochastic nature of the algorithm, sometimes the goal room would be entirely blocked off from the starting position. This happened on roughly half the generated mazes, which resulted in a modest but annoying waste of the programmer’s time. Thus one of the first changes I made was in the maze generation code, to guarantee that every seed produces a solvable maze.

Also, I didn’t want the programmer to have to rerun the program just to get different mazes, so I altered the GUI to allow new mazes to be generated (either randomly or by specifying the seed in a textbox) and the bot rerun through them. This necessitated a change in the overall architecture–the bot could no longer be the main function, instead becoming a separate class. The rest of the system had to become an independent module that could instantiate and run (multiple) bots as needed. Additionally, Professor Yendt had suggested a maze editor to allow custom hand-drawn mazes to be used, so I incorporated this as well, with the ability to save and load mazes. All this became what I called the developer module.

The developer module.

Previously, mazes for all 5 rounds in a competition were generated with the same algorithm (at first it was the type I call “Nested Squares”, and later it was switched to “Grid of Rooms”). One drawback to this was that students tended to make too many assumptions about the maze layout, and fine tune their bots to do well on just that type of maze. There’s nothing wrong with that for the competition of course—that’s what you have to do to win—but it does discourage the writing of generally efficient and intelligent bots that could handle any type of maze well. In addition, for the spectators at the show it looked rather boring, with each round appearing superficially the same as all the others. For these reasons I wanted each round to be distinct, and so added 2 new maze types (Recursive Growth and Pure Random).

There was also a complete graphical overhaul—the earlier versions simply drew a circle in all cells visited by the bot (it could not be discerned which way a bot was facing!) and I changed this to an arrow that traces out a line. Further refinements include controls to replay or step forward and backward through the bot’s path, or to forgo animation entirely and only show the complete path. At the right is a screenshot of the developer module, showing the Pure Random maze type (the other 3 types can be seen in the screenshots in my earlier post).

Batch Module

To optimize a bot, the programmer needs to be able to measure the performance of different algorithms and compare them. Since the mazes are entirely determined by the seed, it’s easy to run several variants of a bot through the same maze. However a single maze is far too small a sample for a meaningful comparison—for statistically significant results, one must compare bots over a set of thousands of mazes. No facility for doing this was provided in the original system, so when I was developing my bot I created a script similar to the one used in the show, except that it generated the maze numbers themselves randomly. Thus a single meta-seed represented an entire fixed series of mazes and I was able to repeatedly run bots over the same set. Processing the resulting log files in a spreadsheet yielded comprehensive information on algorithm performance.

However there were some impediments that slowed down this script. The major one was that there was always the overhead of the GUI—creating the window, drawing the maze and the bot moving through it, plus a delay of a few seconds before the window closed. There was also the fact that half the generated mazes were unsolvable (though that was later fixed), which furthermore required some extra effort during analysis.  Together these issues meant that it could take on average over 10 seconds to run a maze.

To address these issues I introduced the batch mode—a command line module that runs bots entirely in memory and does not draw anything. With my reference bot it can run at least 5 mazes per second, and it also does a simple analysis, showing the frequency of the different bot outcomes (solved a maze, ran out of energy, stuck, etc.) as well as the average score. The output of this mode can still be imported into a spreadsheet for more extensive analysis if desired.

It also provides a new metric called simply “performance”. This arose out of a side effect of the fix that prevented the generation of unsolvable mazes. There was code which checks if a given maze was solvable which, by the nature of its algorithm, also calculates the best  (i.e. lowest) possible score for that maze. The performance metric is simply the factor by which a bot’s score exceeds the best possible score. If a particular maze has a best score of 2500, and a bot finishes with a score of 6500, then the bot’s performance rating for that maze is (6500 ÷ 2500 =) 2.6. This number reflects a combination of the maze’s complexity and the bot’s efficiency.

Competition Module

For the competition show there was one primary goal: make it interesting and fun for the spectators. The 2 basic ways to do this are to provide excellent visuals, and to engage the audience.

The visuals were the area that needed the most attention, as Professor Yendt simply had not the time to polish the presentation. The chief problem with the old approach was that bot programs were self-contained. The show thus consisted of many programs being run in succession—windows would be appearing and disappearing all the time, and not just bot programs. There were command windows running scripts, and a browser being invoked to show the ranking pages. Between each of these, the Windows desktop remained visible with all its usual clutter.

It was, in short, a kludge. I resolved to have a single full-screen program that would run the entire show: loading and running bots, displaying rankings and winners, and doing it all with smooth transitions and animations. My aim here was to make it look like a video game, and the screens were designed with that aesthetic in mind. I developed a method of drawing the maze so that instead of appearing as composed of individual blocks, walls appeared as solid pieces of varying lengths. The bots were depicted as arrows, as in the developer module, but instead of instantly jumping from one cell to another, they would move smoothly between them.

It all looked good, but the bots still seemed abstract and lacked character—this is where engaging the audience comes in. So I allowed for each bot to have a custom icon and name (previously only the programmer’s name was shown). This turned out to be quite fun; not only were the programmers given a chance to personalize their bots, but the audience began to identify the bots after a couple rounds. They knew that certain bots would behave in certain ways, and they seemed much more interested in the outcomes than in previous years.

One of the best new features was allowing up to 4 bots to run simultaneously. In this mode the bots would not interfere with each other; they were simply shown at the same time. In combination with the personalized bots, this was much more interesting to watch, as there was a more direct feeling of competition, as in a race. As a bonus it also reduced the time required for all bots to run through a maze.

The Future

We still have many more ideas for improvements, and a few will be introduced this year. I expect to report on some of these in a few weeks, after the competition is concluded. I also welcome any suggestions that readers may have.

There is an alternative layout in which the arrows keys are placed to the left of the alphabetic keys, and the number pad to the left of those. Besides moving the mouse closer to the most commonly used keys, this also provides an enter key for both hands, and allows one to rapidly type numbers while continuing to use the mouse. A keyboard with this sensible layout (for right-handers) is referred to as a “left-handed” keyboard. The world is, in case you have not noticed, largely insane.

An ergonomic keyboard is one in which the keys are arranged in a curve rather than linearly, and usually have a gap between the left and right alphabetic keys. The intention is to allow the wrists to be kept at a more natural posture while typing. There may be some additional niceties, such as a pad for the wrists or heels of the hands.

Ergonomic keyboards are quite common these days, and a left-handed keyboard can also be had without much difficulty. Sadly it seems that these sets do not intersect, for it is nigh impossible to find an ergonomic left-handed keyboard (or, equivalently, a left-handed ergonomic keyboard). The closest ones I’ve been able to find are made by Fentek and Evoluent, neither of which particularly appeal to me. The good people at Evoluent seem to understand the absurdity of this problem; they even describe their keyboard as “mouse-friendly” rather than “left-handed”. If only the layout more closely matched the usual ergonomic style, such as in the keyboard I currently use made by Adesso or my previous Microsoft Natural Keyboard 4000 (which drowned in a tragic accident).

Actually even these ergonomic keyboards have various problems inherited from their primitive ancestors (truly, it’s like these things had evolved rather than been intelligently designed). I refer to the physical positioning of the keys rather than their logical labeling–a Dvorak layout still exhibits asymmetries that confound human hands. But it’s too much to expect all this tradition to be thrown out and an ideal keyboard produced from scratch. I would settle for an ergonomic keyboard with the arrows and numpad on the left.

In the meantime, I suppose I should learn to mouse with my left hand.

This peculiarity baffles me; I can’t fathom why anyone would program a password check in such a way. But leaving that aside, what are the implications of this behaviour? Minimally, that the program must know the length of my password. Without that information it couldn’t know how many characters to ignore, were I to type too many. (Well, actually that isn’t strictly true—there is a way to do it without knowing the length of my password, but it’s a silly trick.) Now, there are basically 2 ways in which the program could know the length of my password. The most direct and obvious way is to store my password in its database and thus be able to simply count the characters. Alternatively, it could store only the length as a number but not the password itself.

But how could the program possibly be not storing my password? How can it check whether the right password has been supplied, if it doesn’t know what the right password is? By using a form of encryption known as hashing. A hash function takes plaintext (original, readable text) of arbitrary length and converts it into a ciphertext (encrypted, unreadable text) of fixed length, which is called the hash. The important property of this function, that differentiates it from other kinds of encryption, is that the reverse operation can’t be done. This means the function is “one-way” only: you can turn any plaintext into a hash, but given a hash it’s practically impossible to reconstruct the plaintext.

Using this scheme then, instead of storing the password as plaintext, the program could store just the hash. To authenticate a user, the program need only hash whatever the user has typed in, and compare the result against what’s in the database. Thus, without even knowing what the password actually is, it could ensure that the correct one was given. Because all hashes produced by a particular function are the same size, even the length of the original password is obscured. That’s why if the program were using hashing to avoid storing the password itself, it would have to store the length of the password separately. Unless, that is, it used the silly trick I mentioned—which I’ll not reveal here, as it should be fairly trivial to figure out (feel free to ask in the comments if you’re stuck though).

So what is the program actually doing? Well, the observed behaviour is most straightforwardly explained by the storing of plaintext passwords. In fact I jumped to that conclusion when I discovered the peculiarity, and it was only after analyzing the situation in depth for this post that I realized that it wasn’t quite certain. But anyway what does it matter whether it’s storing plaintext or hashed passwords? In a word, security.

Consider what would happen if an attacker were to compromise the database and obtain read access. If the passwords are stored in plaintext, then it’s a disaster; but if only hashes are stored, then the passwords themselves are still (for the moment) secret. Even under normal circumstances there is a benefit—hashed passwords are secret also to the administrators of the system. Users commonly use the same password for many services, so they are better protected if they don’t have to risk placing undue trust in admins; and if something does go wrong, an admin is under less suspicion if they could not possibly have known a user’s password.

This is a very basic security technique, but the knowledge of it seems depressingly uncommon in the software engineering field. A major part of the blame lies with educational institutions; I was not taught this in college, having instead to learn it on my own (fortunately not the hard way). Hashing is only the beginning though, as there are still ways an attacker could defeat such a system. The second line of defense is to add salt, which I’ll cover in a future post.

The Amazebot is an annual competition run at Mohawk College, open to all students (though most entrants are from Software Engineering). Competitors must write a program that will navigate a virtual robot through given mazes as efficiently as possible. It was started in 2003 by Professor Mark Yendt, in an effort to show students a fun side of programming. The first 2 competitions were done in C++, and thereafter switched to Java.

While I was in college I entered 3 times, and (I must beg pardon for this boasting) I won first place all 3 times. It wasn’t all just talent though–I put a lot more time into it than most, and I believe that effort is what really paid off. Back then the system was rather primitive, both in terms of the tools provided for students to develop their bots, and the quality of the visual presentation during the competition itself. I had several ideas for improvement, and after I graduated Professor Yendt graciously allowed me to rewrite the software from scratch. My version was first used in the 2008 competition and was well received by both entrants and spectators. You can see the evolution of the system in these 3 screenshots:

2003

2005

2008

The basic concept has remained the same over the years though. The maze is constructed on a grid of 44 × 44 cells, each of which can be either open (floor) or closed (a wall). This is simpler to deal with than some other types of mazes, in which walls are drawn only between cells. Instead of escaping the maze, bots must attempt to reach a 4 × 4 cell goal room. A bot can perform a few different actions: it can move forward or backward, turn left or right, and look into the cell ahead or to either side of it. Each action costs a certain number of points–this represents energy that a real bot would have to expend to do anything. The challenge is that bots start out without any information about where the walls are–they are given only the location of the goal room. They must explore and discover the layout of the maze as they go along in order to find a path to the goal. There are 5 rounds in the competition (each a different maze) and bots with the lowest overall scores win.

I’m planning a series of posts to discuss in detail how the system works, new features I’ve introduced, and the competition itself. I’ll also offer tips and tutorials for students getting started.