Archive for the ‘game development’ Category

Antigen is complete!

Posted on May 18th, 2014 in Antigen, game development, games, Toxin | No Comments »

I finished Antigen this afternoon and uploaded it to the App Store. As soon as it gets Apple approval, I will prepare for launch! Now I just have to get the new website finished and prepare my marketing materials. Stay tuned…

Submit to reddit

Making a heat map effect for Toxin

Posted on June 20th, 2013 in game development, iPhone, programming, Toxin | No Comments »

Toxin Heatmap

As you might already know my forthcoming iOS game, Toxin involves shooting rapidly dividing toxic cells which eventually fill the playfield or burst to spawn flying enemies.

Now, not long ago I read an article about generating heat maps to display web statistics, and I thought it would be cool to use this technique to colourise the ever changing clumps of cells in Toxin. After finding out how they work, I knocked up a prototype in Processing before adding the effect to the game.

Generating heatmaps is pretty simple. Take a 2d grid of values, perform a Gaussian blur on it, then use each resulting value as an index into a gradient of colours.

For Toxin, the first step was to create a simple array of numbers representing the current state of the cell grid. Toxin cells can be different sizes. To simplify things, I store each big cell as several small cells.

Each cell is given an initial value of 255. When we draw our cells, we use a range from black to white, where values of 0 are black, 255 is white and values in between are shades of gray.

heatmap-initial
The cells are represented as a grid of numbers. Each cell is given the initial value of 255

The next step is to apply a simple box blur to this grid of numbers. Normally heat maps use Gaussian blur, but since Toxin’s grid is such a low resolution we can get away with using a simpler algorithm which is much faster to calculate. To learn more about blurring techniques, I recommend Alex Evan’s article on Gamasutra.

Toxin heat map blur
The cell grid after being blurred. Notice how the values have changed

Now look what happens when we draw our original cell grid using the values from the blur operation. Cells in the middle of large clumps have higher values than solitary cells.

Toxin heat map grayscale
Drawing the original grid with the blurred values

The final step is to colourise these grayscale values so they look cool. We do this by mapping these values onto a gradient I made in Photoshop. Values of 0 map onto the left of this gradient, 255 to the right, and the others to the colours in between.

Toxin heat map gradient

When we draw the grid with the colours from the gradient we get our heatmap!

Toxin final heat map

Submit to reddit

Using a 19 year old art program for IPhone development

Posted on April 14th, 2013 in game development, iPhone, photoshop, Toxin | No Comments »

I’ve been feeling rough this weekend so I decided to work on one of the easy jobs that I’ve been neglecting during Toxin’s development; finishing off the front end.

For some reason the front end design is something that I absolutely must get right before I can envision the whole game. At the start of a project, I will spend hours trying to make a title screen and find the right font. If I get that right, everything else will follow. The design elements that I choose for the title screen seem to become the foundation for the graphical style of the whole game.

Toxin title screen

Needless to say, Toxin’s title screen, like everything else in this supposedly simple abstract shooter was a struggle to get right. It was really just lucky experimentation that lead me to the nice animated effect I use for Toxin’s title screen. This effect warrants a detailed blog post of its own, and I’ll write one soon. Today I want to write about how I made the buttons for the main menu using a 19 year old graphics program.

Toxin menu screen
Toxin’s main menu. What you can’t see from this screenshot is how the glowing colours shift and change using multiple blended layers.

The icons on each button are simple pixel art images which were vectorised, loaded into 3D Studio Max, then extruded. My first icons were made by extruding text using the Topaz font, which was the default font on AmigaOS back in the day. I found it impossible to signify everything using text glyphs alone, so I decided to do some pixel art.

I found Photoshop too frustrating to use for pixel art. It’s just not geared for that kind of work. You can’t delete quickly, and when you’re zoomed in the cursor does not snap to the pixel grid. So I decided to go full oldskool – I started up my Amiga Emulator, WinUAE, and loaded Deluxe Paint 4.

