SpaceChem is a remarkable puzzle game about fake chemistry. The game challenges you to build a factory in order to transmute the given input molecules into the given output molecules. While chemistry is the theme, on a mechanical level it has more in common with programming. The methods used to tackle challenges in SpaceChem are akin to real techniques used by computer programmers. I’d like to elaborate on these manifold similarities, as well as explore how games like SpaceChem could be used to promote procedural literacy.

The player commands two circular “waldoes” by laying out paths and instructions for them. The waldoes follow the path and sequentially execute any instruction they come across. They can grab, drop, rotate, sync, bond, fuse, request input or dispatch output. The waldo’s analogue in computing is the processor, a hardware component that sequentially executes basic operations defined by machine code. Like processors, waldoes are the engines that drive the control flow of a SpaceChem factory.

When a waldo grabs a molecule, it gains the ability to perform instructions directly on it. In other words, a grabbed element is more readily and rapidly available than one lying elsewhere on the grid. Conceptually this is analogous to storing data in registers, a form of computer memory that is accessed very quickly and that the CPU manipulates directly. Just as a waldo can only grab one molecule at a time, computers have very few registers and must therefore rely on caching.

If grabbed molecules are like data in registers, then molecules left on the grid are cached. The cache is a larger, cheaper form of memory, but it is slower to read and write. Data must be written from the cache to a register in order to be manipulated directly by the CPU. The amount of memory in SpaceChem’s “cache” is governed by the area of the grid (8 x 10). Each coordinate on the grid can therefore be considered a unique memory address. This analogy is enforced mechanically: a factory “crashes” if two atoms collide on the grid, since you can’t store two values in the same memory address.

Each factory has two waldoes, and they must be properly coordinated as they move through time and space. This coordination is facilitated by the sync node, which tells a waldo to wait until its twin has also hit a sync node. Parallel waldo management is akin to parallel programming, and they share the same perils: deadlock, starvation, race conditions, etc. The waldoes are like threads operating on shared memory space, and sync nodes are functionally similar to semaphores (operations that tell threads to signal and wait.) Operating two waldoes simultaneously in SpaceChem forces the player to confront the same shared resource problems as parallel computing.

SpaceChem and programming involve similar challenges: laying out simple instructions to achieve a complex result while managing limited time and resources. Like a good software specification, each puzzle is clearly presented as a black box defined only by its inputs and outputs. The player lays out instructions, starts up the factory, observes errors and corrects them, iterating until the puzzle is solved. Solutions can then be further optimized to take less time and use fewer instructions. SpaceChem and programming are engaging, flow-inducing activities because they have an identical inner loop: implementing, debugging and optimizing.

At this year’s GDC, Michael John asserted that programming is 21^st century literacy. If computer programming is currently considered esoteric knowledge, it’s because our general education is not preparing students to think about problems in an algorithmic or systematic manner. Ian Bogost calls this procedural literacy: “the ability to reconfigure basic concepts and rules to understand and solve problems.” SpaceChem may not be an ideal game for the classroom (it’s far too difficult, for one), but it strongly suggests that the best way to learn about and engage with complex systems it to play with them.

Back in January, Henk, Thomas and I presented two games we were working on (Norwegian Wood and an alpha build of Pax Britannica) to the DemoCamp at CUSEC 2010. DemoCamp is a really cool informal event where programmers can show off what they’ve been hacking on. The rules are simple: 15 minutes maximum, no powerpoint, show working code!

I think the talk went really well, we got by with some laughs and a little bit of casual swearing. Big thanks to the CUSEC organizers, host Joey DeVilla and A/V tech Guillaume Theoret for giving us a chance to show off our games!

The response was overwhelming; of the nine people I had e-mailed, seven of them were interested in participating. The project was suddenly much larger than I had anticipated, but I didn’t have the heart to turn anyone away. The eight of us (Henk Boom, Thomas Hibbert, Phil Jones, Renaud Bédard, Alex Charlton, William Mitchell, Kyle Sama and I¹) formed the facetiously titled collective No Fun Games.

You might be surprised to learn that our original game idea had nothing to do with music, shoot ‘em ups or The Beatles. While we explored a number of different game ideas, we settled on creating a murder mystery game set in an JRPG-style lumber town. We gave the development version the nickname Pulp².

Pulp‘s main character was “Penny”, a local girl with a knack for mysteries. She teamed up with retired Sherlock Holmes analogue “Detective Powell” to solve the murder of his former partner “Dr. Watson” (we never really settled on official names). You can see Phil’s concept art for some of the characters above.

We developed an elaborate back story which outlined the motivation behind the murder and its connection to the protagonists. However, our ideas for the game’s actual plot and structure were little more than a skeleton. Truthfully, we possessed neither the inclination nor the talent to write good fiction and this was ultimately the game’s downfall.

On the programming side, we put together a basic game engine in Python with the help of the Pygame and PyOpenGL libraries. It gave us the bare essentials, allowing us to add actors to the screen and assign them behaviours. As seen above, we created a simple world for Penny to run around and interact with (the Fez spritesheet was placeholder art lent to us by Renaud).

Sadly, this is as far as the Pulp project ever got. Despite our best intentions, we drifted apart over the summer. Everyone had personal commitments, internships, and travel plans. We simply didn’t have the time or motivation for leisure coding. By July, Pulp had reluctantly become vapourware. Fortunately, this wasn’t the end of No Fun Games.

By late August, things in my life were starting to slow down. I was back living in Montreal (after spending the summer at IBM in Ottawa), and had a couple of weeks off before the fall semester. Blessed with free time, I decided to reconnect with my teammates for a final sprint. Naturally, we wanted to release something after all our hard work.

Of course, not everyone had the luxury of time off. While we all wanted to participate, only Henk, Thomas and I had the hours to spare. Our artist Phil was also interested, but couldn’t commit to the heavy art demands of the murder mystery concept. With this in mind, we decided to drop that idea and reuse the engine we had created to pursue an entirely different genre.

The concept for Norwegian Wood came from our desire to explore the burgeoning intersection of music and gameplay. We wanted to create a game where listening and following the rhythm played a strong role in the player’s experience, but less directly than a game like Rock Band.

This idea manifested as a shoot ‘em up game where the bullet patterns are timed to the individual instruments. The decision to use The Beatles’ music was somewhat incidental; I happened to be listening to Rubber Soul when the game concept occurred to me. However, the song has certain qualities that make it rather ideal. For instance, the notes are quite discrete, making it easy to divide the instruments and record timestamps. More importantly, using a calm lilting ballad with subtle dark undertones contrasted nicely with the upbeat synth-metal used in most shoot ‘em up games.

Henk, Thomas and I got together at school to work on the game, working nearly full time for two weeks. We managed to create a playable prototype within a few days, then put the majority of our work into refining and iterating on the core gameplay. We also placed a strong emphasis on player feedback, bugging everyone around us to playtest it.

After chasing down the cross-platform bugs and ironing out the details of deployment, we finally released Norwegian Wood in late September. Thanks in large part to friends on Twitter spreading the word, we’ve had thousands of hits, hundreds of high scores and some very positive feedback. We’re thrilled that so many people have enjoyed our game, and promise to put all that excitement right back into making more of them.

