AuroraBound Postmortem and Sales Figures – A Modest Part-Time Success

It’s been 3 months since AuroraBound launched on mobile devices and so far it has done considerably better than I was expecting (though it’s certainly not the kind of irrational break out financial success we all secretly hope for). While procrastinating on my next game, I decided to look over some of my notes and write up a postmortem of how everything went. I’ll try to stick to the standard ‘what went right and what went wrong’ format, but I’ll also throw in a section at the end with the game’s sales performance and analytics to date.

aurorabound animated gif

What Went Right:

1) Scope

If you read my previous blog posts, you’ll know that I developed AuroraBound in my spare time and, in what can only be described as a game development miracle, it kept pretty much to the original estimates of 6 months for development. To do this, the core game design and mechanics were purposely kept as simple as possible and any ‘extra’ features that weren’t absolutely needed were brutally cut.

When pre-production started, the rough goal was actually to make a space based RPG with a ship building & combat system loosely inspired by the Galaxy Trucker board game. The first thing prototyped was the ship building mechanic however – where you can only match up square component based on their connector types. I realized I was having fun just matching colored squares in a little grid and decided to cut everything else from the concept after a day or two and just focus on that. Not the easiest decision I have ever made, but since the main goal was to release a finished game, it was the right choice.

Whenever a section of the game was being designed, how long it was going to take was always a major design consideration. For example, once you enter a puzzle you need to complete it to progress, you can’t exit back out. You also can’t replay previously completed puzzles and there aren’t multiple save files. While these choices appealed to me for the specific game experience they provided, they also saved a lot of development time by allowing me to cut corners in level saving code and in ui design.

Another example of cutting corners time wise was the trailer. Once a solver was made, a very simple ‘auto-play’ mode was also added, which would automatically play through a list of pre-defined levels. This took maybe 15 minutes to set up, and after another hour of tweaking to get the timing right, and display the game’s title when it finished, the result was the trailer for the game. I just ran that, recorded the screen and no further editing was required. It might not have been the best trailer in the world, but I was happy enough with it and the whole process took less than 2 hours. As an added bonus, it was simple enough to then alter the settings to auto-solve the levels in two distinct passes and take screenshots in the middle. I left it running, went off to get some food and when I came back I just picked my favourite 8 to be the promotional screenshots.

I also cut a lot of potential features that I knew the game could benefit from that I just didn’t want to work on, such as social media integration, leaderboards and achievements. Keeping my motivation up while working only on weekends and evenings was challenging enough – doing so while spending that time implementing 3rd party SDKs or more advanced save systems would have been a step too far. 

2) Level Editor & Generator

As soon as the game concept solidified into a puzzle game, it was obvious that some sort of level editor would be required. Since the puzzles were relatively short, a lot of them would be needed. AuroraBound ended up shipping with around 200 handmade puzzles, and once a player completed them, they would seamlessly switch over to completing procedurally generated puzzles.

I don’t actually have a lot of experience creating level editors – most of the previous commercial work I have done has involved creating products with several once-of, single level games in them. I decided to create the level editor inside of Unity, and that worked out pretty well – it’s just a separate scene in the main game which allows me to load, save, display and edit level files ( all of the levels are just simple XML ). A bunch of buttons along the side were linked to editor scripts that perform the various operations needed.

aurorabound unity level editor

One of my shameful little secrets as a programmer is that I love quickly writing terrible, throw away code and, since the editor was only ever for my use, I was able to throw the first version of it together in just a few hours. It looked terrible, and it ran even worse – for most of the project’s development it had a rather impressive memory leak of ~0.5mb a second that would eventually cause it to crash if I didn’t restart it… But for what I needed, it was perfect. Most of the editor actually ended up being rewritten several times (with equally appalling code) as the underlying structure of the puzzles substantially changed and it needed to be ‘updated’ to match.

Even with the editor, creating new puzzles manually was very time consuming. To fix this I ended up creating a level generator that could create new levels based off a small set of parameters such as target difficulty, color set, pattern set and distribution of rotatable tiles to movable tiles. When designing the generator, about 30 puzzles were manually created in the editor and then used to work out desirable puzzle traits ( like symmetry and repeated patterns in the final solution ). These traits were then programmed into the generator.

