Category Archives: photoshop

New game – old game: HyperGunner

I’ve been very busy this last few days turning Wizard Wars in to a vertical scrolling shooter.
It was very easy. Some things cropped up en route that I thought were worth a mention.

When I designed Wizard Wars I made sure that the pipeline was simple. That is, I define the images and animation specifics in the code and then I’m free to go off in to Photoshop to create some sprites. I wanted to be in a position where I could comfortably hit F5 and see my new artwork in an instant. (Chrome’s inexplicable caching aside this has been fine)

Lifting the Wizard code and turning things around a bit wasn’t so much of a challenge. I implemented some simple stars that varied in shades of grey and had them tumble down the screen at varying speeds to give that oh-so-familiar starfield depth impression. I also lifted the sprites from Invaders from Mars and had them shift across the screen whilst the player shuffled his laser cannon back and to taking shots etc etc.

Making Space Invader style games is easy. I got bored of it almost instantly.

So I shelved it and went off to play a few classic shoot-em ups in MAME.
Giga Wing, Esp RaDe, Don Pachi, Loop Master… they’re all up there in my favourite list. I played them all to death.

When I got back to my own game I realised that it was all very pedestrian and lacking in colour and depth.

So I changed the image files for most things to create richer colours.
It was whilst I was adjusting the star sprites that I realised I was doing it wrong.

All I wanted from the stars was the impression of space. I could achieve this with the simple drawing of dots / lines.
I’d draw lines and shapes on the canvas before so I changed the code and hey presto I had a starfield made up of very short lines instead of graphics. I also used context.fillStyle = “rgba(r,g,b,a)” to create some colours mathematically and with varying amounts of alpha.
Not only did I have a nice colourful starfield and some added performance I also had more control. So I played with the numbers.

I’m drawing my stars using context.fillRect(x,y,w,h).
By adjusting the width and height values I could achieve a sense of hyperspace. I also increased the amount which the stars move down the screen. This changed everything. I now realised that I had a game that would be played at pace. Even if the foreground aliens, bombs, lasers etc were moving fairly slow the background pace would make the whole thing seem pretty rapid. I loved the effect. So much so that I made hyperspace one of the mini goals of the game.

Whilst the game was in its infancy I also took the time to play with the drawing.
My initial concern was that the clearRect() method was killing performance.
So I tried a newer method: g.canvas.width = g.canvas.width;
There was no improvement.
I also went to the trouble of calculating the empty spaces left by each sprite and only re-drawing those areas on every tick. When I got the code right (it was very untidy to begin with – stray pixels here and there) it worked well but there was no real gain in frames.
The biggest boost I could find was transfering the actual drawing from using HTML Images  to primitive canvas shapes – in this case rectangles. Whereas previously I had 100 + star images cascading down the screen I now have 100+ shapes being drawn.

Google’s Chrome has easily the best performance so far. Running flat out at 250 FPS.
Firefox is the poorest at around 80 – 100 FPS flat out.
But even then the game plays very well across all browsers.

I hope to put a link up soon.


Building a visual style

I’m very happy with the mechanics of the game just now. Although I still need to set aside some design time in terms of adding a few puzzle elements I’m happy that the game is behaving itself enough for me to go off and start drawing sprites and tiles. Art afterall is what I’m actually good at.

I have a very clear idea as to the look that I’m after. In short I want colour and contrast.
It’s important for me that the floor tiles are somewhat saturated in appearance whilst the walls stand out a bit more. The actual characters in the game will stand out quite a lot since I’ll draw them with more vibrant colours. Same goes for the effects – wizard’s magic, sparks, explosions etc.

There is a feature to my game editor that I hadn’t used thus far that I wanted to use now – the canpass flag.

Each tile has several flags that I set in the editor. One of them is the canpass flag which when set to 1 effectively renders the tile transparent in terms of collision detection. I’m using this flag to present shadow tiles.


Level designer
Level designer

