Writing a real-time game with Clutter

I'd like to talk about writing simple, real-time games using Clutter and its related libraries, and I'm going to be speaking about this from the perspective of someone that usually writes desktop applications.

Writing applications, your top priorities tend to be stability, usability and maintainability. Doing things right has value when you're writing an application, especially large applications.

Writing games, you need to forget all of that. Your top priority writing a game should be to test the gameplay, and you need to do whatever you can to get to that point as soon as possible.

With this in mind, I'm suggesting some guidelines that I think people should follow if they want to successfully make a small, fun game. In true Intel fashion, I'm going to name these 'laws' after myself.

I've written two games prior to this talk - the first game demonstrates what happens when you don't follow these laws and the second game shows what happens when you do. With any luck, they'll reinforce my points, though opinions may differ...


Law 1 - Steal

After you have your game idea, the first thing you want to do is find some software, another open game or library, that will do most of the heavy lifting for you. Writing a new library is not the quickest way to reach your objective.

Law 2 - Take advantage of your software

Make sure to manufacture your game to take the best advantage of the software you're using. Using Clutter, for example, you have a great animation framework and it handles sprites brilliantly. Don't try to do something if the software you're using makes it hard.

Law 3 - Use images for everything

Lots of programmers have the great idea of programmatically generating all their graphics. This is usually a work-around for lack of drawing skill. It's the rare occasion where this doesn't just make everything look a lot worse. Don't do this.

Law 4 - Keep it simple

The simplest games are the ones everyone remembers as classics. Space-invaders, Frogger, Pac-man, Defender... It's easier to excel when your objective is simpler. The more complex the objective, the more people you need to accomplish it well.

Law 5 - Quick and Dirty

Hacks are totally ok in games. You're not going to reuse this code, and if you are, you can always rewrite bits. Don't be afraid to introduce gross hacks if they work.

Law 6 - Get help

It's rare that one person excels in all the areas required to create a game. The GNOME community is very accommodating - find a hero, or heroes to do the jobs that you aren't good at.


With those laws in mind, I think any capable programmer can write a decent game that we can all enjoy. So, here are the two games I wrote. The first, I disobeyed almost every rule, the second, I obeyed them.


The first game. I think you can see how this one works. The only law I obeyed in writing this was law 4, keeping the game concept simple. Unfortunately, I managed to ignore the other 5 and I think it shows.

With regards to the stealing, I wrote a lot of library code to get this done, meaning it took much longer than it should've. On the bright side, I have some nice code I can re-use and some libraries have benefited, but it hasn't made the game any more fun and it certainly didn't make it quicker to test the gameplay.

Disobeying laws 2 and 3 at the same time, I decided to generate all graphics myself and draw them using Clutter's vector drawing API. Unfortunately, drawing isn't my strong-point and vector-drawing isn't Clutter's strong point and now all the graphics look pretty bad.

I was also very reluctant to introduce hacks in this game. This has meant that what should've been a thousand lines of code, perhaps full of hacks, has ended up as almost 4000. And most of that has nothing to do with the gameplay.

And finally, perhaps the cardinal sin, I did this entirely on my own.


Moving onto the second game, this is a simple, wombat-launching game. With this, I followed every law. In contrast to the month or so of on/off programming that the first game took, this game took about two weeks.

For the stealing, I made extensive use of ClutterBox2D to achieve this game. Although that meant I had a bit of fix-up work to do, it also meant that the entire game mechanics were already done for me.

I also only do things that Clutter and Mx are good at in this game. I use almost solely stock actors and I've highlighted Clutter's strengths in animations and sprite manipulation.

If you examine the code, you'll also find plenty of hacks. My priority was to get this done quickly so I could spend time tweaking the gameplay, not to produce the most maintainable code. That can come later.

The most important law I followed though; I got help from a GNOME hero. Hylke Bons drew all the graphics for me and provided a lot of input. This isn't something I could've done on my own.

Just as a comparison point, this contains about the same amount of code as the first game, but also includes a WYSIWIG level-editor.

For anyone that wants to check these out, both are available from my gitorious repositories.