This game was coded in HTML5 Canvas and JavaScript with the Paper.js library. I’ve only used a few of the library’s many features (and pretty much ignored its focus on vector-based graphics in favour of bitmaps) but I found the library vastly simplified basic tasks such as placing image objects on the screen, rotating them, and refreshing and redrawing the canvas with every frame. In this respect it feels like progress over my more rudimentary first HTML5 game.

The gameplay itself is straightforward: use the mouse to aim the anti-aircraft gun, and click to shoot. It takes three hits to bring down a plane. Once the planes have bombed the city into destruction, your game is over. Aid parachutes drop occassionally to rebuild individual towers. Between levels, the city regenerates based on how accurate your shooting was in the previous level, so make every bullet count.

While the game is playable in all modern browsers, the experience differs drastically between them. On Safari the overall frame rate is slow, causing the frequency of timer related events like bomb dropping to be relatively fast, making it almost impossible to survive the first level. FireFox behaves better, but slows down noticeably whenever things get intense. Chrome and Internet Explorer 9 (surprise!) offer the smoothest and most playable overall experiences.

I have attempted to optimize my code as much as possible, through basic things like reusing assets and freeing objects when no longer needed, so I’m not sure what I could do to improve these issues. It’s possible I’m not using paper.js in the way it was originally intended, with so many bitmap images. Still, I think it’s fairly exciting as another proof-of-concept to see what’s now possible in a post-Flash world.

Things I would add or fix if I had infinite time and energy:

• Add some sound: I had some basic gunshots and explosions roughed in, but browser variations and delays between when a sound’s play() method was called and when it was audible made it more distracting than anything, so I removed it.
• Add different types of planes, including ones that drop “super bombs” to destroy entire towers.
• Add different building types and different skylines.
• Make it mobile-friendly (currently it is not playable on a touch interface).
• Integrate a high score board.
• Make it overall more fun and less boring.

Lesson learned: if HTML5 is the platform, next time I’ll make a strategy game, not an arcade game.

Working with Design for Good, I implemented the provided graphic design concepts and requirements as a custom WordPress theme, and enhanced it with customized plugins that help create a friendly, contemporary and easy-to-maintain website to showcase the organization’s work for potential donors, volunteers and participants.

Building an arcade game with these tools was challenging, but the results are promising. This game is mostly a proof-of-concept to see what’s possible; it wasn’t really planned out in advance, hence the silly concept.

Game Play

Control your grey mouse with your keyboard arrow keys, or by touching the arrow key graphics on a touch device. Avoid the evil red mice, who kill you on contact with bloody results. Collect all the cheese, then escape through the unlocked exit. There are 6 distinct level maps. Once you complete all level maps, they start over and the game gets a little faster. Repeat until dead.

Code Structure

To get my hands dirty I intentionally coded everything from scratch without using any third party game libraries or frameworks. This seat-of-pants development resulted in code that’s not particularly well structured, with a lot of global variables and arrays. I look forward to attempting a second game with a more coherent, scalable Object Oriented structure, but for now this jumble o’ functions will have to do the job. The main game file is about 1000 lines of Javascript.

The core of the game is a basic state machine to control the primary phases, such as “title page”, “playing”, “player dead”, “new level”, and “game over”. The game loop is a timeout event that fires every 100ms for the first pass through the levels, and then 5ms faster each pass after that. This is a relatively slow fire rate, so on each timer tick I move the player 15 pixels, and the enemies 5 pixels. The movement is slightly jerky, but I think it mimics the darting motion of real mice.

Everything in the game is Canvas-based except for some of the opening and closing game buttons and rollovers, which I found easier to implement as regular HTML elements layered on top of the canvas, shown or hidden as needed using jQuery and CSS.

Canvas

The new Canvas element is at the core of HTML5, and it’s what finally makes playable games feasible without Flash. However, having used Flash and ActionScript in the past, Canvas seemed quite crude and low-level at first glance. I took me some time to learn that the Canvas is exactly that: a surface to draw on. Once you draw an image or text to the canvas, you cannot modify or move it. There is no built-in concept of a “sprite” or “image object” that can float atop a background and be animated separately. Instead, drawing on the Canvas is more like stamping a piece of paper with a rubber stamp: you can stamp repeatedly, but your old impressions remain visible unless you turn to a blank page.

