Mobile Postmortem: Bill & Ted's Excellent Adventure

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.

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.

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

What Went Right

1. We got the dialogue right

This title had more text in than any mobile game we'd ever developed. 500-600 lines of text may not sound like much, but it was enough to eat up a healthy chunk of the space we had available. Still, we thought that a good amount of text was essential for this sort of game - there's nothing worse than characters that only have one line to say, or re-used stock phrases that make all characters sound the same. Therefore even when space got tight, we tried to keep text-chopping to a minimum.

Given how much text there was, we were very pleased with how well the dialogue managed to capture the spirit of the movie. Despite having to work with tight constraints (some handsets could only display a handful of words at a time and we didn't want to make the player click through too many pages) we managed to differentiate both the characters and the levels. We found it very helpful to have a strong concept in mind for each level - rootin' tootin' gosh-durned chatterin' in the Wild West, for example, and highbrow scholarly talk in Ancient Greece. Once we had this baseline, it was fairly easy to give each character a unique voice - the aging miner, the nervous sheriff's deputy, and so on.

Bill and Ted needed a different approach. We knew that we wanted to include the sort of clueless, spaced-out exchanges that made the movies famous without simply ripping them off. By watching (and re-watching, again and again) the movies, we managed to lock down the feel of the dialogue and then write our own sequences to match.

To reinforce who you were speaking to (character sprites were very small on some handsets) we used a color-coded text box system. Pink and blue might be a cliché, but it works. We also included separate music for male and female speakers, and sacrificed some precious screen space to display the character's name. These steps made things much less confusing when you were paging through some of the lengthier conversations.

2. Puzzle creation was easier than expected

Going into this project, we had some concerns over exactly how we would design complex sliding block puzzles that were sufficiently tricky but solvable. While all of the team had played similar games before, none of the designers had designed this sort of thing and we did wonder whether we'd be able to come up with enough puzzles at the right level of difficulty.

We found, though, that once you get used to working backwards from the solution, the puzzles come together quite quickly. We came up with a number of mini-mechanics - sub-tasks that can re-used for different puzzles. These let the player build skills and break the puzzle down into elements, which makes it possible to create larger puzzles without overwhelming the player. We were inspired partially by Lemmings, which used the same trick - you learn how to build your way out of a pit, then later use that as part of a larger solution. In Bill and Ted, once you learn the technique of getting a block away from the wall by pushing it from the doorway, you start using it automatically.

Balancing the puzzles was trickier. We wanted a range of difficulties, from puzzles that you could pretty much do first time after a bit of thought, to those that would take several attempts (or a great deal of thinking and planning). Some of this was predictable based on the size of the puzzle - the more blocks, the harder it was. We could also make puzzles harder by combining more techniques: in this puzzle you need to build a bridge over a river with wooden blocks, then use stone blocks to fill a hole, then use the second character to stop a skidding block you've pushed with the first, then finally send someone through a doorway to push the block away from the wall to slot it into place. To save on QA time, we drew up solutions to all of the puzzles. While we wanted our testers to solve the puzzles in the same way players did, we also didn't want puzzles to take up inordinate amounts of testing time. This way, QA could play puzzles as a player would to discover the solution "honestly", then use the diagrams we provided to speed through puzzles when checking them for bugs.

3. We managed to make the game replayable

Despite the expected scaling of the game for different platforms, we found we were able to include both bonus levels (time-limited, "run around and pick things up") and hidden levels (comedy skits based on famous dates, found by entering a year in the game's phone booth). We've learnt that replayability is very important in mobile games. If you're stuck waiting for a train and all you have with you is your phone, you really appreciate games that let you go back and milk another hour's play out of them. We made sure there were unlockables (such as downloadable ringtones and wallpaper) for players who achieved high scores on all of the bonus levels and crammed in as many famous date skits as we could to encourage players to wrack their brains and experiment. By setting a roughly 80% completion quota for each level, we also made sure that there was plenty of mileage in returning to levels you'd already completed. This had the added benefit that getting stuck on a single quest or puzzle never meant that you couldn't finish the game.

4. Our GUI idea worked

One early idea was to avoid the usual text-based, list-style front-end and go for an "in-game GUI" where the player walks around a level to pick different options. We had three aims in mind: to steer away from the norm, to get the player straight into the game and to teach non-gamers how to move around without forcing gamers to sit through screens of instructions.

We had to prototype the idea early on to prove it to the publisher and the layout needed to be rethought a few times in order to fit everything onto the smaller handsets, but ultimately, it proved to work. Now the first thing players see when starting the game is an on-screen character and "2, 4, 6, 8 to move". As soon as they press a button, they're into the game and controlling the character.

5. Despite misgivings, the editor/scripting combination worked well

Our in-house 2D editor had been serving us well for some time, but we'd never used it for anything as complex as this. In Judge Dredd, we'd just had to place enemies and script basic behaviors. Now we had to set up multi-character quests and cope with players doing things in the wrong order.

The solution was to split the task up. The placement of objects and characters remained in the editor, but we came up with a new scripting system that let the designers create quests in the localization text file itself. This had the bonus effect of keeping the scripting information and the actual text together - it's much easier to decipher buggy quests when you can see what the character's saying alongside the logic he's using, rather than having to look up what text string L321 is. We were also able to easily tag characters as male or female (this influences their responses to Bill and Ted - Ted's better with the ladies).

Meanwhile, the 2D tool gave us what we needed to set up the puzzles. Being able to switch on and off different layers so that we could see what was underneath a block or pickup was essential. More automatic error-catching - such as preventing pickups and blocks from being placed on the floor layer - would have saved some time.

What Went Wrong

1. Getting Bill and Ted Right

It may have been inevitable, but working with a valued licence meant that it took a while to get both the look of the two lead characters and their actions right. The on-screen sprites were tiny and our artists did they best they could with the small amount of pixels available, but it was still tricky to find something that both we and the licence holder were happy with. We tried a few different styles before settling on a cute, cartoon look that seemed to work well. By concentrating on the key elements - the hairstyles, the clothes - we managed to make the characters recognizable.

Another problem was recreating the feel of the movie, in terms of the sorts of quests the characters went on. The licence holder didn't want Bill and Ted to do anything that was actually illegal, for example - so a quest to help a prisoner break out of jail had to be scrapped. Once we understood what the licence holder wanted, everything fell into place, but we could perhaps have saved some time through a face-to-face meeting (as is common in this kind of project, we never met any of the parties involved).

2. Reworking of levels due to changes in the way vehicles worked.

We knew early on that we wanted to include vehicle sections that would play like a vertically-scrolling shooter canyon level, with the player guiding a horse, a log or the Wyld Stallyns van around obstacles while picking up items. The levels were designed with long vertical sections to cater for these sub-games.

Unfortunately, the vehicle code was one of the last big chunks of work to go in. Once we had the vehicle sections working, we found that they weren't as playable as we'd hoped. Although our flagship platform had a portrait-shaped screen, once this had been squared off by the in-game status panel the argument for having the levels run vertically disappeared. Worse, some of the lower-end handsets didn't give enough look-ahead room due to their small, landscape-shaped screens. There was nothing for it but to rework the levels to make the vehicle sections run horizontally. Luckily we'd tended to place these sections on the edge of the level rather than running them through the center, but moving them still meant repositioning much of the scenery, puzzle blocks and pickups. We ended up with vehicle sections that played much better, but prototyping the gameplay earlier would have helped.

3. The levels ended up with differences in feel

We allocated each of the levels to a designer. This had its advantages - it made for more ownership of the work and it made bug-fixing much more straightforward since only one person needed to have a level file open at a time. However, it meant that the levels varied quite a bit in terms of approach. San Dimas and Wild West were quite quest-heavy, while Ancient Greece and Medieval France were more puzzle-oriented.

Originally this was intentional - we wanted each level to feel different. But once we realized we'd have to drop some levels on some platforms, we tried to provide more of a rounded experience on each level. We did manage that, but not to the extent we could have done. Although there are plenty of puzzles to be found in San Dimas, it still has a different feel - puzzles are something that you do for a specific reward, whereas in Ancient Greece you face puzzles in almost every room. We should have all reviewed each other's levels while they were being built and agreed on some rules of thumb.

4. Our level layout could have been more efficient

The levels we tackled early in development were planned as streets with defined streets, alleys and buildings. This gave everything a clear, navigable feel - the saloon is second left past the sheriff's office and so on. But we found that this approach had its disadvantages - when viewed on a small screen, any large open space (such as areas of grass between buildings) becomes a featureless plain that's confusing to play in.

Later levels - such as Ancient Greece - went to the opposite extreme, winding corridors around rooms and keeping the room size down. This solved the first problem - now it was easy to get a feel for which way you were moving. But it introduced another - now it was tricky to find your way into a room that you could see just a few tiles away because the route to it was so intricate. There was a sweet spot to be found between these two approaches, but we didn't quite find it. While all the levels ended up being playable, we could have improved the result by blocking the levels out roughly first and playtesting them at that stage.

5. We were bitten by flaws in our game logic

Towards the end of development, we started to come up against issues we hadn't seen coming. The problem was the complexity: the player can switch control between two characters, move objects around, pick up objects and unlock doors, then use the "Don't Fear the Reaper" option to call upon Death to restart them from the last doorway they passed through. We soon discovered it was possible to get into a situation whereby a vital key was trapped on the wrong side of a door, leaving the player with no way to get out of the room. At the same time, we couldn't simply reset the game's status every time the player restarted - it would get incredibly frustrating if you solved a complex puzzle to open a door, went inside the room, died and then had to solve the whole puzzle again.

We managed to solve the bugs with a battery of new rules for loading and saving that gave us easy restarting for the players but bombproofed the logic so that they couldn't become trapped. We were lucky - we could have easily had to unpick a lot of code to solve the problems. To avoid this, we should have worked through plenty of example puzzles on a whiteboard before coding started - "What if I do this, use the key, open this, change character, die, then there's a block on my restart point so I can't restart there?" This would have ensured our system was bombproof to start with.

Conclusion

Overall, the team was very happy with what we achieved. In a short time and on a tight budget, we'd moved into a new genre for us and delivered what we think is a genuinely fun game.

We'd definitely use the same set of 2D tools again. Combining scripting with text assets is a strategy we'd recommend - it feels much more natural to designers than splitting the two up. However, be warned that you'll need to think carefully about how you'll handle localization if you use this method - script tokens in the text may confuse translators.

Bill and Ted is being released for a wide variety of handsets as you read this. We'd definitely consider doing a sequel - there's plenty of potential for more time periods (Vikings, Pirates, Cavemen, the Future.). The engine has proved itself, so another possibility is an arcade adventure with a different setting/licence, or to expand the system to form the basis of an RPG. Much of this depends on how Bill and Ted sells. Meanwhile, the team has moved on to a variety of other mobile projects (different genres again), working with different licence-holders.

Party on, dudes!