Guns of Icarus Online Post-Mortem - Part I: Publisher Nightmare

Guns of Icarus Online is over three years of our lives.  In the span of creating this game, our room had caught fire, our building had endured a great flood, we had been stomped on by a publisher to near death, and overcame one of the worst game launches ever, releasing on the night of a hurricane.  Sleepless nights can’t begin to portray the summation of all stress and elation.  In this span I’ve gotten everything from pneumonia to a concussion from walking straight into a doorframe after a few late nights in a row.  With the game now over a year old, I figured it’s a good time to reminisce on how this game came to be, the major the decisions and crisis we faced, how we overcame them, and what lessons we learned.  Through out this journey, our vision and faith in who we are as a team would be thoroughly tested.  There were so many things we didn’t know and many struggles.  To us, this journey wasn’t just about making a game, but also about trying to make a difference together as a small indie team.  I ended up writing a lot, so I’m breaking things up into a few topics and posting them separately:  

What is Guns of Icarus Online?

Guns of Icarus Online is a game set in a post-apocalyptic steampunk world and is all about teamwork and airship combat.  Onboard an airship, you can get on big turret guns, frantically repair the different components as they take damage, or navigate the ship and direct combat.  The game blends turret shooting, time-management, and sim mechanics, and it puts 4 players each playing different roles in a confined space so they are required to communicate and work together through voice and text chat or voice commands.  Ships and crews then form teams to battle in different maps and modes, pitted not only against other players, but against different environments, visibility, and weather effects as well.  

Publisher - The Blessing that Became a Nightmare

Through the intro of a friend, I traveled to Taiwan in 2010 to look for distribution for Flight of the Icarus (the game we made in 2009 that gave inspiration to this game).  I visited a few different publishers, looking to just get on their portals, and instead of distribution, two of the leading Taiwanese publishers both found our vision for the future - a multiplayer online game with airship combat - more appealing.  We didn’t have the resources to pursue that vision on our own at the time, so we were instead working on a game called CreaVures that we ended up selling on Steam and the Mac App Store.  So for publishers to buy into our vision was something exciting, and as a result, I was pretty starry eyed.  

One of the publishers offered us a co-development deal, where the publisher would supposedly fund a large portion of development in exchange to publish the game exclusively.  The structure of the offer was $300K for development leading to release, and the scope, as we would realize later, was 3 big games’ worth.  The major milestones were concept, prototype, alpha, and beta.  The funding being back loaded, with only $100K allotted to concept and prototype.  Not only that, the prototype phase was further broken up into small milestones, which requiring approval for payment, with only $25K paid upfront.  The relationship would later unravel in just about every way and pushed us to the brink of collapse, but the litany of issues and mistakes started with one - I never explored my options more.  With the one publisher being first, I wanted to believe and took it on faith that the relationship would work out and wanted to honor what I thought was their friendship and faith in us.  If I had to do it all over again, I would have been more patient and tried to get the best offer possible.  

To accept the scope of full-fledged multiplayer PvP, co-op, economic system, and skill based progression, all in the span of 18 months, was part absurd and part madness.  And to make absurdity happen, we expanded the team.  Why did I ever agree to this absurdity was something that still gives me nightmares.  I obviously believed that our team could do anything, but we thought that scope would be refined as the project progressed, which was something the publisher assured us verbally but not in contract.  Also, I was eager to realize our dream and didn’t want to give up on this opportunity.  Carpe diem, conviction of the French cavalry at Waterloo.  

Let’s take a look at some sections of the contract that really put us in a bind:

Within 7 days after the deliverables for Milestone X are completed by [Developer], pass the inspection of and become accepted by [Publisher].  Payment Method: [Publisher] shall remit to the account designated by [Developer] according to the agreed due date.

In the event that [Developer] cannot deliver the Prototype Development to [Publisher] timely on the delivery date stipulated in Article 2, [Developer] shall notify [Publisher] immediately and consult [Publisher] for instructions.

Before the project started, we drafted a concept doc and spec list for both prototype and alpha so that the publisher could get better sense of the game and its scope. Verbally, the publisher told us that it was meant to be revised along the way, as changes were inevitable as with any other project. But, the spec list was included as an exhibit in the contract that dictated the “deliverables” for each prototype milestone. At the time, I really didn’t think through the ramifications. The issue here is that the entire review process was contingent upon an “inspection,” and while the specs were defined, how to perform the inspection or its timeliness was not defined anywhere.  In short, the publisher had all the power.  With the publisher, we stayed up multiple late nights every week and pushed ourselves to the limits.  As a result, the project was amazingly on track.  Yet, since all the line items were specified before the project started, as the project evolved, things became obsolete, or we would find better ways to implement things.  The publisher, however, gave just about zero flexibility to allow for revisions to the spec list, and so we had to waste extra time implementing things that were obviously useless.  Frustration mounted.