Just now I have a limitation in the editor that prevents a sprite and a tile occupying the same space. Rather stupidly this doesn’t extend to the game where sprites can pass over tiles with ease.

So now that I have a mini objective (collect the strange brown artifacts) and a few challenges (find the key – open the door, dodge / defeat the bad guys) and a nice little twist (defeated monsters come hunting for you once they’re ressurected) I’m going to set about cementing the game’s visual style.

The latest version is available here:

Something that I’m preoccupied with is the idea of creating a light mask around the glowable objects. I’d love it if the wizard could hurl a magic ball down a corridor and it glows such that it lights up the floor and walls around it. I’m sure there’s a way with canvas.

Writing custom characters to the canvas from a .png file and some frame rates

Firstly my apologies for the random theme change. I’m forever trying to find the perfect theme for this blog. FWIW I rather like this one so will stick with it for about a week or so :-)

Castle Adventure II screenshot

Castle Adventure II screenshot

I added a feature whereby I could write numbers to screen based on my own character set.
The character set is actually little more than an image with characters positioned at equal space throughout and then called up using the drawImage() method.

Numbers The above is 240×48 pixels in dimension. Each number is sat within a 24 x 48 grid. My x offset is therefore set to 24 pixels.
Where I have a String  such as “00001950” that might be used for a score I simply step through each character in the string using the JavaScript substr() method. I can then multiply the value of the integer by the x offset to find the position of the desired character within the .png file.
So in the case of “00001950” the first four numbers  use the calculation 0 x 24 to locate the left hand side of the desired character. The y offset is constantly 0 (zero).

Using drawImage(image, xoffset, yoffset, width, height, canvasx, canvasy, width, height) I can then print a string of numbers from my numbers.png file.

e.g. for the 6th character in the string I would be using

drawImage(numbers, (9 * 24) ,0 ,canvasx ,canvasy ,24 ,48);

where canvasx is bumped by the x offset each time.

Once I had this figured as a function I knew that I could pass a string and a starting x, y to it. So I implemented a frame rate counter and dumped it bottom right on the screen.

Interestingly I got best results from Internet Explorer 9 P6. Chrome was a very close second with Opera, Safari and (a surprisingly poor) Firefox 3.6 in last place. At best I was getting around 22 FPS which when the loop is throttled at around that in the code is no surprise. Despite this Firefox couldn’t get close pulling in around 16 to 18 instead.

When the code is run flat out (i.e. setTimeout() set to zero) Chrome can get over a hundred. IE close behind.
To see such fabulous performance across all popular browsers is thrilling to say the least.
IE finally playing the game just does it for me. It means that games using this technology can be played by everybody someday.

Note: I also tested using the iPad and got around 7FPS. Room for improvement in the way that I throttle the loop perhaps.

Play the latest version here:

Advanced level editor and some good Gauntlet progress

Well I’m calling it Gauntlet anyway ;)

The best thing about a week away from the internet is the amount of quality time one can spend working out the mundane stuff. This last week I got the chance to spend a week next to the coast with the family. In rare moments of downtime I sat with a coffee and a laptop ironing out a number of bugs and issues with my level editor. Issues largely surrounding the storage of data and integration with the main game engine.

Initially I had worked with the idea of the level editor spitting out JSON formatted code which the game then read in to populate the levels with walls, tiles, sprites and other features. It was working fine but I felt rather uncomfortable storing data in text format. So, being a database guy at heart I switched and dumped all level data in to a MySQL database. The results are very pleasing. The level editor still spits out the JSON formatted text for use in game. I was keen not to have any DB involvement with the game. Not yet anyway. (I’m keen on researching the new features of HTML5 with regard to storing data)

Level editor

Level editor

So as you can see with the screen above I got around to implementing a few new features. Namely backgrounds, entities and a number of flags and modes. I’m fairly sure the screen shot explains all but I thought it worth elaborating on something that has caused me much grief.

