Postmortem: Oz -- The Magical Adventure
By Jackie Turnure
Gamasutra
November 6 , 2000
URL: http://www.gamasutra.com/features/20001106/turnure_01.htm

Following the success of GMD's Bananas in Pyjamas PC games for children, we began looking for content for a new game. We wanted to create a completely 3D animated quest game marketed as a "kids' first adventure game". What we didn't realize was how much we were going to learn from the kids themselves.

From the beginning we knew that we wanted to design our own proprietary game but there was the issue of brand awareness. By creating our own content, we wouldn't have a brand that had a market presence. The solution was to adapt a classic children's story. We looked for an adventure story that had the right elements and was in the public domain. L. Frank Baum's The Wonderful Wizard of Oz fit the bill on all counts.

Initially titled The Mysterious World of Oz, we based our game narrative on the sequel to The Wonderful Wizard of Oz (the second of 14 Oz books written by Baum). A small team, including me, worked up a pitch document and we took it to Milia in February 1998. The initial premise was that the Scarecrow (now King of Emerald City) had been dethroned and the child had to reinstate him. The child had to travel around the four lands of Oz, trading for clues and objects that would be kept in an inventory.

At Milia we met with Dorling Kindersley, well-known children's publisher and international distributors of our other titles. DK was interested but concerned that the premise was too removed from the original story of the Wizard of Oz. They also suggested the inventory was too difficult for the target age range, and that should we lose the word "mysterious" in the title. After much deliberation and copyright searches, we decided on the title Oz -- The Magical Adventure.

We returned to the drawing board and revised the premise, adapting the original story to an adventure quest. We decided that the game should be approximately two hours' playtime, be played at one of three levels, and that the game state should be able to be saved at any point. We wanted the game to look and sound amazing, to have a real sense of a narrative, and to include activities that were original and challenging, activities which could be replayed for different rewards, ensuring the game's longevity.

We stripped back the four lands to three, and rethought the way the child would solve the quest. We discarded the inventory and replaced it with one object that showed progress through completion, in this case a medallion. Our final game narrative is as follows: Dorothy is kidnapped by the Wicked Witch of the West and imprisoned in the Witch's castle. With the help of the Scarecrow, Tin Woodman and the Cowardly Lion, the child must find nine missing jewels from the medallion that is the key to the Witch's castle. For each jewel, the child must play an educational activity. Once the child has all the jewels, Dorothy is freed and they return to Emerald City where the Wizard has a surprise for them.

We met up with DK again at E3 and repitched the game premise and preliminary sketches of our characters. We proposed making the characters junior versions of themselves so that the child would be playing with characters closer to their own age. DK liked our new proposal and negotiations began in earnest. It took three months to finalize the deal, and on July 1 we kicked off. My role was creative producer, a role that combined art-directing and producing. As was shown later, my dual role led to some interesting, often schizophrenic situations, usually involving arguments that I had to have with myself. But for now, it was a matter of putting together a team and creating a design document.

Design Block

The first phase of design was a ten-week period we called design block. The design team was made up of the executive producer, the lead programmer, and me. We quickly ascertained that we wanted Oz to be very different visually from other kids' games on the market, and that we wanted the activities to be well integrated into the story. We were determined to create a game that was educationally sound and entertaining, in an approach we called "play to learn."

For the next ten weeks, the design team met two to three times a week for brainstorming sessions. Meanwhile, I wrote the game narrative and briefed the scriptwriter. The lead 3D artist and the modeler/animators worked on preliminary character sketches, landscape designs, and animation tests.

From the outset, we wanted to create a look that didn't scream computer graphics but rather had a more organic, toylike quality. After looking at a lot of traditional animation, toys, and games, we came up with a stylistic approach that combined the texture and movement of claymation (such as Wallace and Gromit), the lighting and humor of Tim Burton's work (like The Nightmare Before Christmas) and the surreal qualities of Willy Wonka and the Chocolate Factory. We wanted the child to feel like they were playing with puppetlike toys that they could reach in and take out of the Oz world.

