The Making of Game of Clowns

April 17, 2016 - Uncategorized

I’ve just released my Unity game, Game of Clowns on iOS (it’s been on other platforms for some time already), and I thought it would be helpful to explain how I made it.


Game of Clowns is a physics puzzle game in the tradition of Amazing Alex and The Incredible Machine. It’s my second game, but my first made in Unity (my first game, Puzzle Detective is available for Windows Phone, WinRT, and Windows 10, and was built in Visual Studio). I was totally new to Unity and C# when I embarked on making this game.

A Naïve Effort Assessment

After playing around in Unity I discovered the Asset Store, and found that I could buy a pre-built game template. I figured I could replace the graphics and audio, build my own levels, and – ABRACADABRA! – have a complete game. To cut a long story short the game took more than 6 months of every spare minute I had (making games is not my day job), and far more work than I anticipated.

I learned a lot while making the game, and I’m now sharing what I learned in this article.

Designing the Game

Game of Clowns isn’t a particularly original game (it was built using an Asset Store template, after all). My main motivation was to build something like Amazing Alex because it wasn’t available my Windows tablet. I also figured that a physics puzzle game was manageable, but also more challenging to make than Puzzle Detective.

With a genre chosen, my next decision was to pick a theme that suited it. I ended up with two ideas:

I decided on the circus theme because it could be colourful and funny, but most importantly it could feature clowns being shot out of cannons.

Scope Creep

Two factors led to the game’s scope increasing hugely.

Firstly, I found that the template I was using had a few issues (the makers of the asset, as well as users on the asset’s forum thread, were very helpful in resolving them), which required me to increase my Unity and C# knowledge sharply.

Secondly, the more I worked on the game the more my ideas flowed. I wanted to add new physics objects (which I would have to build myself with my still limited Unity skills), and improve existing features. The amount of work needed was creeping up.

I realised that the game would take a lot longer to finish than I had first thought.

Lessons Learned

Making Progress

I developed an organisation technique when creating my previous apps and game. Every task I’ve identified – whether it’s as small as fixing a typo or as big as adding a huge feature – goes into either my current working checklist or put aside for future work. Keeping a good balance of ‘quick wins’ and more substantial work in my current checklist helps keep momentum. If I only have a few minutes to work, I can check off one or two quick wins; if I’m in the mood for digging into the code I can work on a large feature; if I’m feeling like Sherlock Holmes I can investigate an elusive bug.

Using this checklist method, I found I could stay motivated even as the scope got bigger and bigger, because there was always a task waiting for whatever mood I was in or how much time I had. When I complete a checklist I mark that ‘version’ complete and create a new checklist from outstanding tasks.

Lesson Learned


Once I had momentum I decided to buy some art. Due to the game’s design I didn’t need any animation or a lot of art, which suited my limited (non-existent) budget.

I found a great artist (via Reddit) who was able to draw what was in my head perfectly. This clown with a hose is my favourite piece:

Here’s how I sourced all the art in my game:

I spent a few hundred dollars on art, and I’m very happy with the outcome on that budget. The art that was drawn specifically for me is perfect, and I’m pretty happy with what I achieved with the public domain and licenced art too.

Commissioning Art

When commissioning art I sent the artist some sample images showing the style I wanted, along with a few notes. When I needed a clown driving a tiny car I sent these images to the artist:

And here is what she created:

Fantastic art, and exactly what I had in mind.

To stretch the usefulness of some of the other art, I created different coloured variations using a simple image editor. The game template asset came with a small red ball sprite, which I used as the basis for some different coloured balls. This simple trick makes the game livelier at no extra cost.

Lessons learned

Building up the Engine

I estimate that by the time the game was finished I had rewritten more than half of the code that came with the purchased asset in order to accommodate my game’s needs, enhance features, and fix bugs.


I must make it clear that I didn’t rewrite chunks of the asset code because it was deficient. I wanted to expand it to allow for new features and to better fit my evolving ideas for the game. There were a few minor bugs, but the asset creators always helped fix them. There is a pretty big thread on the Unity forum where myself and several other users shared ideas and code for improving the asset too. I also learned a lot about Unity from the code provided in the asset.

