Why did Unity become your game engine of choice? Was that choice influenced by the presence of the Boston Unity Group at all, or did you learn about BUG after you had already gotten your feet wet in Unity?
The BUG was formed after I’d already produced a Unity game, but it is a great resource. Boston has a relatively small game community, dominated by big names like Turbine and Harmonix, but it’s also healthy and very supportive on the indie side. The IGDA has a good local presence through Boston Postmortem, and the BUG is run by Elliott Mitchell and Alex Schwartz — Alex is the guy behind Smuggle Truck. Kris is based in Austin, though, not in Boston, and Austin has a much larger game community.
As a tool, Unity is very helpful in a lot of ways, but like everything else, it’s not a silver bullet. It has a great asset pipeline and the workflow is very good, and it is fairly easy to target multiple platforms with it while still relying on external native code on each platform as needed. It has a lot going for it, and it has improved massively even in the year or two since I’ve been using it. Their community is also very supportive; you have the usual politicians and trolls you find in any online community, but the vast majority of people are very supportive of one another. You’ll find some great posts by Mika Mobile, for example, sharing knowledge and cheering on others, and the Crescent Moon guys are helpful and supportive to everyone.
As much as we like Unity, though, I wouldn’t say we’re a Unity shop. We use whatever tools are best for the kinds of games we want to make. I’m quite comfortable moving across platforms and languages. But I would say that given the kinds of games that interest us right now, and the fact that we want to build games rather than core tools and engines or middleware, and we want to build for iOS, Android and standalone with minimal porting costs — Unity is proving to be a great fit.
I read that you spoke about TestFlight at the latest BUG meet-up, and I’ll go ahead and plug a great technical article on Unity/TestFlight integration you wrote for the Wicked Games blog. You also spoke about Flurry Analytics, if I’m not mistaken. How can that be useful to indie devs?
Analytics simply show you how people are playing your game. You learn things like “85% of players always choose the male character instead of the female character,” and that “level 4 has a huge dropoff point where players learn how to throw dynamite,” and that most of our players are in China and their average play session is 150 seconds long, and that sort of thing. Nothing personal is collected, it’s just general game info to help improve a game and its levels.
TestFlight’s SDK lets you use checkpoints to gather some of this data while you are playtesting, and services like Flurry expose even more while your game is live. People are fond of saying games are a hits business like films or music albums, but those things are usually released once and done, while most games these days don’t have to be “done” — they are constantly improved after launch using this kind of information.
That said, games driven entirely by analytics can feel a bit stale, like a Hollywood flick built by committee and aimed at some ideal demographic. There needs to be a creative design balance against raw analytics, to guard against things like hidden valleys and to ensure that post-launch content is truly innovative. Analytics can be somewhat like customer focus groups in that they’re good at discovering incremental improvements – like making the throw mechanic easier to learn in level 4 – but not so good at identifying new features altogether — like completely replacing level 4 with a new level design that is “better” and “more fun” and other subjective adjectives that are very real even if they can’t be quantified.
I’m probably treading on bad memories with this, but I want to touch on your experience with In-App Purchases in SpyCorp (now completely stricken in the latest update of course). I’ve long had the feeling that there’s an odd dichotomy at work here: the press has been whipped into a frenzy with news of IAPs becoming a huge revenue driver on the App Store, and yet when I look at discussion among consumers I usually get this vibe that there’s a widespread push-back against their use. After your own experience, do you have any advice for other indie devs when it comes to navigating this contradiction? Do you think you’ll ever experiment with IAPs again yourself?
Well, we were caught in a bit of general anti-IAP anger when we released SpyCorp, but I also think I did a poor job of designing the IAP and the game was much improved when I removed it. I don’t know if the professional reviewers and gamers who dislike IAP are a majority or a vocal minority, but regardless, I am glad that we no longer have it in SpyCorp.
There is still a model, I believe, for pay-once games that offer deep content. Not everything needs to be freemium or have constant teasers to buy more stuff. SpyCorp is not free, but it also has no advertising and no need for any further investment other than a player’s time to complete the entire game. You can hand it to kids and know they’ll never see any IAP prompts. This means it’s a little out of style, which in this case is fine by me.
I don’t think IAP is outright “evil,” though. I think it becomes objectionable in at least two cases: the first is when it doesn’t arise from core game design but is tacked on as a gating factor to win the game or even to play the game at all. To me, that’s like starting to watch a film and then having the theater cut the projector and charge another ticket price halfway through. At worst, this feels like a form of blackmail, like being tossed into an unwinnable battle which becomes winnable not by skill, strategy, or teamwork but only when you are willing to pay. These are the obvious cases in which IAP is executed poorly.
But what I learned is that there’s another, less obvious, case where IAP also becomes objectionable: when there is a perception – but not reality – that a player must make additional purchases to succeed or win at the core game at some point in the future, if they continue to play. These are games that have purely optional IAP in the core mechanics, presented in a manner that leads some players to conclude it may be required. This is where SpyCorp was before I removed IAP. It’s a bad area to be in, and it could well be considered a flaw in game design.
We landed there because of my naive attempt to have our final 12 levels be extremely difficult for advanced players, but still offer an avenue for casual players to complete the story even though those casual players would never score as high as the advanced players would. But SpyCorp’s game design is simply better without this avenue, even if it means that now only advanced players will finish and beat the game.
I think the lesson, at least for me and at least for the time being, is that any IAP at all in the core game mode should be avoided. IAP for other purposes outside of the core game mechanics, like additional game modes, bonus level packs not related to the core story (music packs in a music game, for example, or side dungeons in RPG games), cosmetic outfits and the like, all seem acceptable. Gray areas in between the obvious things to avoid and the acceptable things are IAPs like virtual currencies and time-gated virtual items, which work for some titles but are slammed heavily in others. As an indie, I’d simply avoid those gray areas altogether for now.