Writing simple, real-time games for GNOME

Chris Lord shares his experiences and six laws of writing simple games for GNOME, using Clutter.

 

At GUADEC 2010, my colleagues and I did a talk, Everything you wanted to do in Clutter (but were afraid to ask)”, which covered some of the things that we don’t often see people doing with Clutter. My part of this presentation was focused on writing simple, real-time games. I chose Clutter as one of the primary tools to achieve this, but I hope the tips I gave would apply equally well to a game written in any library. In this article, I’ll elaborate on what I presented.

The GNOME community contains many talented application developers, and yet you see very few games. In particular, there are very few real-time games. This is probably down to a number of reasons, but one of those reasons may be that the focus of writing games is very different to the focus of writing applications.

Writing applications, your top priorities tend to be stability, usability and maintainability. An application often goes through several developers in its lifetime, so keeping the code tidy, readable and adhering to best practices pays off immeasurably. Likewise, applications are often used for critical work, and to increase productivity, so they are of no use if they aren’t stable and they aren’t understandable. GNOME’s focus on ease-of-use produces great applications that are often used even in corporate environments.

Unfortunately, very little of that is of any use when it comes to games. When a game crashes (and with modern games, it’s usually ‘when’), it isn’t that big a deal. You reset, load up your last auto-save, and replay the lost 5 minutes. With smaller games, such as those on the iPhone, the likelihood is you didn’t lose anything at all, or that the time-impact of recovery can be measured in seconds instead of minutes. Of course, no application should crash, but stability is less of a concern with well-designed games.

Usability is also less important. Games are inherently a learned activity. Like driving a car, you have a way of interfacing with the world that isn’t through direct manipulation and this is something that must be learnt and practised. With this in mind, and with the fact that any well-designed game should place you within the game with as little interaction as possible, there are far fewer usability concerns than with applications.

Finally, maintainability is a much lesser concern too. It is unlikely that you’ll use the code from a game again. If you’re lucky enough to have had such a successful game that you can consider a sequel, that would be the time to start focusing on maintainability, but small games tend to be one-shot activities. Quite often written by one person. Spending hours creating a great abstract representation of your gaming world isn’t going to benefit those that play it and diverts you from the real focus of game development.

The primary, and possibly only, focus of games development is gameplay. Your number one priority when writing a game is to get to a point where you can test how well it plays, and how well your ideas and concepts work given the limitations you work with. Unlike application development, shortcuts do work in games. The quicker you can get to testing the gameplay, the longer you have to make sure your game is actually fun to play.

Turn-based games are much easier for applications programmers to grok, as they are usually driven directly by user input. Real-time games have a world that continues regardless of the user, over which the user has some influence. This is very different to the environment of an application.

With this in mind, I’ve come up with six guidelines that I think will benefit anyone developing a small, real-time game. In true Intel fashion, I’m going to name these ‘laws’ after myself as well. Let’s call them “Lord’s Laws”.

Law 1 – Steal

After you have your game idea, the first thing you want to do is find some software; either another open-source game or library, that will do most of the heavy lifting for you. Writing a new library may be fun, but it’s not the quickest way to reach your objective.

Law 2 – Take advantage of your software

Once you’ve chosen the software to steal, you need to make sure to manufacture your game to take best advantage of it. Using Clutter, for example, you have a great animation framework, great support for 2d effects and lots of supporting libraries for doing video, physics, user-interfaces and the like. You shouldn’t try to do something if the software you’re using makes it difficult.

Law 3 – Use images for everything (aka Generation is bad)

Lots of programmers have the great idea of programmatically generating all of their graphics. In the majority of cases, this is actually a work-around for lack of drawing skill. It’s the rare occasion where this doesn’t just make everything look a lot worse than it ought to.

Law 4 – Keep it simple

The classic games that everyone remembers are almost all simple games. Space-invaders, Frogger, Pac-man, Donkey Kong, 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, and the more time you need to accomplish it at all. Simplicity isn’t a bad thing.

Law 5 – Quick and dirty

Hacks are totally OK in games. You’re not going to reuse the code, and if you are, you can always rewrite it when you get round to reusing it. Don’t be afraid to introduce gross hacks if they work and they save you time.

Law 6 – Get help

The final, and most important law. 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. It can be surprising what people will help you with if you just ask.

When I presented this talk at GUADEC, I had written two games. One of the games, I had broken every law in this list and the other I had followed them. The first game was a simple maze/collection game, available here on Gitorious. In this first game, I used generated, vector graphics and a massively over-engineered abstraction of the game concept. This resulted in an incomplete, bad-looking game (Clutter does not excel at vector graphics), riddled with bugs. I also wasted a lot of time writing library code. Thankfully, most of this library code has actually succeeded in being reused now, but the game itself was never finished.

 

The second game, Happy Wombats, I followed each law. While I have continued development since GUADEC, at that time it was no bigger (in lines of code) than the first game, yet included a fully-featured level editor, high-scores and, ironically, far fewer bugs. In this game, I make extensive use of support libraries (namely ClutterBox2D), and highlighted the strengths of the libraries I used.

Most importantly, I got help from a GNOME hero writing this game. Hylke Bons drew all the graphics for me and provided a lot of useful design input. This isn’t something I could have achieved alone.

Since GUADEC another GNOME hero, Iain Holmes, has been helping out, writing music and generating sound effects. Because I got the gameplay developed more quickly, it generated more interest and resulted in a better looking (and sounding!) game more quickly.

With these laws in mind, I think any capable programmer can produce a decent game that we can all enjoy. I hope that others will be able to follow them and we can have a much larger, and more compelling library of games for GNOME-based platforms.

About the Author

Chris Lord works as an engineer in Intel’s Open Source Technology Centre, working on MeeGo, formerly Moblin.

Discuss this story with other readers on the GNOME forums.