Red Button Arcade
Post categories: Freeview,ÌýMHEG,ÌýOne In Ten
| 08:45 UK time, Monday, 23 March 2009
The Red Button Arcade One in Ten project was borne out of a realisation that, whilst they're nowhere near as powerful as the average PC or modern games console, digital set-top boxes are considerably more powerful than classic home computers such as the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú Micro. As such they should achieve comparable or better performance when running video games.
In my youth I spent countless hours writing games on my Acorn Electron, a Â鶹¹ÙÍøÊ×Ò³Èë¿Ú Micro compatible machine. I was really quite young, so the games I wrote were not very sophisticated. Normally they were text adventure games with occasional graphical elements, all written in the BASIC programming language.
Because the games were written in BASIC, they were "sandboxed" within the BASIC run-time environment. That is, they could not interact directly with the computer's hardware; instead they solely interfaced with the BASIC run-time. This had a performance penalty.
The Red Button Arcade project aimed to deliver concept games that ran on the Freeview platform. Freeview set-top boxes have a run-time environment in them called MHEG. The entire Â鶹¹ÙÍøÊ×Ò³Èë¿Ú Red Button Freeview interactive service uses MHEG, this gives an example of its power. However, MHEG is to set-top boxes as BASIC was to the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú Micro - it sandboxes applications and denies direct interaction with hardware.
In order to see this content you need to have both Javascript enabled and Flash installed. Visit Â鶹¹ÙÍøÊ×Ò³Èë¿Ú Webwise for full instructions
Making matters worse, MHEG was certainly not designed with video games in mind. Much needed trigonometric functions like sine and cosine are absent. Further, MHEG does not provide a data type for storing decimal numbers - integers (whole numbers) are the only kind supported. And, frightening to most software engineers, MHEG does not allow data elements to be held in arrays or programmer-defined data structures, which greatly simplify programming.
Against the odds, three games were written during the Red Button Arcade project. I'll attempt to describe each of these games here as well as the challenges in implementing them in MHEG. These games are concept work only and are not publicly available.
Nibbler
Nibbler is a poorly disguised clone of a game made popular on a certain brand of mobile phone.
The MHEG implementation aimed to be as efficient as possible; during each game tick, the head sprite ("ingredient" in MHEG terminology) is moved to its new location on screen and the tail is moved to the previous location of the head. Therefore only 2 ingredients moved each frame. Similarly, when a cherry is collected, the tail doesn't move but a new body piece is placed where the head was previously, effectively making the snake longer.
The biggest challenge in implementing this game was designing a data structure in MHEG that maintained pointers to each body part of the snake. This was implemented using a text string that is encapsulated by macros which maintained the correct structure of the string and provided access to desired ingredients.
Bounce!
This was the first game I developed in MHEG. The goal of the game is to "nudge" the yellow "ball" by using the arrow buttons on the remote control towards the green balls, whilst all the time avoiding the red ball (okay, they are very square balls!). The red ball gets progressively faster and changes its movement pattern as your score increases, meaning the game's difficulty increases as the player progresses.
The game employs some very simple physics calculations, giving the bouncing ball the appearance of inertia. There is also a gravity effect. MHEG required that these calculations be implemented using only integer arithmetic. So, to effectively provide precision of one-hundredth of a unit, all values were multiples of 100 of their real value.
Ping Pong
Another poorly disguised clone, this game was my first in MHEG to use a pre-compiled trigonometric lookup table to calculate the ball bounces and "spin". A table of 90 pre-computed sin() values representing 90 degrees is stored in the source code, from which complete sin() and cos() tables are derived.
This game also presented user input difficulties. Since set-top boxes do not notify the running MHEG application when a remote control button is held or released, only button press notifications are provided, it was not possible to only move the paddle when the up/down buttons were held. As a workaround, a single press of up or down will set the paddle moving and it won't stop until the opposite direction is pressed. A later addition allowed the player to press the Select/OK button to stop the paddle from moving.
User input challenges such as this limit the scope of games that can be implemented on interactive TV platforms.
Future of Red Button Arcade
There is some debate about whether the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú should use public money to produce interactive entertainment (i.e. games) alongside its current linear output.
CBeebies and CÂ鶹¹ÙÍøÊ×Ò³Èë¿Ú educational games are currently the primary gaming output of the Â鶹¹ÙÍøÊ×Ò³Èë¿Ú. In keeping with this, some of the learning gained from this project will be applied to new children's games in the near future.
The Red Button Arcade project has proved that real-time gaming is at least a possibility on current interactive television platforms. The games are of course very simple and in the future I hope we will push the envelope a little more and perhaps look at the more powerful Freesat and Sky platforms, or upcoming platforms.
The project also proved that real-time graphics processing is possible on Freeview set-top boxes. This opens up the possibility of developing applications that make use of real-time visualisation, for example to display audience votes or sports statistics. And as a team we're looking forward to exploring more the possibilities that provides us.
Mark Hatton is a software engineer working in the TV Platforms Group
Comments