Once the generator was working relatively well, it was hooked up to the level editor and used to create the starting point for each of the ‘hand made’ levels shipped with the game. I would quickly use the generator to cycle through dozens of possibilities for a given difficulty and then, once it gave me one I liked, the editor was used to tweak and refine it a bit to make it more visually appealing. This was necessary as it was important to carefully craft the initial puzzle difficulty curve and because while the editor did a good job at creating large levels, it struggled to create very good small levels at lower difficulties.

In the end ~1500 players have already completed the first 200 hand made puzzles ( ~10% of players who have downloaded the game ). Some players are far beyond that however, with ~60 players having completed over 500 puzzles and with one player now having reached world 115, meaning they have completed around 1000 puzzles. Keep in mind, the difficulty of the puzzles regularly increases, so players who reach world 100 could be facing puzzles like this:

It’s also worth noting that the majority of the IAP revenue is generated in the more complex later levels, after the hand made levels have already run out.

3) Art Style

I am not a talented artist – I have in fact seen my attempts at programmer art literally make some of the artists I work with during my day job cringe. Given this, and the fact that there was no budget for external art, I needed to find a style that I could not only produce, but do so relatively quickly. The style also need to be simple enough that the the app size could be kept as low as possible while having thousands of distinct levels – It needed to be under 100mb for the mobile network download limitation (and because splitting obb files in android is a pain), and ideally much smaller than that for countries with poorer internet connections. In the end, the app was <30mb in total.

It took a fair bit of experimenting and time, but the final style turned out relatively well. The game’s visuals are primarily achieved through the use of hand made triangular patterns and simple color palettes. ~100 black and white triangular patterns were created to make up the puzzle pieces and the best 34 were kept in the final game. Many of the patterns share the same outer edge connector, as this lead to more interesting and visually appealing incomplete puzzles.

36 unique color palettes were created, each of which contain 7 colors – 5 colors for the puzzle pieces in a given level and then a primary and secondary background color. It proved extremely challenging to come up with that many visually distinct (and appealing) color palettes, especially since pieces are darkened when incorrectly placed, and the process took a lot of trial and error, but it was worth the time in the end. These patterns were combined into a single small image, with each color taking up a single pixel, and then sampled at run time to color a level.

aurorabound pattern pallete sample

When a ‘world’ (a collection of puzzles) is generated, it is given its own color palette and set of 5 patterns pseudo randomly – with the main restriction being that the patterns and background colors chosen not having been used in the previous two worlds. This gives every world a distinct feel, and with a pool of 45 patterns and 36 palettes, players almost never see the same combination a second time.

What went wrong

1) Procedural Audio

I have even less musical ability than artistic talent, and since there was no sound budget, I was left to search through the various online collections of royalty free music and sound effects. The goal was to find or create something soothing and relaxing, but since there were going to be an infinite amount of puzzles, there was a very real risk of whatever was chosen eventually sounding repetitive. There were a couple of free music tracks which seemed to provide the desired atmosphere, but filling the app with enough to prevent the music getting repetitive would have bloated it’s size.

I decided instead to try and write a simple musical generator that would procedurally create and play simple melodies, unique to each puzzle and world. After all, the target wasn’t an awe inspiring John William’s score, just some simple ambient background noise, and this approach should have avoided the perceived repetition problem. I found free samples of individual notes played on a variety of orchestra instruments and set about creating a very naive music generator.

The basic idea was to get a collection of ~6 notes for a wide variety of orchestra instruments and then set up some basic parameters for how that instrument to play. A new note every half second for example and there might be some logic for how notes should be selected – randomly or in some pre-defined ascending or descending sequence perhaps. When a player entered a new level, a pseudo-random sub-set of instruments would be chosen and one of them would start playing. As you progressed through the level, more instruments would be added ( either simultaneously, interspersed, or replacing the last instrument ) to help give the feeling of change or progress.

This plan ran into problems almost immediately, primarily centered around the fact that I know nothing about music theory – I can’t even read sheet music. I tried looking up similar approaches and the background theory I would need but I either couldn’t find what I was after or what I could find was too in-depth for me to consume in the time I had. One of the first issues I had was that certain notes apparently just clashed and didn’t sound right when played together – a fact that I didn’t know about and had problem hearing on my own when it was happening. The note samples I had all came from a variety of different sources and as such were different qualities – requiring a lot of time spent in Audacity trying to normalise, amplify or reduce noise. A lot of time was also lost culling instruments that just didn’t give an appropriate sound ( an organ for example, didn’t really seem to provide the relaxed atmosphere being aimed for ).