Here are a few of the features I ended up adding to the game:

Unity itself presented some challenges. Some of the 2D collision functions didn’t work reliably, which caused unpredictable bugs. I ended up adding workarounds and hacks that required me to learn lots more about Unity.

Lesson learned

Music and Audio

When I started adding audio and music the game really started to come alive. I knew I wanted the classic clown theme ‘Entrance of the Gladiators’, and I found a reasonably priced version to licence. Then I found a few licenced and public domain tracks that had a circus feel, and set the music to rotate randomly between the tracks. I spent about US$30 on music. I wish I could have afforded a custom theme song for my game, but the game’s theme luckily lends itself to the well-known, well-used ‘Entrance of the Gladiators’ theme.

This game trailer includes the famous clown music:

All of the audio is public domain, but there isn’t much. Audio is one area I wish I’d spent more effort on, but by the time I was filling in the sounds I was trying to limit the effort needed to reach the finish line.

Lessons learned

Levels, Levels, Levels

Game of Clowns has 88 levels (some of those were added in updates after the initial release). That’s quite a lot of levels. The amount of work that went into designing, building, and testing the levels was probably 100 times more effort than I anticipated (I’m not exaggerating). Every level was carefully designed, sometimes on scraps of paper, sometimes in my head as I rushed to the computer before the idea evaporated.

So Much…Fun

Designing physics puzzle levels is fun. There is something tangible about objects behaving realistically. Watching a clown shoot out of a cannon, bounce on a trampoline, collect a star, then fall into a barrel of water with a splash…it’s so much fun. I thought I’d never tire of making levels, and this would be the easy, fun part of making the game…

So Much…Work

Designing game levels is a lot of work. The nature of a physics puzzle game threw up challenges I didn’t anticipate. Any change to the game’s underlying physics object behaviour necessitated re-testing every level. The difficulty curve was very hard to get right – it’s actually very difficult to determine how difficult a puzzle is when you’ve made it yourself! This meant that I was constantly shifting levels around between the different level sets in the game. Because I had planned some aspects of the game poorly (it was my first Unity project after all), moving levels around was a lot more work than it should have been, which added to the tedium of creating so many levels.

One shortcut I found (and wished I’d found earlier) was to ‘cheat’ in my levels. Sometimes I could get a level to work better by tweaking the physical properties of objects slightly. For example, if the level requires the player bounce a clown off a trampoline to get to a shelf I might tweak that specific trampoline to be a little bouncier than normal. I used this technique sparingly, and only where I felt it helped make the player’s intuitive understanding of physics work as expected.

I could have saved myself a lot of time if I had built a level editor and implemented a way for levels to be loaded and saved to XML. In the game each level is a Unity scene. I didn’t know at the time that that approach would not scale well. I did eventually build a prototype level editor, and in my tests I could get a big improvement in my game package size and performance by storing the levels as XML, but re-working and re-testing every level into the new format would not be worth the effort.

Puzzle Blind Spot

At one point I sent an alpha version of the game to a friend to playtest levels. One of the new levels was quite complex, requiring several carefully placed objects in just the right places in order to solve the puzzle and collect all three stars. It was designed to be one of the game’s hardest challenges. My friend solved it in a ridiculously simple way I didn’t anticipate. I was focused so much on the level I had designed that I was blind to the very obvious simple solution.

You can Never Test Too Much

I developed a habit of playing through every single level as often as possible. On the train home from work I would play as many levels as I could, noting down any problems or glitches, then I’d fix those problems as soon as I got home. I would do this almost every day. I played through each level more than a hundred times, some levels probably 200 or more. The playtesting got extremely tedious towards the end, but it was invaluable.

But by the time the game was finished I was absolutely sick of playing the levels!

Lessons learned

The Final Countdown

Eventually I had to decide that I was going to finish and publish the game. I decided on a ‘feature freeze’ and set about polishing the game as much as possible. I played through the game over and over again, noting any issue – no matter how small – on an ever-growing list of must-do fixes.

Here’s a small sample of my issues list as I headed down the home stretch. On the left are general issues, and on the right are tweaks to the levels:

