Kuju Entertainment is mostly known for its PC and console titles (Microsoft Train Simulator and Firewarrior). In 2000, though, we set up a new division to specialize in games for mobile phones. Thanks to a strong business development team, we've been able to secure deals to develop games such as Crash Twinsanity and Judge Dredd. Most recently, a license-holder approached us with the possibility of doing a game based on the classic eighties movie, Bill and Ted's Excellent Adventure.

It was an easy decision to make. Bill and Ted is a great license - strong characters, high concept, lots of "texture" we could recreate within a game. A good sign was that pretty much everyone in the division remembered the movies - and if we did, then so would the game-buying public. Not the teen audience so much as the people roughly our own age - the twenty-something early adopters who bought higher-end handsets and also picked up earlier retro licenses such as Judge Dredd.

We couldn't ignore the more mass-market audience, of course. Therefore we wanted to create a game that would appeal to everyone, whether they'd heard of the movies or not. A 2D, Zelda-style arcade adventure/puzzler seemed a good match.

For one thing, slower-paced games tend to be a safer bet when developing for a large range of handsets (we try to cover as many of the mass-market handsets as possible. In this case, that meant 35 phones!) Many of these handsets have joysticks or d-pads that aren't ideally suited to games, while limitations such as no simultaneous keypresses (run and jump, for example) can make even simple action tricky.

Secondly, we wanted something that wouldn't scare off a non-gamer. Cute characters, bright colors and a relaxed pace would help to ensure that we appealed to not only the core of mobile gamers, but also to mobile users who remembered the movies and were perhaps trying the game for the first time.

Finally, we'd been wanting to do an adventure game for some time. In the past, the mobile division had had success with pure puzzlers ( Ambistax ) and driving games (Lotus Challenge) but this seemed like an opportunity to branch out into a new area. In terms of tools and experience, we had the advantage of already having a strong 2D, tile-based engine that we'd used on a number of games previously (including Judge Dredd, in which we'd opted for an isometric, Double Dragon-style view). Our 2D artists were adept at squeezing art into 32x32 tiles in Photoshop and animating tiny characters using an in-house sprite editor. Because mobile project development time is just three to six months, most of the team were veterans of at least a handful of different games across different genres. We were therefore more comfortable with trying a new genre than perhaps we would have been if we'd spent four or five years on - say - nothing but racing games.

The pitch process went very smoothly (though it took some time to thrash out the style of the humor - see below) and the licence holder had some excellent ideas of their own. The design we came up with was ambitious: the game would roughly follow the basic plot of the first movie while working in some of the ideas of the second. Bill and Ted would attempt to win a cash prize for best history project by travelling through time to various locations and persuading historical characters to accompany them to the future. Completing all of the historical levels would open up the present-day level, in which our heroes would have to complete more quests and puzzles to earn money. This money, together with the cash history prize, would let them enter the Battle of the Bands contest.

The game would be a full-on top-down adventure with quests, objects, block-pushing puzzles of different types, doors and keys, multiple controllable characters (an early decision was that the player had to be able to control both Bill and Ted), vehicle driving sections, bonus and hidden levels and lots and lots of text. All this across four large levels (San Dimas, Wild West, Medieval France and Ancient Greece) that, with the exception of San Dimas, could be visited in any order and freely jumped between (via a time-travelling phone box, of course). Our size limit? Between 64 and 200K, depending on handset.

We expected to have to make some cuts along the way. Certainly that number of levels wouldn't fit on some of the handsets, and it was impossible at the outset to say how many would. We therefore decided on a modular game design: with the exception of San Dimas, any of the other levels could be dropped as needed and the plot and gameplay would still make sense. The non-linear structure we'd come up with (jump around the rest of the levels to collect enough historical figures to access the San Dimas level) made this much easier - with a linear game design dropping levels might have been quite painful. Similarly, bonus and hidden levels were designed to be independent of each other and easily scalable.

We knew that we faced a number of hurdles, most of which come up with any mobile game.

Screen Space - Handset screens are increasing in resolution all the time, but it's worth noting that they aren't actually getting much bigger, and a tiny screen with a high resolution is still a tiny screen. Also, we couldn't just support the larger screen sizes - we had to support all of the common handsets, and some of them had very limited resolution (a game area of 90x40 pixels in some cases). A small screen is bad enough when you're playing a scrolling shooter or a driving game, but how do you solve a puzzle when it's spread over four or more screens?

We came up with a look-around function. By pressing the # key, you would be able to disengage the camera from tracking your current character (Bill or Ted) and freely move it around the world with the movement keys. Another tap of # would end look-around and scroll the camera back to your character.

This made puzzles that stretched over multiple screens manageable, but we still had to be careful to keep the overall size of puzzles down so that the player didn't feel overwhelmed. Another trick we used was to use paths to guide the player between buildings and compress everything around the paths as much as possible - characters were placed next to doorways or beside paths, for example, so they'd be stumbled across even on a small screen as the player moved around.

	176x208? No problem.

	At 240x260 we have plenty of space.

A Non-Gamer Audience - There was a fair possibility that someone downloading this game wouldn't have played anything more complicated than Bejewelled before. Things that we gamers take for granted - like walking up to a character to start a conversation - would have to be explained. Preferably without screen-fulls of text that would slow the pace down for the gamers who would also be playing.

We therefore implemented a short but reasonably in-depth tutorial level. The first time the game is played, Rufus whisks Bill and Ted off to the future and shows them how to move, switch characters, push blocks, pick up a key, etc. Adding sufficient bulletproofing to catch anything strange the player might do took some time, but we ended up with something that only took a few minutes to play yet introduced every concept in the game.

	130x130 pixels is fine. Go down to 90x90 and we see less. At 70x70 things are a bit confined (and small). And at 90x40 you really need to use look-around.

With our initial hurdles planned around, we started development. Let's look at what went well and not-so-well.