Prototyping Games with Processing

I’ve been busy in my spare time. A couple of months ago I was trying to find a way of quickly prototyping simple game ideas in Java, with the idea being that I’d port them to Android if any of them were any good. I’d gone through a long spell of not getting any of my personal projects completed and was beginning to wonder if I’d ever finish one. The irony was that my work projects were going very well, and I was having no problem delivering there.

I got so far with it, and was writing yet another simple game engine, when I realised that I was coming dangerously close to reinventing Processing. I didn’t have any first hand experience of writing Processing code, but I remembered seeing some Ludum Dare entries that had used it and had been impressed, so I downloaded it and started to play.

Processing is interesting, as it was initially developed as a “software sketchbook” to teach programming, but has grown into a powerful little tool in its own right. In essence it’s just a simple pre-processor that spits out Java code, but it turns out that it is fun to play with. The immediacy of the environment struck me – it was very easy to try something out and see the results very quickly – so much so that I decided that I’d just play around with it for a bit before using it to prototype games for Android.

However, a couple of evenings later I found that I was still just playing around and had ported some old code to display a simple 2D maze in which a little man would run around firing bullets. I then got to thinking, “wouldn’t it be cool if the bullets created a particle effect when they hit the wall?”, and soon found myself implementing that.

Another couple more evenings went by, and I realised that I was having fun and that I’d been putting too much pressure on myself without giving myself a direction. I had come to suspect that my work projects always went well because I would try to establish the requirements and milestones and would have a clear idea of what I was trying to deliver at each stage. I would deliver solid, working code, even if the time pressures meant that what I delivered wasn’t perfect in my eyes. But perhaps that was the problem – I am very pragmatic when it comes to meeting deadlines, but for my own personal projects there were no milestones.

A New Goal

So, I set myself a new goal, which was to write a game with Processing and plan it like a work project.

And that’s exactly what I did. I set out not to write a game, but to deliver a game, knowing that the code would most likely be far from perfect, but that it would work. And to get myself started I reached for an unusual programming tool called Microsoft Excel and wrote down a list of features.

Here’s what I wrote in my diary.

At lunchtime today I managed to finish writing the list of features, plus time to completion for all of them. The grand total came to a somewhat daunting 125 hours, which is over 3 man-weeks of work. Given that I tend to work up to 10 hours a week on my own projects, that really does look like a large number. However, I am pleased, because it does map out everything that I need to do, and I’ve been sensible enough to divide it up into milestones.

The features in each milestone were simple sentences like:

• When the player enters a room then they are placed just inside the door by which they entered.
• The playing screen transitions to the high scores screen when the game ends.

Nothing special – just simple declarations of behaviour. But grouping these into milestones and knowing which feature I was working on made a huge difference to my productivity.

Each feature had an estimated time to completion, but clearly I overestimated the times, because I completed the game in less than half of the 125 hours that I’d estimated.

Of course, the reality was that it was about 2 months in elapsed time, because I was working evenings only, and not every evening at that, and I went away on holiday for a couple of weeks in August. Yes, the source code is somewhat scrappy and breaks a lot of rules, but the fact remains that I completed it and I had fun doing so.

Introducing Very Angry Robots

The game is called Very Angry Robots. Here is the browser version.

You can get the source by clicking on the Very Angry Robots link below the game. That will take you to the OpenProcessing site where the game is hosted. While you’re there, take a look at some of the other sketches, because they really show what people can do with Processing. It’s a fun, productive tool and I very much encourage you to download it and give it a try.