When we reached the “inspection” for the final milestone, more of the publisher’s upper management wanted to get involved, and the review that was supposed to take a day turned into a month.  Why?  Because the management went on a company retreat to some unnamed fancy resort for 2 weeks and cannot be reached.  And then they spent almost 2 weeks to “catch up.”  When we finally heard back after weeks in limbo, we learned that we had failed the inspection and they would not pay us.  The CTO, who had never been involved directly in the project, whom we’ve interacted for no more than 15 minutes for over 5 months, decided to meddle.  The reason why we failed was not because we didn’t deliver.  In fact, we delivered on time and on pretty much every single line item.  Instead, it was because he demanded to squeeze in features, such as a finalized and market ready UI, that were clearly defined for alpha and way beyond the prototype specs.  To give a clearer context to the ridiculousness of the demand, consider this.  The NDA that we signed was essentially blackout, forbade us to disclose the project to just about anyone.  So how was it possible to reach a finalized UI without player testing and feedback during prototype?  The CTO either was clueless or just wanted to squeeze us and did not really cared if we survived or perished.  If we didn’t meet his demands, we weren’t to receive payment.

The clause in the contract that gave the publisher justification for demanding alpha features on us at prototype and not paying was:

Unless the event is caused by force majeure, in the event that [Developer] fails to complete the Prototype Development within the scheduled period stipulated in Article 1 or the Prototype Development delivered fails to pass the inspection of [Publisher], [Publisher] shall be entitled to terminate the Agreement by written notice after [Developer] fails to improve or complete the improvement within one month from the receipt of the written notice of [Publisher].

Then, the CTO wanted to negotiate for an “extension” of the prototype, so we can implement more features slated for alpha phase at reduced rate and payment.  While we slaved away and met all demands, the publisher decided to break contract, ignore everything we agreed on, and demande features outside of scope, seemingly on a whim.  We were stunned.  We took a leap of faith and landed with a thud.  If there was a lesson for us, it would be to never again relinquish development control and agree to an opaque process.

Our troubles did not end there.  For the first few weeks, working with the publisher’s R&D team was at least amiable creatively.  They promised to respect our creative vision and art direction.  In fact, in both verbal and written communications early on, they professed to “love” our direction.  Our art direction for the game was Steampunk, post-apocalyptic, closer to realistic body proportions, and more gritty:

Yet, as more marketing folks and upper management got involved, the creative honeymoon began to deteriorate rapidly.  One night, the R&D director who was our window started our call with, what do you think of something like this:

Google Images

As it turned out, their marketing people thought that something with 4.5 heads, cartoony, big heads, big eyes, and big boobs in really bright and high contrast environments would go over better with the Asian audience.  Especially on the portrayal of female characters in game, this went completely against what we believed in.  A suggestion one day became more of an ultimatum the next day, because they were supposed to know better about players and the market.  

Part of our embodiment of steampunk was to infuse it with influences from cultures of the world.  In their attempt to exploit this, the publisher then asked for “stereotypes” of different cultures.  Reason?  They claimed that stereotypes are more easily distinguishable.  We thought this was flirting with racism, but once again, the publisher claimed to know better.  The art style that we settled on was more in the spirit of Miyasaki or early Final Fantasy games.  That is not inherently a bad thing; it’s just not what we wanted or agreed to.  We decided to make a compromise to keep the relationship going.  

With the project hanging in the balance, teetering on collapse, I made the trip to Taiwan.  After a day of sitting in a claustrophobic meeting room, it came down to either accept an extended prototype with the lower pay or be terminated.  We decided to terminate and get out of the contract and the relationship.  Then, I got a phone call from the publisher’s CTO.  On the phone, he posed this question:  “If you wanted to go through with termination, what do you think about us copying the game?”  I was shocked.  No was my answer of course, but that wasn’t everything I said.  In a follow up meeting with their CEO, apparently they never really wanted to terminate and wanted still to find a way to make it work.  We were happy just to walk away and start over.  Later, as I reminisced with project managers who had since left that publisher, I learned that what we went through happened to other developers as well.  In other instances, indie devs lost everything, including their IPs.  

Through it all, I think the lessons were three:

The next post will be about how we started over and formed processes that worked for us.