In a recent conversation, someone asked me a question I had never heard before - “What is your favorite failure?” Over the course of a long career in game development, I’ve made a lot of successful games. But I’ve also made a number of unsuccessful ones, and even some that never saw the light of day. So having nearly 30 years of experience to think about gave me a lot to digest.
After reflecting on the question for a few days and reviewing the various failed projects I’ve worked on, there was one in particular that stood out - both for the reasons for its failure and the lessons I learned from those going forward.
Back in 2003, I had founded and produced and designed the first few games for Pogo To Go, Pogo.com’s downloadable PC game channel. Some of those games were modest successes, some were hits, and some were misses.
There was enough going on in the business to justify a couple of new hires so we could release more games, so I expanded the team with a pair of producer/designers. One of the new hires had come out of the edutainment industry and didn't have a strong background in pure gaming.
Around that time, we had been talking about making a version of
Puzzloop, a simple puzzle game where you shoot colored balls into a spiral to make matches. We talked to a number of developers, and settled on a new team that I hadn’t worked with before, but who had done a number of games for my previous employer, The Learning Company.
Before we kicked off the project, we wanted to give it an innovative twist. Around the office, we had been playing an emulated version of an obscure Japanese arcade game called
Money Idle Exchange. This was a more complicated puzzle game that involved pulling coins down from a grid then tossing them back up to merge them into coins of higher denominations. It was a bit of a niche game, but fun and different.
We decided to combine both of these mechanics into a single game with a charming cartoon pirate theme. The game’s original working title was Pirate Booty, but one of our advisors convinced us to change the name after a quick Google search. The game’s final name was
Swashbucks, and we put it into production with the new developer under the new producer’s supervision. What could go wrong?
Well, as it turns out, a lot could go wrong and it did. From the start of development, the art quality in the game wasn’t great and we couldn’t get the developers to improve it up to our usual standards. As we started to press harder, we began to understand why this was. The developer we contracted with had subcontracted out both art and engineering - and had sent the work to separate companies. We were eventually able to pierce the veil enough to find the engineers and sit with them to help develop the product. This was when we learned that the art shop was extremely low cost and low capability. Lesson learned: When you are working with a new partner, always insist on maximum transparency and visibility.
From the time we started getting testable builds, balance testing went poorly. On one run, balance would be screamingly easy and the next punishingly difficult. No matter what levers we pulled we couldn’t get the game to deliver any kind of consistent difficulty, which really messed with the fun factor. As it turns out, combining these two mechanics led to a lot of inherently tricky design challenges that we hadn’t anticipated and that nobody on the team had the right skill set to solve.
Lesson learned: When you have a new team, especially with new leadership, trying to innovate too dramatically in your first project can be a big mistake.
About two thirds of the way through development, PopCap released the game
Zuma. Zuma was a fantastic game that nobody in the office could stop playing. It was a brilliant twist on the Puzzloop formula that kept its extremely simple casual color-matching loop in place while adding level designs and a simple linear progression that deepened and enhanced the game experience without adding complexity to its core. It was a game that could clearly appeal to an extremely wide audience (and did).
Lessons learned: Often when you combine two disparate games, you think will attract the fans of each game, yielding a massive audience. Instead, you often wind up with just the people who love both games.
Almost as soon as we saw Zuma, we realized it was going to be a massive hit. The game was smooth, simple, addictive, and incredibly polished. We couldn’t stop playing it. I had a pretty challenging conversation with my manager about how we could catch up to Zuma (we couldn’t), or whether we should cancel the game. We talked about it for a while, realizing that we didn’t have another project that we could bring into the quarter to replace lost revenue from the cancellation, so we kept the project going. In the end, it launched but generated lukewarm interest and minimal revenue at best.
Lessons learned: If the market shifts in a way that doesn’t give you a opportunity, you need to pivot or cancel your game. And if your game isn’t up to your own standards, don’t expect your audience to love it.
All in all, Swashbucks was a risky project beset with a variety of issues from the get-go. We were overambitious in our core design, especially for a green team, failed to execute at a high enough level to succeed, and ignored clear market shifts. It was a challenging project for everyone involved and wasn’t much of a commercial or critical success. But of the failed projects in my career, I love it for the important lessons it has taught me about how to be a better project, creative, and business leader, and I try to apply those learnings to each new project I take on. I hope sharing these painfully won lessons will help you in your own journey.
