richardjdare.com

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.

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’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 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.

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.

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.

If you’ve read this blog for very long you’ll know that I am a big fan of Photoshop scripting and procedural graphics. Toxin, the iPhone game I’ve been working on, uses procedural art and animated image processing effects extensively. I don’t think the game would be possible without Photoshop scripting.

However, Photoshop’s scripting system is far from perfect. You cannot access pixel data from within scripts, nor can you draw lines or circles or anything like that. These limitations have become really frustrating to me.

For example, on the day I started work on Toxin, I needed to draw an ellipse with precise dimensions. The whole game takes place inside an ellipse, you see. I couldn’t do it in Photoshop by clicking and dragging, it was too inaccurate, so I wrote a C program using the Allegro game library to create the precise shapes I needed. These were then loaded into Photoshop and used as guides while I created the game artwork.

Later I discovered Processing, which is much quicker to develop in than C. I soon developed a workflow where I would go back and forth between Photoshop and Processing, generating procedural content then processing it or running it through scripts until I got the desired result.

Processing, however has some frustrating quirks of its own. As a simplified front end to Java, you often get Java errors that are incomprehensible without digging into the underlying platform. Also, it cannot effectively save semi-transparent PNGs which means that the anti-aliased sprites I was creating all had a solid background which had to be removed. I ended up redesigning my workflow and using the excellent Ghost and AntiGhost plugins from Flaming Pear to overcome these problems.

From graphics app to graphics platform

All these issues got me thinking about what I really want from a high end graphics program. What I want is something like a programmable, graphical Lisp Machine; a powerful graphics programming platform with the UI of an art application, not an art application with a bolted-on scripting system.

I want the ability to programmatically control every aspect of Photoshop from both external scripts and from a real-time REPL inside Photoshop that works like the command line used in some CAD programs.

I want to be able to type line(10,10,100,100) and have a line appear on my presently selected image. I want to be able to open the REPL and assign my current selection to a variable which I can later re-select with a simple command. I want to be able to access the pixel data in my images, and write my own filters in Javascript within the scripting system itself. I think anyone in high-end graphics or scientific imaging would love something like this.

A true graphics platform like I have described would likely have to be written from the ground up with programmability built in. Nevertheless I did spend some time finding out how far I could go with Photoshop’s native capabilities.

I had the idea of writing a Photoshop plugin that contained a number of drawing functions which could be called from scripts via a Javascript library that integrates with the Photoshop document model. So you could write PSDraw.line(10,10,100,100); in ExtendScript Toolkit, and my Javascript library would construct a call to the plugin which would draw the line.

Unfortunately, it’s not possible to get information from a plugin back to the Photoshop script thats running it, so it wouldn’t be possible to do a getPixel() or anything like that. At best, this plugin/script combo would give us a somewhat clunky way of drawing programmatically but little else that would justify the effort involved. (have you ever seen the Photoshop plugin API?)

As a secondary option I thought about actually embedding V8 inside a plugin which would contain an editor and debugger. Besides the ugliness of having 2 distinct Javascript engines running in the same app, the plugin architecture put paid to this idea. Photoshop plugins are one-shot operations. Load the plugin, set the parameters, perform the operation, then shutdown. My idea would only be effective if the plugin was a persistent part of the Photoshop environment.

So the only options then, would be for Adobe to integrate scripting more completely, or for someone else to start making what would be a true sucessor to Photoshop.

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

This is just a quick update for everyone wanting to know what’s happening with AtlasMaker. I have a new version planned, but I’m not quite sure when it’s going to get done. I wrote AtlasMaker over a couple of evenings to save me time with an iPhone game project I’m currently working on and that is taking priority at the moment.

The next version will hopefully contain the following features.

• More/better error handling and a more robust and informative interface.
• Several rectangle packing algorithms – choose the best one for your data.
• Improved export file: more data, bigger text box for xml fragments etc.
• You can choose the filename and location of the export file.
• Optional flattening of layers on the finished document.

I was recently able to test AtlasMaker on CS4 (I developed it on CS2) and was dismayed by how slow it is in comparison. I managed to speed it up a bit by turning off “open documents in tabs”, but it still ran at a glacial pace.

I’m not sure what this means for the future of the project. It’s still quicker than making atlases it by hand, but I’m wondering if I should make the next-version-but-one a stand-alone program written in Python or C# or something. (I haven’t settled on a cross platform language for tool dev yet, but I am looking.)

Let me know what you think. Would you prefer a slow Photoshop script, or a faster external tool?