Because our production was in Sydney, and DK, our distributor and development partner, was in London, we needed to come up with a way to have reviews and sign-offs. While the distance didn't faze us, the time difference was a bit of a pain -- although in some regards it worked to our advantage. Between the distributor's U.K. office, U.S. office, and ourselves, there was always someone working on Oz, 24 hours a day. The first strategy we employed was to set up an extranet to enable DK to see our work in progress. Initially we put up the game narrative, style samples, character descriptions and sketches of the landscapes. Once these had been approved we put up 3D models and activity prototypes.

The extranet was a great way to showcase our work in progress but we needed regular communication. We set up weekly conference calls and e-mailed daily, making sure we confirmed all decisions and changes. Meanwhile, our lead programmer was creating programmer art prototypes of the activities, which we started testing on kids. We were surprised by the kids' clear likes and dislikes, even at this early stage of crude artwork (more on that under "What Went Right"). By the end of October we had a design document with nine leveled activities and five puzzles detailed and prototyped. We were in pretty good shape.

Production

However, we had not anticipated the enormity of the scope of the game that we had designed. This game was a huge departure from our experience on our other titles. Curbing feature creep became my priority, and as art director I was certainly a big part of the problem. Coming from a film background, I had worked with the storyboard artist to create sweeping camera moves, close-ups, and shifting perspectives. One of my first oversights was not reviewing the storyboards with the lead programmer before getting everyone excited about the shots. As we moved into production it quickly became clear that with our minimum specs and performance issues, there was no way we could have full-screen movies. It started to dawn on us why so many kids' adventure games are 2D.

The Echo Bird can have its title as a caption.

Feature creep was also an issue for our 3D team. Our character designer had a hard time not building characters for the next Toy Story movie. Texture and lighting details that were gorgeous in high-resolution blurred at our 256-color target and often dithered badly. We couldn't have large graduations and had to be careful with lighting glows. Anything that made our movies too big or that dithered badly had to be redone, leaving the team feeling disappointed and frustrated. We soon learned to run test dithers before getting too far along. Much of our morale problems came from the team having to scale down their expectations.

Next we needed to find the actors, and this proved to be one of the toughest parts of the process. I completely underestimated how hard it would be to find actors (animation actors, not radio voice artists) who could do an authentic American accent. Agent after agent assured me that their client could do a U.S. accent, and then they showed up at auditions and couldn't. We hadn't anticipated how long it would take to find the actors and then we needed to get approval from DK. I had not scheduled enough time, and because of the delay the character animation schedule ultimately fell behind.

As the animators began animating, our landscape designer was building sets and starting work on the activities. The landscape was something we invested a lot of time in and it paid off. We designed each land to be a separate part of the Oz world, with each land having its own climate, geography, industry, color, lighting design, and architecture. We wanted the child to have the sense of travelling though a world, not just around a neighborhood. The toughest part of the landscape was keeping consistency across the different modelers, as style guides are often open to interpretation.

At that point we seemed to have recovered from our scheduling delay, when we found out we were losing our audio engineer. Our main audio designer had left to tour with his band and we had been working with someone he recommended. Now he was leaving and I began to panic. Audio had been somewhat of a problem on Bananas in Pyjamas and I wanted to make sure it all went smoothly this time. We did find someone else but it didn't work out and it cost us a lot of time and angst (more under "What Went Wrong").

However communication was working well and weekly production meetings helped keep morale high. The DK producer came out for a week and was very impressed with the work to date. As we got close to Christmas, the game really started to take shape and we all took the week off feeling fairly confident.

The new year started well, and then programming hit our lead programmer like a tsunami. Like me, he hadn't realized the enormity of the game and he quickly became overloaded. We brought on two other programmers, but it was a little too late for our lead to totally hand off so it became a case of "it's quicker to do it than explain."

In addition, the executive producer injured her back and couldn't go to Milia. I went in her place, and while it was stressful being away from production, it was invaluable for understanding our foreign publishers' localization needs. It was also great to get such a positive reaction to our demo and we came away from Milia with presales to France, Spain, and the Netherlands, and a lot of interest from other territories.

As we neared the end of production, the music composition was finalized, packaging art was put together, and the localization kit was completed. We continued to test with kids and did bug-testing both in Sydney and London. The title appeared to be robust and the kids loved it. As the lead programmer moved onto installers and the audio designer did final mixes, the animation team started to relax. But there was one more hurdle just around the corner.

