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

Toxin for iPhone and iPod Touch

October 13, 2012 0 Comments

Toxin Screenshot
Its time to introduce my forthcoming game, Toxin! It’s my first game since 2003, and has been in development for erm, *too long*. I can’t give a release date yet; every day I sit down and say, “this week I’m going to finish it”, but most of the code and artwork is complete. There are some cosmetic changes I want to make, so please bear in mind that these screenshots might not reflect the finished product.

Toxin is an abstract puzzle/shooter for the iPhone and iPod Touch, running on iOS3.0 and above. The basic gameplay is simple. You control a ship that rotates around the edge of an elliptical playfield, shooting inwards. If anything touches the edge you lose energy. Lose too much energy and you die.

Inside the ellipse are 99 levels of swarming biological foes, multiplying toxic cells, physics puzzles and colourful particle effects.

Microbes - Vision Software 1991

Toxin was inspired by a number of different games including Geometry Wars, Tempest, Space Invaders and Ebonstar, but the biggest influence was Microbes, released by Vision Software in 1991. I really enjoyed this back in the day, and like many innovative Amiga titles it seems to have disappeared from the consensual history of video games. You can play it with UAE, but I dont think the emulation is perfect.

I also tried to add some simple puzzle concepts to give the game more depth but without affecting the pace too much. The design process involved me sitting down with a coffee every night after work, staring at my sketchpad and thinking, “now what can I do inside an ellipse?”


Tempest - Atari 1981Vortex - 1988 Visionary Design
Ebonstar - 1988 MicroIllusionsE-Motion - US Gold 1990
Direct and indirect influences.Clockwise from left: Tempest, Vortex, E-motion, Ebonstar

Once this game is done, I am thinking about writing a Toxin “Remix” called Antigen. It will have the same ship-in-an-ellipse structure but the core game will be more puzzle based and slower paced as well as having different artwork. I think the idea of a game remix could work well at low pricepoints, a little like the way remix CDs used to accompany singles.

Soon I’ll write a little on how the artwork was done, and how it went through a long, painful process of development. I am also looking into producing a gameplay video, so stay tuned…

View Comments

New Website –

July 12, 2012 0 Comments

The website for my forthcoming iOS game, Toxin, has gone live today. Its just a teaser at the moment. I’ll add more details as the game gets closer to release. I’ll also start posting here a bit more often too:)

View Comments

Notes on a Language of Game Design #2

October 15, 2011 0 Comments

One of the things that got me thinking about the possibility of a language of game design is the feeling I often get while playing that content doesn’t matter. After I’ve been playing games for far too long, the lush scenery and the carefully rendered characters devolve into blurry signifiers, shapes that appear in configuration with other shapes, triggering wordless actions that have been scoured into my mind by hours of play. Thoughtlessly, I finish every sentence the computer starts, never letting it complete itself before I have acted and moved on.

Game content can be interpreted in any number of ways, but the game rules only allow the objects and characters to behave in a limited number of ways. Eventually, the feeling of possibility evoked by the content diminishes as the player learns the few terms by which he is allowed to use it. The characters, landscapes and even storylines become icons in a much simpler network of concepts.

The relative simplicity of this network of concepts is one of the things that convinces designers that there is such a thing as a language of game design.

I am beginning to wonder how much of this perception that there is a language of game design is down to the controller, rather than anything to do with the logical form of game entities. Imagine actually performing the action in a game rather than using a joypad.  Is there still a sense of musicality and rhythm? When imagining driving, then shooting, then playing tennis, is there the same sense of rhythmic sameness that arises during long playing sessions on different games?  The controller masks the complexity of relations between game objects and makes them feel the same.

A language of game design would be the same as the language that describes relations between entities in the real world.  Certain types of relations would be more playable than others, and this would narrow things down, but the essential form of game entities is the same as it is in reality.


View Comments