[This article can serve as a companion piece to Jonathan Kromrey's “A Day in the Life” development diary of the original 24: The Mobile Game that appeared on Gamasutra in February 2006. This is Part Two, discussing What Went Wrong.The first part of this article, discussing What Went Right, can be found here.]
What Went Wrong
1) Behind the Single Stage Curtain
By focusing down the story, characters, and mini-games into a single location at CTU we were able to keep the player's attention on the "next" action without having to break his or her immersion and suspension of disbelief; however, having everything happen in one place also limited the "action" oriented possibilities of the mini-games. For instance, initially we had thought a helicopter chase sequence would be cool, similar to the fantastic car-chase sequences from the first game. But flying a helicopter within the CTU compound didn't make sense, and helicopters in general didn't fit with the story arc or as a repeated mini-game (if you've seen one helicopter chase you might have seen them all). Similarly, a drive-by shooting sequence sounded cool, but it posed problems if the player replayed it multiple times as the story progressed. In the end it simply came down to a choice of working within the spotlight we defined and choosing / optimizing the story, mechanics, and graphics to give us the best variety and fun factor when played over and over.
2) New Features Added at the Very end of Production
With exactly seven days from Gold Master we were informed of a need to support I-play's new lobby system. After picking ourselves up from the floor and telling the surrounding crowd and the ambulance drivers that we were all okay (really), Bruno Mateus, the Sr. programmer, looked at the code to see if / how / when it might be possible to implement. Fortunately the I-play lounge was created by our Technology group to support the functionality exactly the same as other carriers' game room environment - which we already had working well, and within a few days the new system was implemented and working. Whew!
3) Unforeseen Drawbacks to Original Design
A sordid side of mobile development is that there are different requirements and standards by mobile carriers (worldwide) in addition to different device key layouts which also vary depending on the manufacturer. So, to maximize the number of devices that can play our game, the application must be able to re-assign its control and soft-keys in order to meet submission requirements. To test all of these variables I-play has a hefty certification matrix, pre-certification process, and production-to-conversion-handover processes which all games must adhere to and pass. Puzzle games are easiest to get through as the gameplay is usually linear and the design rather straightforward. As with the first 24 game, however, we found that original titles like 24: AD created new Menu and game flow issues which broke the mold that hadn't been seen before in other, more simple mobile games.
In particular, it was late in our development cycle when QA pointed out that there were soft-key label cert issues with the main game Adventure interface - namely the "Back" key was located between the Talk and End keys on the phone, but not labeled, and functioned throughout the game to pause the application (but only at certain times and menus during gameplay). We faced the decision of either documenting it (which could potentially cause more issues as it was not "standard"), or simply disable it consistently throughout the game. We disabled it throughout so as to be consistent (which in a lack of specific rules, makes it easier to get past certification).