In a couple of minutes I had knocked up some simple 16*16, 1 colour icons ready to be imported into 3DS Max.

dpaint-toxin-icons
DPaint 4 running on the WinUAE Amiga emulator. Drawing sprites inside a 16*16 checkerboard is an old technique from the Amiga days

For those who don’t know, Deluxe Paint (invariably referred to as DPaint) was the de-facto standard graphics program on the Amiga computer, just like Photoshop is for today’s machines. It was also the industry standard for video game art up until the start of the 3D era. (At least it was in the west. I have no idea what was used by the Japanese games industry to create such pixel art masterpieces as Seiken Denetsu III and Final Fantasy 6. If you know, send me a message).

It was developed by EA, believe it or not, back when they released interesting creative software like the Deluxe Music Construction Set, and published games like The Bards Tale. The first version was released in 1985, and was in development until 1994, which was probably the beginning of the end of the Amiga era.

I still have my copy of DPaint I. I bought it for £5 in 1991 when I was a poor schoolkid saving my dinner money to buy games. By that time it was already six years old and two versions behind, but I spent hours on it drawing cyberpunk cityscapes and trying to copy Street Fighter characters from magazines.

dpaint1

Submit to reddit

Toxin – Advanced Sprite Techniques

Posted on March 24th, 2013 in game development, photoshop, Toxin | No Comments »

toxin-sprites

Creating good looking graphics for an abstract game like Toxin is harder than it first appears. Not only are your images stripped bare of most signifying information, requiring a real eye for the principles of graphic design, but creating the artwork itself – giving each line the right balance of sharpness and glow, demands careful image processing and a great deal of experimentation.

When I started making Toxin, the graphics were a real struggle. It took me an enormous amount of work to develop the look of the game. To give you an idea, I have a folder on my laptop with all of Toxin’s artwork in, and it weighs in at 967meg! All for a little mobile game!

Eventually all my experimentation began to pay off, and I developed some powerful techniques for creating animated multicoloured abstract sprites. In this post I want to describe one of my favourite methods.

I start by creating our sprite out of spline shapes in 3D Studio Max. Unlike many 3D programs, Max can render splines at various thicknesses, animate them, and can even apply texture maps and materials to them.

I then use gradient maps to mask out areas of the shapes that I want to be different colours. These gradient maps are then animated, so the different coloured areas can actually move around the shape.

Then, I do two sets of renders. First I render the shape with the masks on, so there’ll be a hole wherever the coloured area will be. Then I do another render with the mask inverted, so that only the coloured area is visible.

make-a-spiker
This diagram shows each step in the creation of one frame of animation for a Toxin sprite. The total animation is 64 frames long. This intricate process is largely automated using Photoshop scripts

Then its time to start up Photoshop. After deciding what colours I am going to use, I run each set of sprites through a Photoshop script that colourises them and adds a glow. To create the glow, I duplicate the image into another layer, Gaussian blur it, then additive-blend it on top. Sometimes I use several glow layers with different Gaussian blur parameters. I also find that using image->adjustments->Hue/Saturation to colourise gives me the best results.

The final step is to compose the two sets of colourised renders into a single sprite. I do this with another Photoshop script. The end result is a lot more interesting than the basic Geometry Wars style sprites everyone else is using, I think.

Submit to reddit

AtlasMaker 0.7 – Make Texture Atlases in Photoshop

Posted on November 24th, 2012 in AtlasMaker, game development, photoshop | 44 Comments »

In game development it is common to have hundreds if not thousands of texture maps and animation frames in a single project. Keeping track of all these images is taxing for both the developer and the computer, so what we do is arrange the images into texture atlases.

A texture atlas is an image that contains many other images. Usually, all the animation frames for a single sprite, or all the textures for a single object are arranged into a single image. The game code then looks at a smaller portion of this image when it needs to draw a particular sprite or texture.

