Postmortem: How Puzzle Quest Saved Infinite Interactive

Completing Gamasutra's best of GDC 2008 series, Steve Fawkner, president of Australia's Infinite Interactive, discusses the development Puzzle Quest: Challenge of the Warlords, giving insight into the melding of both match-three puzzle and RPG gameplay elements to appeal to both casual and hardcore players. Steve Fawkner began by introducing Puzzle Quest as a project that Infinite Interactive had to start to get themselves out of trouble after a significant period of poor decisions and low-selling games. The project had to fulfill several criteria: it had to be possible to execute with a small studio and it had to be possible to pull off in a short time with a reasonable number of staff. They examined trends in PC gaming and decided to look at where the industry was heading. They concluded that games were simultaneously heading in a more casual direction as evidenced by the success of PopCap-style titles, and still held a strong beachhead with more traditional core RPG-style titles such as Elder Scrolls Oblivion IV. They decided to aim for something in the middle. This choice seemed to fit the core competency of the studio: delivery of a focused project with a core mechanic of fun, easy to learn game play. When they looked at the staff they had at their disposal, they found that most of them were designers. No artists, no graphics programmers, just a few designers with some basic programming skills. This lead to executing a game that was pretty heavily design-focused. They decided to apply their usual approach of iterative design, following the four word mantra: "Clear Goal, Loose Plan." So they knew where they were aiming, but weren't quite sure how they were going to get there. Their faith was that if they began development, in the process of iteration the game would become clearer and clearer as they went along. Iterative Design The inception of the game concept was a "happy accident" caused by the process of iterative design. Steve started his plans with the ideas that he really liked Bejeweled and he really liked RPGs. Putting the two together seemed to result in a style of game that landed in that sweet spot the studio was aiming for, and seemed to be something compelling enough to play. He made a few versions that "sucked," and fixed those up over a month-long period until he ended up with something that "was pretty cool." Even at that point, the studio knew they had a game that would work. Infinite Interactive fleshed out Steve's early prototype to get it to a stage where they could show it to some potential publishers. Once the design was stabilized enough, they threw out most of the code and started to build it up from scratch with a reference version to keep them honest. This is the "Design and Review" process where the studio compares where the game is to the original prototype and they examine if they are straying too far from the original plan. Of course, straying from the original plan can be healthy. But at times, they decided that it was better to keep to the simplicity of the original design. Next, they had an honest discussion at what core skills they could bring to the game. They knew they weren't good at art, they weren't going to be able to port the game efficiently to other platforms, and they also knew that Steve couldn't negotiate a business deal to save himself. Even at that early stage, they saw the potential appeal that art direction could add to the game, they identified that publishers would probably want to port to other platforms, and they hired an agent to represent them in their business deals. The last piece of the puzzle was to leverage their own original IP: until the game was close to publication, they called it Warlords: Champions. Although the name was never meant as anything more than a placeholder, it got them through to a stage where a publisher was willing to pick it up and back it properly. Selling The Game The next part of the quest was shopping the new game around. Infinite Interactive really wanted to build more presence on the handheld platforms -- the Nintendo DS and the PSP -- as well as gain some presence on the downloadable console space such as in the Xbox 360's Live Arcade. In order to gain a foothold in these new territories, they really needed help from a publisher. So they started showing the game around. Steve explained that having an innovative product can sometimes make the pitch process even more difficult because publishers like to be able to predict how many units they will move prior to backing a title. As an example, he noted that they tried to sell the game to an unnamed publisher who loved it, but wouldn't pick it up. As the pitch process went on, they started noticing that several names on the net play high score list always came from this particular publisher. So when they called to follow up, they were told, "Oh, we really love the game. So much so, that we decided to start a high score leader board. But we still won't pick it up." Eventually, Infinite Interactive hooked up with a like-minded publisher who saw the potential for the game -- D3 Publisher. From the start, the project incurred a lot of risk. But the way to mitigate the risk was to outsource pieces of the project properly. From the start, Infinite Interactive handled the PC and Xbox Live SKUs. D3 partnered Infinite Interactive with Vicious Cycle who provided artwork as well as the PSP, Wii and PS2 versions, and with First Playable and Engine Software who did the DS port. But outsourcing is only a good short term solution. Although it allows for rapid release of multiple SKUs, all of the work produces no licensable technology for the primary developer. The way to handle these shortcomings is to have an extremely polished design and front end so that the back end development is mostly porting the technology to other platforms. Meanwhile, Infinite Interactive was hard at work trying to hire a team to develop their own in-house proprietary engine technology. It wasn't long before things started going wrong. Project Hurdles Code Portability The team had not worked on very many platforms other than PC and some playing around on PSP. In the case of the Nintendo DS, as good a platform as it is, code portability between the DS and the PC isn't that transparent. For example, standard list implementation isn't very good on DS. So for these cases, the programmers had to work on their own technology to overcome those obstacles. System Constraints Back in the days when Infinite Interactive used to work on 640k DOS machines, the team was used to running out of memory and having limited graphics power. But on more current platforms like the PSP and the DS, they started running into custom limitations in graphics power, stack sizes, and even Read/Write limitations with UMDs on the PSP. On the DS, the team was so inefficient with their code that screen refresh used up all of the available memory. The lesson is that programming on modern PCs will make you lazy. Cartridge Sizes Committing to a cartridge size with a publisher isn't one of those things that you can take back later. 4K is four kilobits, not 4 kilobytes! So when the publisher asks how much storage one needs for saved games, there is a pretty substantial consequence to changing your mind down the line. On the PC, the saved games were 14K. The team had to compress the 14K into 200 bytes in order to fit their storage requirement. Eventually, they were able to squeeze two saved games into 512 bytes. But it cost the team somewhere between two and three months. Accessibility Complexity The team had scheduled three months to accomplish the Xbox 360 Arcade port. The implementation actually took them 6 months because of TCR accessibility implementation issues. As a word of advice, Steve recommends that developers who plan on doing multiplayer implementation on modern platforms get a hold of the TCR checks as soon as possible and read them thoroughly. If possible, talk to a QA team that deals with these issues on a daily basis and run multiplayer screens by these teams as soon as possible. If Infinite Interactive had the foresight to do that, they would've saved themselves a lot of time in the multiplayer implementation. Localization D3 set up the focus testing, which actually uncovered a wealth of useful information. First of all, the team found that the name of the game, Warlords: Champions was reminding people of a fighting game. So as a first response, Steve came up with Puzzle Quest. No one liked it at first, but the name soon grew on them. The second finding from the focus groups was that girls weren't happy playing the game. All of the women asked, "where are the female avatars?" This was done purposefully to save on localization expenses. But when they ran the numbers to add the female-centric content against the potential increase in sales, they decided to pull the trigger. As a result, Puzzle Quest had too many words: over 100,000 of them! By adding dialogue for the female avatars, the team ran into gender issues in French, Italian, German and Spanish translations, and with the Japanese language, the team didn't realize that the form of the language changed if a speaker was older or younger than a listener. So now, rather than only having to worry about male and female issues, they had to translate old female to younger male, and every other permutation. The lesson learned was, if one can hire staff that speaks other languages, go ahead and do so! Session Takeaway Things learned * Time spent polishing is time well-spent. The extra time spent certainly resulted in additional sales. Focus and usability testing makes a difference. * Good design is still important: A graphically simple game can still sell quite well. * Focus groups are awesome: the title change, the addition of female avatars, and the shifting of the style to something a little more anime in execution all turned out to be great changes. * Good QA teams are even better than focus groups: even though a few bugs slipped through, a solid QA team really helps. Improvements for next time * Work more closely with marketing to maximize how many games are sold in to the stores. This can be done by identifying whether the game has an instant appeal. * Work with marketing to deal better and smarter with the press. * Make sure the game is nice and showy to ensure that the press doesn't have to spend hours trying to find the most appealing parts of the game. * Improve the build pipeline to minimize production times and bugs. * More respect for what the casual gamer really wants. * Some of the standard RPG conventions were absolutely mystifying to casual gamers, such as matching purple gems to level up.