The Making of Game of Clowns

This is a short ‘Making of’ for my first Unity game, Game of Clowns.

Background

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. 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:

• A Flintstones-like caveman theme
• A circus with flying, bouncing clowns.

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

• Any estimate of effort required is probably short by a LOT.
• A template is a starting point for your own ideas, not a ready-made game.

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

• Productivity directly correlates with organisation.

Art

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:

• Commissioned art.
• Licenced art packs.
• UI pack from the Unity Asset Store.
• Art from the game template.
• Public domain sprites.

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

• Art is worth every penny you spend on it, and it’s great to find an artist who can draw in exactly the style you want.
• When your budget is small you can find ways to stretch it. Try re-colouring art for variation, search for public domain images, and look into licencing packs of art that suit your game style.

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.

 

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

• Cannons that shoot clowns.
• Trap doors that can be opened by pressing a button.
• A clown with a hose that pushes objects that enter its stream.
• Moving platforms (horizontal and vertical).
• Multiple goals to complete a level.
• Custom touch input controls to make manipulating objects more intuitive and reliable.

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

• Purchased assets can save you a huge amount of time, but they work best when you use them as a starting point to build on.

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

• Sound and music are as important as graphics, but unless you’re a sound or music person that’s not necessarily intuitive. George Lucas says that sound is 50% of a movie, and I think that holds true for games too.
• You can get pretty good sound and music on a budget, but as with graphics you get the most value from something customised to your game.

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

• You should have as many people as possible test your game. Different points of view shed light on different things, often things you as the developer can’t see.
  • Non-gamers will show you if your game is intuitive.
  • Kids will show you if your game is simple and fun.
  • Good gamers will find creative ways to solve problems.
• Any time or effort saving you can find in creating levels is worth implementing. The effort required to build a simple level editor and/or serializer will repay you several times over in saved time and energy.
• Designing levels is a huge creative drain. Spread the load as much as possible. Look for inspiration everywhere. It’s not the ‘fun’ part of developing a game, it’s just as much work as any other aspect.

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:

• You need to draw the line somewhere in order to finish a project. Don’t be scared to release something that is not 100% finished, but make sure it’s 95% there and nicely polished.
• Test constantly. Note down any issue no matter how small, then fix it. Some issues don’t present themselves immediately. There is an example in the list above of a sound effect that is annoying – but it’s only annoying when you hear it several times, which only happens when you playtest the game properly.
• Don’t be afraid to push a feature or bug fix into a future update. You can’t fix everything immediately. A bug that only happens in very specific circumstances will not affect many people, and you can fix it with a clearer head if you just release the game and then get to work on a small update to fix the bug.

Marketing

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

• There is no success in the app world without marketing (unless lightning strikes). People need to know your game exists; they need to want it; you need to reach a critical mass of recognition. That comes from marketing.

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

• I get far more downloads and sales on Windows Phone than Android. This is probably due to the difficulty of being noticed in the much larger Android store.
• iOS is a trickier platform to publish to, and costs a lot more. Time will tell if iOS users buys more copies than Android and/or Windows users.

Conclusion

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

• Game development is hard work, and there are no shortcuts.
• Only through experience can you really understand how much work goes into any aspect of game development.
• The best art and music comes from talented people who have the required skills, but with some clever tricks you can stretch a small budget.

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.

• Art: ~US$400, mostly on commissioned art
• Music: ~US$30 for licenced music
• Software: US$55 for original game template
• Marketing: ~US$150 on some banner ad impressions.

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

Check out more information about the game on the Game of Clowns page.