music failure

After about two solid weeks of making and iterating over the system, I reached a point where I just had to accept defeat, cut my losses and move on with other aspects of the project. The system was simplified a lot and set up to only play one instrument at a time while the overall volume of the instruments was reduced and the volume of the ambient pad loops I was playing them over was increased. The end result sounded okay, it even earned a few complements in reviews, but it never achieved the originally desired effect. I am convinced that an approach similar to the one I attempted could work for games like this, but I eventually had to accept that I just didn’t have the required time or aptitude to implement it.

2) Early Solver

The main form of monetisation in AuroraBound is through players purchasing extra ‘hints’ if they get stuck on a particular puzzle and this mechanic obviously required that the game be able to solve its own puzzles. Very early on in development, maybe a month in, I spent a few days creating a solver that, at the time, I was extremely proud of – it was probably the cleanest code I had written in years. Since this was a feature players would effectively be charged to use, a lot of effort went into making it as ‘efficient’ for them as possible. A single hint would effect a single tile, so it was designed to look over the current state of the board and programmatically find the shortest path to a correct solution from where the player was now by removing as few incorrectly placed pieces as possible.

When it was done, it worked like a charm – always finding the best possible solution for the player… It just had one, tiny little (glaringly obvious in retrospect!) flaw… You see, when it was created all of the levels were hand-made and very small – but the puzzles would need to get a lot larger to provide an interesting challenge for most players. When tested later on with mid-sized levels the solver failed. Well, it technically still worked and found a perfect solution – it just took about half an hour to get there on a development desktop… Because of the multiple levels of recursion in the solver, each puzzle piece added resulted in a more than exponential increase in time taken to find a solution.

After a day of stubborn optimisation and swearing, I eventually accepted that my fundamental solver approach was just plain flawed and ripped it out in a mixture of anger and professional embarrassment. It was replaced with a simpler system that generates solver data when a level is first generated, embeds that data into each of the ‘slots’ on the puzzle board and then uses that to quickly ‘solve’ levels when needed. In practice, this works well (except for an embarrassing bug the game shipped with that has now been fixed) and provides almost the same experience for the user as the original solver, but it means that there is only one ‘correct’ solution to a puzzle when using the hint system.

3) Time Management

When work started on AuroraBound, I was determined to finish and ship the game and not just add it to my huge list of unfinished prototypes and side projects. To do this, I adopted a hard and fast rule of working on it every day for 1-2 hours ( more on weekends ). I generally didn’t allow myself any exceptions to this unless something unavoidable came up. I also never allowed myself to work for more than 2.5 hours on a given day, no matter how well or poorly things were going – I don’t crunch to finish projects, ever.

This gave a clear amount of development time for the project, since the target timeline was six months, and it was possible to design, estimate and cut features to hit that target. At first, the system seemed to work very well, but about halfway through, I started noticing issues – my attention and motivation were lagging and the temptation to ‘just take today off’ was getting stronger. It wasn’t due to the work being done though – individual features were being finished every day or two and I was regularly swapping between different types of work (and if I really didn’t want to work on something, I just cut it). The simple fact was, I was burning out.

While two hours a day may not seem like much on its own, put in context it was effectively taking up the majority of what had previously been time I spent relaxing and playing games. On weekdays I get up early and leave for work at around 6.30am and then get home at around 5.pm. Exercise and a shower takes me to about 7 and then dinner might take me to 7.30 or 8.00 depending on whether it’s my girlfriend or me making it. If I add two hours of dev work in here, it’s basically time for bed and you will notice a distinct lack of fun and relaxation in that schedule.

Working like this was fine for a brief stint at the start of the project to get things going, but I should have cut back to 3-4 days a week as soon as I noticed the problem. Instead I powered through and ended up basically crashing as soon as the project shipped – post release plans for new features and to finish off and release the desktop version were put on indefinite hold. I misjudged the toll the lack of time off would take on me, and it’s not a mistake I’ll be making again. I’m starting to make some progress on my next game, but this time around I am making sure to keep some days free for the finer things in life (i.e. playing computer games instead of just making them)

4) Good, But Not Great

