For those of you that haven’t heard of it, Game & Watch was a line of LCD handheld video games from the 1980s. The Donkey Kong title was probably one of the most popular in the series, selling more than a million units worldwide. The game was split over two screens and built into a distinctive clamshell casing.
My starting point for this project was with the construction of the casing in CSS . There is nothing particularly revolutionary about this procedure, but it was a new experience for me. The basic structure of the body was formed with a set of div elements, then border and box-shadow properties were applied to control the colouring of the edges. For circular elements, a border-radius was used to adjust the shape appropriately.
When complicated colouring or shading was required, one or more layers of gradient were applied to the background property to produce the necessary effect (typically a linear-gradient ). This part of the process was very much trial-and-error – some of the best results were achieved largely by accident – so I was quite pleased with how it turned out in the end.
Game screen backgrounds
When it came to rendering the background screens of the game, I decided to go with SVG , since that was another web technology I had always wanted to try out. I started by sketching the individual components as monochrome bitmaps in Microsoft Paint, then used an image converter from the Online-Convert website to translate those bitmaps into SVG paths.
Once I had an SVG path for each part of the screen, I manually coloured and combined those fragments, then added appropriate shading and filter effects to produce the final image. I had initially had a separate SVG for each of the screens, but once Chrome eventually agreed to support SVG stacks , it became feasible to merge the two images into a single file.
As for the LCD elements of the game ( Mario , Donkey Kong – basically anything that moves), the approach I took here was to create a custom icon font with each entity being a character in that font. This seemed like a perfect fit for LCD , since everything would obviously be a single colour, and I could then create the shadow effect that you get with an LCD just by applying a text-shadow property to the font.
As with the game screen backgrounds, the glyphs were initially sketched as monochrome bitmaps in Microsoft Paint, then translated into SVG paths using the Online-Convert website. Once I had an SVG rendering of each glyph, I used the IcoMoon font generator to package them all up into an icon font, which could then be exported as a WOFF font file.
With all of the assets assembled, the first step towards making a playable game was to develop a mechanism through which Mario could be moved. This was achieved with a set of radio input elements corresponding to the various locations in the game, each linked to a div , which rendered Mario , via a :checked pseudo-class and a general sibling selector. The currently selected radio button would thus control the position and appearance of Mario’s div .
Navigating through the game could be accomplished by clicking on a label that targeted the radio button of the intended destination. When in position one, a label beneath the right arrow would target the radio button for position two. In position two, the label under the right arrow would target position three, while the left arrow targeted position one. The appropriate labels were activated via the currently selected radio button, in much the same way that Mario was positioned.
Simulating the barrel movement was somewhat easier. Each barrel location could be represented by a div with an appropriate sprite that turned on and off in sequence using a CSS animation. To keep things simple, the speed and frequency of the barrels never increased, nor did they stop on collision the way they would in the original game. This enabled the use of a finite set of keyframes which simply repeated forever.
To avoid a lot of repetition, most of the barrel locations shared the same set of keyframes, just with a different animation-delay on each of them. The top screen was a little more complicated, because the barrels could follow a number of different paths, but that still just meant an additional four keyframe sets. One of these low frequency sets was also shared by the iron girders moving overhead on the second level.
Detecting when Mario had been hit by these barrels was a little more complicated, though, since now it was necessary for the game to trigger a change of state, rather than simply responding to a player action. The way this was accomplished was with a kind of mechanical key constructed from a stack of floating div elements – these div elements were the teeth of the key and would push out a block of content aligned to the right of them.