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.

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.

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 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.

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.

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.

2. Sign the .deb with your private key, without using debsign (please comment if you get debsign to work for you, I couldn’t…).
   1. Take an existing .deb and unpack it:
      

      $ ar x my_package_1_0_0.deb

   2. Concatenate its contents (the order is important), and output to a temp file:
      

      $ cat debian-binary control.tar.gz data.tar.gz > /tmp/combined-contents

   3. Create a GPG signature of the concatenated file, calling it _gpgorigin:
      

      $ gpg -abs -o _gpgorigin /tmp/combined-contents

   4. Finally, bundle the .deb up again, including the signature file:
      

      $ ar rc my_package_1_0_0.deb _gpgorigin debian-binary control.tar.gz data.tar.gz

3. Export your signing public key and determine its key id.
   1. Export your public key:
      

      $ gpg --export -a > my-debsig.asc

   2. Extract the key id by taking the last 4 chunks of the fingerprint, CA58BC6A0695623E in this case. We always use it without the spaces:
      

      $ gpg --fingerprint
      /home/floyd/.gnupg/pubring.gpg
      ------------------------------
      pub   1024D/0695623E 2009-02-04
            Key fingerprint = 6577 AAB2 8850 9E0B 1059  C510 CA58 BC6A 0695 623E
      uid                  Purple (Floyd) <--your email address-->
      sub   2048g/EB122979 2009-02-04

4. Setup the machine(s) that will be downloading and verifying the package.
   1. Install the debsig-verify package
      

      $ apt-get install debsig-verify

   2. Import the public key into the debsig keyring:
      

      $ mkdir /usr/share/debsig/keyrings/[key_id]
      $ gpg --no-default-keyring --keyring /usr/share/debsig/keyrings/[key_id]/debsig.gpg \
            --import my-debsig.asc

   3. Configure a policy for the key, policies are discussed in some detail in /usr/share/doc/debsig-verify. The policy file needs to be kept in /etc/debsig/policies/[key_id]/[policy_name].pol. Mine looks like this:
      

      <?xml version="1.0"?>
      <!DOCTYPE Policy SYSTEM "http://www.debian.org/debsig/1.0/policy.dtd">
      <Policy xmlns="http://www.debian.org/debsig/1.0/">
      
        <Origin Name="PurpleFloyd" id="CA58BC6A0695623E"
                Description="Another package from PurpleFloyd"/>
      
        <Selection>
          <Required Type="origin" File="debsig.gpg" id="CA58BC6A0695623E"/>
        </Selection>
      
        <Verification MinOptional="0">
          <Required Type="origin" File="debsig.gpg" id="CA58BC6A0695623E"/>
        </Verification>
      
      </Policy>