Since I’m not beholden to a publisher or any set schedule I could take the attitude of releasing the game when it was good and ready. However, I did choose to limit myself to just polish and bug fixes at this stage or I knew I would never finish.

Here’s one of my favourite bug notes:

The funny thing about that bug is that it bothered me for a long time…and that was simply due to my lack of Unity experience. It was quite a simple fix in the end.

I chose Windows Phone and Windows 8/RT as my launch platforms because they were the platforms I was most familiar with. I figured I could port to Android (and possibly iOS) later. I didn’t have any financial expectations for the game, so the platforms didn’t matter to me at all, really.

I finally finished the game and pushed a very small number of issues into my plans for version 1.1, which I would get to work on as soon as version 1.0 was submitted.

Lessons learned:


Because I had no actual budget I did very little marketing. I did spend a small amount of money on some banner ads, and I promoted the game on a few websites and forums. I don’t think my marketing had any real effect on downloads or sales. I know that advertising is crucial if you want to make your game successful. It’s practically impossible for a game to get noticed among the glut of products being released into app stores every day, and you’re competing with the big game studios.

If I had a real budget I would probably choose to spend 50% of it on marketing if I felt I had a game that could be popular, but ifor my hobby game I had to choose to put it out there and cross my fingers.

The game was originally called Clowntraptions, and was renamed sometime between the initial release and the Android release a few months later. I felt the pun was a bit forced and obscure, and I thought maybe Game of Clowns could trade on the popularity of Game of Thrones.

Lesson learned

Other Platforms

I released Game of Clowns almost 2 years ago on Windows platforms. The intention was always to release an Android version, and then an iOS version if I could figure out how (I don’t own or use any Apple devices, so there’s a big barrier there). I published both a free (limited to about 30 levels) and a paid version to Android a few months after the initial launch, again with no marketing. I have sold very few copies on Android, though I have almost reached 20,000 free downloads, which is cool, I suppose. Ratings are generally 4 or 5 stars, which is great.

Porting to Android (and later iOS) was very easy. There is only one script in the final code that has any differences for the different platforms. I got some help accessing a Mac via remote desktop, and set about publishing the iOS version. The tools were new to me, and using remote desktop was tedious, but I got it sorted out and published.

iOS Publishing

A major reason it took so long to port to iOS was the cost of a developer licence (AU$150 per year compared to a nominal one-off fee on Android and Windows). I don’t know if I’ll sell enough copies on iOS to cover the developer licence, but at least I have iOS publishing experience and my iOS-using friends can now play the game.

Lessons learned


The main lessons I learned while making Game of Clowns were:

What I Spent

Here’s a quick list of costs I incurred making this game. I’m very happy with the end product considering the budgetary constraints I had.

I haven’t made back the ~US$600 I spent creating the game, but I’ve definitely got more than US$600 worth of lessons learned.

Get the Game

If you want to check out Game of Clowns, you can get it for the platform of choice from the following links:

Android (free version with limited levels)

Android (paid full version)

Windows Store (phone/PC Windows 8+, works great with mouse or touch)

iOS (iPhone and iPad)

Game of Clowns website and desktop PC version


3 thoughts on “The Making of Game of Clowns


Thanks for the nice writeup! I am at the very beginning of the path that you have traveled, but lots of things sound familiar. Our game is not released yet and is much simpler (just 10 levels! at least that’s what we plan to release at first) but the challenges are the same. Some questions: Do you have ads in the free Android version? If so how much do they earn? How many testers aside from yourself you had before the release?


    No, I don’t have ads in my game, though I probably will next time. My free and trial versions have limited levels, with all the levels in the paid version.

    I had about half a dozen testers while making the game. Every tester found different issues, so the more testing you have the better!

    Good luck with your game!


      Thanks! You’re right that the learning aspect is invaluable… but making some money would be nice too. On the other hand I’m disgusted by the level of greed some game authors demonstrate (ads during play, and some even try to sell me different backgrounds for their puzzle!), so we plan to be modest, only showing ads between levels. And then we plan to only sell a complete unlock (unlimited lives, play any level at any time) as an in-app purchase instead of “packs” of 100 coins or lives that most games seem to be selling. We’ll see how it goes.


Leave a Reply

Your email address will not be published.