One of the main traits that an indie developer must cultivate is that of wearing many hats. All indie game develepers will tell you about it, and it is the first thing you will realise when going indie. Wearing many hats is usually the result of small budgets. Small budgets mean less heads, but equal amount of hats. What I learned through the course of developing my indie game is that your success depends on how well your head fits those hats. Your game will simply be as good as the worst fit.
One of the hats I had to wear for the development of “Pop Corny” was that of the game designer. The closer I had ever come to game design before this, was playing games with a little more inquiring spirit than most players do. This can definitely be interpreted as a bad hat fit. It was clear that in order to have a successful game, I had to find clever ways to improve the fit. This of course could be done by adjusting the head (becoming a better game designer) or by adjusting the hat (adjusting the problem itself to something that I would handle). It was obvious that I had to do the first as much as possible, but without the later I was not going to go far.
Adjusting the head
So I went out and absorbed every single drop of knowledge I could on game design. Read blog articles, watched video presentations, hanged posters of Johnathan Blow over my desk, etc :) All these helped, but I knew that I had to bring the battle to my battlefield in order to win. This meant that I had to base my game on a simple (yet effective) gameplay idea, and build on that using analytic methodology where I can be good at. My guidelines were:
- single touch, simple and effective game mechanic that would make great gameplay for touch devices
- The player should be able to start a game whenever he had some time to “kill”, whether that is 1 minute or 10 minutes or half an hour, and enjoy the game equally.
- The gameplay should not require too much “brainpower” from the player and depend more on trained reflexes and getting used to, while giving you the joy of acquiring true skills.
The process of meeting the above requirements can’t be fully transcribed, as it was mostly intuition based. It was clear that the game had to be an endless runner, which basically means that the player can never finish the game, and getting better would mean better score and more play. This would allow for my “short fun” direction.
I struggled a lot more on what an effective game mechanic should be to produce a great gameplay for touch devices. The simplest of all mechanics on a touch screen is the “tap”. I wasn’t feeling right about it, as it is overused and you probably end up with an experience not so original. Then I looked at swipes. Swipes are simple, but at the same time elaborate enough to resemble real life “game” actions. For example a swipe can be a throwing action in real life. So I centered my thinking around throwing stuff with your fingers. I did some prototypes of throwing circles and hitting rectangles and it was fun. Through an experimentation process I ended up with the “sling” throwing mechanic. You basically swipe in the opposite direction of the intented. This was a revelation. The inverted swipe posed a slight challenge to the players brain, that as one started to get it, it gave a very cool feeling of accomplisment. I went out and gave it to friends so I could test reactions. As people where getting it you could see fingers pointing all over the screen… fights over the who plays next, etc… I was convinced.
Mr. Pop Corny is a popcorn loving monster
The idea of the pop corn, the pop corn loving monster, etc came from my sister during a brainstorming session. So we had a theme. Next we started thinking of ways to enrich the experience and keep the players’ interest for longer time. One of the elements that worked was the “box progression”. I got the idea originally from Tiny Wings, and the way you upgrade nests, but found out that it is a common thing in the iPhone games field. So the user has to complete certain objectives to upgrade his popcorn box and get bigger score multipliers. We also used this progression to teach the player how to get bigger scores, and survive longer. After that we added an extra task of collect drachma coins for the player (an inside joke for my country possibly defaulting to its national currency drachma). He could then use the drachma coins to upgrade bonuses and buy new pop corn boxes that gave extra powers. So the game became more complex and hard to balance, but this was mainly a problem I could cope with as an engineer. I was in my field.
Do it like an engineer
Questions like “how much should a bomb cost?” (a bomb is used once and pops all corn on the screen at once) are hard to answer without the right tools. What data is necessary to give a good answer? For the above question you need to know the answer to at least “How many coins does the player get in one game session?” and “How many bombs in a single session does not put the game out of balance?”. An experienced game designer might be able to answer the original question by instinct and get it right. However, I had to do what I can do good. Break down, measure, answer, build and repeat until the required feeling is achieved.
What I did was log all the key elements of game sessions by beta testers, and interpret them with the so handy SciPy and related NumPy modules for python. These modules allow you to easily read csv files, process the data with almost every statistical analysis method in the world, produce beautiful graphs, etc. For example lets look below at the number of sessions per coin collected range. These are the samples that were collected for the same player level in the game.
These follow the normal distribution around the value of 80. This means that most of the times a user will collect 80 coins per game. However there might be caveats if we are not careful enough. For example lets look at the distribution below:
If we try to fit a Gaussian function in the above data we will have huge errors in our estimations. Before we go and hit least squares and optimization algorithms, we would always try to think through of what is generating the data. Here the false assumption about our data comes from the fact that we consider them all to be coming from the same “generator”. That “generator“ is the player interacting with the game in order to collect as many coins as one can. However because the game is a beta, and users are beta-testing it, the generators are two. The first is the one I described before, but there is also the sessions that the user tries to test some other aspects of the game and does not collect coins! So what we really have here is two different data sets mixed to one. One from the players trying to collect coins that produces a distribution of values around 80 (the red graph) and one from the players that don’t collect because are testing something and produce a distribution of values around 0 (the green graph). Adding the red with the green gives the original observed blue. The graph bellow illustrates it:
So we need to fit the sum of two Gaussians in our data with unknowns the two mean values and the two variances. This way we get the correct value of 80 for the mean coins collected per game session, which would otherwise be detected as 60 or something. So if you want the player to be able to afford 3 bombs every 4 games you set the bomb to cost 100 coins and you are set.
Conclusion
This was my approach to designing my game, and it seems to have worked out quite well, with the game receiving great acceptance. The game got to #1 Top Paid Game in the Greek AppStore within hours of its release and #2 Top Paid across all app categories, all 5 star reviews. On most reviews the addictive gameplay was mentioned, which is so comforting when I know that was not my best field. It turns out you can replace part of intuition and experience with analytic tools.