One of the strategies we learnt while running our startups was to attack a wedge, a problem overlooked by the bigger companies, which was sorely needed by a lot of people, and which, the big company was ignoring because of other problems it was more concerned about.
So what you do is quickly make a piece of software that solves the problem and put it out there in the market to attract people. Then as people walk into your fledgling startup, you start interacting with them improving your software and adding features based on their requests until your product fits your customers just right. Once you do this, you’re ready to scale to millions of people, assuming your market is large enough.
Having been in both the animation industry and startups, I was intrigued by the thought of applying the same principles to games. So I came up with this strategy for games:
- Implement a basic game with just the core mechanic, see if people like it.
- If you get a good response, then start interacting with playtesters improving the game.
- Start iterating on the released game concept improving it and adding updates to improve things.
I wanted to see if this strategy would work with games too, and this is how things went for us. I looked around if people were doing it, and sure enough, there were some. The most notable one of those, which impressed me a lot was this Gamasutra article, whose title was aptly, “How To Prototype A Game In 7 Days”.
Encouraged by the notes in the article, I set out to apply my ideas to our game development process. This is how it went roughly:
Step 1: Get the game mechanic
That was done first on paper and pen, I racked my brains for a few days before the Xcavate puzzle concept hit me, and I started playtesting the game concept with my wife and family. She gave me the excellent idea of making it challenging by having multiple treasures on the board. After that, we played around 80 boards offline, it felt good, it felt like it could stick.
Step 2. Build a prototype around the game mechanic
We then built a prototype, we bought or downloaded most of the art assets, and we just put them all together with a bunch of code and made it work. Our prototype was loved by many, but they wanted more graphics and more interaction. One of the guys really opened our eyes up by telling us that we’re trying to speed up everything, but instead, slow things down, let players get a great experience on everything they do in the game, rather than just ruthless efficiency and speed in every action.
Step 3: Working game
After the prototype we went on a long cycle of around a month, implementing feedback from the prototype. Our motto for the build was slow every user interaction down and make it fun.
At the end of it, we launched the game again. This time around, we got feedback from friends, reddit and roast my game that the game was really nice.
Step 4: Launch
My friend Saurabh Gupta, who worked with me on the game, once decided to show the game to his wife, Dhrishty Gupta just before we launched. She was kicked! And she told her sister and they decided to promote the game for us. We launched and they went and told every friend of theirs to play the game and got them to install it. They were so persuasive that they actually asked for screenshots to prove installs from their friends.
The result? We have around 280 installs in a week’s time.
Whats Next?
From the 280 installs we have, we did a cohort against levels. We found that 78 players complete level 1, but then we lose two-thirds of them within the next three levels. Anyone who goes past level 3 becomes a committed gamer, and we lose only 5-10% in the subsequent levels.
We now know that there’s something wrong with our user onboarding. Maybe its that people don’t get the game, or its that we don’t excite the player enough right at the beginning to stay committed to the game.
With regards to retention, we lose a lot of gamers by day 7, and this we found to be mainly because we don’t have enough levels in the game.
We now plan to iterate weekly on releases. Our primary focus is to add levels, our secondary focus is to improve the tutorials and make the game more rewarding to play.
Conclusion
After 3 months, do I think iterative releases work in gaming? Absolutely. I really think games can benefit a lot from the release-fast-release-often strategy. I feel that player data and analytics can play a vital role in improving gameplay, and benefits derved from this method far outwiegh those of building something big and then going to market.
Is this a surefire route to success? Well, I can’t say yet, but I can say that feels a lot better and easier on me to get continuous feedback while making the game, instead of making something big and then realizing that nobody wants to play what I make.
I doubt I’ll ever go back to the “make something big and go to market” approach again. It doesn’t mean I’m against it, its just that it doesn’t work for me.
Thanks a lot for reading the article, I hope it helps everyone in the indie community make and sell games better.
Xcavate 