It’s not often that we get to talk about the development process of a game so publicly as we can with Cloney; most of the time we are bound by contract not to discuss anything, so this certainly is a nice change for us. Cloney presents a rare and wonderful opportunity to discuss some of the decisions made throughout the development process, the mistakes, and divulge what it actually took to get a simple game like Cloney made from start to finish, in a postmortem of sorts.
One last thing before I begin; this game was never intended to be anything spectacular. It was merely an exercise in creating something simple and putting it out there. However, through some twist of fate it found a special place in the heart of a child which meant that it was given some extra love along the way.
It all started the morning of February 6th, 2014. I was on the phone (and by phone I really mean Skype) to Mike (Fortais) talking about a project we were working on at the time. We were both commenting about the success of Flappy Bird, and how it had absolutely nothing new in the manner of game mechanics or controls yet it had cult-like success. For quite sometime, our studio has prototyped all sorts of radical gameplay mechanics, but far too often we have chosen to bench them instead of taking the risk to see an internal project through to production.
The reason Flappy Bird is so popular is that it happens to be something different from mobile games today, and is a really good game to compete against each other - Dong Ngueyen
The joke was that I could take a bunch of stock assets and create a clone of the clone in a day. It seemed like a reasonable challenge, and with our past experience creating infinite runners, I was already familiar with many of the technical hurdles of the process. I don’t know what pushed me over the edge to actually start; it could have been some of the hilarious tag lines that we came up with for the game, or that I am not one to ever back down from a challenge. As I started to look at some stock assets, I began to envision a cute little game that my son would love to play.
Initially I had no particular budget in mind, I just knew I needed some basic stock assets to play with and would go from there. I estimated that I could make this game from start to finish for about $500.00 (and if it wasn’t for some decisions later on, I probably could have too!). As an indie studio, when we prototype something we typically don’t allocate more than a few hundred dollars toward stock to assist in the process (I’m not talking about people’s time here, that’s a whole other world of hurt), so I based my estimates around that idea.
It was only later, after watching my son play the prototype I made the decision to dedicate some additional resources toward the project (audio!). He really liked the simplicity of the game, and was easily able to identify the mechanics of “staying alive” and “collecting coins”. Of course having a cute little dragon character as your avatar helped a bit too.
I’ve tried to breakdown the actual costs below into a few categories, specifically outlining what costs could be recouped by reuse in other client work, and sadly what I classify as throw away costs, where the money was effectively wasted but needed to be spent to put an idea to rest.
I was very fortunate to find the Michael Orkisz’s 2D Art Pack early on in my search for a style to work with; I instantly knew that I wanted to create the game using it. Thankfully the package was made with tiling in mind (this guy is a pro after all) and I was able to quickly integrate it. The art budget was relatively low compared to other things, much of that is a result of the quality of the packages I found on the Unity Asset Store. Something to note about the visual budget is that while the 2D Art Pack didn’t require much work, I spent a significant amount of time working with the GUI pack that I picked up just laying out how the GUI would look. I am by no means a graphics designer type person, so that could have played into my effectiveness, but I did spend the better part of 8 hours working on the final UI that is seen in the game (not the picture below!).
One of the things that stands out about the budget, is the disproportionate amount of money that I spent on audio for the game. This was a decision that was not made lightly as it bumped up the investment (and risk) quite a bit.
First and foremost, I should make it very clear; the amount of sound effects and music clips that I got for this game at that price point was WELL below the industry rates and for anyone else you should expect to pay at least triple that to any good audio firm. I have worked for many years alongside Funky Rustic on numerous projects and as Alex put it, I am one of 6 people in the world that could get that sort of pricing. So one might say, I owe him.
That being said, I strongly believe that audio budgets for games seem to get overlooked far too often in favour of visuals. While visuals play a strong role in user immersion, I feel audio plays an equal part when it comes to interfacing with our senses. The visuals in Cloney were already strong due to the great stock I found early on, so I wanted to match that level of quality with even more awesome audio. For all those people saying “you could have gotten great stock audio”, you are absolutely right. I could have done that, and during the initial 24 hours of game development I actually did place in stock sounds and it sounded horrible as none of them matched in style, which is often a telltale of stock usage. The investment in stock cost me about $80 that I had to throw away; lesson learned.
There is all sorts of little extras that go into games when they target mobile; specifically in the area of platform specific features and social connectivity. This is the area where the costs could have really soared for this project, but thankfully due to our long history of making titles for numerous companies, we have built up quite the nice little collection of plugins that make our lives easier when it comes to this. Of course, something we have never targeted before was the Mac App Store, and with that being one of our points of release, it was a no brainer to continue our faith in Prime31‘s long list of Unity plugins. One of the methods that I had hoped would drive some revenue was ad placement on devices which supported it (mobile). However, when I used some of the included iAd features with Unity; I ended up having more headaches with random crashes on devices than it was worth, thus I turned to a Prime31 plugin to remedy the situation. One thing to take away from the iAd headaches was that on older devices a small hick up is present the first time an ad is shown. This hick up is deadly in consideration of Cloney’s gameplay and as such I made the decision to remove ads from older (slower) devices.
These are some of the hidden costs which I never really thought about until I actually went to release the project. I was very fortunate to be able to do the whole website thing myself, if I had to pay someone, it quite frankly would not have been done at all. One of the additional features Cloney offers is a world-wide, platform-independent leaderboard. I accomplished this by utilizing some of our already existing infrastructure for handling leaderboards. With a little work, I was able to extend UnityForge to be able to store tagged datasets in an efficient manner (yay cross training!). All of the scores in the database are tagged with the associated platform that they were sent in from.
This system (UnityForge) was originally intended for distributed building of Unity projects, however has been extended out to also offer data storage and retrieval opportunities. We haven’t gotten it to a point yet though where it is available for public consumption, that is one of those “Friday Projects”.
The total cost of the project currently sits at $1,292.95 USD.
Of course, we are not an american company, so that will convert out to being a bit higher. This amount also doesn’t include the cost of my time throughout the whole process. I am very lucky to have such diverse skill set that allowed me to do much of the heavy lifting myself; if I had to pay staff to develop this game, I could easily see an additional $5,000 USD on top of that figure. Another thing to consider is the fact that a Unity license runs about $5,000 for what is needed for Cloney. The price quickly adds up as you start to factor in all the other things involved with making a game; and Cloney was an extremely simple game to make.
Making a game in 24 hours sounds like a great idea, and let me tell you right up front, IT IS!
It was a fantastic experience, which brought me back to my roots of development and just getting the job done. One of the smart things that I did was setup Screenflow to record my screen. Initially this was meant so that I could produce a nice little time lapse video of the whole game getting put together, however it developed so many other useful side-effects. It was a pain at times as it meant that some personal messages were recorded and would have to be edited out, but it served as a constant reminder that I was on the clock and was accountable sort of.
Disclosure: Part of this challenge was to create a game as a surprise for my son over a weekend. I’m sure all the parents out there will appreciate the motivation of creating something for their children.
The first thing to realize about a 24 hour deadline is being realistic with your expectations. I am not the first person to stress this, nor will I be the last. You are not going to be able to build a AAA quality game in 24 hours; you need to think smaller, something along the lines of a prototype but with a bit more polish. It was because of having a clear goal that I was always able to stay on task.
This resulted in me developing a day-to-day work ethic counterintuitive to my norm. I did not use a task list as it would have just slowed down my entire process. Because the game’s goal was simple, I was always able to identify what needed to be done next by simply thinking about how the game would play out. Any time I came across a bug, I immediately fixed it, therefore there was no need to write it down. This approach worked great for a small rapid development process, but would be a terrible idea for a much larger project. I should also note that after my initial 24 hour sprint I created a task board on Trello to keep track of tasks as I wouldn’t be completely focused on the project after that first 24 hours.
Early on in development I thought about experimenting with some stock game kits to accelerate the process, however I quickly realized that most of them are great for people just getting into making games, but they will frustrate an experienced programmer. Thus, those experiments cost me around $80.00 of throw away money. Another lesson learned the hard way; it seems thats how I always learn my lessons.
I cannot stress enough the importance of having people other then yourself and those close to you play your game. What I thought was a pretty simple thing to understand, apparently wasn’t.
I had thought that collecting coins and avoiding the branches was a pretty simple set of mechanics, but as it was so elegantly pointed out to me:
“Why can Cloney fly past the tree trunks and the wood parts of the branches, but not the leaves, what are they some sort of poisonous death leaves?”
It was a harsh smack in the face, but a very necessary one. I had created a visual representation of the whole avoidance mechanic that didn’t make any sense to a person playing the game for the first time (an amateur move on my part, I really should have known better). This late into development I ran into a predicament of how or what I could do to inform the user of what they could and couldn’t touch. It wasn’t as simple as having some sort of story element explaining it would be sufficient, this was a very real problem when it came to my target audience. A casual gamer doesn’t want to sit there and read a manual, they want to be able to pickup and play within seconds.
This predicament spawned the help mode, an attempt to just show and highlight things that you could and couldn’t do. While it is not the perfect solution, it did accomplish at a basic level the goal of showing off the avoidance and collecting mechanics of the game.
When development started on Cloney, I chose to use a preview version of Unity which contained some new features in development. I wanted to evaluate and provide feedback on (no better way then to put them through their paces than making a game using said features). As development progressed, numerous updates came out, which, for the most part, vastly improved things. However, as is the risk of using any pre-release software I eventually got caught (let me make myself clear, this was entirely my own fault, I knew the risk of using unreleased software) in a situation where there was a regression that was highly visible in Cloney. A core part of my GUI was broken, and after some attempts to find a work around, I found that I had to downgrade the project to a previous version. While that wasn’t so bad, as I had been using a version control system (GIT), an ugly issue caught me off guard where the older engine build had some platform specific crashes which had since been corrected, thus leaving me unable to deploy to a certain predominant robot related mobile platform.
Over the course of development I was bound to make some silly mistakes. They did happen, but because of my decision to fix bugs immediately upon running into them, the situation never turned terribly grim . Where little bugs started to cause a dramatic impact was when I was trying to get the game approved on different platforms.
The initial Mac App Store release was rather straight forward, and I had thought when Apple stated that it would work on OSX version 10.6+ that they had actually tested it on those older versions. I can only imagine the look on my face as I went to run Cloney on an older iMac I have for my son, only to have the main menu never pop up. This sent me panicking as I knew I had a pending release for the Mac App Store, that was almost done it’s cool down period and would be out any day. The pending release would also bring all of the features available in the mobile version to the desktop (yay feature parity!). A simple mistake of not thinking about older platforms cost me five days of release cool down.
Apple does provide a little option to flag your upload as a major usability fix (or legal concerns fix), but I am not entirely sure if that effects your timeline, or if it is merely as they mention to prevent previous version download.
When I originally started working on Cloney, I whipped together a quick logo and icon for it within 30 minutes and was quite happy with it. However, as time went on, I grew tired of it and realized that other people wouldn’t have their interests piqued by a boring icon either. The icon is often the first thing that someone is going to see on the marketplace, and as such, it needs to grab their attention. I tried all sorts of things with fancy pin striping and effects, but with my limited graphical abilities I had to start thinking about modifying existing things or just following a tutorial. So clearly, the new icon spawned of Angry Birds influence.
When it comes to selling a game on PC, there really is only one viable platform, Steam. Whilst there are many great competitors, they all pale in comparison to the install base Steam boasts. Depending on how you look at it, fortunately or not, a large component of the active Steam user base is considered hardcore gamers. Which in the case of Cloney, are definitely not the target market, and as I learned were not so receptive to a casual game.
Enter the haters.
It was this market segment difference which provided some of the more colourful comments about the game that I have received. It’s an unfortunate demonstration of stereotypes which I’m not even going to address. It took some restraint not to respond to some of the more hate filled comments that users were posting about the game being a clone of Flappy Bird. However, I did find some solace in the fact that most of those commenters didn’t realize the irony of the name Cloney, nor did they understand any of the sarcasm present in any of the quickly generated marketing material.
At a cost of $100.00 to be able to submit a game to Steam’s Greenlight review process, and an already stretched budget, making the decision to put Cloney on Greenlight was one which I still don’t think was worth it.
Mac App Store
This was surprisingly one of the best decisions that I made when it came to the deployment plan.
While distribution on Windows and Linux based machines still is primarily dependant on Steam, Apple has provided an easy way for developers to get their title out with a rather simple process. It took very little work to include the plugins purchased to accommodate for the mac platform release, and within a few days (5) of submitting the signed application to the Mac App Store for review, I received a successful approval, and within hours sales started happening. Of course, this was a bit of a stressful situation as the version that was approved was a few versions back from the current iOS version and I hadn’t even submitted a feature parity update for review yet.
iOS App Store
The process of getting your game into the iOS App Store is quite simple nowadays (ya I said that, and some of you will know what I mean), however we ran into something which we did not expect causing our initial rejection. I missed a new rule for iOS 7 where purchases or even leaving an application (like I do for the worldwide leaderboard) must fall behind a “parental gate” if your application is marked as “Made for Kids”. Clearly, Cloney was made for kids, so of course I flagged it as that in the submission, and as such paid the cost (7 days!) of not having adequately reviewed the rules. Doh!
I scoured the internet for different examples of parental gates, and found that there was no exact standard. Apple had a subjective decision over what satisfied their requirement for a parental gate. There were some methods that other applications had used that had been approved, so I started there. My first attempt was to create 3 random numbers displayed on screen that had to be tapped in increasing order. This mechanic had been used prior, and seemed to be the quickest and cleanest to implement, however it seemed too simple. So I increased the required numbers to 4 and away I went.
The iOS version of the game is supported by iAds. However, for the same price as purchasing the game on non ad supported platforms ($0.99) they can be removed. Giving the purchaser that warm and fuzzy feeling of supporting a good cause (yay!). Having to “approve” In-App Purchase (IAP) items for submission separate from your main application can be daunting the first time a round; even now I still forget to approve them when I go to submit something, only to have it rejected because of it.
So there is one problem with the iOS App Store, and that is the review times, they are absolutely brutal. When you’ve gotten rejected, you have to resubmit your application again, and it must wait the automatic cool down period (6 days?) before the reviewers will look at it again. That seems a bit harsh if you are simply correcting a minor mistake.
From my past experience, putting a game on Google Play is relatively simple and straight forward, however at the point of writing this article Cloney is still unable to run on Android. Unity has always been very responsive when it comes to my bug reports so I have no real doubt that it will get sorted out over the next little while. I plan on using the same model that I did with AdMob instead of iAds for a possible revenue stream.
I really never gave much thought to the whole marketable side of the game, nor will I really do much in that regard. The website provides a great hub of information and thanks to all those people that contributed to the project (even if they didn’t know about it — stock providers, etc). The question that I’m faced with right now is:
How could I market a game which is effectively a clone of many other games out there?
I have been reading that a third of all new app submissions to the iOS App Store are Flappy Bird clones. So what sets Cloney apart? For me, I know the answer is simply the production quality behind it.
While the first 24 hours of Cloney were a race to the finish, the month or so that I spent off and on afterward adding polish and tweaking things definitely let Cloney take a step up on all the other games in its class (in my honest opinion). Yet, how do I convey that message? I decided to fire off a few emails to different media outlets to let them know about the title, following some advice on how to do the submissions, I received no responses as of yet. For fun, I decided to reach out to the big three platform holders (Sony, Microsoft, Nintendo) about Cloney, and (not surprisingly), got no response.
In reality, I can’t really blame anyone for not caring much, the game is a clone, yet this does make me question how Flappy Bird was able to gain the traction that it did in the first place. I know the rumours just as well as the next developer, I just don’t want to believe them.
I may try and reach out and contact a few other websites, but I’m not holding my breath.
Things I Would Have Changed
In an attempt to create this game as fast as possible, I avoided some of the time tested development practices that I am used to in my day-to-day operations, specifically task management (via Trello in most cases) and creating my normal test setup with NUnit (or more recently Unity Test Tools). The time I saved not mapping out everything in Trello was substantial, but not feasible for a project any larger than Cloney, and especially not if you have additional resources working on a project. So, while I wouldn’t have changed that in this case, I think it’s important to note that not using some sort of task management system would be a poor decision.
Test Driven Development
There were all sorts of little bugs that crept up and were difficult to find simply because of the sheer scope of what I was doing in a condensed time period. There was just so much going on that I couldn’t keep track of everything and little slip ups in code lead to much larger wastes of time tracking down improper results. This is where I love NUnit, although more recently I’ve adapted to using Unity’s own offering. If I had created a set of tests which made sure the functions were all behaving as expected, then when I made a few changes late into development to the core system, I would have instantly seen feedback that I had borked it up real good. I guess this is why I like to use it regularly when developing, time permitting.
Originality (Or Lack There Of)
I knew from the get-go that I personally would have an issue with the fact that I was just recreating a game that was already out there. While other developers may not have a problem with that idea, I fundamentally always have. I have always wanted to create games which are different from others, with mechanics that set them apart. I would have liked to inject more originality into the game, possibly with some sort of additional complimentary mechanic.
When the project first started out, it was called “Forest Runner”. It’s rename to Cloney was merely to make a blanket statement that the game was a clone of all the other clones which cloned other games which were based on clones themselves, which ultimately copied their forefathers generation of games (you get the point).
Realistically there isn’t much more that can be done with Cloney from a development sense. On Trello there is one remaining development task to investigate the possible addition of showing some sort of number effect when you pick up coins to give a visual representation of the count up to speed increase.
I would love for Cloney to make back the money that I have put into it, however I am not counting on it. The investment into Cloney doubled as an investment in creating something that my son had a hand in. He got to see a glimpse of what his father does for a living (at an understandable scale), and the fact that he plays it every day is merely the icing on the cake. He’s not very good at it yet, but I think with some more practice he will be taking the top spot on the leaderboard soon enough.
I guess it’s back to my regular job of creating great titles for clients, however I take away from this experience some lessons which I feel are worth sharing:
Just Do It!
I need to stop being so super critical of our prototypes and determining whether or not they are a viable investment. There is of course a line to be drawn, but empowering a developer to create something that is their passion should be my top priority when making decisions (for myself or others). The product that would be created will have more blood, sweat and tears in it than anything that I could pay someone to create.
Haters Going To Hate
As I suspected a clone of a game that is meant for the casual space would get hated on by the hardcore gamer. Not letting their comments discourage my decisions or directions was important; however it was important to look at their feedback and see what I could do to improve the game. Even if it wasn’t going to win them over, it still improved the gameplay to some extent.
When you know you only have a certain amount of time to work on something, magically you start getting it done in that time. Where as, if you are working on a project and there is no specific timeline, that project could take forever for all you care. I purposely set 4 hour timers up when I was working, in which I had specific goals in mind that had to be done during that time. It was amazing to see how fast things got done when I was in the hot seat.
Well that about sums up everything that I’ve got to say, hopefully I didn’t babble on too badly about anything. If anyone has any questions or comments by all means ask away.