     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Mobile Postmortem: Bill & Ted's Excellent Adventure 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|