There were two City Conquest Kickstarter campaigns. We set the initial goal at a modest $12,000. When it moved too slowly, we canceled it, worked on extensively polishing the game, and returned a few months later with a better pitch, a better product, and an even more modest $10,000 campaign.
The good news is that we reached our funding goal and delivered a much better product than our Kickstarter actually promised.
The bad news is that it probably wasn't worth it. We only got 146 backers and only modestly exceeded our funding goals. The time involved in creating and managing the two Kickstarter campaigns and promotional videos would have been better spent working on the game.
The most problematic issue we faced was our promise to offer our backers the full game for free. At the time, we believed we could use Apple's promo codes to keep this promise, but we unknowingly made it impossible to keep when we changed the plan for our pricing model from separate "lite" and "full" versions to a single combined product with an in-game IAP to unlock the full game.
We'd been assured by several sources that Apple promo codes worked with in-app purchases, so we felt very confident in this approach. We also had a long list of workarounds on hand in case this failed, including hard-coding the recipients' device UDIDs or offering a customized redemption dialog in-game. Unfortunately, promo codes proved not to work for IAPs, and we learned how severely Apple frowns on custom redemption dialogs, the use of UDIDs, and pretty much every single other workaround we'd had in mind.
This was a clear and unfortunate failure of due diligence. We immediately apologized to our backers and offered a refund. The financial impact was minimal since this ended up being only a few dozen pledge refunds at $6 each, but it still should never have happened.
The true value of Kickstarter for us was that we could convert many of our backers into playtesters who provided invaluable feedback. If we use Kickstarter again, we will focus on using it to acquire playtesters and communicate with our audience rather than using it as a fundraising vehicle.
4. Getting Engineering Help Too Late
We realized in May 2012 that our team was stretched too thin to be able to implement and test multiplayer properly. We had a relatively solid first-pass multiplayer implementation in place, but our discovery-driven plan was telling us that multiplayer was a huge risk and required much more attention.
At the same time, multiplayer was non-negotiable: it was an essential part of the game's vision and added far too much value to the project to consider dropping it.
We brought on the Full Cycle Engineering team to replace our proof-of-concept netcode with a serious multiplayer implementation. The multiplayer undoubtedly is a far better experience now than it could ever have been without their contributions. However, we should have recognized the bottleneck and brought the Full Cycle team on board much earlier than we did, and we should have focused on Wi-Fi from the outset rather than experimenting with cellular. The tasks involved were huge and this development effort would have benefited enormously from a much earlier start had we been willing to admit sooner that we needed the help.
5. Due Diligence Failures
Our biggest mistakes were several basic errors in due diligence. None of these ultimately impacted product quality, but we hold ourselves to a higher standard than to be the type of studio that would make these kinds of mistakes.
Other than the aforementioned Kickstarter snafu, the worst due diligence failure was iPod Touch support. For reasons too complex to explain here, the iPod Touch 4 had to be our baseline iOS device, and our discussions with friends and our own research indicated that the iPod Touch 4 was basically the same as an iPhone 4.
This was incorrect. The iPod Touch 4 is a markedly inferior device, and it suffers from much more severe memory constraints. This forced us to bite the bullet and implement a lot of fine-grained memory optimizations. We spent four to five developer-days on time-consuming texture and sound memory usage reductions and major improvements to our asset-loading system and resource management code. Although many of these memory optimizations benefited the overall game, these problems should have been identified and resolved earlier.
We also had problems with a third-party technology we selected for the multiplayer lobby. Very late in the development cycle, we were forced to confront intractable technical issues around this technology, and we had to replace it with a solution based on Amazon Web Services. Rather than selecting this technology ourselves, it would have been better for us to have tasked the Full Cycle team with the due diligence around this and let them pick the best tool for the job.
A third case was our achievements. Some developer friends assured us early in development that there was no limit on the number of Apple GameCenter achievements per game. When we realized that GameCenter actually has a fixed limit of 100 achievements, we needed to drop dozens of achievements to get back under this limit. In the end, this ended up being a good thing, as we only lost a few days' worth of time and we were able to significantly improve the overall quality of our achievements by separating the wheat from the chaff. Although we regret the wasted time and the due diligence failure, the net result was that we ended up with what we feel is truly the best possible set of 100 achievements for the game.
IEDS is a different kind of indie developer, and we are interested in exploring a genuinely different approach to making games. Although we do not claim to have any sort of magic bullet to game development, we are deeply encouraged by what we have seen so far of the results of our approach and the success of our game. We're deeply proud of the final City Conquest game experience and looking forward to evolving it and building on its success with the sequel.