Something from my Acclaim days that always haunts me is the notion of scale. When you’re working with a small screen (GBA) scale is a big deal. We always knew that we had little room to move with characters. Indeed memory limitations demanded a small scale with plenty of repeatable tiles. But that’s not such an issue with my game. The issue is with squeezing enough in to the playing arena and not reducing everything to pea size to accomodate. I like large and colourful characters in my games. Chunky sprites makes for happy gamers in my book :-)

So I tried a number of variations. Initially I drew all sprites to 32 x 32 on a base 16 grid. Nothing is drawn less than 16 x 16px. But I had to try all options. 24 x 24, 16 x 16. They just seemed to dwarf the characters such that it seemed like I was controlling a dot in a large playing area.

I’m using Atari’s wonderful Gauntlet game as a guide for style and play but of course that game contained a larger playing area than was viewable. Everything scrolled through the playing window hence their use of larger sprite characters. I’m not using scrolling this time.
I just couldn’t get comfortable with the scale of the sprites in my game so I took the decision to increase the playing area and present it more landscape than portrait (the original orientation).

I quickly put together a test whereby I could provide some adversaries and collectable items.

Currently the Wizard character can fire magic using Z or CTRL. I’m not sure if I want to keep this as a free feature. It’s just too easy. What I liked about my original Castle Adventure game was the emphasis on avoiding the Ghouls. Each level had collectable magic balls that could be picked up and hurled at the ghouls to wipe them out. I often think that the perfect maze game would involve a good balance of player missiles / monsters / puzzles  and exploration.


Anyway this is a somewhat hasty attempt to catch up on some blogging before the game and related tech moves on too far.

I’ve not uploaded the level editor because of its hooks in to the offline database but you can see the latest version of the game here.


Animated wizard vs animated zombies + improved motion

Something dawned on me earlier. I love it when that happens. It was such a simple thing. So much so that I’m amazed I haven’t thought of it before.

My movement and drawing code sit independent of one another. First I call the code to move a sprite with move(sprite), then I immediately call the code to draw it to screen with draw(sprite).

The effect has always been satisfactory but when you want to move a sprite that actually walks rather than glides (as with a space alien or starship) it leaves a bit to be desired. You wind up with the effect that the walking sprite is actually gliding along the game canvas whilst going through his motions. Michael Jackson style.

But then it occured to me that I could simply change the order of events to have the sprite’s x, y co-ordinates incremented on every frame bump. So I moved the call to move(sprite) to sit within draw(sprite) at the exact point the frames are changed.

The end result is that the sprite only physically moves on screen when the animation permits it. Hey ho, my characters are walking properly.

I also introduced a new sprite – the Zombie.

Zombie graphic

Zombie sprite sheet

Over time I will add collision and some special effects.

You can check the working code here:

If the content doesn’t load for you first time please reload the page.



Wizard test updated with ability to hurl magic

Well things moved at a bit more pace last night as I quickly introduced the fire button in to my simple canvas anim test.
I love the ability to string animation frames together in to a single spritesheet and have the code logically step through to locate the frame to display. Reminds me of my GameBody Advance days which is no bad thing.

So I created an additional frame to display when the wizard is hurling magic.

Wizard sprite sheet

Wizard sprite sheet

I intend to add frames to allow the player to hold down the fire button and charge up the magic in the wizard’s hand before hurling it. Perhaps another 3 or 4 frames that are activated the longer the player holds the button down. Of course releasing the fire button before the magic is fully charged stops the process altogether and the wizard defaults back to the standing frame.

The key to this is adding a bit more structure to the spritesheet class such I am able to set the frames that correspond to each action.

I may use properties within the class such as:


which will allow me to go straight to the attack frames when the player is shooting missiles.

My approach with the player missiles (magic bolts) is the same as in all my games.
I define what I call a pot of missiles to pick from. The size of the pot (array) is identical to the amount of missiles that I am prepared to let the player shoot at any one time. i.e. the maximum number of missiles on screen at any one time.