The Interactive Storybook

On the way back from Milia, I had met with Dorling Kindersley in London to review the demo. They were excited by the 3D graphics and came up with an idea to reuse the Oz assets to create a companion piece for the title. Based on the concept of a reader or book that helps kids to read, Oz -- The Interactive Storybook would be an animated storybook on CD-ROM telling Baum's original story of The Wonderful Wizard of Oz.

The logic was great -- we had the whole 3D team, the models, the programmer and the time to put this together in just 12 weeks. It certainly made sense from a marketing point of view but everyone was exhausted and it was a tall order to get the team to start on a new project. To everyone's credit, the companion piece is a gorgeous addition and matches the game in quality and depth. We just had to have a few extra milestone lunches to get everyone through it.

In the End

We finished up the adventure game and the interactive storybook, and all took a well deserved break. With plans afoot for the next classic adaptation in the adventure series, I returned in August to the news that Dorling Kindersley had been acquired and their games division closed down. We were horribly disappointed, but Oz is now in the stores and getting great reviews. The entire team is immensely proud of both titles and while there were a few rocky periods in production, to this point it's been a total success.

What Went Right

1. Design block; creating the blueprint. The design block proved to be an efficient and highly enjoyable part of the process. What started as ideas on Post-It notes quickly segued into rough storyboards and a game matrix. The matrix allowed us to view all the activities and puzzles together and make sure we had a balance (early mathematics, spatial relations, listening skills, and so on). We used a flowchart to map the navigation paths and number of screens. This was a good way to lay out our narrative, with the linear opening and closing sequences bookending our nonlinear core section. As art director and producer, I was often arguing with myself over more screens versus not enough time, but at a total of 88 screens, the game had a lot of variety and depth.

As we finalized our ideas, the lead programmer created crude prototypes which we tested on kids. It was incredible how little information kids needed to "get" the activity. It gave us a lot of confidence in the activities that worked, and glaringly showed us the ones that didn't. Doing early prototypes was probably the smartest thing we did in regards to design.

At the end of design block we had a comprehensive design document that contained the game narrative, character and landscape descriptions, style guide, technical specifications, activities and puzzles (including educational objectives and levels), storyboards, flowchart, activity matrix, and a map of Oz. The design document proved to be an excellent tool for the entire team and was also useful in securing our distributor's confidence.

2. Communication, or how we managed to overcome 10,000 miles. As the enormity of the task at hand dawned on us, communication took on even more importance. I needed to make sure DK knew exactly where we were at, that reviews and sign-offs happened on time, and that any changes were incorporated back into the schedule.

The extranet and daily e-mails made communication with DK easy and relatively stress-free. They had nominated one of their producers as our point person, and as we needed sign-off from both the U.S. and the U.K., it was much more efficient to deal with one person. The producer and I spoke on the phone every couple of weeks and he came out for a week in November. I went to London in February and it certainly helped meeting face to face. While the time difference was sometimes a frustration, in general the distance wasn't an issue, and the experience was a professional, highly satisfying partnership.

Communication also ran exceptionally well within the production team. We had weekly production meetings which ran from 15 minutes to two hours, depending on the needs of the production. Sometimes it felt like we didn't have enough time, but it was still important to get together in a room, even if it was just to talk about the weekend or discuss our personal frustrations. In addition, we set milestone goals that were celebrated by lunches out together. Again, it was tempting to keep working when we were in crunch mode, but the morale boost was well worth the time away from the project.

3. Usability testing; trusting the kids. We started usability testing with kids right from the beginning. Programmer art prototypes were shown to various children from the target age range, and we had a mix of boys and girls with different degrees of computer literacy. One of the joys of working with children is their absolute candor. They made it very clear when something was boring or "lame," and could quite eloquently explain why they liked some activities better than others. We were often surprised by the results, but knew that we had to trust them.

