A Platform Game Using HTML5 Canvas

Nearly 15 years ago, when I was all of 15 years old, I wrote this little platform game which I have recently ported to Javascript/HTML5.  It is a kind of Mario clone and at the time I named it “Fred Jones in Adventureland”… hmm, not a great name.

It was a fun game to write and I learned a lot about game development and even game design in the process of writing it, some of which I occasionally put in to practice in my current job.

The game remains somewhat incomplete; the player has unlimited lives and unfortunately there are only 5 levels.  But as it stands it is a playable game and hopefully a little bit of fun.  There are a couple of small surprises in the levels along the way too.

Browser Issues

If you’re using Microsoft Internet Explorer 7.0 or higher the game will run awfully slow (Update: The game now supports the Google Chrome Frame plug-in.  If you are using Internet Explorer you should install this plug-in, otherwise the game will run slowly).

It also will not run at all in earlier versions of Internet Explorer, Firefox 1.0 and I believe Opera 9 and earlier.  This is because these browsers do not support for the necessary parts of the HTML5 specification.  Please upgrade your browser.

Controls

Left Arrow: move left
Right Arrow: move right
Ctrl: jump

Play!

Click the link above to play the game.

Technical Details

The game you are playing here is a port of the original game to HTML5/Javascript.  This means it now runs within any web modern browser.

Unlike most web games the game does not use Flash.  The <canvas> HTML5 element is used to draw all the visual elements.

All the code for the game is all available to read if you hit “view source” in your browser and I invite you to take a look.

I was pleasantly surprised by the performance of the <canvas> drawing operations and the modern javascript implementations, it runs at the same framerate it always has on pretty much all browsers except Internet Explorer.

Linux Users Slowest to Update Firefox

My screengrab script for Mozilla Labs Ubiquity (think of Ubiquity as an extensible command-line interface for Firefox… if you can imagine that) gets fairly regular hits.  Depending on the user’s preference, each time they start Firefox a request will be made to my site to check for any newer version of the script.

This means that for some users I get a web server log message every time they start their browser.

One interesting statistic I’ve uncovered from these logs is a startling lack of hits from Firefox 3.5 on Linux systems.  It seems that almost no one running Linux has bothered to upgrade to the shiny, if not a little over-hyped, latest offering from the Mozilla team.

These ugly charts show the picture somewhat better than words can.  (Can anyone recommend a prettier, free charting tool?).

As the pies show, only 4% of the 70 Linux users to hit my site in the last 5 days have upgraded to Firefox 3.5.  Compare that with the 76% and 56% of Windows and Mac users respectively and you cannot deny the conclusion that Linux users are slow adopters.

Of course the reason behind the slow adoption is obvious: the ever so slightly Orwellian package maintainers.  Ubuntu (which comprises 58 of my 70 Linux visitors) only makes Firefox 3.5 available in development repositories, not the main-line.  It’ll be the default browser come Karmic Koala, but do we really all have to wait until October for a faster Javascript engine and what not?

There are more ways to get Firefox 3.5 into your Linux distro than I care to name or describe.  But all of these either find ways around your package manager or use untrusted 3rd-party repositories.

So for the sake of keeping your system stable, the pragmatic thing to do on the Linux desktop is to wait until your distro decides to support the software you want to use.  That is hardly putting the user in control.

There has to be a better way.

I’m on BBC News!

If you visit the BBC News Technology Homepage at the moment you’ll find a link to my Red Button Arcade blog post in the Features, Views and Analysis section.  Must have been a slow news day…

Woop!

My BBC Red Button games blog post is up…

My BBC Red Button Aracde blog post is live on the BBC Red Button blog.  Follow the link to read about the challenges of writing simple games on interactive television platforms.

The post includes a video and screenshots of the games I’ve written during my “10% time” at the BBC.  This is time we are given — half a day each week — to work on our own projects and try to innovate.

The games are written in the MHEG programming language, a subject I often discuss on this blog.

I get a mention on the BBCi blog

Today’s post on the BBCi Labs blog briefly mentions  a Pong game I wrote for Freeview/Freesat set-top boxes a while ago.  A couple of the guys in the BBCi team took my game and tried to make it multiplayer by passing players’ movements over the internet.  I don’t think they were totally sucessful though in getting it to work though…

Here’s the link.  The ‘Pong challenge’ section is the where it’s at…

Also see here for a video of the Pong game (the single player version), it’s the third game shown in the video.

Signing .deb packages

Okay, so here’s the scenario: you distribute .deb packages without an apt repository, but want to start signing your packages to ensure they aren’t corrupted or tampered with during transit to your users. I say “without an apt repository” since apt has its own mechanism for signing whole releases, via SecureApt.

The tools you are expected to use for this purpose are debsign and debsign-verify. Unfortunately I found the documentation for these to be pretty thin and ended up having to read the source of debsig-verify to work out what was expected of a signed package.