That means my game code needs to manually manage the clearing of the canvas on each update timer tick. I handled this at the beginning of each refresh cycle by simply re-drawing the current game board background image to clear everything in the top portion of the canvas. Then I recalculate and redraw the player, enemy, cheese, and exit in their appropriate states in the right places.

Tiles

Rodent Race is essentially a tile based game, meaning that the gameplay area is a grid divided into square tiles, in this case, 30 by 30 pixels. The game mazes are then represented internally by simple two-dimensional arrays, with numbers representing open space, walls, or cheese. The information for the levels is defined in an external XML file that’s loaded and parsed dynamically. Here’s an example of the definition of the maze for level 1:

1,1,1,1,1,1,1,1,1,1,1,
1,5,0,0,0,0,0,0,0,5,1,
1,0,1,0,1,1,1,0,1,0,1,
1,0,1,0,0,0,0,0,1,0,1,
1,0,1,0,0,1,0,0,1,0,1,
1,0,1,1,0,1,0,1,1,0,1,
1,5,0,0,0,1,0,0,0,5,1,
1,1,1,1,1,1,1,1,1,1,1

In a tile based game, it is very easy to do some simple math during each timer tick to determine which tile the player and the enemies currently reside on. From there, it’s easy to determine if there’s a collision between the player and enemy, or to consult the array to see if the player is on top of a piece of delicious cheese. This is helpful since Canvas has no built-in low level collision detection like hitTest() in Flash ActionScript.

Graphics

The graphics are all simple PNGs and JPGs created in Photoshop, loaded dynamically at the initiation of the game. I made some effort to optimize the images, however, for a future game I would aim to use more “sprite” images to reduce the number of different assets that need to be loaded. I did use sprites for images that have have multiple positions, such as the mice, which face in four directions. For example, here’s the player sprite image:

Sound

Audio in HTML5 is probably the most poorly supported aspect, with many cross-browser and cross-platform challenges. About 50% of the time I spent on this game was eaten up by experimenting with sound, experiments that were only partially successful. On desktop browsers, the support is quite decent. I was able to loop a simple (annoying) theme song in the background, and then simultaneously play other game sounds (like mouse “squeaks” and cheese “chomping” sounds) as needed without much difficulty. On these browsers, the delay between calling a sound and when it is played is negligible. The song loops reasonably smoothly, though that varies from browser to browser, so sometimes there is a noticeable glitch in the song when it starts over.

Mobile devices, on the other hand, are way behind in HTML5 audio support. The iOS devices such as iPad, iPod (and I presume iPhone, which I don’t have) do support audio, but only in a very restricted way — audio can only be played immediately after a user interaction such as a click, two sounds cannot play simultaneously, and there is sometimes a painful delay between when a call to play a sound is initiated and when it is actually heard. On my Android phone, the song would not play at all; the shorter sound effects would play, but only after an unacceptable delay, and after a half-dozen sound calls the browser would crash. As a result of these struggles, I concluded that mobile HTML5 isn’t yet ready for the sort of real-time audio an arcade game demands, so I implemented a simple user agent check and then disabled sound entirely on those devices. Sniff. (I read with interest Remy Sharp’s post on “audio sprites” for iOS which sounds like a great theory, but I didn’t feel like investing that much time here. Something for the future.)

The theme song was “recorded” in Garage Band using the keyboard piano tool, the notes sounded out by my semi-musical ear. The other effects were downloaded from free sound effect sites, and then heavily cropped and munged in Adobe Soundbooth. Each sound file had to be uploaded in three formats: .mp3, .ogg, and .aac, since different browsers and platforms use different formats, though all can be encapsulated within a standard HTML audio element.

Artificial Intelligence

The “intelligence” of the enemies is fairly rudimentary, but because of the small size of the mazes, it’s more than enough to keep things challenging. Essentially, the enemy rodents will always keep moving in their current direction until they hit a wall. At that time a new direction is chosen. This direction will always be towards the player; however, when the player is in a different position both horizontally and vertically, only one of the two directions is chosen randomly. This adds a little bit of unpredictability to the enemies’ movement, and also helps reduce the number of times they stop moving entirely behind a wall while waiting for the player to move, though this still happens occasionally. After a bit of practice playing, you can learn to predict certain patterns of enemy movement and find “safe” squares where you can wait until the coast clears.

