Omelette Design Notes

Omelette was interesting to write. The technical side wasn’t too complex — unlike most “embedded” work, the Apple TV is a pretty robust base to build on — but from a design side, there were some challenges. I wanted Omelette to run as much as possible on a “vanilla” device: Omelette only needs a modified Apple TV because there’s no official way to install third-party plugins. In all other respects, it’s a regular Apple TV Appliance, it launches from the main menu, it relies on no other modifications, add-ons, peripherals or non-standard behaviour. I wanted to make something that would feel like a part of the Apple TV, like it “belonged” there.

From a graphical point of view, I was torn between making the game as flashy and glittery as possible, verses fitting in with the clean, understated tone of the Apple TV. In the end, I erred towards the latter, using the standard fonts and colours, designing the icons according to Apple Human Interface Guidelines, using the built-in sounds where appropriate (confirm, cancel, etc) and using animation to liven things up.

This actually worked better than I thought it would; I expected it to be too sterile, but the soft rhythmic sounds and animations are quite pleasing. The egg graphics themselves posed a problem: As I first designed them, they were more restrained and soothing, but the result was a nightmare: your eyes would glaze over, finding it hard to pick out patterns from the jumble of icons on the grid.

So I played with the colours, making them almost eye-burningly bright in places, and introduced extra details to help differentiate them, trying to give shapes as well as colours, which would also help colour-blind players: the star on the dinosaur egg, the burning spots on the phoenix egg, the stripes, the alien grunge, and so on.

(If you’re colour-blind, please let me know how you got on with it)

Of course, all this was after I’d come up with a game design. That was trickier. Although similar to some existing puzzle games, Omelette isn’t a straight port — it has its own small twists and turns due to the platform it runs on. For a start, the Apple Remote is quite limiting as a “game pad”. There are no analogue controls, just six digital ones, combinations of buttons are mostly impractical, and auto-repeat behaviour is quirky (it behaves differently horizontally to vertically).

All this made an “action game” awkward, simply because the player could easily end up struggling with the controls, rather than their decisions. There are still ways to do action games, and I’m mulling them over, but I wanted to start simple while finding my way around the new device.

One solution is a purely turn-based game, because then the speed of input isn’t a factor — you can take all the time in the world. So, I ploughed ahead with a “grid game”, getting pieces (eggs) drawn on the grid, a cursor hopping around under control of the Remote, and swapping them around. Then I added the line-detection, removal, and replacement code, with gravity pulling pieces down and causing chain-reactions.

The first time I got a chain-reaction going, the mental transition took place from, “Hey, I have some test code running on the Apple TV!” to “Hey, I have a game running on the Apple TV!”

But still, there was something missing. There was no challenge. In theory, the game ended when there were no valid moves you could make. In practice, this never happened. At the time, I only had five types of egg, so the obvious thing seemed to be to add a sixth type. More types of egg meant fewer of each type on the board, meant less opportunity to make lines of three.

So did this work? Find out in part 2…