I feel confident enough at this point to say that AuroraBound is a good game, and a lot of players seem to really like it – but it’s not a great game. It’s not exceptional or different in any major way and it has no major, unique hook to attract press or streamers. This made it very difficult to get the attention of the press and major platform holders or for it to stand out noticeably amongst other puzzle games.

I followed all of the usual advice for contacting press and quite a few of them actually got back to me (though a fair few of those were with offers to feature the game for money which I politely turned down). While most outlets contacted never replied, one or two went so far as to let me know they had tried the game but wouldn’t be reviewing it and why ( which I appreciated immensely by the way!) A few outlets did end up reviewing the game however, and were generally quite positive, including the Japanese site Isuta, which (through google translate) provided my favorite quote about the game:

In a relaxed atmosphere, it is a rice cake that combines addiction and healing that you want to play forever ♪

After the reception AuroraBound has received, I have decided to spend a bit longer on my next game and make it a bit more immediately impressive and different in the hopes of making it easier for it to get attention and stand out amongst the crowd.

How Did It Do?

I’ll break from the usual right and wrong postmortem format here to share some sales figures and analytics data for AuroraBound’s first 3 months.

The game has around 15,500 unique users, the vast majority of which (13,000) are on iOS, with ~1700 on Googleplay. Half of those GooglePlay users are as a result of an AdWords ad campaign I ran as an experiment though. It has only 22 downloads on the amazon app store and 330 on Windows phone (the result of a positive article on Windows Central). It received a small amount of featuring on the iOS app store (it was in the new section of the puzzle and board game categories in various countries) which helped immensely and probably accounts for the majority of those downloads, as you can see below:

 

aurorabound units on ios

In the first three months since its release, AuroraBound has recorded sales of $6,434 (which means a revenue of almost $4000 after the app stores take their cut), considerably more than I expected it to. As my last blog post explained, the game cost <$1500 to make and release (not including my precious time), so I am extremely happy with that. Almost all of that is coming from iOS at the moment, with GooglePlay sales amounting to only $134. You can see a breakdown of iOS sales over time below, and you will note it doesn’t directly follow downloads as only a small subset of users ever pay anything and they generally only do so after spending quite some time playing the game. It’s also worth mentioning that around two thirds of players come from non-english speaking countries (primarily China), so the money spent in localisation was well worth it.

aurorabound ios sales figures

There are 372 unique paying players on iOS so far ( a conversion rate of 2.7% ), meaning the average revenue per paying user is $10.32, but the average revenue per user (including non-paying) is only $0.28. This is important, because it basically rules out using paid installs to increase revenue – the cost to buy a new user is generally between $1 and $4 at the moment.

You may have noticed that while the game has only 372 unique paying users, it has sold 2,483 IAPs – most users who make a purchase end up making several ( in a few cases over a hundred ). 72 users have spent over $20 in the game, while another 111 have spent between $5 and $20. The most popular IAP by far is the 25 hint pack for 0.99 cent, with some users purchasing it hundreds of times despite it being worse value that the other hint packs ( the 2020 hint pack for example is $19.99, and so would give 4 times the amount of hints per dollar as the 25 hint pack ) I’m not sure if this is due to me not making the value proposition clear enough or some users only wanting to buy enough hints to get them through the current puzzle.

Unsurprisingly the least popular IAP is the ‘Tip the Developer’ gratuities, with 6 purchases in total. It was added it as an experiment in case there were users who wanted to support the app, but didn’t want to buy any hints. Despite only generating $10 in revenue, I am glad I included it as a few of the reviews reacted positively to it being there as an option. Besides, with other In-App purchases already hooked up, $10 pretty much covers the dev and localisation cost of adding the gratuity option as well.

While the download numbers have been relatively small, they are better than many other similar apps and the game has generally been getting very good user reviews, averaging about 4.7 stars on both iOS and GooglePlay:

AudoraBound App store ratings

Overall, I’m pretty happy with how AuroraBound turned out. I’ll be releasing another update in the next few weeks fixing the last remaining known bug, and maybe adding a few more levels, and at some point in the next few months I hope to get back to the desktop version and release that on Steam and the Mac App Store. Work has already started on my next game and it’s going relatively well (if a bit more slowly than I would have liked). It should be ready for release early next year and I have tried to integrate the lessons I learned from AuroraBound into its design.

The Cost of Your First Game