High Scores

Against my better judgment, I have implemented a high score board. The scores are stored in an external XML file, which is read and parsed by jQuery. Only the actual score updating is handled by Ajax calls to PHP, which is required to write to the server. I say “against my better judgment” because I know that it is pretty much impossible to create a secure high score board in client-side Javascript. I am fully aware that hacking this scoreboard to blast it with artificial high scores would be trivial for the right person. However, if you do this, I will be impressed only by the amount of free time you have to waste: please volunteer at an animal shelter instead. There are probably some mice-loving cats that need saving.

Lessons Learned

As I mentioned, this game was really intended as a personal proof-of-concept and a learning experience. And I am pleased to report I did learn a few things. In no particular order, here are some notes to my future self:

• This game is technically playable on touch mobile devices, but pretty much impossible. If you’re going to make a game for mobile, make sure the controls are super easy: a four-direction arrow pad is just not feasible in a fast-paced game. Two touch points, widely separated on the screen, would be much more reasonable.
• The canvas is pretty flexible once you get the hang of it, and modern browsers can seem to handle a lot of graphic updates on a single timer tick. This bodes well. But manually handling the drawing and refreshing of multiple elements quickly leads to spaghetti code. A nicely abstracted object model that allows sprites to be created, assigned parameters, and then “forgotten” as they are automatically managed on each tick will be mandatory for anything more ambitious.
• HTML5 Audio in desktop browsers is surprising well implemented now: only a year or two ago Flash add-ons were still needed to play sounds in HTML5, so this is a great advance. There are not too many limitations to worry about here. (Mobile is another story entirely for now.)

The Code

All the game code, minus that related to high scores, is available on GitHub at this URL:
https://github.com/garyesmith/RodentRace

Please feel free to download the game code, check it out, play with it, laugh at my coding blunders, use code snippets in your own projects, and so on. However, please don’t redistribute the game in its entirety, and if you are re-using the vast majority of the code base for some reason, please give me credit and a link back to garysmith.ca.

And finally, credit where credit is due: any resemblance to an old Commodore 64 game called Radar Rat Race is entirely intentional.

Feedback or suggestions about this game is welcome, either in the comments or via my contact form. Enjoy!

Only One Site at a Time

First, I had to be careful to develop and test my new website on a server that was not accessible to the world at large. If my work-in-progress was exposed publically for even a day or two, the Googlebot might have found it and indexed it. I really didn’t want two distinct copies of my portfolio indexed separately: in addition to being confusing, that might also cause Google to downgrade my search result rankings because sites with cloned content can be penalized to discourage content farming.

My quick solution for this was to use a password-protection WordPress plugin called Private! that ensured I had to be logged in to view my site. It also let me create multiple users, so if I wanted to solicit feedback from trusted friends or colleagues I could give them a username and password. But bots and spiders from Google and other search engines were blocked.

Create 301 Permanent Redirects

When it finally came time to launch, I ensured that my new domain was pointing to my new site and then removed the password protection. Then, since my site host runs on an Apache server, I created an .htaccess server configuration file in the root of my old gesmith.ca site to map all the existing URLs from that domain to my new one. Other types of web servers implement this differently, but the idea is the same.

It took me some time to create this redirection file, as I had to carefully comb through my old site to determine exactly what pages needed forwarding, and find their equivalent URLs on my new site. I also did some common Google searches on my own content to make sure that any pages in the search results were forwarded correctly.

In the .htaccess file, I mapped each URL from the old to the new site using a permanent redirect with the status code of 301, which informs clients like the Googlebot that the requested URL has been moved permanently to a new URL.

To define a 301 permanent redirect in an Apache .htaccess file, I used this syntax:

redirect 301 /contact.html http://garysmith.ca/contact/

Here, 301 is the code to indicate this is a permanent redirect, /contact.html is the path requested on the old server relative to the domain, and http://garysmith.ca/contact/ is the full destination path to redirect to. This same syntax applies to all redirect lines in the file; my small site has several dozen.

