Games and the Imagination – now on PDF

November 11, 2012 0 Comments

I’ve added a pdf version of my 2004 article series Games and the Imagination to the writing page. I still get people asking for it in an easy to read format and I found that since their last redesign, the layout of Gamedev’s article section doesn’t do much to reflect the amount of work that goes into such writing. It looks a little like some lost blog post that got picked up by a content aggregator or something, so I made the PDF to provide a better reading experience.

In Games and the Imagination I use Jungian psychology to explore how players imaginatively engage with games. Its main idea is that gamers do not simply identify with playable characters but that the whole game can operate as a kind of dreamscape where all characters, landscapes and situations have the potential to reflect the gamer’s psychological concerns.

When it was published on Gamedev in 2004 I got a terrific response; people wanted to cite my work in their studies, I had several working psychologists respond positively, and even a few big names in the games industry wrote to me.

I come from a self-taught working class background; university wasn’t even mentioned to me when I was at school, so it was very gratifying to have students and big-shots thank me for helping them with their studies and asking to cite my work.

I left school in a bad way, depressed and angry; angry at bullying, angry that nothing in my world appeared to allow me to be the person that I felt I was, a creative thinker. The responses I got from my writing really made me feel that the years of lonely self-education that followed were finally leading to something.

The one thing I didn’t get out of it was the one thing I was desperate for: a job in the games industry. I actually wrote the series some time earlier, and was using it as part of a portfolio of code that I was sending out with job applications. I’m not sure how many of the people I sent it to actually read it. I probably didn’t push it hard enough. A part of me has always wanted someone else to come over and say, “Hey, you belong over here, come and join us”, but that never happens.

New Ideas

After I finished Games and the Imagination I got interested in the idea that there might be a single language of game design, a grammar or logical system that could be used to describe all games. I wrote a little about this in part four and linked it with ideas that went back to my first game design article from 2001.

A lot of work has been done in this area in the past ten years. People like Raph Koster, Daniel Cook, Ernest Adams and Joris Dormans have done detailed analyses of game mechanisms in the hope of eventually deriving something like a grammar or set of logical axioms that designers can use to think about how games work.

My own approach is more phenomenological. After surveying the usual suspects such as semiotics and system theory, I started reading twentieth-century philosophy; Wittgenstein, Husserl, Heidegger and Deleuze, to name a few important figures. I’ve spent probably six or seven years on this study and I still don’t feel that I’m ready to write anything yet.

I *do* have concrete ideas, and they are informing everything I do when I work on my games, but I just don’t feel capable of describing them in words yet. I have a picture in my mind of a nicely illustrated book, but I’ll probably just end up with a simple pamphlet stating the obvious! The ideas I have in mind are simple, Its just that they are not made of the same stuff as ordinary concepts if you can catch my drift. They are about appearance, not representation. (Told you I wasn’t ready to write yet:) )

Another area that I got interested in was the investigation of the imagination itself. What does it mean to imagine? Why does this faculty seem to be treated so dismissively outside of a few subcultures? How does it relate to other faculties? Can a rethinking of the place of the imagination within phenomena tell us anything new about being human, or open up new horizons for us? These are some of the questions that come to mind. I plan to write some more about these questions soon.

View Comments

Toxin Graphics – Introduction

November 3, 2012 0 Comments

It has taken me a long time and a lot of experimentation to get the graphics right for Toxin. When I began, I didn’t really have a single picture in mind of how the game was going to look. I knew I wanted abstract, and I knew I wanted a contemporary style influenced by information graphics and designers like James White, but that was all. Most of my inner images of the game were fleeting. I had a gameplay concept and a “feel” in mind more than anything else.

Also, Toxin is the first game I have worked on since the Smartphone stuff I did around 2002-2003. I was desperate to get back into game development and I mistakenly thought I could begin again where I left off. It was like running into a brick wall. The first artwork I did was so bad I deleted everything, took the bus into Stratford on Avon and spent the rest of the day sitting by the side of the river in despair!

It took me some time to reach my old level again and then improve on it. As much as I have enjoyed developing Toxin and the creative discoveries I have made, there has been a great deal of struggle and fruitless experimentation involved.