Launching a new mobile game is cheap these days, right? I mean, the common wisdom is that anyone can make and release a mobile game for practically nothing – just a small bit of time and maybe some hard work and then you sit back and wait for your ‘free money’ to potentially roll in. I assume this is part of the reason why, once people hear I make apps, they keep telling me about their new (and impractical) ‘awesome app ideas’…

But what does it really cost? And what does it cost if you want to do it professionally – create a company and treat it as the first game in an eventual portfolio?

question mark on money

For me, the answer was €1,319 – and it could be a lot more for you. My company’s first game (AuroraBound – Pattern Puzzles) launches in 2 weeks on 3 platforms and 4 app stores. I did the design, coding, art, audio and marketing myself – only outsourcing the localisation, yet the various costs still added up.

Forming a Company

The first cost for me was setting up a new company I could release games under (Final Game Studio Limited). You can technically avoid this if you want, as I think all of the major app stores allow you to sell apps under your own name, but there were a couple of reasons I decided to go down this route.

Limited Liability

I’m offering a product for sale worldwide and while I don’t anticipate any issues, there is always the slim chance someone will decide to try and sue me over some obscure patent, copyright, trademark or some other reasons. That’s just the reality of the world at the moment, and I’ll sleep better at night knowing I’m somewhat protected since they can only sue the company and not me personally.

Tax Advantages

As an Irish citizen, there were a LOT of tax benefits to setting up a company to release my games. Since my short to medium term goal is just for my games to pay for their own costs (less my time), any money they earn can stay in the company account and only be subject to corporation tax (12.5%, and there are exceptions even to that for the first few years of a new business). As I mentioned in my last post, I work full time at another game company, so if I were to release the games under my own name, all income would be taxed on top of my existing income (at over 40%) and cause me additional headaches since I would need to register as both employed and self employed.

Professionalism

I think its just looks a bit better. I would rather have customers seeing a company name at the top of my products’ store pages than my own. I think it also adds a bit of credibility when contacting press or platform holders for featuring.

The Cost

The final deciding factor for me was that it was extremely cheap (and relatively easy) to set up a new company as an Irish citizen. It cost me €50 to incorporate the new company, and another €20 to register a trading name so I could drop the ‘Limited’ from the end of the company name on stores (it just looks better). I spent about 10-15 hours reading over all the relevant documentation and laws and then I was good to go. There is a bit of ongoing paperwork (doing accounts for example), but I didn’t need a lawyer or accountant to get started and as long as the company’s yearly revenues stays below a certain amount a year, I won’t need to incur any major costs like audits and don’t need to register for vat straight away. This process could cost you a lot more depending on where you are living however.

There were a few other costs related to the company though. I needed a company website for things like press kits (plus this blog and some cat photos). I also got www.aurorabound.com to act as a landing page for the game – I’m not sure if that was strictly necessary, but I got the url for €1 for the first year. The two urls, plus hosting for a year €90. I decided to make the website myself, because I wanted to save some money. I also decided not to just use WordPress at first, because I am stubborn, grouchy engineer at heart (pro tip – just use WordPress, it will be faster). I needed a company email address, so I got Google G Suite for €40 a year. You need support email addresses for some of the app stores, and it looks a bit more professional to not be emailing press from ‘superc00l_yeah@aol.com’ (that’s an example, but my spam email from when I was 14 isn’t much better…)

App Stores Registration Fees

One cost that isn’t optional is the various app store ‘registration costs’. I am releasing on the Apple App Store, GooglePlay, Amazon, Windows Store. The Apple App Store is €99, GooglePlay is €24, Windows is €93 and Amazon is free. The only hidden catch here is that the Apple App Store developer license is recurring , so its actually €99 a year (but that’s next years problem…) So that’s €216 to release on all 4 stores.

The Hardware

You need build machines and mobile devices to test with. I actually had access to everything I needed already, but my circumstances are a bit unique, so chances are you don’t… I do most of my development on my windows gaming PC, but I also have a 27′ iMac I got years ago for some ios Development at home. You need a mac to build and release on the Apple App Store and you need a Windows 10 PC to build and release on the Windows Store (and because Unity can be a bit of a pain to use on the mac). Since even a cheap second-hand mac can set you back a few hundred Euro, this could be a major expense for a few people.

test devices