This redirection happens silently, so casual web users might not even notice that the page they’re reading is actually on a different domain than was shown in the link they originally clicked. But that’s okay… it beats a dead link! The important thing is that no traffic is lost, and the search engines now know that the original link is obsolete and what its replacement should be.

After all my specific pages had been redirected as above, I added a final generic redirect to the bottom of my .htaccess file to catch any other attempts to hit files on my old domain. Since I don’t know exactly what these unknown paths might be or they were meant to go, I just send them to the home page of my new domain:

redirect 301 / http://garysmith.ca/

The “from” path in this line is simply a “/”, which refers to the root of the domain. This also catches attempts to hit any file or path on the old domain that hasn’t already been redirected: even something nonsensical like http://gesmith.ca/blah/blah.html will now redirect to my new new site, even if it is in turn redirected to my “Not Found” page. That’s fine, because it gives visitors a chance to find what they’re looking for on my new site.

Letting Google Know

If I had done nothing more than the steps above, Google would have eventually figured out that my site had moved. Old references to gesmith.ca would have gradually fallen out of the search results index, and new references to garysmith.ca would have been added. But that process could take weeks or months, and I’m an impatient modern man. So I wanted to hurry things along a little.

Luckily, Google is staffed by fellow impatient people, so they have kindly provided a set of Webmaster Tools for just these sorts of tasks. After my account was activated, I added both my old gesmith.ca and my new garysmith.ca domain into the tools, both with and without the www prefix. For each domain, I had to upload a special HTML file provided by Google into the site root, to prove I actually owned the site — imagine the chaos if anyone could manage any site on the Internet.

Once the domains were added and confirmed, I clicked on my old gesmith.ca domain in the tools. Under the Site Configuration section I chose Change of Address. From there I was able to specify the new domain for the site by selecting garysmith.ca from a dropdown list of all my previously added sites. I submitted the request, and that was it: Google had now been explicitly informed that both these domains hosted versions of the same site, and that one was moving to the other.

The Waiting Game

Of course, since I was dealing with Google’s enormous index of data, nothing happened instantaneously. After a day or so, links to my new site began showing up in certain very specific Google queries, but most of the results were still pointing to my old site (though of course when clicked they were redirecting to the new site). It was only after about 10 days that my new domain became the default result for most of the search terms that regularly generate my traffic. Mission accomplished! Eventually.

This new portfolio site, its fourth incarnation since 2003, is a total overhaul. The site now runs on WordPress 3 with a custom theme I heavily adapted from ElmaStudio’s nifty Yoko theme. It’s in HTML5 and uses some CSS 3 style effects that degrade gracefully in older browsers. This site was also a chance to indulge my new addiction to Google Web Fonts, a great tool that finally frees us from the oppressive shackles of Arial.

In addition, this theme adopts Yoko’s use of stylesheet @media queries to create a fluid layout that adjusts automatically for various screen resolutions, all the way down to mobile devices such as iPhones. This ability to create content once and have it display nicely on a multitude of different devices is fantastic for both the content maintainer and the end user. That said, it definitely takes extra development effort to consider all the possible layout scenarios that might result from a smaller screen resolution.

My job gets more interesting every year, but it definitely doesn’t get simpler.

As the site content will remain fairly static, no CMS was required. However, I did create some custom functionality for a jQuery-powered animated client logo slider which dynamically parses data from an XML definition file, allowing for easy modification of client logos at a later date.

Working with the designs provided by S+P Design, I was responsible for coding the XHTML, JavaScript, CSS, and PHP required to create a clean, search-engine-friendly website.

I created a custom WordPress theme to implement the design provided by Swerve Design, and used a combination of third-party and custom plugins to create members-only site sections. Other custom features include a jQuery-based home page feature rotator and a content font-sizing widget.

Working with the designs and concepts created by Design for Good, I coded custom PHP and MySQL to handle the pledge submissions, validation, data exporting, and email sending functionality.

I worked with Design for Good to build this custom PHP/MySQL website. Integrated with an existing donation system, the Protect Your Share site enables donors to make a donation to protect a share of the Malcolm Bluff Shores, and then see that share represented visually as a part of a forest along with supportive messages. The site also includes information and galleries showcasing the natural resources being protected.