The interior designer and UK TV legend Laurence Llewelyn-Bowen was an unlikely influence. On his TV home makeover shows he’d get his clients to collect images they liked and pin them to a board for inspiration. I had a Toxin folder on my laptop which I filled with images from ffffound and other design inspiration sites. When I got stuck I’d fire up IrfanView and spend half an hour blanky staring at images until some ideas popped up. I highly recommend this practice. A few of the images from my Toxin folder are in the image below.

Toxin Image Board

That watch is a Dievas Aqualuna Blue Professional. No I can’t afford one yet. Buy Toxin!

Toxin Ship SpriteThe first thing I did was the main ship, which is the only thing I got right first time; it remained unchanged throughout development whereas everything else got remade at least three times! I think it works really well and has a nicely balanced, iconic look. I designed it in a vector drawing package which I later abandoned in favour of using rendered, animated splines created in a 3d program.

The background was next. It was essential to get the background style nailed as it would define the look of the whole game. I tried a few different styles as you can see in the rough drafts below.

toxin background drafts

One of my biggest goals here was to create something that looked good within the phone. Too often, mobile games just present windows on to the game world without any consideration for the device that is running the game. To me this is like designing a watch face without taking the case into account.

Next time I’ll talk about how Toxin uses procedural graphics and describe how I used Photoshop scripting and Processing, a Java based generative arts platform to create much of the game’s artwork.

View Comments

Programming Toxin – Making Levels

October 25, 2012 0 Comments

Nearly everyone who asks me about game development will begin with the question, “How do you create levels?”

The main way of going about it is to use a custom editing program. Developers either write their own specifically for each game, or they’ll use one provided by a third-party game engine like Unity, Source or UDK. Sometimes, they might take a popular modding tool like one of the Quake editors and use it for their own ends.

Unity EditorTiled 2d map editor


These editors allow you to create levels visually; you can draw maps, position items and enemies, draw movement paths, edit dialog text and set up events to occur at different points in the level. All this information is saved in a structured file that the game is programmed to understand.

The complexity of these tools and the files they create depends on the game. Some of them are as large and complex as the 3d modelling tools used by animators and architects; others are simple programs coded up in an afternoon that allow a programmer to avoid some laborious data entry.

I’ve always enjoyed writing game development tools. My first map editor was written in 1994 in Blitz Basic on the Amiga for a strategy game I designed that went nowhere. I probably spent more time polishing the editor than working on the game itself. Not long after I wrote an isometric editor that let you sculpt terrain like in Populous, again, for a game that failed to materialise.

My last game, Starblaster didn’t use an editor; the levels were stored as a script, but when I started Toxin, my forthcoming iPhone game, I knew it was time to break out the old skills.

The Toxin Level Editor

Toxin Level Editor main interface
The Toxin Editor uses the same Opengl graphics engine as the iOS game

The Toxin Level Editor is my first ever Mac program, and it’s pretty clunky. It was my first attempt at writing a program in Objective C, using the famous Interface Builder which originally came out of NeXTStep. I always had a thing about NeXTStep, so it was exciting to finally write a program with its direct descendant.

Once I got the basics up and running, I needed to decide how I was going to save the levels. While many developers create their own file formats, I decided to use an existing one. That way I could use an off-the-shelf library to save time and effort.

Having worked in web application development for the past five years or so, I had some experience with XML and JSON. These are text based formats commonly used by web services to exchange information. I chose JSON as my level format because of it’s simplicity and readability. I use the SBJSON library in the editor and in the game for loading and saving.

Levels in detail

Toxin levels contain four main things. A list of cells, a list of linear events, a list of timed events and a set of general preferences that are applied to the whole level.

The cells are toxic blobs which spawn and multiply and gradually fill the playfield. The editor allows me to draw cells into the level and directly set their parameters.

Events in Toxin are instructions to the game to perform an action such as add an enemy to the game, set off an explosion or play a sound effect.

Linear events are fired off one after the other from the start of the level. They are the main way I add mobile enemies to the game. I can split the events into waves using a WAIT event which instructs the game not to add events until the previously created enemies are all dead. Enemies have standard parameters for position and angle, and a set of custom parameters defined as key, value pairs.

Timed events let me perform actions and spawn enemies at a specific time, or at a random time within a range. I did toy with the idea of having rule based events that I could fire off when certain game conditions were met. In my next game I plan to embed a scripting language to handle this kind of thing.