Test devices are trickier – my main test devices are a cheap kindle fire and an old nexus 7 for android and my current iPhone 5s and old iPhone 4 for iOS. (I always prefer to test on older, slower devices – I can get a rough idea of how things look on my dev machines, but for performance you need to test on device). Those 4 devices really aren’t enough for proper testing however – you’ll need to test on few more android devices from different manufacturers (bare minimum would be a kindle, a nexus and a htc). You also want to test on different iOS devices – especially the newest iPad Pro to see what your game looks like in full retina resolution. Its pretty common to find rare bugs/inconsistencies that crop up across the different CPU/GPUs of the iOS device family. You also want to test on a few different versions of Android and iOS….

Luckily for me, I have access to all of these devices at my day job – and they have been very cool about me testing on them outside of my work hours. Without this, I definitely would have had to purchase at least a few of them – and the newest devices don’t come cheap.

The Game

So what about making the game itself? How much can it cost when you do ‘everything’ yourself?

First off, while I’m not counting my time as an explicit cost – I am aware of it. Anyone who tells you it cost them ‘nothing’ to make a game is lying to you. I’ll work out the exact times later for a retrospective, but I have probably spent about 400 – 500 hours working on the game in one form or another. That’s maybe 3 months of full time work, so the opportunity cost of that is theoretically pretty high. For illustrative purposes, I’m a C++ software Engineer when not making games and the average US salary for that is $115,000 – so $~28,000 for 3 months ). Now I’m doing all of this in my spare time, so I’m not missing out on any income, but there is still a cost – as of writing this I still haven’t started Zelda! Let alone the various games that came out over the Holiday season…. Oh, yeah – and missed time with loved ones, that’s also important…. (maybe not Zelda important, but still important!)

In terms of production costs, I did all of the design, programming, art, audio and marketing (such as there was) myself – for better or worse. I actually enjoyed switching between the different disciplines more that I expected, but I was never quite happy with how the audio turned out. There is obviously going to be a trade off in terms of quality and scope when wearing all the hats yourself. While I am confident enough in my design and engineering skills for example, I work with some really talented artists and my limitations in the field are made immediately obvious when I try to draw something to illustrate a point (my stick figures put other programmer art to shame…). This heavily effected the design of the game, as I adopted an art style I was confident I could pull off.

localisation

Localization was something I couldn’t do myself though (and if you are reading this and thinking to yourself ‘Google Translate’… No. Just No.). I wanted to launch worldwide and decided to localize in 14 languages – most of the major ones and a few that I suspect the Apple featuring team have a soft spot for. Localizing obviously broadens your potential markets, and not localizing reduces your already infinitesimally small chance at getting featuring from the major store-fronts. (As a side note, I really wanted to localize into Arabic, but Unity doesn’t support it by default – get on that Unity!)

I knew localization was going to cost a lot, so I worked to keep the number of words as low as possible and chose re-usable phrases where I could – some of those translations are going to be used in future games to help reduce costs! In total, I needed 175 words translated. As a side note, I strongly recommend you have all of your store pages filled out before you get things translated, there are a lot of small things you can miss like minimum and maximum string lengths or descriptions for IAPs. I went with keywords for the localization as they had localized apps I had worked on before – they weren’t the cheapest option, but their rates were reasonable, they were nice to work with and had a great turn around time. In total, localization set me back €440 including vat.

I also purchased a Unity License… which I am kind of on the fence about. My main reasons for getting it were to get access to an android profiler (which I probably could have done without for my game since I am pretty good at designing efficient systems at this point and I purposely tried kept it pretty simple) and to get rid of the basic splash screen (which is probably just industry snobbery on my part, since I doubt most casual users will care). I probably could have put off upgrading to their paid license tier a bit longer, but at least I got it towards the end of the project – the Unity licence set me back €464 (which is another recurring yearly cost). Thankfully all of the other software I use is either open source or free for a company as small as mine (Audacity, GIMP, etc)

What’s Left?

Surely that’s it right? Well, for me it is. But some of you might have noticed a distinct lack of market spend…. I’m not going to pay for ‘expedited reviews’ on principle, but what about advertising? For this game, I don’t think its worth it – its a fun game, but the monetisation is basic and it doesn’t have the kind of stickiness a modern free to play game needs to succeed.  I needed to stick to free marketing for this release – I have sent out promo codes to various outlets and YouTubers, contacted the stores in the hope of promotion, and will send out a few press releases on launch day (Oh, and I wrote this, this blog counts as marketing I suppose – If you are reading this and are on the Apple, GooglePlay or Amazon editorial teams, you should totally feature my game).