One of the most interesting experiences lay with our Itchy Bug activity. This game involves spotting the difference between fruits on a tree. Four of the fruits are identical, but one is actually an itchy bug. Children must look closely at the lines and dots on the fruit to determine which one is different. When we tested this game, children liked it but found it too easy. However, adults found it quite difficult. We tested various iterations, and ended up going with a version that, at the hard level, had only a one-pixel difference between fruits. Children loved it and found it challenging, but when we bug-tested the product we were told there was a problem, as all the fruits were identical. In fact they weren't, it was just that the adult tester couldn't spot the difference.

The Viewing Tower can have its title as a caption.

We continued usability testing throughout production. One of the smarter things we did was to write down the audio prompts that worked best, and in later reviews, to test out the prompts we planned to record. This saved us a lot of unnecessary rerecording and gave us the confidence that the prompts were the right ones. During each usability test we would take notes which would be compiled into a report. We would suggest actions based on what we saw, and the executive producer would decide on which actions to take. Every single usability test raised new issues and illuminated problems. This is one area we got right and our feeling is that one cannot test too much.

4. Knowing our weaknesses and using consultants. In addition to our usability tests, we used educational consultants on both the game and the interactive storybook. While we liked to think we had a certain degree of expertise based on our previous experience, there was still a lot to learn. Hiring experts was definitely one of the smartest things we did.

Early on we brought on a children's television producer and adviser on our Bananas titles. He helped us a lot in understanding how children of our target age think and see. For example, we had planned on a camera angle that was almost a top-down view of the forest. He pointed out that children of this age have no understanding of extreme perspectives. They wouldn't understand that they were looking at the top of trees, but instead would see them as dark green clouds on a light green background.

Likewise, he caught a number of potential problems with the activity audio prompts. I had thought it would add variety to ask the same question in different ways. For example, in the Whirly Flowers activity, the child must learn the rules of which flower can grow next to another. We told the child, "Red flowers only like being next to blue flowers," and then, "Red flowers don't like yellow or white flowers." It was the same piece of information but having two prompts totally confused the kids.

Our scriptwriter had also had a lot of experience writing children's content for games and television. He was able to solve many of our logic problems within the narrative and was able to find humorous solutions for linking the activities to the central quest. For example, in the Water Pipes activity, he drew on the Wicked Witch's fear of water to set up the mixed-up water pipes. The result was twofold: it gave a reason for the game and also hinted at how the child could defeat the witch. In this case, his experience with children's television drama crossed over and enriched the game.

5. Localization: avoiding the nightmare it could have been. Having been through the arduous process of localization on our other titles, we were determined to be on top of localization from the beginning. Our experience on Bananas (distributed in 18 countries) combined with Dorling Kindersley's expertise meant we were off to a pretty good start.

First, we designed our characters to have what we called "Muppet mouth." Because one animation had to fit multiple soundtracks, and once localized had to fit another language, we didn't want to create real lip-synch. The advantages were many -- modeling was simpler, animation was faster, and at CD-ROM resolution and movie size, it didn't look too bad. We also wrote the script with localization in mind. Dialogue was always overwritten so that when translated into a longer language such as German, the dialogue could be cut down and still match the length of the animation.

We also had to pay attention to fonts and live text within the game. We wanted the child's name to appear at various places in the game, including on the back of the boat in the lake scene and on the Order of Oz certificate. We needed to design the live text areas with flat perspective and build in enough space for long names. Likewise, we needed to provide layered artwork with all embedded text on a separate layer.

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.

Water Pipes - Find a path for the water to flow through the coloured pipes to receive a red jewel

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.

Moving Forward

Like all projects of this magnitude, the real skill is learning from our mistakes and being able to apply the lessons learned to the next game. Feature creep, scheduling issues, navigation problems, and audio were our biggest challenges, but were all resolved and only served to strengthen ourunderstanding of the process.

For me, the best part of the project was experiencing how kids play and learn, discovering what makes them laugh, what bores them, and what they like in a game. Adapting a linear story to an interactive game was very challenging and satisfying, as was creating a 3D world and characters that children could relate to and enjoy.

Ultimately the real test lies with the kids' reactions. Watching our kid testers laugh and talk to the characters on screen made all the production problems worthwhile. Moving forward, we all hope to apply our experience to another adventure game sometime in the near future.

http://www.gamasutra.com/features/20001106/turnure_01.htm

Copyright © 2003 CMP Media Inc. All rights reserved.