5. You should now be able to verify the package using debsig-verify, i.e.:
   

   $ debsig-verify my_package_1_0_0.deb
   debsig: Verified package from `PurpleFloyd' (Another package from PurpleFloyd)

Et voila! You have signed and verified a debian package.

Note: on most distros, dpkg/apt will not check the signature of a package when installing it, even if a signature is present. This checking can be enabled by removing the --no-debsig line from /etc/dpkg/dpkg.cfg.

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

You may also have noticed that our 5 Bitmaps have :InitiallyActive set to false.  We will later call :Run and :Stop on our Bitmaps to control which frame of the animation is visible, so they do not need to be running at startup.  However we do still want to pre-load our Bitmaps when the scene loads in order to have them prepared in memory and ready to use, so we add the following to lnkStartup:

  // preload graphics
  foreach num (0..4) {
    bmpPac<num>.Preload()
  } endfor

Here we are using a foreach loop not for ingredient declaration but to duplicate a line of code in a link effect.  Again, <num> is substituted appropriately.

Drawing each frame

As in part #1 of this series, we will use the Link lnkGameTick to calculate and render each frame of our game.  The first thing we did in lnkGameTick is set the next timer event, this is to ensure our game runs at a fairly consistent pace.

We now extend lnkGameTick to call out to two sequentials.  The first sequential “calculates” the next game tick, the second renders it to the screen.  We therefore add the following to lnkGameTick:

  tgPac.CallActionSlot(calculateNextFrame)
  :LockScreen()
  tgPac.CallActionSlot(updateScreen)
  :UnlockScreen()

(Note: Games often separate the concerns of calculating a frame from rendering it.  In an environment other than MHEG this could allow us to choose whether to render the current frame (which is normally an expensive operation) to keep the game tick rate consistent.  MHEG however without precision timing does not allow us this freedom, but separating along these lines makes our code more maintainable.)

Note that we call :LockScreen and :UnlockScreen around the call to updateScreen.  This effectively tells the MHEG engine to render our new frame off-screen and display the changes only when we call unlock.  This is akin to Double Buffering and helps reduce screen flicker.

We still need to implement the sequentials calculateNextFrame and updateScreen, which I’ll describe in the next two sections.

Calculating what to display

For each game tick we need to determine what should be visible on the screen.  In the case of our animation of the ‘Pac’ character, this means determining which of our 5 Bitmap ingredients should be visible.

So the effect of the calculateNextFrame macro should be to modify an integer variable whose value will later be used to identify the Bitmap to display.  We’ll call this integer intNextPacObjectId.

Here is the necessary code:

  defSequential calculateNextFrame :Namespace tgPac {
  (
    // increment counter
    intCount.Add(1)
    intCount.Modulo(constNumFrames)

    // calculate object Id of Pac Bitmap to display this frame
    intNextPacObjectId.SetVariable(:IndirectRef intCount)
    :If (intNextPacObjectId >= constNumBitmaps) {
      intNextPacObjectId.SetVariable(constNumFrames)
      intNextPacObjectId.Subtract(:IndirectRef intCount)
    }
    intNextPacObjectId.Add(constPacObjectIdOffset)
  )
  } endSequential

Of note in this code section:-

• The sequential declaration states which namespace it belongs to.  When we call a sequential we use the notation: namespace dot CallActionSlot( sequential ), as we do in lnkGameTick.
  In MHEG+ we also must declare the tgPac token group and call :InsertSequentials, see the complete code listing below for example code.  An MHEG+ sequential is a façade to an MHEG ActionSlot.  Sequentials though can be declared anywhere in the source file and have cleaner syntax.
• Did you notice the :If?  MHEG+ gives us the syntatic sugar of being able to declare inline If blocks.  In classic MHEG our only way of implementing conditional code sections was to use the :TestVariable action and write separate :Links to perform actions based on the evaluation of the test.  In fact this is what MHEG+ does behind the scenes, but the abstraction is very handy.  We can also write :Else and :ElseIf blocks.

Updating the screen

Now that we have calculated the object Id of the Bitmap to display and stored this in an integer, we need to write a sequential to hide the current Bitmap that is displayed and show the new one.

Only by a call to a resident program can we translate an integer value into a reference to an actual object, the resident program to do this is called CastToObjectReference, or CTO.

Here is our implementation of this sequential:

  defSequential updateScreen :Namespace tgPac {
  (
    // stop the bitmap of previous frame
    :Stop(:IndirectRef objPac)
    prgCastToObjectRef.Call(boolTemp
        "/tut/tut2.mhg" :IndirectRef intNextPacObjectId
        :IndirectRef objPac)
    // run the bitmap of this frame
    :Run(:IndirectRef objPac)
  )
  } endSequential

• We call the prgCastToObjectRef resident program in order to retrieve a handle to an object given its object Id. We pass an integer (which will be in the range 100 to 104) and dynamically gain access to the object with this identifier. This is why we explicitly stated the our Bitmaps’ object Ids when we declared them.
• Note that we can’t use object dot action notation when dealing with object references (objPac is an object reference variable), this is a limitation of MHEG+.  This we must write :Run(:IndirectRef objPac) and not objPac.Run().

Putting it all together

Hopefully it should be fairly clear by now what the scene does.  At the middle of the screen we see the following animation:

Because we have used :LockScreens and tried to keep the work done whilst the screen is locked to a minimum, the animation will be fast and practically flicker free.

Looking at the complete listing (see Resources section below) it would be true to say that MHEG+ is not the cleanest of programming languages. However it is a lot more readable and maintainable than traditional MHEG.

The source listing really boils down to two key sequentials: calculateNextFrame and updateScreen.  We would be wise to move each of these sequentials into separate files and develop them somewhat independently of eachother and the rest of the scene.  MHEG+ allows us to use import declarations in order to better manage our source code.

Where to from here?

This is a good starting point for a game.  Of course there is still plenty to do, including:-

• Moving the sprite around the screen
• Rotating the sprite when it changes direction
• Adding a maze
• Adding other objects to the maze

There are also a number of  MHEG+ features we have yet to use including macros (both parameterised and not), state machines and imports.

In later posts I hope to explore these themes and also discuss the tools that make up the MHEG+ SDK including the MHEG Player (emulator), MHEG+ compiler and the Eclipse editor plug-in.

Resources

Complete source listing as a PDF: tut2.pdf.

Animation graphics (0.png through 4.png):

Other posts in this series:
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.

MHEG Timers however provides us with some hope.  The :SetTimer action expects a millisecond count as an argument – hooray! we have precision timing.  Well, almost.

The UK MHEG profile goes into considerable detail about the accuracy of Timers which I won’t go into here except to say that they are accurate enough for most gaming needs.

The UK profile also states that the MHEG engine must start a timer immediately when a call to :SetTimer is encountered.  This we can use to our advantage.

Let’s try this out in some code, here is a simple MHEG scene with a timer. It is written in MHEG+:

{:Scene ("/tut/tut1.mhg" 0)
 :Items (
        // Constant declarations
        // ---------------------
        {:IntegerConst constTimerDelay :ConstValue 100}

        // Variables -----------
        // ---------------------
        {:IntegerVar intCount :OrigValue 0}
        {:OStringVar strTemp :OrigValue ''}

        // Ingredients ---------
        // ---------------------
        {:Text txtText
         :OrigContent           '0'
         :OrigPosition          0 [(576 - 100) / 2]
         :OrigBoxSize           720 100
         :HJustification        centre
         :VJustification        centre
        }

        {:Timer tmrTimer}

        // Links ---------------
        // ---------------------
        {:Link lnkStartup
         :EventSource           0
         :EventType             IsRunning
         :LinkEffect
         (
                :SetTimer(0 tmrTimer constTimerDelay)
         )
        }

        {:Link lnkGameTick
         :EventSource           0
         :EventType             TimerFired
         :EventData             tmrTimer
         :LinkEffect
         (
                :SetTimer(0 tmrTimer constTimerDelay)

                intCount.Add(1)
                strTemp.SetVariable(:IndirectRef intCount)
                txtText.SetData(:IndirectRef strTemp)
         )
        }

        {:Link lnkKeyText
         :EventSource           0
         :EventType             UserInput
         :EventData             KeyText
         :LinkEffect    ( :Quit() )
        }
 )

 :InputEventReg 4
 :SceneCS 720 576
}

The key elements of the scene are its :Links. Links are where most processing happens in MHEG applications. MHEG links could have been called “action listeners”. You write links to listen for particular events, when this event occours your procedural code in the :LinkEffect section is executed by the MHEG engine.

The links defined in the scene are:-

• lnkGameTick — this link is fired whenever the timer times out.  Its effect is to increment our integer counter variable, convert it to a string (storing in strTemp) and update the display (txtText).  The very first thing we do in the link effect however is set the next timer event.
• lnkStartup — this link is called after our scene has finished loading.  It is important because this is where we set up the first timer event.  Timers cannot be set to fire automatically when the scene loads.
• lnkKeyText — this link listens for a key press, specifically the Text button on your remote control.  Its effect is to simply exit the application (it calls :Quit).

Other things of note in the code:-

• MHEG+ allows us to use names for our objects, conversely classic MHEG requires that all objects be identified solely by a number.
• The actions in lnkGameTick are using MHEG+ dot notation (object dot action).
• The vertical position of the txtText Text object is written as an expression ([(576 - 100) / 2]), this is an MHEG+ feature, the expression is evaluated at compile time.
• We declare a constant (constTimerDelay) another MHEG+-only feature.
• :InputEventReg and :SceneCS at the bottom of the scene if you are wondering are indeed required. Let’s not go into detail about these now though as they can be considered just boilerplate code in most cases.

If you haven’t guessed by now, when its run the scene displays a counting number in the centre of the screen, which updates every 100ms.  Here is a cropped screenshot of the app after letting it run for approximately [100 * 103] milliseconds:-

The key lesson to take from this is that we set the timer at the top of lnkGameTick. Why?  By doing so we are ensuring that the timer event will be fired at the most consistent rate possible in MHEG.  The timer can only ever be late. We simply now have to make sure that our game loop is efficient enough to be executed within our specified time period (here, 100ms).

So that’s it for part #1 of my MHEG+ tutorial.  I hope that you got something out of it.  I would imagine the most useful content here was the code section — is this the first time you have seen MHEG+ code?

I hope later posts in the series will look into some of the more advanced features of MHEG+ such as If statements, For loops and Macros, plus I shall of course endeavour to include the complete source code for a number of simple, but playable, games.

Ciao for now. Hope to be back soon.

Resources

Other posts in this series:
Part #2 — Animation

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:

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.