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