Each sprite in the missile array has an alive flag which by default is set to false.
When the player presses the fire button the code loops through the array looking for a missile that isn’t alive.
When it finds one it sets its status to true, initialises it’s position to that of the missile initiator (in this case the player sprite) and breaks out of the loop. When the missile expires (reaches canvas edge, strikes a target) I kill() it which effectively sets its status to false again and therefore renders it available for selection once more. Strictly speaking I should also move it well off screen to a negative location (e.g. -32, -32).

So there you have it. Take a look at the results here:


Wizard sprite animated using HTML5/Canvas and rotate() method

Quickly following on from my previous post about using the rotate() method to save a ton of artwork I thought I’d knock up a quick wizard sprite with 2 frames in Photoshop. I think it’s interesting sometimes to peek in to people’s development environment so I thought I’d share a snapshot of my Photoshop session whilst I was creating the sprite.

Photoshop sprite session

Sprite being constructed in Adobe Photoshop CS

You can see a screen grab from Castle Adventure under the main document which I was using to put me in the right mood for drawing a Merlin style wizard. The effect is tidy but crude. Adequate for demonstrating the simple animation process I am aiming for.

Here’s the code and sprite in action:

1970’s style magazine poster for Hoth Strike


Bored one afternoon flicking through an old magazine online. Loved the type and layout so thought I’d crank up Photoshop and have a go.

Font is Delicious and Delicious Heavy.

Hoth Strike – development thoughts and notable points

No updates for a little while so I thought I’d offer some thoughts on the progress of the game (Hoth Strike).

The last stuff to go in was the Pod / Pod Launcher stuff. Anyone familiar with Defender will know all about these little devils. The theory is simple: you shoot the pod launcher (carrier) and destroy it only for the screen to fill with tiny little pods that are to be frank a swine to hit. I was always hugely frustrated by this in Defender (leaving aside the sheer thrill of destroying all pods before they scattered with some amphetamine trigger finger action) so for my game I wanted the pods to be big and destroyable. To counter their size I made them persist within the bounds of the playing area and simply bounce around.

I now have a few aliens in place with differing behaviours:

Probe – Dump probe modelled on the one from the movie that strikes the surface of Hoth and proceeds to inform the Empire of the location of the Rebel base
Lander – Slightly less dump probe that looks for Rebels to hijack
Mutant – Awful hybrid of Lander and Rebel that turns on the player and pursues him across the playfield spunking bombs all over the place
Pod Launcher – Big dump blob (not yet drawn) that drifts around like a jellyfish and is generally a nuisance
Pod – Big bouncing ball that will most likely knock the player for six as it ricochets off the screen edge

I had a number of emails from folk asking why the AT-ATs weren’t animated and why there were no Wampas. The answer is simple, I failed to animate the AT-ATs convincingly and I couldn’t be bothered to draw and code the Wampas :-) That said, I may have some help in the AT-AT department. Look out for a sequel to Hoth Strike in the near future to see the walkers in motion !

So that leaves me with a game that is very close to completion. I have to say for the most part it has been fantastic fun to develop. I spend most of my time just now playing the game and working out where to improve it. But generally I’m very proud of what I’ve achieved.

Some notable points in the development:

Realising that the lasers could be “double timed” by utilising the onkeyup event to spawn a player laser. This was a cracker. I was frustrated at having to rapidly smack the fire button and then realised that every key press had to be met with a key up event. Both events fire a player laser. All I had to do was force a small interval but not so much that you’d experience a gap in the action.

Perfecting the “speeder slide”. This was initially frustrating. I’d wanted to have the speeder slide left and right since it adds a whole new dynamic to the game. But I had the speeder sat static in the centre of the screen and literally swung the landscape around. The effect was poor until I unglued the speeder and had it swing around the screen with only minor adjustments to the landscape below. On playing the game I realised that the speeder slide is an effective technique against the mutant probe !

Scrolling the terrain. This is key to the game working. I knew that I could stitch tiles together since I’d done it with the prototype but actually moving them at pace seemed a bit ambitious. Never the less I worked it out to the pixel so that the scenery tiles moved seemlessly. This is something that I am quite proud of.

