Author: by Charilaos Kalogirou

[In this reprinted #altdevblogaday opinion piece, Nlogn Information's Charilaos Kalogirou shares the various ways he had to "improve the fit" of his game design hat while trying to create an approachable and addictive game.] One of the main traits that an indie developer must cultivate is that of wearing many hats. All indie game developers will tell you about it, and it is the first thing you will realize when going indie. Wearing many hats is usually the result of small budgets. Small budgets mean less heads but an 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 latter 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. I read blog articles, watched video presentations, hanged posters of Johnathan Blow over my desk, etc :) All of this 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 the analytic methodology that I can be good at. My guidelines were:

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 higher scores 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 intended. 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 accomplishment. I went out and gave it to friends so I could test reactions. As people were 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 popcorn-loving monster 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 let's 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 time 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 are 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 three bombs every four 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. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]