This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
2. Ride the Feedback Cycle
We build multiple feedback cycles into our dev process to allow the team to improve features before launch. Our philosophy is that we don't know everything but we can learn from everyone -- testers, beta players, team members, and press alike. Like most online games we went through multiple beta cycles, a Canadian test launch on iTunes, and we also took feedback from press during guided game tours. Most developers try to do the same, but we emphasized to the team throughout the process that we wanted to take advantage of any useful feedback, no matter what the source. If the janitor had something good to say, we'd listen.
The first and most intense feedback cycle came from the core team, all of whom are people who are committed to the game. This feedback was the most in-depth and continued all through the process, leading us to change or fix many things from battle mechanics to character animations. Our in-house testers in Korea were also helpful at stopping issues. However, because the team also knows the game best, they didn't necessarily see issues that new players might experience. Sometimes you get used to 'how things work' and ignore glaring issues.
For those issues, our two QA engineers in Korea and our beta testers and our iOS players during the Canadian "test launch" helped spot more problems. We had to focus on issues in the core gameplay as well as problems that could pop up on one device or another, but we kept a good attitude throughout the team toward anything we felt could improve the game. When we had builds we could share more widely, including with members of the gaming press, we got even more valuable feedback -- the only drawback there was that some was too late in the cycle to implement by launch.
Post-launch, we of course listened closely to user feedback and are using that to shape some of what we aim for in future updates. And of course we watch our metrics closely, similar to other social developers. Crash reports are particularly important for allowing us to hone in on any critical user issues but of course we also look at retention, length of play session, etc. to see how players are enjoying the game. However, we found most crash tracking tools do not support the Unity application very well.
Knightly Adventure testing dashboard (click for larger version)
3. Community and PR Helped Spread the Word
We didn't launch KA when we initially planned -- we were months later than anticipated, in fact. But the upside of this (making lemonade from lemons) was that we had more time to utilize community and PR throughout the cycle to get the word out about the game early enough to create awareness at launch. We were able to establish demand without spending a ton on marketing. This is very valuable for smaller companies like us that don't have big budgets.
We launched our social media campaign on Facebook months before launch, attracting a small but dedicated audience who helped us spread our message. Now sometimes all fans were saying was "when are you going to launch your game?" but this still gave us a chance to engage them in conversation. Even when we didn't have a new item or asset to reveal, we'd talk about other things that could relate to the game even if it was just a picture of a frog riding a squirrel (frogs feature prominently in the game).
Our PR campaign started with press meetings at GDC in 2012, over six months before our eventual launch. Because the launch was delayed, we did end up with some "dead time" in our PR cycle, but we maximized our presence closer to launch when it mattered most. Because assets equate to coverage (and no assets means no coverage!), we dedicated a team member toward creating videos and screens to maximize PR coverage. This person was on the publishing side rather than the dev team since we didn't want to pull anyone from dev tasks, but it was still a cost against the bottom line -- and one we were happy to pay. We were able to get some nice previews ahead of launch to help set the stage for our appearance in the App Store.
Reaching a core audience before launch