With a brief cross-over and much handshaking and “Merry Christmas”-ing before Kostas and Kyriakos left, Adam Clixby and Glen Watts joined me in the Drummond to continue with my day of interrogation. Adam is a founder of Rodeo Games, makers of turn-based strategy games Hunters and Hunters 2 and currently developing Warhammer Quest. Glen is a long-time Lionhead veteran, recently freed and looking to start his own indie games company. I first worked with Glen in 2001 at Dogfish Studios and we both ended up at Lionhead a short time later (Glen via HotGen, myself with a more direct trajectory). Most of the following is Adam’s advice, arising as the three of us talked about making games.
“Testing on iOS is like xbox, testing on Android is like PC” – The Android platform has such a variety of mixes of hardware that testing for Android is much like testing for PC. There are an unfeasible number of permutations of hardware, which almost guarantee that your code will fall over somewhere, causing a very vocal backlash against your game and one star reviews that you have almost no control over. Even a given version of a specific phone can have subtly different pieces of hardware in different territories, one of which might crash and the other of which won’t. This level of testing hell is expensive to deal with and almost impossible for a small developer. iPhones, on the other hand, have much more homogeneous hardware, making testing a far more constrained problem.
“Use the NS data types on iOS” – this is a specific piece of coding advice, but Adam said that loading in from XML to the NS data types made everything very easy in terms of serialisation. The whole data structure just ended up as a dictionary of dictionaries after load and saving became updating those dictionaries and pumping it back out to XML. I don’t know if this will make me redo the work I’ve done with pugixml, but it’s at least worth looking into.
“Throw away everything that doesn’t work between games” – You’d think that between writing versions one and two of the same turn-based strategy game, you’d only be expanding and refining your codebase, but apparently the only things kept between versions were the renderer and asset system. The reason for this is that they (much as Mark advised me to) didn’t over-plan and didn’t write generic systems that were unlimitedly extensible. They just wrote the game they wanted to make as quickly and fat-free as possible. Maybe if they’d known the additions they’d wanted to make for Hunters 2 they could have built Hunters 1 differently and made it extensible in just the right way that more code reuse would have been possible, but that would have required incredible prescience, a lot of luck and still come with the trade-off of time, effort and money. As a self-funded start-up they almost certainly made the right choice. They certainly made the safe one and they’re still in business now, two games down and making a third for Games Workshop because of their success.
“Test for low memory situations” – One of the early bugbears for Hunters Part 1 was the game crashing when it was sitting in the background as the user was using another app. iOS might then decide that it was running out of memory and would dump Hunters or part of its resources our of memory. This wasn’t a situation Rodeo had tested in before release and it caused a lot of unhappy customers. Making sure my app deals with partial or entire unloads, then jumping back to the game where the user left off, will certainly cost time and effort to do, but the alternative is one star reviews and demanded refunds. On switching back to your app after a partial or full unload, Apple gives you a warning message and then display the last frame of your game before it was switched away from, giving you time to get everything back together ASAP.
“For freemium, balance your costs for in-app purchases very carefully” – Punch Quest was originally released as a free-to-play game, where you could earn in-game currency and spend it on in-game items, with the option of buying extra currency to purchase things quicker in-game. It seems the developers were too kind with their pricing of in-game items and with 600,000 downloads, they only made $10,000, forcing them to eventually switch to charging for downloading the game. Here’s the article in depth. Whilst you want your customers to like your company (good will still counts for something) and enjoy your game, you’re still a business and finding a good way of getting people playing your game to pay for it shouldn’t be misconstrued as ripping anyone off. You might want to make it that players could, in theory, play the entire game without paying a penny if they put the hours in, but making that laborious to the point that most player would consider paying for extra items or content is just good business sense. This is in no way advocating pay-to-win, which will definitely alienate your customers in multiplayer games.
“Make something good. Tell everyone.” – It sounds obvious but sometimes the most common of common sense advice is forgotten. If there are two stages to making a game, these are they.
“Give exclusives to interested journalists, then digg/twitter everything to fuck” – If you give an exclusive to a gaming site, you’re doing so because it’s more likely they’ll more prominently display the article about your game, but what you really want is for *everyone* to read it. If you then go on to use all your social media heft to get it out there, there’s more chance of other social media outlets picking it up, which brings us neatly onto…
“Tak’s pyramid of upselling” – Named after Tak Fung, co-founder of Supermono Studios, this isn’t an alternative to making a creative, fun, polished game, but a solid approach to gaining traction in the media to publicize it. Tak suggests that, in the beginning, the big sites are unlikely to have much interest in you. Unless your game is so left-field creatively that it’s news by itself, it’s unlikely to be immediate front page material. However, like any ecology, there is a food chain and whilst the largest gaming sites might have little interest in eating your output initially, they’ll happily eat the best output from the sites one level down. If you find small sites and get them interested enough in your game that they put you on their front page (maybe as an exclusive, as suggested above) then the sites above that are more likely to consume your content from that level, and so on up the chain. This is unlikely to get you to the top in one go, but by the time you do your next round of publicising your game, the sites one level up the chain might have heard of you and could be willing to take an exclusive, until you find yourself getting your emails replied to by the biggest sites directly.
“Be careful and well-crafted with your output, the press might repeat it verbatim” – If you give a journalist some copy to read, there’s a chance that the headline you wrote (or some mash-up of your first sentence) will be the headline of their article and the rest of the article will be a verbatim reproduction (or some condensed version) of the rest of that copy. If you can’t imagine what you’ve handed them looking good as an article on their website, then re-write it until you can. This isn’t any guarantee that what you write is what will end up on their front page as-is (most will at least re-write it to keep within their own style guidelines), but a good failsafe against your poor language skills ending up being the next thing a potential customer reads about you.
“Give the journalists anything and everything they ask for” – Screenshots, videos, sound bites, your sister’s phone number, just do it or you run the risk of the article about your game being at the bottom of their front page, under the articles about the games of people who did.
“https://testflightapp.com/” – This website looks amazing for beta-testing your game. It takes all the heavy lifting out of getting a signed version of your app onto the devices of whoever you like (specific friends or x number of strangers), then feeding back usage analysis to you. It’s something I’ll definitely use and currently it’s free, but great things can’t last forever.
“Always keep the game stable” – At Rodeo they always stop production whenever anyone hits a significant bug and ensure they fix that bug before continuing. I think we all agreed that asserts should be unskippable and should crash the game. If you’re checking something is true and it isn’t then stop and fix now (including it not really being an assert and removing it), don’t let people “come back to it later”, when they never will. Keeping the build functional at all times will save more time than it costs.
“Xcode static analysis” – We used to use lint a little at Lionhead, but there weren’t enough evangelists about it for it to be used enough. Using static analysis and cleaning up all the complaints will get rid of a lot of hard to repro bugs (uninitialized variables and the like) before they cost you time and sanity.
“Pay up front worked better than unlocking in-game” – Hunters Part 1 was initially a free to download game, where you unlocked the ability to continue upgrading your characters beyond level 2. This wasn’t working as well as they hoped, so after a few months they switched it to pay to download. This was worrisome for them as all the people who had already downloaded it for free would get the update and now have it unlocked for free. Only new players would be paying to download the new version and make them any money. It turned out this was worth it as their daily income doubled. No doubt a lot less people got to play the demo version for free, but they made more money in the long run.
“Apple offers automatic refunds but few people take them up on it” – Apple’s policy is that anyone that asks for a refund on an app gets it, no questions asked. The app is also not removed from their device and they can keep playing as normal after the refund. If this sounds bat-shit crazy and scary to a developer, I can understand it, but only around five people per week ask for that refund on Hunters, which says a lot about the people who choose not to pirate games in the first place.
“Use GIT for source control” – Currently I’m using perforce for free on my own computer, but I really need to get everything in the cloud in case others join my project. My perforce directory is in dropbox so I’m reasonably safe from losing it under most conditions, but I shall have to soon do it “properly”. There are many possible solutions but GIT was Adam’s favourite.
“By the time your game is released it has to be your personal favourite game” – I think this is a great sound bite and something that will have to be true before I release anything myself. If I don’t love it and can’t be the best evangelist for my own game then what chance does it have in the highly saturated app store?
Thanks to Adam, Glen, Kostas and Mark for their time and advice (I think they enjoyed giving it as much as I enjoyed rapidly jotting it down). I’m sure I’ll head to Guildford and assault more ex-Lionheaders for their advice in the future, but for the next while I’m going to spend my time doing less typing of English and much, much more of C++. Happy 2013 everyone 🙂