AtlasMaker is a Photoshop script that lets you create these atlases inside Photoshop. It takes a directory of individual textures and arranges them on a single image. It can be used both for atlases of different sized images, and for tile grids which are commonly used in 2d games. Earlier versions of this script were released in 2009. I know I promised an update long ago, but I have been working on my iPhone game, Toxin. I have been using this script throughout Toxin’s development, but never got round to tidying it up for public release.


AtlasMaker main window. A tile grid for a 2d game is being created

Features

  • Cross platform – tested in Photoshop CS3,CS4,CS5 on Windows and Mac OSX.
  • Open Source
  • Create texture atlases or tile grids for 2d games.
  • Several image sorting algorithms. Find the most efficient one for your textures.
  • Add a margin to each image.
  • Custom data file export.
  • Extendable – It’s easy to add your own rectangle packing algorithms and sorting methods.


Generated with AtlasMaker: Left, a texture atlas with variable sized images. Right, a tile grid. Images used are randomly generated test textures.

Installing AtlasMaker

There are two ways to running AtlasMaker in Photoshop.
Unzip atlasmaker-v0.7.zip to your photoshop scripts folder. On windows this is usually: C:\Program Files\Adobe\yourphotoshopversion \Presets\Scripts
On a Mac this folder is at: Applications/yourphotoshopversion/Presets/Scripts

When you next start Photoshop, AtlasMaker should appear in the File->Scripts menu.

Alternatively, you can run the script without installing by unzipping the atlasmaker folder somewhere, then selecting Scripts->Browse from the file menu and then selecting AtlasMaker.jsx.

Quickstart guide

The first thing to do is select a directory of images by clicking “browse” at the top of the window. Once you have done this, AtlasMaker will scan through the images and collect size information about them.

Next, you want to select your packing method. If your images are texture maps of different sizes then you want to select the “Atlas Maker”. If you are making a traditional 2d game where the sprites are all the same size, then you want to select the “Tile Grid”

You’ll notice that some text will appear underneath “Number of Files”. This is a notification from the Tile Grid Packer telling you how many rows and columns your images will take up given the default document size. Different packing methods provide different notification messages according to their nature.

Then you can optionally select a sorting method. Sorting the images in different ways can improve the efficiency of the texture atlas. Some packing methods do not allow sorting, and will disable this option if they are selected.

You can also add a margin here if you want a gap between your textures. Margins are added on to the width and height of each image just like CSS margins.
Next, click “Document Settings” and you will be able to set the size of the texture atlas you are going to create. You can also set the document name here, and choose if you want to flatten all the layers into one, once the atlas is complete.

Now click “Create Atlas” and you’re done.

Custom data file export

One of AtlasMaker’s most powerful features is the custom data file export. You can export a text file for each texture atlas containing information about each image on the atlas. This might be XML or JSON to be loaded by a game engine, or you could use it to directly generate source code to be pasted into your application.


AtlasMaker custom data file panel. Here an XML fragment will be generated for each texture in the atlas. filenames and texture positions are substituted into the text using tags

Tags are used to substitute information about each image into the text:

  • #i – Image index (0.. number of images in directory)
  • #filename – Filename of source image
  • #width – image width
  • #height – image height
  • #x – X position of top left corner on atlas
  • #y – Y position of top left corner on atlas
  • #p – page number

If you click the “Reorder export file” button, you can rearrange the order in which textures are listed in the export file. Just select filenames from the list and click “up” or “down” to reorder them. You can select multiple filenames by shift-clicking.

The zip file contains a readme.txt which describes every option in detail.

AtlasMaker is designed to be extensible. It is easy to add new packing methods and sorting algorithms. I have written the code to be more or less self explanatory in this regard, but if you want me to write something about it, please let me know.  And let me know if you find any bugs!

Download AtlasMaker version 0.7.3 (Last update 8th Feb 2014)

Submit to reddit

Toxin – Creating sprites in Processing

Posted on November 18th, 2012 in game development, Toxin | No Comments »