The general look and feel of the game. The entire project has been a retro step for me in that I get to play with individual pixels in Photoshop once more. I love pixelling game graphics and this has been hugely entertaining and rewarding. There are a host of sprites that won’t make it in to the game which I may post up some day. The next game will be sprite intensive and will be an vehicle for testing my pixel work ;)

So there you have it. I hope to finish the game off in the next week or so and add it to my expanding library of 2 games.

Thanks for reading.

Hoth Strike colour, composition and Ralph McQuarrie


Ralph McQuarrie's inspirational painting of an AT-AT Walker on the surface of Hoth

Ralph McQuarrie's inspirational painting of an AT-AT Walker on the surface of Hoth

 Like any other game designer I take my inspiration from all manner of sources. Hoth Strike is a fairly easy one to research since the movie The Empire Strikes Back is one of the top grossing movies of all time. There is literally a truck load of material out there. Obviously I also have the movie on DVD so plugging and playing for research purposes is often called for.

But it’s the work of Ralph McQuarrie that provides the greatest inspiration and the painting above inparticular helped to define the palette for the game.

Blue and Orange sit together beautifully. As artists we all know that and in a lot of cases it’s been done to death. But in the image above it just says it all. What I love about it is that it excludes any evidence of snow and ice. It could just as easily have been a concept piece for a battle taking place on Tatooine. There’s nothing in that shot to suggest that the vehicles are engaged in a battle on an ice planet in sub-zero conditions.

Even without the exploding trail from an unfortunate Snow Speeder this image has drama. The walker looks menacing with it’s upward pointing head and gun turrets and clearly stands at a good height from the ground. (Anything with legs is unlikely to be flying, surely !) 
The speeder dashing past appears to be trailing a rope. The mind boggles as to it’s intention. On watching the movie obviously we know the outcome.

What strook me about this image is that there are about 5 or 6 clear colours that dominate.


At first I translated the colours literally in to the game. The sky was bright blue, the ice below was shades of light blue and white/grey and the probe droids were dark and bleak. I wanted to remain faithful to this painting and fought with it for the best results. Ultimately it didn’t work and I had to reluctantly rethink.

The droids just didn’t sit right against a bright sky. Infact I really didn’t like the sky like this. I had always envisaged a night sky bleeding in to the bright Hoth daylight. (note: I’d opted for a clear setting as opposed to the bleak setting in the movie where horizons were largely undefined) So I applied a stepped gradient to the background layer and placed an obligatory Atari/Activision sunset colour scheme behind the mountains. (I always loved those saturated sunsets in the early VCS titles).

The result was that I could create brighter and more cheery graphics and sprites to fly over the darkening sky. I instantly brightened up the main probe droid and coloured the “raider” tones of yellow and orange. The mutant probe is actually comprised of colours from the McQuarrie painting.

Better still I had the perfect backdrop for bright Star Wars lasers and a beautiful contrast with the snowy terrain below. At Software Creations and subsequently Acclaim I pixeled a hell of a lot so putting these images together was pure retro fun. I even created tiles that wrapped seamlessly as if still designing for the GameBoy :)

The rebel soldiers take their base colour from the same orange that drives the explosions which in turn is taken from the McQuarrie painting. (I should add here that I modified the colour levels on the painting in Photoshop before taking the colours out and plonking them in to my game palette)


So there we have a detail from a frame of the final game. 
I think the overall result is extremely satisfying and great fun to play.
The most important part of playing with colour schemes and composition is understanding the game and what you want the player to “experience”.
In Hoth Strike I was always going to move everything at pace. It was therefore vital that colours were clear and anything that moved, such as landscapes and alien missiles, were clearly defined. Otherwise the entire thing would have become a mud of colours and confusing to play.

I will be creating a second Hoth game at some point and when I ultimately put the finishing touches to this one the plot and scenario will become quite apparent.

I hope you enjoy playing the game as much as I do bleating on about it !