**2012 UPDATE**: I have released a new version of AtlasMaker with many more features.  Check it out here!

As I promised last time, here is a photoshop script for creating texture atlases from a directory of images. The script uses a rectangle packer class written by Iván Montes which is itself based on an article by Jim Scott. All I really did was add a GUI.

Instructions

AtlasMaker works in much the same way as the SpriteGrabber script I wrote a few weeks ago. Unzip the AtlasMaker directory somewhere, then in Photoshop,  go to File->Scripts->Browse and load AtlasMaker.jsx. The script should then run automatically.

To create a texture atlas, click browse and select the directory containing your textures. The script will then process each image to get the information it needs to make the atlas. Once this is done, you can modify your destination document size, or add an optional margin around each image. AtlasMaker will create as many pages as it needs to hold all the images.

When you are ready, click ok and AtlasMaker will generate the texture atlas, with each texture on its own layer. You should end up with something like the image on the left.

Datafile Export

If you tick the “Enable datafile export” checkbox, AtlasMaker will create a text file in the src directory called “AtlasInfo.txt”, containing a line of text for each sprite.

Each line is generated from the text entered into the “line template” edit box. Tags are used to substitute information about each sprite into the text.

#i - Image index (0.. number of Images in directory)

#filename – Filename of source image

#width – Sprite width

#height – Sprite height

#x – X position  of top left corner on spritesheet

#y - Y position of top left corner on spritesheet

#p – page number

Lets say your game engine loads textures or sprites like this: “TextureManager->GetTex(x,y,width,height);” and you have 50 images to load. You can generate all 50 calls by entering the following into the line template box:

TextureManager->GetTex(#x,#y,#width,#height);

SpriteGrabber will then generate 50 lines containing the correct coordinates and dimensions for each Image.

Download AtlasMaker

One of the most common and tedious tasks in 2D game development is making sprite sheets from dozens or often hundreds of individual image files. Back when I was making Starblaster, I laid out several hundred sprites by hand. It took many, many hours and severely restricted my ability to experiment with different graphics. It’s even worse these days since most sprites use alpha channels; the semi-transparent images are almost impossible to line up by hand, and some particle effects are practically invisible unless they are laid on a dark background.

For my latest project (more info coming soon!) I decided I’d had enough of this drudgery, and wrote a Photoshop script to do the job for me.

SpriteGrabber will take a directory full of image files and lay them out for you on one or more sprite sheets. Additionally, SpriteGrabber can export a text file containing information about each sprite. You can use this feature to generate calls to whatever function you use to load the sprites in your game.

Instructions

To run the script in Photoshop just go to File->Scripts->Browse and load the SpriteGrabber.jsx file from wherever you downloaded it to. It will run automatically and present you with the interface above.

Click “browse” and select the directory containing your sprites. SpriteGrabber will now process the directory and work out how many valid image files there are and how big the sprites are going to be. If you have different sized images in the directory, SpriteGrabber will use the largest dimensions to determine the sprite size.

Once the images are processed, the script will work out how many rows and columns there’ll be per page and how many pages will be needed to hold all the sprites. You can adjust the document width and height to alter these properties. Once you are happy, just click “Ok” to generate the sprite sheets.

Datafile Export

If you tick the “Enable datafile export” checkbox, SpriteGrabber will create a text file in the src directory called “SpriteInfo.txt”, containing a line of text for each sprite.

Each line is generated from the text entered into the “line template” edit box. Tags are used to substitute information about each sprite into the text.

#i - Sprite index (0.. number of sprites in directory)

#filename – Filename of source image

#width – Sprite width

#height – Sprite height

#x – X position  of top left corner on spritesheet

#y - Y position of top left corner on spritesheet

Lets say your game engine loads sprites like this: “SpriteManager->GetSprite(x,y,width,height);” and you have 300 sprites to load. You can generate all 300 calls by entering the following into the line template box:

SpriteManager->GetSprite(#x,#y,#width,#height);

SpriteGrabber will then generate 300 lines containing the correct coordinates and dimensions for each sprite. (This is probably a poor example as in real life you’d use a simple loop to do this, but it does illustrate how the feature works. The datafile export will come into its own when the next version is complete.)

The Future

SpriteGrabber is not intended as a masterclass in Photoshop scripting. In fact it’s the first script I’ve ever written, but it should help trim a few tedious hours off the development process. Soon I hope to have a new version ready that will be able to efficiently arrange sprites or textures of any size.

Download

SpriteGrabber has been tested on Photoshop CS2,CS4,CS5 for Windows Vista, and CS3,CS5 for Mac OS X.