Editing Level Events
Adding an entity to the level. The linear events list is used to construct consecutive waves of enemies. The entities can have many custom parameters

The levels are saved as a bunch of text files which are then zipped and put into the game. I think this was a mistake. While it’s a good technique for larger games, with Toxin I could have got away with storing them in a single file.

If I were working on a desktop game I would try and build the editor into the game itself, as well as give the game a console that lets me manipulate level data and game parameters during play. This isn’t really feasible on a mobile app, though you might be able to do it on a tablet. I do get tired of having to zip all my level files, then replace the zip inside the project and recompile every time I want to try something.

I have a lot more Toxin posts planned, so stay tuned. Let me know if you have any questions or want more details.

View Comments

Programming Toxin – Part One

October 19, 2012 0 Comments

Over the next few posts I want to write a bit about how my first iPhone game, Toxin, is being developed. Although I’ve been programming for a long time, this is my first ever project in the Apple ecosystem; I hadn’t even used a Mac before starting this game.

Toxin is written in C++ inside a thin layer of Objective C. I did this for a number of reasons. Firstly I am much more familiar with C++. Secondly, as the most common game development language I knew I would have better luck finding additional libraries and answers to any development problems if I worked in it.

It also meant I could reuse some of my own code. Toxin actually contains code used in my first game, Starblaster (2003). Some of it goes back to DirectX stuff I did in the late 90’s. I always liked having a sense of continuity in my work, a feeling that all my games are connected.

The Objective C layer handles iOS specific stuff like getting the app started up, passing touch information to the game logic, and setting up threads for Toxin’s concurrent level loading. The sound library I use, CocosDenshion is also in Objective C. I wouldn’t rule out doing a whole project in Objective C. I’ve enjoyed learning it and I’ve used it to create several utilities already, including the Toxin Level Editor, which I will probably write about soon. I would, however, want to spend some time comparing the performance of the Objective C Container libraries with the STL beforehand.

Engine? What Engine?

Now, some of my friends believe that the main reason Toxin has taken me so long is because I didn’t use one of the popular 2d engines out there like Cocos2d and instead wrote all my own graphics code. They don’t believe me when I tell them that large engines are unnecessary for small games (though I would never stop anyone from using them) and that I could rewrite my entire graphics system in about 2 weeks.

What’s in Toxin

  • Batched sprite drawing
  • Resource management
  • Messaging system
  • 2d particle system
  • JSON file loading
  • Zip file loading
  • Chipmunk physics
  • Oriented bounding box collision
  • Keyframe interpolation system
  • Concurrent level loading


My “engine” if you could call it that, is a basic set of classes for things like sprite drawing, line drawing, loading textures, and drawing basic primitive shapes. All sprite and line drawing is batched using vertex buffers for maximum speed. The classes are loosely related; I just add something when I need it, not worrying about architecture or anything. The whole thing is about 7000 lines of code, and that includes some significant utility classes I wrote, such as my keyframe interpolation system. I use this all over the place to animate transitions, colour blends and movements of all kinds. I wrote interpolators for many different data types and I’m sure I could reduce the lines of code by making them into template classes.

I used this graphics system to build Toxin’s particle engine which I based on John van der Burg’s Gamasutra article, Building an advanced Particle System. The particles use some simple physics to bounce them off the inside of the elliptical playfield.

At one point, the game had elliptical gravity: When a particle hit the ellipse, gravity would activate for that particle and it would “fall” into the ellipse, over 360 degrees. It was a cool effect but it didn’t look like anything you would expect to happen, so I replaced it with simple bouncing which is much more satisfying to watch.

Some of the enemies in Toxin use the Chipmunk physics engine. One of the things I’m proud of in this game is how you can easily mix and match different types of objects. Some use Chipmunk, others use simple bounding box and oriented-bounding box collision.

Game structure is accounted for by a basic game state manager with simple transitions and there’s a resource managment system that lets me load and unload graphics whenever I need to.

After reading Mike McShaffry’s Game Coding Complete I wrote a messaging system which allows different parts of my game to easily communicate with each other with a minimal amount of dependency. I use this messaging system for spawning enemies, creating explosions, and playing sound effects.

Next time I’ll write something about how Toxin levels work, and I’ll describe my first native Mac program, the Toxin Level Editor. Please let me know if you have any questions or if you want more information about any of the things in this post.

View Comments