To summarize Gamasutra-style, here are some lessons we learned during development:

What Went Right

1. Working Together Locally
While most of the work on Pulp had been completed remotely, it came at a cost to communication and motivation. For Norwegian Wood we decided that there is really no substitute for face-to-face time and met up in person every day. This was extremely effective, both for making consistent measurable progress and sharing a common creative vision.

2. Recording Global High Scores
The online high score table was a minor last-minute addition to the game. However, as Eric Swain pointed out in his insightful Indie Spotlight, it added a ton of value in terms of competition and replayability. “Even after all these years and innovations it is still a huge motivation to play. [...] It isn’t all about competition, but the close knit community that get formed in that competition.”

3. Sidestepping Copyright
It took a lot of thinking to come up with a way to release a music game without infringing on The Beatles’ copyright³. Despite our doubts, having the user provide their own mp3 turned out to be a very successful strategy. Of course, it’s a shame that we picked the one band whose music can’t be downloaded legally. In the future, we’d very much like to reexplore this concept with Creative Commons licensed music.

What Went Wrong

1. Big Team Woes
Starting out with such a large development team on Pulp was a major challenge. Responsibility was spread too thin, and no one felt like they had creative control of the game on an individual level. In retrospect, I would recommend a team of no more than 4 for your first indie collaboration. Furthermore, it helps to have a fairly autocratic team leader.

2. Summertime Blues
I had assumed that summer would be the perfect time for students to pursue a side project. Working nine to five at an internship means having evenings off and lots of free time, right? Sadly, I was way off. The temperament of summer is lazy and leisurely; it’s hardly a season for picking up additional work. Furthermore, working full-time turns casual hacking into an unpleasant chore. Counter-intuitively, students would much rather attempt side projects while they’re juggling exams and assignments in the fall.

3. Storytelling Failure
We were incredibly naive about the process of writing a story for Pulp. We had the big picture ideas and the game mechanics, and just assumed that the moment-to-moment narrative experience would flow from that. We quickly discovered that writing a good story is an extremely demanding task, one we were ill-equipped to handle. Lesson learned: if you insist on having a narrative element to your game, make sure you have a dedicated writer (or semionaut) on the team.

Thanks again to everyone who was involved in Norwegian Wood, including those of you who playtested it and helped spread the word on release day. Making this game was a terrific experience, and it taught me a great deal about game design, programming and project management. I look forward to applying these lessons to my next game!

¹ Ben Abraham was also briefly involved as music director, he wrote us a lovely dirge for Pulp.
² Funny how Pulp turned into Norwegian Wood. The arboreal theme is coincidental.
³ Actually, Nick suggested this approach. Thanks Nick!

I was originally introduced to Markov chains by Josh Millard’s Garkov, a project that applies this mathematical model to Garfield comics. I thought it was an amusingly random idea, but didn’t fully appreciate the concept until Jeff Atwood wrote a post detailing how Markov Chains work.

To quickly summarize, the algorithm chooses its next word using a probabilistic function based on two criteria: the current word, and a large sample of coherent text. The chance of a word being chosen is based entirely on how frequently it follows the current word in the sample text. For instance, if the sample was “To be, or not to be, that is the Question”, the word “be” would have a 50/50 chance of being followed by “or” or “that.” As the sample size increases, the text produced becomes increasingly sound. [Update: The size of the sample does not necessarily increase the coherency of the text, the number of words used in the seed is the biggest determining factor. Thanks for the correction, Josh.]

Reading about this got me very curious. What would a Markov chain generated using my own writing look like? Would it overuse “however” and frequently misapply the word “parse” like I do? I decided some experimentation using the Markov Text Synthesizer was in order.

The first test sample was my Rockin’ The Boat series on rock ‘n’ roll and race relations in 1950′s America. At a scant ~4000 words it was a poor sample, which made it quite possible to recognize parts of the original sample in the text:

Rock ‘n’ roll party. Freed considered completely alien. Mintz had his personal success, but rather the Speeds had been a little pressed for school facilities. They were subject to unsuccessful alternative names such as much for the trend was classified under the Brown v. Board of, in ten in, most popular opinion in the same records was no memory of the major label was a lesson. He was a token job. The major record store owner in postwar economy. During the following lyrics which were localized in America. A successful rhythm and I feel would sing to popular.

For my next attempt, I used every post listed under the Video Games category. This was over ten times larger than my original sample, and the text was much more randomized as a result (it even snuck in a “however”, hooray!):

There are games have two things spectacularly well. One where it will work at first. They mix means of Internet hype around the U.S. Addresses Only. Heartbroken, I was, however, describe what is one of the censor, the creative Wiimote according to the end. Plot holes and Escapist feature. Embedded below is minutes of military shooters had her to convince you feel that the game will work done with blood all available up the narrative. He created the Medic class impressions. The use of his weekly feature film was already breaking my favourite newspaper articles. Read the end. The very effective ways. My favorite aspect of a short stories, particularly dystopian centuries. At first game Rock Band, but the best like a timeless void movie revolved largely passed under them all.

Next, I decided to use the same sample but increase the “word grouping” to two. This means that the function will now determine how frequently a word follows the two previous words (in order.) This made the text much more coherent, but brought back the problem of being similar to the original sample:

There have been used by other games in the villa’s lobby. Recharging your beam sword’s energy with a Little Sister crying for “Mr. Bubbles”, but it costs a whopping. December is a classic for years to come. Valve could have easily rested on their laurels and sold Portal on its PS release Tools of Destruction, with some great part series detailing each other, it seems that the FPS genre has been getting a lot of the murder investigation. The evidence found and is by far the best thing the Bioshock movie revolved largely around and go buckwild with ADAM. I would rescue them all. It was also annoying at times. To move Zack around you have to mimic it in real life.

Finally, I decided to test the program with a very very large sample: Cory Doctorow’s free e-book Little Brother. I don’t think this is the sort of remixing Doctorow had in mind when he released his book under Creative Commons, but here goes:

I’m a stone Disney park freak see my fear. Marcus, it can fill you with our magic coffee bean supply. If you’ve got it for a lot longer than me. One only spoke Arabic he began, when one of the country, the world to know it’s there. The truck drew closer. I kept hitting it with both hands. She was dressed in a drawer with the texture of very ugly stuff on the back of a polished marble plinth. I decided I wanted to do stand down. Will you promise me that? They promised with all the walls and other little devices, my wallet intact. Forbidden Planet rarely do I go to jail, Marcus, and not that many cool puzzles that you wanted to be a part of that Hummer, my head for my book by net or phone and memory sticks are private. Thats because of cryptography message scrambling. The math behind crypto is good and solid, and you wonder, Was it always like that? I hadn’t thought about trying to intimidate me the picture she’d snapped of us, if you wanted to.

I’m amazed, a very large sample with a word grouping of two or greater can produce some terrific results. It makes me wonder why spammers always end up with such nonsense titles, use a larger sample you jerks!

In my various attempts, I also ended up with some rather spectacular phrases. Here are some of my favourites, I swear I did not make any of these up:

The whimsical charms of each of disappointed children

Holding the Wiimote in the holiday rush? Either way, you’re probably online looking for awesome news like this

Your character’s level is on a couch. They’re comfortable for both sides.

a combination of raw stem cells, dubbed thing, and the USA

I believe I was blindsided by exploiting my childhood memories

…and the best one by far:

This essay will be successfully ignored altogether.

Check out Ben Abraham’s post for some more great ones (he beat me to the punch by a few hours.) Finally, I’ll leave you with a challenge. Can you guess what sample I used to produce the text below?

Peyote solidities of halls, backyard green tree cemetery dawns, wine drunkenness over the rooftops, storefront boroughs of teahead joyride neon blinking traffic light, sun and moon and tree vibrations in the roaring winter dusks of Brook-lyn, ashcan rantings and kind king light of mind, who chained themselves to subways for the endless ride from Battery to holy Bronx on benzedrine until the noise of wheels and children brought them down shuddering mouth-wracked and battered bleak of brain all drained of brilliance in the drear light of Zoo,

***********ANSWER***********

Trick question, it’s actually a word-for-word excerpt from Allen Ginsberg’s Howl. Only the formatting has been edited. I think the beat poets would have dug Markov chains, don’t you?

As a long overdue followup to my previous experimentation with Python, I decided to kill two birds with one stone by writing a script to clean up some common errors in my posts. Blame it on my sloppy HTML education, but I make these mistakes all the time. For instance:

• Using <i> instead of <em>
• Using <b> instead of <strong>
• Not closing my IMG and BR tags
• Forgetting to give my images “alt” text

Furthermore, due mostly to my Musical Box series, I’ve embedded a rather large number of YouTube videos in my posts. For some crazy reason, the default code uses the deprecated <embed> tag and is therefore not XHTML 1.0 compliant! The mind-blowing part is that it’s relatively simple to embed videos in an XHTML friendly way. Why isn’t this code available by default?

Armed with my copy of Dive Into Python and basic experience with regular expressions from Perl, I went about writing a script to parse my blog posts and fix the sloppy HTML. Since trying to embed Python code in a blog post would be inelegant at best, I present the script in three different formats (including some neat JavaScript syntax highlighting):

• Python Script File (.py)
• Syntax-highlighted HTML (Light)
• Syntax-highlighted HTML (Dark)

I’m not sure that my code is especially pythonic; sadly I have too many bad habits from Perl and Java. While I’m told that Python is frequently used as a scripting language, I get the impression that its real strength lies in larger applications. Furthermore, using regular expressions to parse HTML is a suboptimal solution, in retrospect I should have used an XML parser module. Any constructive criticism of my code is more than welcome, I’m here to learn.

Code qualms aside, I can now proudly say that The Quixotic Engineer is written in valid XHTML 1.0 Transitional (the front page at least, I’m still working on some of the archive posts.) Coming up next: XHTML 1.0 Strict, and perhaps some CSS experimentation to spruce the place up a bit.

The topic of discussion was SOEN341, Concordia’s “Software Process” class. Many past and present Concordia students were grumbling about what they felt was excessive formality and an overemphasis on arbitrary documentation completeness in the class. Dr. Constantinides’ argument was as follows:

In Software Engineering, I am not much interested in those things which you either can build on your own or you build only for yourself. I am very interested in those things that you alone cannot build and in those things that you together with a team of engineers build for others. In doing that, you must prove to me (your boss, line-manager, stakeholder, etc.) that what you are about to build is what you are expected to build (validation), and what you have built is what you were expected to build (verification). Asking me to “just trust” your code because “you know what you are doing” (maybe because you had a high GPA in some college, or you’ve been programming in this language for many years, etc.) is not enough for me. I cannot trust my medical / financial / … data on how sexy your CV looks. I want proof of concept for a solution to my problem. Architects and civil engineers refer to this as “blueprints”; Electrical engineers refer to this as “circuit diagrams”, etc. The proof of concept can done by paper and pencil, chalk on a blackboard, drawing software, etc.

Later in the discussion he elaborated on this position:

Let us talk about development as the production of a number of artifacts, at various levels of abstraction.

In my opinion EVERY artifact produced during development is important: You have artifacts produced in a natural language (e.g. English), others produced in a modeling language (e.g. UML) and others produced in a formal system (e.g. C++). You must be fluent with all different languages because you use each one for a different purpose. Yes, we can argue that implementation is vital because code is absolutely necessary for a system to run. However, in the absence of a requirements / analysis / architecture / design model, your level of confidence on the correctness of the system is rather low (and the maintainability of your system is very low).

Someone told me: “Go to the code.” Yes, I can do that. I should be able to do that. The code describes your rationale at a very low level and it’s not very helpful for a number of reasons including a) I need to stop you from doing something wrong before you start coding and b) a formal system is rather cryptic when it’s the only means of communication. Again, let me reiterate that I am interested in VERY large scale systems, not something which is a couple of thousand lines.

To maintain a high level of confidence, you must build strong confidence during requirements analysis (validation) and maintain it throughout the development life cycle. Because as your project manager I am the one who is responsible for it (see: lose the contract, being sued, etc.), then if your use case model is not validated I will not allow you to proceed to analysis. If your analysis model is not validated I will not allow you to proceed with architecture-design and if your architecture-design is not validated I will not allow you to map it to code. If your code is not correct (if tests fail etc.) or consistent, I will not allow you to consider the verification of requirements successful (for example, assume iterative process).

There is no such a thing as “documentation and source code.” I would love to eliminate the word “documentation” from our vocabulary. Let us talk about artifacts and models. With the exception of the magnetic 1s and 0s, everything else (installation scripts, user’s manual with screen shots, test suite, source code, supporting libraries, architectural-design model, analysis model, use case model – requirements) can be regarded as “documentation.” However, the problem is that many software engineering textbooks (and many instructors in many schools) place emphasis EITHER on requirements / analysis / architecture / design XOR (that’s an exclusive OR) on implementation. I think this creates confusion (and frustration) among students. Especially in the first case (emphasis on early stages only), it is very frustrating to focus on formatting (and dissemination) of reports and other issues as if a model will be mapped to implementation by magic or as if it’s not our job to map it. Give me the design mode in pencil and paper, as long as it is correct. Show me that you can faithfully map it to implementation.

Because of the above and with all tradeoffs considered, then my view is that ALL artifacts are equal. In fact, there are artifacts produced even after deployment (e.g. execution traces) which are valuable for post-deployment tasks (maintenance and evolution).

[...]

One last comment. There is a misconception (among us) that Software Engineering is that bureaucratic activity you do AFTER you build something to provide supporting documentation and explain what you did so that you can satisfy your instructor/ line manager/ boss, etc.. This is wrong. The adoption of UML as a common vocabulary helps us produce small documents and the advancement of modern (iterative) process methods helps us do the whole thing with confidence. Software Engineering is not about avoiding programming. In fact you cannot be a good software engineer if you are not a very good programmer.

Thanks again to Dr. Constantinides for allowing me to quote him here.