Summary:

App Store Dev Licence     :   €99 (per year)
GooglePlay Dev Licence   :   €24
Windows Dev Licence      :   €92
Amazon Dev Licence        :   0

Unity ‘Plus’ Licence          :   €464 (per year)

Company Registration      :   €50
Company Trading Name   :   €20
G Suite Company Email    :   €40 (per year)

Website Hosting and URL : €90 (per year)

Localisation                       : €440

Total Cost :  €1319

I am in the enviable position of not needing this game to turn a profit since I made it in my spare time. I hope people download it, play it and like it, but to pay back its ~1,300 cost I would need a lot of downloads once you factor in conversion rates (probably 100,000+). Luckily, I worked out the majority of this before I started and knew what I was getting into – and I really enjoyed making it. Some of those costs won’t come up again, and depending on how many games I make a year, some of them can be spread out. The next game should cost me less, as will the ones after that, and I do plan to keep making them. Hopefully, if you decide to make your own games, this post will help you go into it with your eyes open.

Oh, and in the mean time you can follow me on twitter here: @finalgamestudio (see? more free marketing)

Cat doing the budget

Part Time Indie Game Development

Making a sustainable living off indie games is difficult.

Whether you believe in the indiepocalypse or not, please take that statement as fact. There are hundreds, if not thousands, of new games and apps being being released every week and even if you do manage to rise above the noise and have a hit, that is no guarantee you will manage to do the same again next time.

But that’s probably not going to stop you making games – it’s not stopping me. Not a single day has passed in the last decade when I haven’t had an idea for a cool or interesting game I want to make and I am determined to make at least some of them. But personally, I want to make fun, polished, completed experiences for players to enjoy – not unfinished game jam prototypes. And I know this might come across as greedy, but I want to do it without quitting my day job, burning through all of my savings, living like a pauper and putting myself through a mental and physical endurance test.

So the question I asked myself last year was, can I make the kind of games I want to make in my spare time?

My Motivation

So, not only do I currently have a full time job – it’s a game dev job. I have been working as a software engineer at StoryToys making kids apps for the last 5 and a half years or so. In that time, I have lead the development of over a dozen apps in a variety of engines, worked in multi-disciplined teams with some really talented people and generally learned a lot. The work I get to do is challenging and rewarding, and while it has its ups and downs, I enjoy it and I plan to keep doing it… So why am I writing a post about part time indie game development?

Well, because I’m doing that too and there are a couple of reasons for that;

The first is that as much a I like making kids apps (seriously, seeing a 4 year old jump up and cheer out loud over something you made is an awesome feeling), there are lots of other types of games I want to be making as well. If anything, there are too many other types of games I want to be making, and frankly it’s hard to get management to greenlight a tactical rts or dark fantasy rpg when your company’s core demographic is 2-10 years old.

The second reason is creative control. While I am very lucky to have a huge amount of creative input into everything I work on at the moment, there are always going to be things you would do differently if you got to call all the shots. It’s a very different experience being in complete control of every facet of a game from Marketing to UI and Game Design to Programming.

The final reason I’m making my own indie games part time is the fact that I was doing it anyway – I just wasn’t doing it very well. I have been making little game prototypes and thinking through game design ideas in my spare time for years, but I usually didn’t make a lot of progress with them. I’d have an idea, work on it for a few hours or days and then leave it unfinished when something else came up or I hit some part of it I didn’t really want to do (looking at you networking code… ). I didn’t have a clear goal or a lot of motivation to finish them, so I didn’t – and over time that started to really bother me, so I decided to change it.

What was getting in the way?

While I was certainly learning from researching and making all of these prototypes in my spare time, I couldn’t shake the feeling that I was just wasting a load of my time and not getting any tangible benefit from it. I wanted to make finished, polished games and release them for people to play and as many of you know, there is a VERY long road from prototype to finished game.

I identified the main reasons I would stop working on something.

Not Fun:

I could discover the game idea just wasn’t fun to play – that reason is fine and perfectly valid, and generally becomes obvious after a few hours at most. 

Boring Details:

I would hit a part that was a pain in the ass to work on. This was more of a problem – I just don’t enjoy coding up certain low level things like setting up a C++ rendering engine.

Scope:

Another big problem was scope – not scope creep, just scope. I usually didn’t have clear goals or limitation when I started prototyping something, so I often ended up in a situation where I would find something really fun and then realize my idea would take over a year full time dev work to actually complete ( examples include a multiplayer RTS game and several RPGs with a procedurally generated world and stories ).

Interruptions:

Finally, the biggest hurdle to finishing these prototypes, at least for me, was just leaving them for a while and not coming back to them – maybe a new game came out I wanted to play, or I wanted to work on something else for a while… basically, if I left a project unopened for over a week it was as good as dead.

What changed?

Clear Goal:

I wanted to make and commercially ship finished games, and I wanted to make them in a (relatively) short amount of time to keep the finish line in sight and my motivation high. I decided I wanted to ship my first game within 6 months of starting on it ( Which meant picking something I thought I could get finished in about a month since I am experienced enough to know how estimation and scope creep work… ).

Plan for the future

I intend to continue making games in the future, so I was willing to front-load some of the work into the first game to start off on the right foot. I designed elements of code/UI/Design to be somewhat re-usable in future games I have planned. I also formed my own company to publish the games under and set up some other boringly-important things like a company website and email.

Work consistently

I knew I needed to work on one game consistently and for me, that meant 2 hours a day, every day, with an extra 8 hours spread over weekends. I have traditionally been very good at making excuses for myself, so to get into the habit, I didn’t let myself skip a single day for the first 2 months of work. After that, I relaxed it a bit to allow for, well, a life… but I have been sticking to this schedule pretty well for the last 6 months. To some of you 2 hours might not seem like a lot, but it was the absolute max I was willing to commit to. My day job can be pretty draining at times and I also wanted to make sure I still have time in the evenings to relax, enjoy myself and spend time with my girlfriend.

Enjoy the work

This 2 hour timescale lead me to decide on another rule designed to keep my motivation up and generally make sure I was actually enjoying working on my own games: No feature goes in that I can’t make in satisfying 2 hour chunks. At the end of each session, I wanted to commit a fully working/compiling version of my game and feel like I accomplished something useful, whether code art or sound. I have broken this rule a few times and regretted it every time.

Design a game to suit this approach

The short timeline, combined with broken up work schedule, led me to design a game that was not only much smaller in scope that most of my previous prototypes, but also much simpler. The only goal was to make a fun game and any features that weren’t going to achieve that or were a pain to implement got cut. That meant no networking, no third party SDKs, no monolithic pieces of cool new tech. That’s not to say my games won’t have these in the future, I just intend to introduce anything like that over time – maybe one large piece of new tech per project?

Has it worked?

So far, things are going great.

I submitted my company’s first app ( AuroraBound ) last week to the Apple, GooglePlay and Amazon app stores – It will be released on May 9th. I am also preparing Tizen and Windows store builds this week. AuroraBound is simple, fun, polished and, most importantly to me, I really enjoyed making it – the last 6 months have probably been the most rewarding of my life. I don’t expect it to be a large commercial hit (the monetisation model is simplistic and getting PR/featuring for a new app is pretty tough these days), but I don’t need it to be.

I have some future updates planned, as well as some ideas for a deluxe desktop version, and after taking a few days off to finally play the new Zelda game I’ll start work on my next title. Throughout the entire development of my own game, my work at my day job never slipped (quite the opposite actually, I was able to make use of a few things I had discovered during AuroraBound’s development ).

I plan to keep making more and better games in my spare time, and maybe one day I will take the plunge and go Indie full time – but if I do, I’ll be doing so with my eyes open, invaluable experience, an existing codebase, a catalog of existing apps and relationships with some the major platform holders.

 

Starting a Dev Blog

Well, the title of this post is rather self explanatory… Hopefully over the coming months I’ll get around to filling this blog section with tons of interesting musings… or musings at least…

In the mean time, if you are reading this I guess I haven’t quite gotten around to it yet. (Or I did, and it was so good you already read it all and then reached this post which I kept around for posterity or something…)

For context, I am hoping to submit the companies first app in the next week or two, and then start work on the next one ( by which I mean go play Zelda Breath of the Wild… which I haven’t let myself start until I get AuroraBound submitted… )