It’s not often that we get to talk about the game development process. Most of the time we are bound by contract not to discuss anything. Cloney certainly was a nice change for us, being able to debrief publicly. Cloney presents a rare and wonderful opportunity to discuss some of the decisions made throughout the process. Divulging what it actually took to get a simple game made from start to finish in a postmortem.
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.
Origin
It all started on the morning of February 6th, 2014. I was on the phone (Skype) with Mike (Fortais) talking about a project we were working on. We were both commenting about the success of Flappy Bird. How it had absolutely nothing new in the manner of game mechanics or controls. Yet it had cult-like success and a loyal fan base. For some time, our studio has prototyped all sorts of radical gameplay mechanics, benching most.
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 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, 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.
Budget
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. 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 aid in the process. I’m not talking about people’s time here either, that’s a whole other world of hurt.
It was only later, after watching my son play the prototype I made the decision to dedicate some more resources toward the project (audio!). He really liked the simplicity of the game, and was easily able to find 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 real 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.
Graphics: $87.00
I was very fortunate to find 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. I did spend the better part of 8 hours working on the final UI that is seen in the game (not the picture below!).
Audio:$750.00
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) a bit.
First and foremost, I should make it very clear; the number of sound effects and music clips that I got for this game at that price was WELL below the industry rates. 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 many projects. As Alex put it, I am one of 6 people in the world that could get that pricing. So one might say, I owe him.
That being said, I strongly believe that audio budgets for games seem to get overlooked. While visuals play a strong role in user immersion, I feel audio plays an equal part. 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 first 24 hours of game development, I actually did place in stock sounds. 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.
Plugins: $210.00
There are 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. Thankfully due to our history of making titles for other companies, we had built up a collection of plugins. Of course, something we have never targeted before was the Mac App Store. 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. 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 hickup is present the first time an ad is shown. This hick-up is deadly in consideration of Cloney’s gameplay. I made the decision to remove ads from older (slower) devices.
Operations: $245.95
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 website thing myself if I had to pay someone, it quite frankly would not have been done at all. One of the other 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 our API to be able to store tagged datasets in an efficient way (yay cross training!). All of the scores in the database are tagged with the associated platform that they were sent in from.
Our API (called UnityForge) was originally intended for the 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“.
Total
The total cost of the project now sits at $1,292.95 USD.
Of course, we are not an American company, so that will convert out to be a bit higher. This amount also doesn’t include the cost of my time throughout the 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 extra $5,000 USD on top of that figure. Another thing to consider is 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.
Development
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 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.
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.
Being realistic
The first thing to realize about a 24-hour deadline is being realistic about 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 an AAA quality game in 24 hours; you need to think smaller, something like 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 find 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 larger project. I should also note that after my first 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 to throw away money. Another lesson learned the hard way; it seems that’s how I always learn my lessons.
Testing
I cannot stress enough the importance of having people other than 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 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 tell 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 pick up and play within seconds.
This predicament spawned the help mode, trying to just show and highlight things that you could and couldn’t do. While it is not the perfect solution, it did carry out at a basic level the goal of showing off the avoidance and collecting mechanics of the game.
Production-ready
When development started on Cloney, I chose to use a preview version of Unity. It contained some new features UI in development. I wanted to check them out and get a handle on them before release. As development progressed, many 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 fault, I knew the risk of using unreleased software. 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 workaround, I found that I had to downgrade the project to an earlier version. While that wasn’t so bad, as I had used 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.
Silly mistakes
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 first Mac App Store release was rather straightforward. 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 running Cloney on an older iMac. My son watching, 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. The release package was almost done its cooldown 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. A simple mistake of not thinking about older platforms cost me five days of release cool down.
Apple does give a little option to flag your upload as a major usability fix (or legal concerns fix). I am not entirely sure if that affects your timeline, or if it is merely used as they mention to prevent earlier versions from downloading.
Deployment
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. I 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 in the marketplace. It needs to grab their attention instantly. I tried all sorts of things with fancy pin striping and effects, but with my limited graphical abilities, I had to be realistic. Modifying existing icons or just following a tutorial would prove the most productive. So clearly, the new icon spawned of Angry Birds influence.
Steam’s Greenlight
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 part of the active Steam user base is considered hardcore gamers. Which is 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 discuss. It took some restraint not to respond to some of the more hate-filled comments. 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.
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. 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 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. We 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 the screen that had to be tapped in increasing order. This mechanic had been used earlier 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.
iAds
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 around; 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.
Google Play
From my experience, putting a game on Google Play is relatively simple and straightforward. 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.
Marketing
I really never gave much thought to the marketable side of the game, nor will I really do much in that regard. The original website provided 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 read 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.
Who needs a plan
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 shine. 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), and (not surprisingly), got no response.
In reality, I can’t really blame anyone for not caring much, the game is a clone. This does make me question how Flappy Bird was able to gain the traction that it did in the first place. I know the rumors 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
Task Management
In trying 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 and creating my normal test setup with NUnit (or more recently Unity Test Tools). The time I saved not mapping out everything in Trello/JIRA was substantial. This is not feasible for a project any larger than Cloney. Especially if you have more resources working on a project. So, while I wouldn’t have changed that in this case, I think it’s important to note. 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. There was just so much going on that I couldn’t keep track of everything. The 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 only 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 thereof)
I knew from the get-go that I 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 other complimentary mechanics.
When the project 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. Those ultimately copied their forefathers’ generation of games (you get the point).
The future
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. This would give a visual representation of the count up to speed increase.
I would love for Cloney to make some money back, 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. 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 get there. 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. I take away from this experience some lessons which I feel are worth sharing:
Just do it
I need to stop being so critical of our prototypes and determining whether they are a viable investment. There is, of course, a line to be drawn in the sand. However, empowering a developer to create something that is their passion should affect my decisions.
Haters gonna hate
As you can suspect, a clone of a game that is meant for the casual space was hated on by the hardcore gamer. Not letting their comments discourage my decisions or directions was important. It was also important to look at their opinions 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.
Set limits
Knowing you only have a certain amount of time to work on something, magically it gets done faster. Whereas, if you are working on a project and there is no specific timeline. That project could take forever for all you care. I set 4-hour timers for this experiment. 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.
Game over
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.