[A.I Competition - Tim's Algorithm]

What I did was get 3 values for all the empty spaces to the left, right and in front of the player. To be “in front” the empty spaces must be connected to the forward move square and it must be forward of the player. So each connected space is bounded by a rectangle to one side of the current cycle position. I then regard each rectangles emptiness value as half if the nemesis cycle is within that rectangle. Then I arbitrarily decide to move to the square which has the second highest empty space value associated with it. [...] Basically the idea is to cut of the nemesis cycle from the empty space without retreating into it.

He later added:

I made a slight mistake, best explained by example: If I am getting the space that is south, the GetSpace function gets each empty square that’s below it and to the left and right recursively. What I meant it to do was to do that, but also go up again if it is still below the player’s cycle, this would let it account for spaces that go down and then up again to one side.

To reiterate, what Tim’s algorithm does is compare the amount of space connected to the three spaces adjacent to the cycle. However, it only counts the spaces contained in a rectangle defined by the cycle and the scanning direction. To illustrate:

The forward scanners will only scan within the forward box, the left ones within the left box, and so on. It’s an interesting approach, but I fear that it may suffer from the same weakness as algorithm 3: doing a bad job of filling empty space slowly. Without real code to test, of course, this is mere speculation.

Lastly, I have a few wild and crazy algorithm ideas I came up with while trying to approach the problem sideways. I don’t think any of them would work particularly well, but they make good thought exercises.

• The Calculus Approach: I thought of this algorithm while working on a Numerical Methods assignment. We could send out a 90 scanners, 30 in each direction. These scanners would have semi-random behavior; they would never run into a wall if they could avoid it but would make all other turning decisions randomly. These scanners would leave walls behind themselves on cloned maps as they moved, and return their path length upon death. Once they have all died, we could take the average of their path lengths and choose to turn in the direction with the highest average. We could increase the number of scanners for a better estimation at the cost of processing time.
• The Cardinal Directions Approach: We could send out four scanners from the cycle: one that can only turn North and West, another North and East, another South and West, etc. We could then calculate the free space value for each cardinal direction using the average of the two ordinal directions: (NW+NE)/2 = N. We decide in which direction to turn based on this information.
• Average of BFS and DFS: I mentioned in my last post that a Breadth First Search and a Depth First Search estimated free space in a slightly different way. Perhaps the best solution would be to perform both and take the average, hoping that the strengths of one would cancel out the weaknesses of the other. It would involve twice as much calculation, but I think it might actually work reasonably well.

In conclusion, I would like to quickly thank Sven and William (my CS games teammates), Alexei, Andrew and Tim (for taking the time to discuss their algorithms with me), and Renaud and Thomas (for the lengthy algorithm discussions.) I learned a lot by writing this series, and am now exceptionally prepared for next year’s A.I. competition.

In part 2 of this series, I wrote about how the recursive Algorithm 4 was memory intensive because it needed to clone the entire map at every step. Alexei, however, thought of a very clever way to get around this problem by implementing backtracking.

[A.I Competition - Backtracking Algorithm]

Using this algorithm, you would need to clone the map exactly once (assuming the original map cannot be modified.) In Alexei’s words:

Nothing is being cloned, because you are always operating on the same state. As it recurses in, it marks the node, and then unmarks it as it recurses out.

So if you’re in a 10-level deep recursion, you have 10 nodes marks as visited (ie the “path” you’re currently looking at). Suppose that you’re in that state, and there’s 3 directions for you to take (a, b, or c).

You call yourself on [a], which gets marked as visited. Then [a], calls all of its adjacent nodes, one by one. Each one marks itself as visited, and before it returns, it marks it as unvisited. So after your call on [a], your array of booleans (which you didn’t clone ever!), is in the same state as it was before the call. But you now have the longest path starting at [a]. Then you do the same for b and c, and return (to your parent caller), the longest of those three, and unmark your node as visited. Your parent caller does the same thing for all the other nodes adjacent to it, and returns to its parent, and so forth. It works.

However, even with this modification an exhaustive longest path search can be no more efficient than O(2ⁿ), making it unsuitable for anything but small maps. We must therefore find a way to estimate the longest path in quadratic (or linear, ideally) time. The other Concordia team accomplished this as follows:

[A.I Competition - Alexei/Andrew/Jason's Algorithm]

Alexei explains once more:

On startup, we calculated the density of the map (how dense walls are vs. empty space.) Then we implemented two general purpose algorithms:

1. BFS: Breadth First Search to the enemy. Finds the shortest path to the enemy, and returns the first direction.

2. LongestPath (modified BFS): Finds which of the three directions would produce the largest open space. Essentially, 3 BFS searches are done, each one from scratch from each of the possible directions. However, instead of terminating when something is found, you instead count how many locations were traversed in total (the algorithm terminates when all reachable locations are traversed). Algorithm returns the direction that gives the highest such value.

In addition, the LongestPath was modified to not return a direction that would put us in a location to which the enemy could also move next turn, as otherwise this can cause a tie.

The idea is: At first, you want to advance the closest possible to the enemy, to “conquer” the most ground. After this, you want to take the direction that would produce the longest path.

Since we didn’t have time to code something that would detect when advancing BFS to the enemy would put us in a dead end path in the future (i.e. locking us and the enemy into a trap), the density check was necessary. On maps with lots of walls, like the chessboard – this situation could happen, so our AI just goes for LongestPath all the time there.

I’m really not sure how to go about analyzing their enemy chasing intelligence, other than to say that it sounds like a very good idea. When the wall density is low, following the longest path is less critical and it makes sense to try and restrict the amount of free space that the enemy has. This feature may very well have been their team’s winning edge. What is also remarkable about their algorithm, however, is how they went about searching for free space.

To reiterate, their team used a Breadth First Search, which is O(n), to estimate the longest path. Why is this an estimate? Because it fails to return the longest path (and therefore the theoretical best move) in every situation. Consider the following:

In this case, is it advantageous to turn right and survive for 7 turns. However, a modified BFS would choose to turn left, since there are a total of 8 free spaces as opposed to 7 on the right. The cycle would die sub-optimally in 4 turns. The same weakness is true for a modified depth-first search:

In this situation, the longest possible move is to turn left for 8 moves before dying. However, the modified DFS would return 6 for the right path and 5 for the left one, resulting in a disadvantageous right turn. Therefore, we can find specific situations where both BFS and DFS fail as estimators for the longest path.

Despite the shortcomings, I believe that estimating the longest path in this way is truly the most effective solution in a real time system. Since performing the exhaustive longest path search within the time constraints is impossible on a medium or large sized map, we must settle for using reasonable estimators. The modified BFS and DFS both do a very good job of measuring free space, each in a slightly different way.

[A.I Competition - 3rd Iteration]

This is where the pseudocode starts to become a little obscure. Essentially, this is a case of algorithm 2 where the scanners can turn exactly once. In other words, at every point along the straight line search we send a second set of scanners out perpendicularly left and right until they reach a wall. We find the maximum value of the sum of a straight and perpendicular scanner and turn in that direction.

In theory this algorithm is more powerful than the one from our second iteration. It looks further ahead, avoiding the situation that prematurely killed our cycle in the first competition. However, in execution, it actually dies a bit faster than the previous A.I. on some maps. The reason for this is that algorithm 3 will often turn faster when filling up an empty space. For instance, in the diagram below, algorithm 2 survives four turns longer in an empty rectangular space.

While the light cycle deathmatch was ostensibly a head to head fight, matches usually degenerated into a race to fill a separate space more slowly than the opponent. Needing to slowly fill empty space was actually much more common than the situation that exposed the flaw in algorithm 2. Algorithm 3 was therefore a bit of a flop.

[A.I Competition - 4th Iteration]

Where algorithm 3′s scanners could turn exactly once, these scanners search the map exhaustively and turn as many times as possible. This is achieved recursively, with each cell calling the check method on the left, right and forward cells. The result is a longest path value for each direction, and the cycle chooses to turn towards the maximum of the three.

However, the moment you allow the scanner to turn more than once you must allow for the possibility of visiting the same cell more than once. Algorithm 4 gets around this by cloning the map at every step. The scanners can leave walls behind themselves on these replicated maps without affecting the real one. Note that the map must be cloned at every recursion and that is is the modified clone that is passed as a parameter to the next step.

Unless some bug in the pseudocode has evaded me, there is no logical error in this algorithm. It will find the longest movement possible on any kind of map, which is exactly what we were looking for. However, there are two big problems with it in execution.

1. If placed in the centre of an empty map with n cells, this algorithm would have a worst case time complexity of O(2ⁿ)* (see Big O Notation.) The resulting calculation would take much longer than one second to process.
2. The entire map is cloned at every recursion, potentially using a tremendous amount of memory. We could slightly improve on this by instead keeping a list of visited nodes, but this list would also need to be cloned. There is a very clever way to get around this problem, but I’ll save it for my next post.

*Finding the time complexity of a recursive algorithm without having real code to test is tricky. I’m basing my analysis on the fact that the longest path problem is NP-complete. Feel free to disagree in your comments, and enjoy the following nerdy song (thanks Skrud.)

Longest Path – Daniel Barrett [download]

Were time and memory not factors, algorithm 4 would be sufficient to find the longest path at every step. In a real time system, however, it’s unfortunately completely useless. Since algorithms 3 and 4 were failures, we were forced to resubmit algorithm 2 for the final competition.

I’ve been discussing this problem with programmers smarter than myself (including the other Concordia team who came in 3rd on the second day) ever since I got back from the CS Games and have learned a great deal in the process. In my next post I’ll be discussing a few of their solutions.

The match was played on a roughly 30×30 grid where each cell was either empty, a wall or a cycle. Each player was given one second every turn to decide whether to move forward, left or right, with each movement leaving a wall in place behind. The cycle that could survive longest without running into a wall or another cycle was deemed the winner.

The competition took place over two sessions, the first worth 25% and the second 75%. The A.I.s from all thirty schools went head to head in a round robin tournament at the end of each day. With this in mind, my teammates and I decided to apply what we were learning in Software Processes and grow the program iteratively. This was a wise decision; we had a simple yet effective working model ready for the first competition while many groups were still debugging their more complex algorithms. In the end, we tied for 6th on the first day and 10th on the second.

After the competition, however, I found myself still thinking about this problem. It’s a twist on pathfinding, as there’s no set destination, and could nearly be described as a longest path problem. The ideal solution has to be flexible enough to accommodate both narrow corridors and open spaces. Our algorithms didn’t even take into account the position of the enemy, mostly because we weren’t sure what to do with that data.

I’ve written from memory the pseudocode for our four iterations, as well as a little something about their performance, strengths and weaknesses. I present this in the hopes that you too will get this problem stuck in your brain, and will soon return to comment with your wild and crazy ideas about the best Tron A.I.

Note: I’ve tried to keep my pseudocode notation consistent and as close to plain English as possible. They looked ugly when embedded, so click through to read each txt.

[A.I Competition - 1st Iteration]

We began with a very simple algorithm that could look exactly one square ahead. It would therefore never run into a wall unless it was the only possible move. It’s simple and it works reasonably well, but with no foresight it quickly gets caught in traps that it should have avoided. There’s really not much else to say about it, it was a stepping stone to greater things.

[A.I Competition - 2nd Iteration]

Our next plan was to look in a straight line in every direction, and turn in the direction with the most empty space. Another simple yet solid algorithm, but with more foresight than the first. This was what we ended up submitting for the first day’s competition, so we have a glut of experimental data on it. Namely, we discovered one common situation that it handles very poorly.

We lost two of our first round matches getting caught in this scenario. Any human can see that the correct choice in the above situation is to turn left, but algorithm 2 only evaluates one block left and one block forward. Since we hard coded it to move forward in the event of a tie, it traps itself and dies in two turns. Clearly a robust A.I. would need to evaluate length around corners, a concept that we applied to our next iteration.

Since I got a little carried away with the diagram, I’ll finish writing about our two final iterations this weekend. Stay tuned.

Meeting up Friday morning at 100 Génies, L’École de Technologie Supérieure’s pub. Some of us start things off early with a Laurentide.

The ETS team, with whom we shared the bus ride up, came well prepared.

Nerds and laptops as far as the eye can see.

Tetris DS got a lot of playtime this weekend.

Alex and Jacob with Concordia’s secret chocolatey weapon.

ETS rockin’ the white shirts and red suspenders, they definitely had the coolest team outfits (and were just all around terrific people.)

Braving the snow to get midnight snacks.

A Concordia University mural we found in the underground tunnels. Incidentally, L’Université de Sherbrooke is built like a labyrinth. We actually had the sports competition in the tunnels because of the weather.

Finally, here’s our entire CS games team rocking out to 8-bit DragonForce. Enjoy!

This year the Université de Sherbrooke is hosting the 2008 Computer Science Games, where programming nerds from all over Canada and the U.S. gather to do battle on the field of code. The events include (descriptions copied from the CS games website):

• Debugging – “The creator of this competition gave a new meaning to “strong coupling”, “obfuscated code” and “spaghetti code” and refuses to believe that some programmers can live without GOTOs. The “/” and “#” keys of his keyboard are as shiny as they were when they were assembled. So many bugs and so little time to solve them all.”
• Extreme Programming – “Two programmers, one computer. This is the basic principle of this competition, but of course, we added a twist or two! Participants will get a unique occasion to test their coding skills with a buddy and enjoy this unique bonding experience under extreme circumstances! Remember, what happens in XP stays in XP… or on the Internet.”
• Relay Programming – “This is our new home brewed competition. 3 competitors will have 3 hours to code 3 different applications. Seems easy? Well, each of them will only be able to work one hour per application before having to relay it to another team member. WHAT, no comments!!! &*%*$!”
• Team Software Engineering – “We sure hope competitors have good design skills, because this time, there’s no going back to the drawing board! After a short planning period, team members are isolated for implementation. At the end, the team get a short period of time to stick the pieces of the puzzle together. It better fit well!”
• Many more

This is my first year attending the CS games so I’m not quite sure what to expect, but from what I hear it’s a three day whirlwind of nerdy fun, code and beer. We’re heading up tomorrow afternoon with the ETS team, who I’m sure will drink us under the table at the dégrise. Wish us luck!

Montreal Girl Geek Dinners are an offshoot of the London Girl Geek Dinners, started by Sarah Blow. The goal of these get-togethers is to make technology accessible and interesting to all age groups and all people, particularly women.

These monthly events are aimed at providing a welcoming atmosphere and a platform for learning in an informal environment. They are always held in pubs, bars or restos and there is usually a speaker (or several) who talk for a short while on a chosen subject for the evening.

The event lasted 3-4 hours, a large part of which was spent eating and networking. I had a chance to speak with the organizer Tanya McGinnity as well as Peter Yang, a designer at Ubisoft Montreal. The attendees came from many different backgrounds; some were programmers and web designers, others were just self-described geeks. In the spirit of making these events accessible, the speakers avoid getting too technical.

This evening’s talk by Aleece Germano was about self-employment. Ms. Germano encouraged us to adopt the mindset that everyone, even nine-to-fivers, are really self-employed. She spoke of her own experience as a consultant, how to develop professional relationships with clients, and how to protect yourself legally and financially in these situations.

Though I have no personal interest in being self-employed, a lot of what she said was just good general career advice. The other Girl Geek Dinner topics chosen so far sounded great too. Last month Angela Byron did a talk on Open Source development, and Heather Kelley of Kokoromi spoke in December.

These dinners are a fantastic initiative, and if one is being hosted in your area I strongly urge you to check it out. Kudos to the organizers, great job.

Yesterday marked the end of CUSEC 2008, a three day software engineering conference for Canadian university students. While the conference has been going annually since 2002, this was my first year attending. I had initially planned to be quasi-live blogging the whole thing, but I hadn’t realized how busy the three days were going to be. Instead, here’s a quick recap of some of the terrific people I heard from at CUSEC.

• Day One
  • Tim Bray – Hard Problems in Network Computing
    One of the co-editors of XML, he gave a great talk about some of the difficult problems that programmers are having little success in solving. I don’t remember the exact words he used (relying on my brain was a bad idea, I plan to take better notes next year), but the main problems were communication between different programming languages and taking advantage of parallel processing.
  • Dr. Marsha Chechik – Guarding Against Software Accidents
  • Zed Shaw – The ACL is Dead
    Author of the Mongrel web server and notorious blogger, he talked about staying creative in the face of bureaucracy and corporate greed. The part of his keynote that really struck a chord with me was that “managers want all of your creativity, but trust none of your judgement.” I had a chance to talk to Zed later at Brutopia and a little throughout the conference, he was a really cool guy with a lot to say. Here’s hoping he comes again next year.
  • Bruce Miner – Taking Risk
• Day Two
  • Sylvain Carle – We Didn’t Start The Fire
    A self-described “venture technologist”, he talked about why we should consider founding or working for startup companies.
  • Michel Martin – The Evolution of Large Scale Business Software
  • Dr. Peter Grogono – Living with Concurrency
    This talk was a bit over my head, but it really made me appreciate what a problem concurrency is and will be in the coming years. Dr. Grogono is one of the most loved computer science teachers at Concordia, and after hearing him speak I can understand why.
  • Dr. Jeffrey Ullman – When Theory Matters
    Prolific textbook writer and Ph.D. advisor of Sergey Brin (co-founder of Google), Dr. Ullman spoke about the theory of how Google’s PageRank system works, as well as variations such as minhashing and locality-sensitive hashing.
  • Jeff Bailey (Google Corporate Speaker) – Hacking on Open Source After Graduation
    He talked about the history of OSS and why major companies like Google and IBM invest millions to develop it. I had always been interested in contributing to an open source project, but after hearing his talk I feel compelled to begin doing so within the next few months.
• Day Three
  • Zed Shaw – Factor Tutorial
  • Dr. Jeremy Cooperstock – Music & Games: How Fun Applications Stimulate Core Technologies
    I really enjoyed this presentation, he began by talking about how the video game industry has been accelerating technological progress, which included some of his own research into the “next step” of virtual reality. The meat of his talk, however, was about his research into ways of overcoming network latency to allow people in separate parts of the world to play music and talk together naturally.
  • Jon Udell – Hacking the Noosphere
    Another talk that was a bit over my head, he spoke about keeping the focus of Web 2.0 and information sciences on people, and how we can gather information in a human-centric way.
  • Jeff Atwood – Is Writing More Important than Programming?
    As a big fan of Coding Horror, I had been looking forward to this talk from the beginning. In his keynote, he argued that writing for people was in many ways more important than writing for machines, and that it is crucial to “convince other people that your code, in a world positively overflowing with free code, is worth looking at in the first place.” His talk provided a counterpoint to some of the more technical presentations, and was a fantastic way to close the conference. Better yet, his talk inspired my friend Malini to pick up her abandoned blog again!

I can’t believe how much I learned in three days. Hearing from passionate people and being in a community full of fellow coding geeks has really inspired me to be creative, take chances and really explore the world of software engineering. I’ll definitely be attending CUSEC 2009!

Inspired partially by xkcd and partially by testimony from other programmers, I’ve decided to take up learning Python in my spare time. I’ve been using the free e-book Dive Into Python as a reference, and it’s been an interesting experience so far (whitespace for code blocks!?)

I was showing the Python Shell to my friend Thomas the other day, and he typed in a few equations to try it out. While “2+2″ and “3*8″ resolved normally, “2^3″, which is a standard notation for two raised to the third power, returned “1″. We were a bit confused, but decided that the caret symbol “^” must mean something else in Python. We entered a few more formulas in an attempt to discover what the symbol meant, and here are the results:

• 1^0 = 1
• 1^2 = 3
• 2^0 = 2
• 2^2 = 0
• 2^3 = 1
• 3^2 = 1
• 3^4 = 7
• 4^1 = 5

Try as we might, we just couldn’t figure out what this operator did. I had a theory that it had something to do with modular arithmetic, but some cases just didn’t fit. Despite our combined brain power, we just couldn’t crack it, and after twenty minutes consented to Googling it.

I would challenge you to try and figure it out yourself! For cheaters, the answer is below.

***********ANSWER***********

In Python, two multiplication symbols “**” are used to indicate exponents, while the caret symbol in this context is used to indicate XOR (exclusive or). Since I was comparing two integers, the computer was doing bitwise XOR on the two numbers and returning the result as an integer. For instance:

2 = 010 (binary), 3 = 011 (binary), 010 XOR 011 = 001 = 1
3 = 011 (binary), 4 = 100 (binary), 011 XOR 100 = 111 = 7

It was obvious in retrospect, but my mind was so focused on the usual mathematical operators that I hadn’t even considered the basic computer operations. However, as it is with most lessons learned the hard way, I’ll remember for the rest of my life how to do an exclusive or in Python.

It’s a well known fact that programmers are generally unkempt, hairy and scruffy-looking fellows. Some believe this is due to the fact that, without a beard to rub, we would be unable to think. Justin Etheredge, however, suggests that we are merely emulating our computer science heroes, burly men such as Dijkstra, Stallman and Knuth. His gallery of scruffiness is well worth a click and a read.

Fear not clean-shaven programmers, you can always say that your well-groomed face is a tribute to Alan Turing.

[The Programmer Dress Code - CodeThinked]

First up is an article over at CGSociety about the visual design of Team Fortress 2. I’ve geeked out more than once about how much I love this particular aspect of the game, but reading this article has given me a new found respect for the team of animators at Valve. Among the piles of great concept art (including an early build of the Heavy with a mullet), the article explores how well-designed characters and maps can enhance the gameplay experience. Consider the following excerpt:

Due to the importance of the nine character classes to the gameplay, the team focused on them first. They established a “read hierarchy”, a prioritized list of the information that players needed to extract from the character model. From most to least important, this was: the player’s team, the player’s class, and the player’s current weapon, which usually implies the player’s intent in our game.

They used the model color palette to represent the team, a somewhat suboptimal solution for varying lighting conditions, but a good tradeoff given the technology constraints. “We found that silhouette and animation were better long-range identification characteristics than texture detail or color,” says Jamaal Bradley, “so we used those for class identification. Finally, we tackled the weapon by using contrast and color gradients to draw the player’s eye to the chest area, where the weapons are held.

What a powerfully simple idea: using colour, shading and silhouettes to draw the player’s eye towards important information. It’s this level of attention to detail that has garnered Valve so much critical acclaim and fan loyalty. For more TF2 reading, consider the recently released Steam statistics, which include heatmaps and other interesting tidbits (such as the fact that the Medic class is criminally underplayed.)

Secondly is a fascinating look at the Morris worm, a 99 line program that ended up infecting 10% of the Internet back in 1988. The creator, Robert T. Morris, was a grad student working at Cornell University who simply wanted to prove that it was possible to propagate a program by exploiting vulnerabilities in sendmail and Finger. However, due to a flaw in the reproduction algorithm, the benign worm ended up reproducing itself many times on the same computer, eventually tying up the CPU. While the Morris Worm has been overshadowed by some of the modern malignant worms, I highly recommend this article to anyone involved in software security as a case study from a time when the web was much more homogeneous.

Finally, a short article about one of the most famous and successful heists in MMORPG history, one that left the victim’s character frozen dead in space and relieved of virtual goods worth an estimated $16,500 USD. It’s a fascinating look into the world of EVE Online, a game that seems to be as much about political intrigue and skulduggery as it is about spaceships and mining. The story reads like a virtual Ocean’s Eleven, and is an interesting commentary on the consequences of meeting people semi-anonymously in online worlds.

Have a great weekend, and best of luck in all your procrastinating.

…and that concludes a very busy four day programming marathon. The final project for my Databases class involved creating a database and web interface for a hospital. We were a five person group, and I was responsible for designing the interface for the doctors, nurses and residents. Elaine wrote the interface for Administrators and Directors, Sven and Fadhl were in charge of the MySQL database and Alex used Dreamweaver to make a great looking site.

All in all this was a great learning experience. Fortunately for me, Elaine was quite familiar with PHP/Javascript and sent me over lots of code that I could use as a template for my own work. I was already familiar with Perl and Html, so PHP wasn’t especially foreign. I managed to write ~18 interactive pages that allowed doctors to view their patient list, add/modify/delete patients, view their schedules and paystubs, etc.

Unfortunately, our project demo today didn’t go as well as planned. Databases was a rather involved four credit class, and taking it in ~5 weeks really didn’t allow us to invest as much time into our final project as we would have liked. Due to inadequate testing, our demo was full of errors and bugs. I’m not expecting a very high mark, which is ashame because we put lots of work into it.

At the very least, this project has taught me a great deal about group programming dynamics and the importance of code testing. It’s very likely I’ll work with the same group of people again in the future.

I was going to write a big post Monday about the Bioshock demo, but I was unfortunately too busy programming. I’ve now decided to wait and and just write a review of the whole game in the near future.

New header/favicon today, and a renewed appreciation for the hard work of graphic artists. While the Blogger template I had before did look a little more professional, I think I did pretty well for an amateur (go go MS Paint!). I figured out how to make these modifications using a combination of guides and trial & error. I’ve compiled the information I found into the small guide below, I hope you find it useful.

Using an Image as a Header

I found most of the information on how to make this modification here. The first step is to remove the old header. Blogger doesn’t allow you to remove it as a page element normally, so we’ll have to change the template html first. From the Blogger dashboard go to Template > Edit HTML. Back up your template and then look for the following code:

<b:widget id='Header1' locked='true' title='YOURBLOG (Header)' type='Header'/>

Replace the word true with false and save your template. You can now remove your old header as you would any other page element. We will now replace it with the image header, which I recommend you use Photobucket to host. Go to Template > Page Elements, and create a new Javascript/html page element, then insert the following code:

<a href="YOUR BLOG'S URL"><img src="YOUR NEW IMAGE HEADER'S URL" /></a>

Move this new Page Element over to where your old header used to be and hit the “Save” button. However, depending on your template, you may notice that you still have a small piece of your old header above your image. To remove this, delete the following line of code from your template’s html:

<div id='header-wrapper'><b:section class='header' id='header' maxwidgets='1' showaddelement='no'/></div>

Using a Favicon with Blogger

See that little picture next to the “http” in the address bar? That’s called a Favicon, and by default Blogger gives you an orange one with a letter B. If you’d like to change this to your own icon, first head on over to FavIcon Generator and save the .ico file it generates. Usually, a webamaster would host this on their own site, but since you can’t do this on Blogger we’ll have to host it externally. Since Photobucket doesn’t let you upload .ico files, so I recommend you use ImageDip. Next we’re going to edit the html template, so once again remember to back up your template before modifying it. Look for the following line:

<title></title>

Once you’ve found this line, add the following code one line above it:

<link rel="shortcut icon" href="Your .ico file's URL" />

Save your template and you’re done. Thanks to Tips for New Bloggers and My Tech Life for information on how to do this.

• Once enabled, Google will redirect your Atom feed subscribers to Feedburner. However, Blogger also publishes a second feed (in RSS format) which for some reason it does not redirect. Feedburner won’t be able to collect statistics about people who subscribe to the non-redirected feed, making your efforts fairly moot.
• Bloggers who use their Atom feed as a sitemap for Google will receive errors due to their Feedburner feed being in a different domain than the rest of their blog.

Using a bit of creativity, however, I do believe I’ve found a suitable workaround that should allow motivated Blogger users to integrate Feedburner and Google sitemap without these problems.

UPDATE: Easier Method
Commenter Lamer came up with an even simpler way to integrate both feedburner and Google sitemaps. Turn on the Feedburner redirection (Dashboard > Settings > Site Feed) and then use http://YOURBLOG.blogspot.com/rss.xml?orderby=updated as a sitemap (for whatever reason Blogger does not redirect this XML file). Simple and efficient, thanks Lamer! The rest of this post goes on to describe the old, more complicated method, which may be useful if you want to modify your autodiscovery tags.

Note: I do not recommend the trick explained below if you already have a sizeable number of subscribers to your Atom feed that you want to redirect to your Feedburner feed, since they will no longer be redirected afterwards. Use the updated trick above instead.

Preparation:
Set up a Feedburner account. When it asks you for your Feed URL, type in “YOURBLOG.blogspot.com/atom.xml”.

Next, under the Blogger dashboard, go to Settings > Site Feed and clear the “Post Feed Redirect URL” field. This will stop Blogger from redirecting people who try to access your Atom feed.

Step One: Modify Your Autodiscovery Tags:
To credit my sources properly, I learned how to do this from a post by matt in the Feedburner forums that has since had its contents removed.

With your blog open, view the html source of your page. Look for a block of code similar to the following:

<link rel="alternate" type="application/atom+xml" title="YOURBLOG – Atom" href="http://YOURBLOG.blogspot.com/feeds/posts/default" /> <link rel="alternate" type="application/rss+xml" title="YOURBLOG – RSS" href="http://YOURBLOG.blogspot.com/feeds/posts/default?alt=rss" /> <link rel="service.post" type="application/atom+xml" title="YOURBLOG – Atom" href="http://www.blogger.com/feeds/9501038560806028465/posts/default" /> <link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://www.blogger.com/rsd.g?blogID=9501038560806028465″ />

Copy the similar looking block from your blog’s html source code and paste it in a temporary .txt document. You may now close your Blog’s html source.

We’re now going to modify what you just pasted into the .txt document. Replace these two lines:

<link rel="alternate" type="application/atom+xml" title="YOURBLOG – Atom" href="http://YOURBLOG.blogspot.com/feeds/posts/default" /> <link rel="alternate" type="application/rss+xml" title="YOURBLOG – RSS" href="http://YOURBLOG.blogspot.com/feeds/posts/default?alt=rss" />

with the following:

<link rel="alternate" type="application/atom+xml" title="YOURBLOG – Feedburner" href="http://feeds.feedburner.com/YOURFEEDNAME" />

This next step will involve modifying your Blogger template. I strongly urge you to backup your Blogger template beforehand in case you make a mistake. From the Blogger dashboard, go to Template > Edit html. Look for the following line in your template’s html:

<b:data='blog' name='all-head-content'>

Delete this line and replace it with the contents of the .txt file you saved earlier, then click “Save Template”. You have now successfully modified the autodiscovery tags, and browsers that auto-detect RSS feeds will now be directed to your Feedburner feed only.

Step Two: Use Your Atom Feed as a Sitemap
If you have Google’d your own site, you may have noticed that not all of your individual Blog posts have been indexed. One way to help this along is to provide the Google webcrawler with a sitemap. A sitemap is an XML document that tells the crawler how to properly index all the pages on your site. As Blogger users, we cannot write our own sitemap file, but we can use our Atom Feed as a sitemap.

To begin, sign into Google Webmaster Tools using the same Google account that you use for Blogger. Follow the on screen instructions to verify your Blog. Once you’ve finished that, click on the “Sitemaps” tab, then the “Add Sitemap” button. Select “Add General Web Sitemap” from the pulldown menu, type in “atom.xml” for Step 3 and click “Add Sitemap”. Google will now be able to use this information to index your site properly.

Current Issues
I so far have not been able to figure out is how to redirect the “Subscribe to Posts” link at the bottom of the page to Feedburner.
UPDATE: Fellow blogger Juls came up with this excellent way to redirect your main page Feed footer while preserving your comment feed! Locate this block of code:

<b:includable id='feedLinksBody' var='links'> <div class='feed-links'> <data:feedLinksMsg/> <b:loop values='data:links' var='f'> <a class='feed-link' expr:href='data:f.url' expr:type='data:f.mimeType' target='_blank'><data:f.name/> (<data:f.feedType/>)</a> </b:loop> </div> </b:includable>

And replace it with:

<b:includable id='feedLinksBody' var='links'> <b:if cond='data:blog.pageType == "item"'> <div class='feed-links'> <data:feedLinksMsg/> <b:loop values='data:links' var='f'> <a class='feed-link' expr:href='data:f.url' expr:type='data:f.mimeType' target='_blank'><data:f.name/> (<data:f.feedType/>)</a> </b:loop> </div> <b:else/> <div class='feed-links'> <data:feedLinksMsg/> <b:loop values='data:links' var='f'> <a href='http://feeds.feedburner.com/YOURBLOG/' target='_blank'>Posts (Feedburner)</a> </b:loop> </div> </b:if> </b:includable>

Conclusion
This is by no means a perfect trick, but I think it’s a decent way to work around the current Feedburner integration problems and still make use of Feedburner and a Google Sitemap. If you have suggestions, problems or ideas, please feel free to leave a comment.

This winter I took a course called System Software. In it, we learned a neat programming language called Perl. Perl was handy for that class because it happens to be very good at parsing text, and we used it to write a simple compiler. Being the pragmatic kind of person that I am, I immediately began to think of ways to use this new found skill, and the opportunity arose in a rather roundabout way.

You see, I have what I’d describe as a fairly large collection of music (roughly 18.6 days worth according to iTunes). This sometimes causes problems when I’m out shopping for CDs and I can’t quite recall which ones I already own. iTunes is able to export a list of your music as an XML document, but you end up with a large unwieldy file with roughly 15 lines per song.

The solution: create a small Perl script to go through every line of this gigantic XML document and create a list of albums matched with artists. The result of my code monkeying is in the box below. Is the script terribly well written? Not especially. Did my album problem really need solving that badly? Not particularly. Was this a good excuse to play around with Perl a bit? Damn right. Enjoy.

#!/usr/bin/perl #=========================================== #Script written by Matthew Gallant #=========================================== $filename = $ARGV[0]; print("Extracting album list from $filename… "); open(READ, "$filename") || die("\nError: $filename not found or cannot be opened."); my %albums; my $artist; while(my $line = <READ>) { if($line =~ m/<key>Artist<\/key&gt/) { chomp($line); $line =~ s/^\s+<key>Artist<\/key&gt<string>//; $line =~ s/&/&/; $line =~ s/<\/string>//; if($line =~ m/^The /) { $line =~ s/^The //; $line = $line . ", The"; } $artist = $line; } elsif($line =~ m/<key>Album<\/key>/) { chomp($line); $line =~ s/^\s+<key>Album<\/key><string>//; $line =~ s/&/&/; $line =~ s/ \(Disc \d\)//; $line =~ s/<\/string>//; if($line ne "N/A") { my %artistalbums; if(exists $albums{$artist}) { my $albumsref = $albums{$artist}; %artistalbums = %$albumsref; } $artistalbums{$line} = ""; $albums{$artist} = \%artistalbums; } } } close(READ); print("Complete.\n"); print("Writing album list to Album List.txt… "); open(WRITE, ">Album List.txt") || die("\nError: Album List.txt cannot be written to.\n"); for my $key (sort(keys %albums)) { $tempkey = $key; if($tempkey =~ m/, The$/) { $tempkey =~ s/, The//; $tempkey = "The " . $tempkey; } printf WRITE ("%-40.39s", $tempkey); my $valuesref = $albums{$key}; my %values = %$valuesref; foreach my $album (sort(keys %values)) { print WRITE ("$album\n\t\t\t\t\t"); } print WRITE ("\n"); } close(WRITE); print("Complete."); exit(0);