The scary missteps that plagued the Kinect-exclusive Haunt

With so many parties involved, it was hard to maintain a coherent vision for Haunt. In effect, we had three creative centers—us in Tokyo, our publishing team in Washington, and the Zoe guys in the U.K. One of NanaOn-Sha’s guiding philosophies is that in order to have games with cross-cultural appeal, you need to have staff from different backgrounds (PaRappa's character designer was American, as was the lead programmer for Vib-Ribbon), and this project certainly fit the mold—indeed, it was our most ambitious yet in terms of multinational collaboration. Of course, this approach isn’t without its downsides. Haunt’s development was anything but smooth sailing, and we faced creative disagreements at every milestone. This may sound like more hassle than it’s worth, but we really believe that creative conflicts are a great way to tease out unique products with that elusive “universal” feel. Also, we had been reading a lot of articles about failed collaborations between Japanese and Western studios, so we were determined to prove that when done correctly, a multinational partnership can make a game better. From a practical perspective, there were several things that helped us pull this off. First of all, we hired a Japanese-English translator who translated almost all of our email into each language for the entire project. This meant staff wouldn’t lag behind on certain issues, because they wouldn’t have to read in their second language. Second, we held frequent video conferences, because face-to-face contact helped ensure subtle things didn’t get lost in translation. We also visited Zoe Mode whenever possible to make an effort to get to know each other and understand our cultural differences. Finally, we made sure that we “clicked”—if you don’t have good chemistry with your partners, it’s harder to keep everyone on a unified course.

There was one point of contact at Microsoft, Zoe Mode, and NanaOn-Sha, and generally this worked well. Having one point of contact helps to focus discussions, but sometimes it would clog up development. We would get feedback from our publisher’s top-level management, but by the time it had reached the coder or artist responsible for the implementation, it would have gone through up to five middlemen. This led to a feeling that the feedback was practically an order, rather than a suggestion or topic for debate. In the other direction, when we had to explain certain contentious development decisions—such as our choice of navigation system—we were never really able to take full control of the issue, and subsequently no parties ever felt satisfied. This was compounded by several management changes at the publisher during development, many of whom we never had an opportunity to meet with, speak to, or even email directly. We had to re-justify our navigation system decisions several times during development, but even then we could tell that the top brass weren’t satisfied. Having to repeatedly make the same arguments proved to be a real distraction, and there was a real sense of frustration and helplessness about not being able to control our vision. We should really have flown to the publisher HQ to communicate our vision and passion for the project and just hammer out these differences, but in the end we never visited and instead these troubles festered throughout the latter half of development. Our failure to resolve these differing opinions on the navigation system really shook the publisher’s confidence in the project, which ruined any chance we had of getting marketing support at launch.