Free Electron — Case Study

How I got 250+ plays with $0 budget!!

That’s right, people — to date over two hundred and fifty people have played my very own game, Free Electron!

Read on to find out how I achieved this incredible milestone with a marketing and development budget of just ZERO dollars (or NO Pounds Sterling)!!!

Clickbait parody aside, this is a tear-down of the development process for a small game that I published earlier this year.

My aim was to go through the whole development and publishing cycle in order to gain experience and get an actual, real game out there in the wild.

As a hobbyist, I had the underwhelming budget of… nothing, and I like to think that with that I achieved entirely predictable results.

It pleases me that that a couple of hundred people, a couple of hundred of whom I have never met, and never will meet, have spent a few minutes of their time exploring something I created.

Everything else beyond that is a huge bonus, and part of a rich, valuable learning experience that I will forever treasure.

Of course, it would be nice to be forever treasuring a rich, valuable pile of advertising revenue, but never mind. We’ll do that in a future game (that’s how this works, right?).

Game Synopsis

To summarise the game, I’ve labelled it a minimalistic action-puzzler. It’s a twitchy little beast of a game where you are an electron, trying to escape from all the positrons.

Each level is a single screen with a two dimensional grid of positrons forming walls and obstacles between you and the exit. When you reach a new level you gain an extra life.

The catch is that the positrons exert an electromagnetic influence on you, so you get sucked towards them like the Starship Enterprise to a black hole.

If you get close to a positron it will start to drain your energy. The closer you are, the more energy you lose. When you lose all your energy you go back a level and lose a life.

If you are not close to any positrons, you recuperate your energy. However, all positrons on the screen affect your position no matter how far away they are, so you can never stop moving.

Larger concentrations of positrons exert a proportionally larger force on the electron, leading to some pretty taxing level designs.

Once you have completed all fifty levels you are free and the game is over.

If you’re going to read the rest of this article, and haven’t played the game yet, you should really go and do that.

Making the Game


At this point I turn to my trusty sketchbook, in which I contentiously date every entry, who tells me that the first idea for this project was set down on the 21st of March 2015.

First sketches for Free Electron — 21/3/2015

I wanted an action puzzler, of the style I was used to playing on Kongregate during my lunch hour. It was important to me that this was something that I knew I would be able to execute a bit at a time, over an extended period of time.

My schedule is always busy with the myriad projects I have on the go at any one time, so diving into something that needed a high degree of complexity to even get a playable experience was something I had to consciously avoid.

My priority for this project would be to RELEASE A GAME. In order to achieve this I had to be vigilant against featuritis and perfectionism.

My priority for this project would be to RELEASE A GAME.

The next entry (as far as I can see — I’m a busy man, don’t have time to go through every page) is dated 07/3/2016, a whole year later. Here I’ve clearly been chewing the idea over, amongst all the other random chaos of my life, and have jotted down some equations for how the movement of the electron is affected by the wall objects.

Detail on the ‘attraction’ mechanic

This basically forms the central experience of the game, and, satisfyingly, seems to be a memorable and enjoyable mechanic for people playing it.

Two days later (on fire!) I plot a couple of graphs that detail how I want the influence of the walls to affect the speed relative to their distance, and a sketchy mock-up of how that might work in practise.

It was at about this point that I opened a GitHub repo for the project and laid down the first bits of code.


I love using JavaScript to create games, and a huge thanks is due to Matt and Geoff of Lost Decade Games, who not only keep the gamedev juices flowing with their weekly podcast, Lostcast, but also leave beautiful things around the internet for hobbyist gemdevs like myself to feed from. The whole game is based around their super-simple and very versatile template for HTML5 JavaScript games.

Using their guidance I have been able to get the basics of a game up and running, kicking it about until it feels like I want it to feel.

Screen shots of the beta version — a 20 x 11 grid

At this point I throw some sliders on the screen and hook them up to the guts of the game so I can adjust all the variables (attraction strength, speed, health, etc.) on the fly until I get a set of values that I am happy with.

Here I realise that if I am ever going to ship this game then I can use the ‘power’ of JavaScript to create the whole thing using simple shapes drawn straight to the canvas.

No images to load, no sprites to map. And while we’re at it, I’ll just keep all the sounds (‘zip!’, ‘ftzzz’, ‘crKK!’) in my head for now.

I chose a nice retro arcade-style font from Google Fonts and left it at that.

The importance of finding your people has come up again and again with this project, and Lost Decade have always really struck a chord with me. Their dedication, deprecation, generosity and good-humour have been a real tonic for me when slogging away at the nine-to-five when I have a hot idea for a game that’s burning a hole in my brain.

If you can find someone who’s doing what you want to be doing, and that person is not an arsehole, then it can really help you feel that you can do it too, for which I owe a huge debt of gratitude to Matt & Geoff ❤

So I laid down the foundations of the game then, with that itch scratched, I moved house and a tonne of other stuff before coming back to it.


The next phase of development kicked off with me visiting a local game dev meetup. Wow. The focusing ability of putting your creation in front of a group of omnipotent gamedev cognoscenti, for them to tear you apart like velociraptors toying with a lost hamster. I polished what little I had, hosted it on my site and took the plunge.

As you can imagine they weren’t as horrific as I’d feared. It’s tough putting yourself out there, but everyone else who’s out there is also out there (IYSWIM), so everyone is likely to treat each other as they would want to be treated. And you get a cup of tea. Smashing.

