|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
What Went Wrong
1. Production manager: the role that wasn't. As I mentioned earlier, we didn't entirely realize the scope and enormity of the game until well into production. I thought I could juggle the dual role of producer and art director, and thought we could do it without a production manager. Hindsight being 20/20, not hiring a production manager was one of my biggest oversights. While I had a great production assistant, she had no experience in scheduling or managing a team. Balancing the often-conflicting roles of art director and producer didn't leave me enough time for micro-managing the production schedule. While I was attending usability tests and design meetings, production problems such as render problems due to lack of server space, version control issues, scheduling of changes and redos, and technical problems, all fell on deaf ears. This led to a much-understood level of frustration within the team. Luckily for me, my lead animator and lead programmer took on more of a management role and my production assistant put in some very long hours. In retrospect, I would hire a production manager to come on immediately and work closely with me in managing production. 2. Navigation -- learning from the competition. When we initially did our research on kids' games, we noted that many of the games navigated left to right. This seemed somewhat repetitive and predictable. We felt that the navigation could be a lot more interesting so we designed our navigation to use both the x and the z axis. We carefully built screens so that the background plate could be switched depending on which way the child was travelling. We didn't test the navigation until late in production and didn't realize there was a problem until more than half the screens had been modeled. The core issue was that children didn't understand that when they clicked to go back on the Z-axis screens that they had turned around. We changed the way navigation worked and used a back arrow instead of a curly arrow. When the child clicked to go back they were brought back to the previous screen, but facing the same way.
Another issue was that mixing a left/right navigation system with an up/down navigation was confusing. The child would click up to go forward for three screens and then have to click right to go forward. This proved to be a real problem until we placed signposts on the left/right screens and masked the paths so that the child understood where to click. The map also proved to be a major point of discussion. Initially we had planned to have the map areas activated only after the child had explored the area. However DK wisely suggested that if there was any confusion with navigation, we needed to make the map available at all times. We changed the way it worked and although some children will miss the roadside puzzles and play animations by jumping around on the map, the child will never be lost or feel stuck. Ultimately all our navigation problems were solved, but as we discovered, we had a lot to learn from our competition. 3. Audio: too many cooks. Early on in preproduction our audio designer's band was signed by a major record label. He trained up a new audio engineer and left to tour with his band. The new engineer recorded the actors and commenced editing the voice-overs. Guide tracks were sent over to the animators and animation began. However before we could start the final edit, the new audio engineer resigned. With just days to find an engineer, we tried every agency in town. We had actors booked for pick-ups and no one to record them. Finally, we found a young audio engineer keen to take on the job. He assured me he understood the system and we proceeded with the pick-ups. The recordings went well, and final editing began but seemed to be taking a long time. Eventually, the audio engineer admitted that he was completely overwhelmed. He hadn't been able to find all the files and was having a hard time getting the equipment to work. As each day passed and the schedule started to slip, I began to panic. Luckily our original audio designer was able to free up some time and he joined us full-time for a few weeks. We ended up releasing the other engineer and finished the job with our original audio designer. The moral of the story is twofold. Don't hire someone you have to train in the middle of production (if you can help it), and make sure your filing system is clearly documented. We lost countless hours searching for files or redoing files that had already been done at least once before. And for my part, in future I would lock down the audio engineer from the start and would budget and schedule as much audio time as possible. Audio adds so much to the experience of the game and should never be underestimated. 4. Programming overload and sticking to the plan. Like so many of the "What Went Wrongs," programming suffered from an overly optimistic schedule. As we came out of design block with our activities prototyped and our storyboards mapped out in a director shell, it seemed all the hard work had been done. We were confident the navigation worked, the activities and puzzles were solid, and now it was just a matter of dropping in the art. Of course, nothing is ever that simple. For a start, we had not considered the implications of having on-screen characters host activities and the amount of animation and dialogue that would be involved. We also didn't realize that having an on-screen character hold the jewel meant that programming needed to track every iteration of the game state for that character and all the movies involving that character. It was certainly doable but put a lot more pressure on the programmer and the delivery schedule. While the usability tests were incredibly useful, I hadn't scheduled for the changes resulting from the tests. Issues such as navigation ate up a lot of time, and of course the activities involved a lot more than "dropping in the art." On top of that, we had decided we didn't need the second programmer we had budgeted for and I reallocated the budget to 3D. This was probably one of the biggest miscalculations we made. By the time preliminary bug-testing had started, our lead programmer was putting in huge hours and was exhausted. We brought on two short-term programmers but it was too late for them to be really involved. Thankfully, the title was very robust and our bug list was relatively small. In the end, the programming was completed on time but the last three months certainly could have been a lot more fun for our lead. The lesson learned here is that if you've budgeted and scheduled for a second programmer, then there's probably a good reason you did so. Don't change it in the euphoria of design block. 5. Bug-testing: the importance of scoping. We have a good relationship with the Australian Multimedia Testing Centre and felt confident that we were all on top of the testing schedule. However, once we delivered our first candidate and testing brief, they realized that their time estimate would only allow for 75 percent of what the product needed. They had miscalculated the time and resources needed to test a game of this scope. Because of this, the testing center had to put in a lot more days than they had planned. We had to renegotiate the budget and they covered most of the overage. We all agreed that next time we needed to be more specific about the scope of the game, what role the testing center would play, to what level they should feature-test, and how many days we should build in as a buffer. We had a very productive debriefing, and thankfully the title was extremely solid. In addition, DK was doing parallel testing in the U.K. and we needed to synchronize our testing reports. We had decided that DK would focus more on configuration testing and that our testers would focus on feature and performance testing. Unfortunately, the parallel testing soon fell out of synch and the schedule fell behind. This was probably the only time that the distance and time difference became a real issue. Next time around I would be a lot more conservative in my testing schedule estimates and build in more time if coordinating with an offshore testing facility. ________________________________________________________ |
|
|
Features
