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.

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.

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.

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?”

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…

This StackOverflow discussion was useful, along with this guide to the png format from the W3C, but unfortunately, Apple threw a spanner in the works.

If you’ve been programming the iPhone for a while you’ll know that by default, Xcode premultiplies the alpha channel of PNG files before adding them to the application bundle. It also adds its own undocumented data chunk to the beginning of the file, breaking PNG guidelines which state that the IHDR chunk should always be at the beginning.

This Objective C function will return the size of an image for both standard and Apple PNGs. It scans through the file looking for the IHDR chunk, making no assumptions about its position. It should be easy enough to convert to other members of the C family.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

#include <stdio.h>
 
//----------------------------------------------------------------------------
// GetPNGSize() - gets PNG Dimensions without loading any data
//----------------------------------------------------------------------------
BOOL GetPNGSize(const char *fileName,CGSize *pngSize)
{
    // PNG Signature
    unsigned char png_signature[8] = {137, 80, 78, 71, 13, 10, 26, 10};
    // IHDR chunk identifier
    unsigned char ihdr_signature[4]={'I','H','D','R'};
 
    FILE *fp;
    if( (fp = fopen(fileName,"rb")) == NULL )
    {
        return NO;
    }
 
    // load png signature and check it
    unsigned char sigBuf[8];
    fread(sigBuf, 1, 8, fp);
 
    if(memcmp(&sigBuf[0], &png_signature[0], 8))
    {
        fclose(fp);
        return NO;
    }
 
    // examine chunks until we find IHDR
    BOOL done = NO;
    while(!done && !feof(fp))
    {
        // get chunk length and type
        unsigned char chunkInfo[8];
        fread(&chunkInfo, 1, 8, fp);
 
        long length = (chunkInfo[0] << 24) | (chunkInfo[1] << 16) | (chunkInfo[2] << 8) | chunkInfo[3];
 
        // is this the IHDR?
        if(!memcmp(&chunkInfo[4], &ihdr_signature[0], 4))
        {
            unsigned char sizeInfo[8];
            fread(sizeInfo,1,8,fp);
 
            pngSize->width = (sizeInfo[0] << 24) | (sizeInfo[1] << 16) | (sizeInfo[2] << 8) | sizeInfo[3]; 
            pngSize->height= (sizeInfo[4] << 24) | (sizeInfo[5] << 16) | (sizeInfo[6] << 8) | sizeInfo[7];
            done = YES;
        }
        else 
        {
            // skip over the data and checksum and go to next chunk
            fseek(fp, length+4 , SEEK_CUR);
        }
    }
    fclose(fp);
    return done;
}