Turns out I had the novelty factor with my HTML5 game (none of this ‘I exported a build, but it’s not on this USB’ or ‘Oh, Unity seems to have crashed’). Just fire up a browser and there it was :D

Screen shots from the v1.0.4 — yes, you can get to level 49!

That first session I got so much good feedback it was hard to keep track.

I made notes on my phone, discarding some of it later as too ambitious (multiplayer, 3D, different characters/classes, AR — all do-able, but not trivial).

Everything I did had to focus around making a shippable game, not the perfect game, and any group of people will have varying opinions about the best way to do that. It was very fruitful to hear those opinions.

The game was judged to be ‘compelling’, as in those that played it really wanted to get to the next level!

A little thing that took people by surprise was that you get punted back a level each time you die.

This means that if you fluke a hard level (and some of them are very hard), you really need to get a few levels past that before you are really clear of it.

It gives good playability, in that you genuinely have to become skilled at navigating the game in order to progress.

The main comment that came up, aside from suggestions for balancing the gameplay after I had increased the levels to a 40 x 22 grid, was having some kind of scoring mechanic.

I had considered this in passing, but these comments caused me to look again.

The problem was, on what would you measure your score? Highest level? But this was a finite game, with a set number of levels — your score could only go so high… Time taken? But if you only did half the levels your time would be low anyway…

It would be a problem that i would not solve until after the day of release.


There are a million articles out there on how to publicise your game. This is not one of those articles. I know I should’ve done a Kickstarter, posted regular dev blogs and tweeted incessantly, leveraging any social media standing I may have to build interest in my product.

But I didn’t do that. Mainly because I just wanted to ship a game, not pay my mortgage. A Kickstarter for a game with no sound or images is not going to do terribly well, and doing one properly takes a lot of time and effort, so I passed.

In order to publish the game I intended to use one of the many online platforms available today, starting with Kongregate because I’ve always enjoyed their offering and lusted after that ‘D’ icon next to my user name :)

Publishing on a platform rather than hosting myself would give me more exposure for less effort.

Kongregate provide an API whereby you can pump high scores into their system, linked to player accounts. This extends into being able to award badges to players when they have reached a particular milestone.

I looked into the documentation and it seemed pretty straightforward, and may have gone some way to solving my high score headaches. I implemented it, and the scores were successfully passed through to their servers. All was well.

However, I hadn’t quite realised the mechanics of their high score API, which allows you to pass a number of variables across each time. I had thought that they would do some ‘magic’ and display these as a single score, as I’ve played a lot on Kongregate and only ever seen one score.

Turns out I was wrong, and this is a quirk of the UI, where the other variables are hidden behind a drop-down that I had never noticed. You can views scores for time, scores for levels, etc., which was a bit of a fail for me.

Level Design

By now it’s Spring 2017 and I am desperate to get this game out of the door so I can get closure!

More levels are added, bringing the total to 50. I aimed for a series of steep difficulty curves interspersed with plateaus, and I think I achieved this.

Level designs from December 2016

Every level ending with ‘2’ is a big jump in difficulty, while the rest of the levels get progressively harder on a more gentler curve. Levels 44+ are simply punishing and the last level is a total killer!

I was really fascinated by something unintentional that came out of the level design, and that was that when you die and get pushed back a level, it screws you over in an unexpected way.

When you are travelling forwards in the levels, you get a sense of flow and it’s not unknown for a player to scoot through levels 44–48 in one go.

What happens then is that you fail each level in turn until in no time you are back at level 44 again! It’s like there’s a cognitive bias at play. On the way up, you learn that moving down the screen more and more as the level starts is a good tactic.

But on the way back this behaviour is too strong and you overshoot, leading to death, back another level and repeat the same mistake. There’s something in me that really enjoys this (except when I’m trying to complete the game at a demo!)

I released the game! Yay!! Objective met, but I still wasn’t happy enough to leave it alone :D

I tweeted about it and got some traffic to my page on Kongregate, but the high score thing was bugging me. Not least because it meant that a main art of my game was now strongly linked to a proprietary platform.

Eyeing up, I was struck by their monetisation approach of inviting donations. This seems like a reasonable way of asking people for a few coins if they enjoyed your offering, so I was interested in having my game there as well. But the high score bit was all on Kong…

After further chats with the Norfolk Game Dev meetup I finally arrived at a solution — weighted scores in favour of level completion, with a reduction in score for time taken and a juicy bonus for completing the game.

To get it out of the door I implemented this with cookies, threw your high score and highest level up on the start screen and viola!

I published on itch, tweeted some more, and took a shower.

My number one priority for this game had been to release it. Mission accomplished!


I’ve learnt a huge amount over the course of this project, most notably that the people around you can make or break a project — huge thanks to everyone at NIGD for their time and support, you are amazing and inspiring (and yes sometimes disturbingly weird) people.

Doing a hobby project like this takes time, so thanks to my wife and son for their patience and for leaving me alone at times. Little and often is the way!

Scoping a project to suit the resources (time and money) is key. I ruthlessly kept the scope small in order to achieve my main goal. I like to think I published a fun, challenging and playable game. It could be so much more, but it could also never have left my own server, so I’m happy with the outcome.

Now I’m on to brighter and better things, including a larger game (Unreal Engine, I’m coming for you!) and a couple of UX projects.

If you enjoyed what you’ve read then please recommend this to others. Follow me for more articles about things I make in the worlds of game development and user experience design.