So hopefully to prevent others from having to trawl through source code, below are steps you could follow to sign your own .deb packages. My method is somewhat contra to the prescribed method from Debian, however it is the only way I’ve managed to get working.  Please suggest better methods if you know them.

The steps I performed were:

1. Create your GPG signing key, run
   

   $ gpg --gen-key

   
   and follow the steps.

MHEG+ Game Development Tutorial, Part #2 — Animation

In part #1 of this series we built a basic MHEG+ scene which was capable of firing timer events at a consistent rate.  In this part we will look to extend the code by adding an animating graphic to the scene.

A further aim of this part is to explain some more of the language features exclusive to MHEG+, including foreach loops, sequential blocks and ifs.

Adding our graphics to the scene

I have hand crafted the following 5 png graphics to use for this tutorial:

Using an MHEG+ foreach loop, we can add all these graphics to our scene in one fell swoop:

  foreach num (0..4) {
    {:Bitmap bmpPac<num> = [constPacObjectIdOffset + <num>]
     :OrigPosition          [(720 - 32) / 2] [(576 - 32) / 2]
     :OrigBoxSize           32 32
     :OrigContent           :ContentRef ('/tut/<num>.png')
     :InitiallyActive       false
    }
  } endfor

There a number of subtleties of this loop which are probably worth discussing:-

• foreach loops are preprocessor instructions, not run-time loops.  Because of this we can use foreach loops around object declarations, or in fact any code section at all.
• In this case, the contents of the foreach loop will be duplicated 5 times, this is controlled by the (0..4) range on the first line.  This range need not be numeric, text may also be used, for example: foreach key (red, green, yellow, blue) is allowed.
• The Bitmaps we declare will be named bmpPac0 through bmpPac4, <num> is substituted with each value in the range.
• The object identifiers for the Bitmaps will be 100 through 104, assuming constPacObjectIdOffset has the value 100.  We use the MHEG+ notation: objectname = objectid to declare both names and object identifiers for our Bitmaps.
• <num> is also substituted in the png filename

MHEG+ Game Development Tutorial, Part #1 — Timing

Introduction to this Series

One of the joys of my job at the BBC is staying back after hours and trying to nut out how best to write real-time games on current interactive television platforms.  That is, trying to write the kind of games that you might have once played in an arcade, or maybe on your BBC Micro, but allowing you to play them via the ‘Red Button’.  See this post for a video of some of my efforts so far.

Here in these tutorials I hope to share with you some of my findings in trying to get the best out of the MHEG platform.  I also hope to demonstrate the power of the MHEG+ programming language, an extension to MHEG.  MHEG+ has been developed in-house at the BBC and compiles down to traditional MHEG/ASN, but is a far richer langauge than its predecessor.

For these tutorials I will assume you have some background in programming generally and hopefully some experience writing MHEG or interactive TV applications (MHP, OpenTV, etc.).  The code samples will all be in MHEG+ which at time of writing is not available outside the BBC, however efforts are being made to attempt to open source MHEG+ development tools, so watch this space…

I guess for the time being then you most likely won’t be able to compile or run these applications, but hopefully one day soon you will be able to.  Therefore I suppose the code herein is currently just for educational purposes, but then that is the point of the series

So, without further ado…

Part #1: Timing

The first significant challenge that I came across when writing MHEG games was that of timing.  How could I ensure my game would run at virtually the same speed on any set top box?

Unlike more sophisticated languages (yes, I openly admit that MHEG is not the most sophisticated language, but then it was never designed to be) MHEG does not provide the developer with a means of retrieving accurate clock information.  The most fine-grained time information you can retrieve (achieved by a call to the GetCurrentDate resident program) provides no better than whole second precision.

Screengrab Ubiquity Script

Firefox users with the Ubiquity extension installed might like to try my Screengrab script which provides the commands:-

• ’screengrab’ — saves the current browser window to the clipboard, and
• ’screengrab-to-file’ — saves the current browser window to a png image file.

Once the screengrab command has been issued, the image can be simply pasted from the cilpboard into webmail emails such as GMail.

I’d like to eventually extend the script to provide a ’screengrab-and-email’ command.

Downloads and more details here.

Here’s a screenshot:

Video: Games I’ve written in MHEG

MHEG is a programming language & middleware found in digital set top boxes in the UK and elsewhere around the world.  This video briefly shows a few games I have written in MHEG while working at the BBC.

The games shown in the video are:-

1. ‘Nibbler’ – a Snake clone.
2. ‘Bounce!’ – really more of a tech demo than a finished game, but surprisingly fun.  Catch the green blobs but avoid the red one.
3. ‘Ping Pong’ – pretty self explanatory I think.

The games have never been broadcast.  I am hoping the powers that be at the BBC will let them go to air.  What do you think?  Would you like to be able to ‘Press Red’ and play games such as these?

Obviously the graphics could do with some work, but these games do at least prove the technology…

Leave a comment if you’d like to see the BBC do classic arcade style games on interactive TV.