One of the most powerful graphical tools I am using to make Toxin is Processing, a Java based platform used to create generative art. Processing provides you with a basic IDE, a graphics API and a simplified front end to Java that lets you get things up and running with a minimal amount of work. It’s great for doing experiments or when you need to create art programmatically rather than with a graphics program.


Processing provides a simplified front end to Java, ideal for quick experiments

The green cells in Toxin were all generated using a Processing program. Each cell is a circle made up of a number of connected spline segments. I animate the cell by displacing the spline control points using Perlin noise. The cells are then resized and colourized in Photoshop.


Left, a cell being rendered in Processing. Right, the finished result

As you can see, the finished product does not look exactly like the original Processing output. I had to do a lot of tweaking, re-rendering and reprocessing until I got them looking right. It was very time consuming. There were many moments where I wondered if I was going to get useable results at all.

Many of Toxin’s graphical effects have their origins in experiments I did with Photoshop blend modes. I discovered that certain combinations of layers and modes resulted in nice abstract animations when the layers were dragged around. I wrote photoshop scripts to perform these movements and spit out animation frames. Unfortunately these scripts revealed many bugs and inaccuracies in Photoshop and its scripting system. You only have to look through the source of my AtlasMaker Photoshop script to see how many strange workarounds are required to accomplish straightforward tasks.

To solve these problems I implemented Photoshop’s blending modes in Processing, and use this to create my animations. Below are a few frames from Toxin’s shot animation that demonstrate the technique. The way the colours shift throughout the animation is down to the movement of multiple layers blended into a simple white shot sprite. You can get a better idea of how this looks in the game by looking at the screenshots I posted a couple of weeks ago.


Many of Toxin’s sprites use animated image processing effects


I also used Processing as a test bed to work out algorithms before implementing them in the game. For example, Toxin has a weapon which freezes the edges of groups of cells. It didn’t take long to prototype this in Processing.


Testing a powerup that uses a flood fill algorithm to find edge cells

Stay tuned for more posts on Toxin, and a new version of my texture atlas Photoshop script which is in final testing…

Submit to reddit

Toxin Graphics – Introduction

Posted on November 3rd, 2012 in game development, iPhone, Toxin | No 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.

Submit to reddit

Toxin for iPhone and iPod Touch

Posted on October 13th, 2012 in game development, iPhone, Toxin | No 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 1981 Vortex - 1988 Visionary Design
Ebonstar - 1988 MicroIllusions
E-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…

Submit to reddit

Toxin – Coming Soon

Posted on June 10th, 2011 in game development, iPhone, programming | No Comments »

Toxin Title Screen

This is the titlescreen of Toxin, my first iPhone game. It was only supposed to be a warm-up; a short project to help me get back into the game after a few years developing web applications, but it has taken much longer than I anticipated.

I’m doing the whole thing myself, code, graphics and sound, largely because I don’t know anyone who could help me out, but also because I was a child in the 80′s, and despite all the developments in gaming that have happened since then, I still have the image of the lone game developer somewhere in the foundations of my mind. I grew up idolizing 8-bit legends like Tony Crowther and Andrew Braybrook, and learned to code in a world where games had authors associated with them. Things have changed, but I still carry all that with me; I just wouldn’t feel like a proper game developer if I didn’t do at least one game on my own.

Oh, and the title screen is animated. It uses a pretty cool effect that I will probably write about soon.

Submit to reddit

Getting the size of a PNG without loading it

Posted on October 9th, 2010 in game development, programming | 1 Comment »

My current iPhone game (more info coming soon, I promise!) has a resource system that allows me to load texture maps when I need them and unload them when I don’t. This helps makes the game very memory efficient, but it had one annoying flaw. At program startup I had to load and unload several textures to get size information I needed to set up other game structures. To avoid this wasteful operation I started looking at ways to extract information from a png without loading the whole thing.

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;
}
Submit to reddit