I’ve been so busy with the launch of Antigen that I forgot to post the trailer video on my own site!
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…
Posted on May 6th, 2014 in Antigen, games, iPhone, Toxin | No Comments »
Sorry I haven’t been posting lately, I have been very busy finishing off Toxin, or Antigen as it is now called. Unfortunately I had to rename the game as there was already a game called Toxin on the app store. Antigen was originally going to be the name of Toxin’s sequel. Now I’ll have to find another name for it. The game will be out in the next few weeks. I am working round the clock to finish it.
Once Antigen is out the door, I will be able to devote some time to writing. I have a bunch of articles in the works on mathematics, self education and game design.
And I’m already planning my next game…
In September 1987 I bought my first copy of Computer and Video Games magazine. Alongside reviews of Road Runner and Solomon’s Key and a feature on the newly released Sega Master System, there were a few astonishing screenshots which awakened in me a new sense of what was possible in computer games.
These screenshots were from a game called Ancient Mariner.
Although I couldn’t have explained it at the time, they helped form the original vision that got me into game development in the first place; a vision that one day technology might allow us to externalise our imaginations and let us experience them with all the intensity of physical life.
Described in one preview as “what could be the most grand and impressive game so far”, Systems Architects’ Ancient Mariner swashbuckled its way through the games press inspiring excitement and wonder before vanishing, unreleased and without explanation. One year later, in response to a reader’s inquiry, a Games Machine staffer wrote: “As for the legendary Ancient Mariner, we’ve heard nothing of it recently, seen nothing of it and can’t make contact with Systems Architects themselves.”
As anyone who follows the games industry will know, cancelled titles and vanishing companies are nothing out of the ordinary. But some unreleased games seem to stand out as talismans of creative potential, symbols of what gaming could become. These games often appear during the axial ages of the industry, when technological shifts raise up new continents of possibility, inspiring developers to embark on foolhardy voyages in search of distant visions.
Ancient Mariner appeared at the beginning of one such age, at the time when the Amiga and Atari ST really began to make their mark on game design. Up til then, many 16-bit games still bore the impressions of the 8-bit era; some were little more than C64 games with a few more colours. But from 87-89 developers began to get to grips with the new technology and started to design games which broke with the past.
The game was programmed by Manuel Caballero, who previously wrote Imhotep for 8-bit legends Ultimate: Play the Game. C&VG quotes him as saying that Ancient Mariner is probably the first Atari ST game written completely in assembly language.
The artwork was produced by Mike Jary and Emma Hughes. I suspect they had a background in traditional animation; the artwork has a confidence and expansiveness rarely seen in games of that time. The most impressive shots don’t seem to restrict their lines to the axes of movement like so much game art. This is partly what made these images so evocative. You can’t quite see what the game mechanics will be just by looking at them.
So what kind of game was Ancient Mariner? According to C&VG, it was meant to be a trilogy, with each part coming on three disks. The player takes the role of an “impoverished 16th century seadog whose lands have been lost through gambling and bad business deals. To regain his former status in life he must trade – both legally and illegally – all over the world”.
The game “will contain play that will appeal to the traditional adventure game player” as well as combining “fast arcade-action with icon-controlled elements”. The arcade sequences would have included “battles in the Spanish main, skirmishes against cannibals, raiding and boarding parties and hand to hand combat”.
It seems to me that Ancient Mariner might have been something like a cross between Sid Meier’s Pirates and a Cinemaware game, perhaps with something of the eccentricity and high art of Captain Blood mixed in.
Sid Meier’s Pirates needs no introduction, It’s probably the best known and best loved pirating game there is. It was released in 1987, and reviewed two months after Ancient Mariner was previewed so I’m not sure how much of an influence it would have been. Pirate games were definitely in the air that year. The C&VG review of Sid Meier’s masterpiece compares it favourably to others available at that time, such as Cascade Software’s Pirates of the Barbary Coast.
Cinemaware however, might be less familiar to the gamers of today. Cinemaware were one of the outstanding developers of the early 16-bit period; their games had production values few others could match at that time and had a distinctly American “bigness” which still counted for something in my corner of eighties Britain.
Their games were early attempts at interactive movies, and usually featured arcade, puzzle and strategy sub-games within a well-animated linear narrative.
Ancient Mariner sounds very much as if it could have been a moodier Cinemaware game, taking its cues from European comics and animation rather than Hollywood.
And that is pretty much everything I have discovered about this mysterious game. If anyone knows more, or has even played Ancient Mariner, please let me know.
Posted on June 20th, 2013 in game development, iPhone, programming, Toxin | No Comments »
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.
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.
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.
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.
When we draw the grid with the colours from the gradient we get our heatmap!
Sorry I haven’t posted in a while, but I’ve taken a break to deal with a sad family situation. I will be back soon.
I want to get Toxin out the door as soon as possible, and get started on my next game, which has been brewing in my mind for over a year now. I also have a radical web development tool I’ve been working on as a side-project.
I’m also working on some more serious, philosophical articles on game design. I’m hoping to start a bit of a shit-storm with those to be honest!
Till the next post…
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.
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.
Posted on March 24th, 2013 in game development, photoshop, Toxin | No Comments »
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.
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.
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?)
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.