First of all, a small confession

I consistently refer to myself in ‘the majestic plural’ (not all the time, only in the context of this game). The reason I decided to do this is because people are used to read about a team of developers and designers building a game. I don’t want to draw attention to the fact I am a one-man-team, I hope the game can stand out on its own and doesn’t need the ‘indie-developer’-story. That is why the majority of this story is not about me as a person, but about how this game came together.

The Original Balls

As a child I played a lot on the Atari St (the one with the joystick and one red button), a lot of those games have gained almost mythical proportions. But the game I loved most seems to have been forgotten almost entirely. So I’m on sort of a mission to change that.

The game I am referring to is also called Balls, created by Simon Carter in 1993 (more information: Inspired by this game I converted it to a mobile puzzle-game. I’ve updated the look and feel to match the flow of a mobile device, but other than that I tried to stay as close to the original as possible. The changes include an updated design, the simplification of the game-mechanics and a huge reduction in the size of the puzzles.

Simon Carter, if you ever come in contact with this game, feel free to send me a message. I would love to repay you for the hours of fun you gave me as a child (and still give me developing this game).

One step at a time

A Prototype

With the Atari-version of Balls in mind, the first thing I had to verify was if the gameplay would translate to a mobile device. In order to check that, a prototype was created. As you can see below, it was not a masterwork in design, but it worked as a proof of concept. (And yes, that eye blinding red was the background-color I used, which didn’t make it easier to convince myself this game would be a good idea.)

Balls Prototype

The first prototype


Physics And Gameplay

After deciding I would spend the next few months developing this Balls tribute-game, I started working on the physics and optimizing the gameplay.

Although the original Balls is, in my opinion, a brilliant mind-bending game, the puzzles are designed for a computerscreen and the game-mechanics are optimized for playing with a computer mouse. During development it immediately became clear that the way you interact with the game had to be symplified. The Atari-version of Balls uses the left mouse button to create diagonal walls that go up (/) and the right button for walls that point down (\). This obviously won’ translate to a device with a touchscreen and after trying a few different models my beautiful girlfriend pointed out to me that all those complicated systems could be reduced to a simple tap to plant a wall and an other to switch it around (can’t believe I didn’t think of that earlier). And thus, the gameplay was decided upon.

Next, I had to get the physics right. I’ve spend several hours getting the movement of the balls fluent and consistent and after that I started adding obstacles the balls should interact with. As this is the first fully functional game I created, this involved a lot of trial and error. After a few days I got the hang of it thanks to a dear friend of mine (and all the information available on the internet). The first batch of obstacles (or ’tiles’ as I call them) were implemented and the first playable, but pretty ugly, version of the game was done.

Struggling with the Design

That was all fine and dandy, but still I couldn’t get the look right. In my vision the game would get a hipsterish-triangle design (Google-images of a ‘hipster triangle design’), but all the things I tried resulted in a very confusing layout that stood in the way of the gameplay. So, again, I realised I was overcomplicating things and started simplifying. This original design-concept is however still visible in the design of the main-menu and the animals that represent the level-packs.


First Design


Simplifying the ‘obstacle-tiles’


An other image of the simplified tiles.



Final design (more or less)


Simplifying the background


The first instance of the Banana-level



At this point I thought the hard part was over, the game was finished, only one thing to do: create a level-editor and design 150 levels.
This, of course, proved to be harder than expected. The level-editor came together fairly well, but my determination to both create good looking levels and challenging puzzles made this task more difficult than expected. It is one thing to solve a puzzle, but it takes a completely different mindset to come up with original puzzles again and again.

It was obvious from the beginning this game wouldn’t be able to please everyone, it’s aimed at hard-core puzzlers who don’t shy away from frustrating almost-had-it-but-my-fingers-decided-to-do-something-completely-different-than-I-had-in-mind games. Although I know this probably isn’t the ideal way to draw in the big crowds, it was decided from the start this should be a difficult puzzle-game. The game-mechanic is so easy to understand that I believe the puzzles should be borderline impossible to solve. That way, every solved puzzle is an achievement in itself and will motivate to keep playing. Most puzzle-games lose me after a few minutes, half an hour tops, because after completing 25 levels I still feel I’m playing a tutorial.
It took a few weeks to complete the final 150 levels (throwing away more than a hundred in the process). After that, satisfied with how the difficuly progresses and the pace at which new functions are introduced, the game was done, at last.


Looking back at the process and the end-result, I am proud of what I realized, which is a strange but satisfying feeling.

Please let me know what you think about the game, what I should have done differently, …
Don’t hesitate to contact me in whatever way you feel appropriate.