Category Archives: animation

Death frame animation and expanding on the base classes used for sprites [no code]

At some point I knew that the challenges of writing new code to render sprites would give way to good old game logic. That time has come.

I have recently started to consider all possibilities with my sprite and spritesheet classes.
Such things as which frames to use for Attack and Death. I want as many on-screen objects as possible to be animated rather than just a simple flicker on and off. Such things as muzzleflashes needn’t be lengthy affairs but death frames always work best when they are stretched a little.

I also want to be able to leave the corpses in place on the canvas and possibly continue the collision detection beyond sprite death to include blooded footprints after a corpse is crossed. Depends on performance but I wouldn’t imagine it’ll make much difference.

The good thing here is that I’m not actually writing new code. I have numerous functions at my disposal for detecting collision and skipping through frames. Where the syntax for drawing is slightly different the logic is the same.

As anyone who has read my blog before will know I don’t use libraries. They kill my interest stone dead. But I do make a point of reusing my code liberally. For me much of the fun is in crafting and assembling new functions and classes to fit the purpose of the game. Now that I am faced with a different approach to making browser games I am enjoying the new look of my code.

Something that is at my disposal which I am enjoying a great deal is the ability to work with sprite sheets. Splicing all animation frames together to a single .png file and then programmatically selecting the frames to display based on a situation is truly wonderful. As is rotation. Those two features alone have cemented my commitment to producing games using this new technology in the future.

I heartily recommend the use of canvas and the new JavaScript functionality to anybody with an interest in creating plug-in free games to be played in a web browser.

See the latest code in action 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:

Rotating a sprite with HTML5 and Canvas

From a newbie’s perspective the process of drawing an image and then rotating it is daunting.

In my simple mind I had expected to be able to simply grab a context to work with (i.e. the HTML image object) and then paint it to the canvas context and apply transformations.

So I started to write the following…

var ctx = document.getElementById(“canvas”).getContext(“2d”);

ctx.drawImage(…with all the spritesheet selection criteria as parameters…);

… and then I stopped. I was suddenley confused at how any further code would be interpreted. How on earth can I write JavaScript to physically rotate the image object supplied to the drawImage() method.

So before I could think of writing a call to the .rotate() method I knew I had to understand how this drawing and transforming worked.

The solution lay here:

The canvas context within which you work needs to be understood.
To effectively rotate my image on it’s axis I discovered that I needed to first save() the context’s state.
I then needed to translate() it.
Then I could rotate() and finally I would draw the image.

What is important is the sequence of events.

Take a look at the following:
//gl.ctx is the canvas context that I create within the global (gl {}) namespace. // var o = sprite object that carries a spritesheet object.;

gl.ctx.translate(o.x,o.y); gl.ctx.rotate(o.angle * (Math.PI / 180));

gl.ctx.drawImage(o.spritesheet.image, o.frame * o.spritesheet.offsetw, 0, o.w, o.h, -o.w/2, -o.h/2, o.w, o.h);


The above sequence of instructions see to it that the rotate() method is effective only for the image that I am about to draw.
The translate method effectively moves the canvas by x and y.

So if I have a sprite that is sat at 128 x 128 on the canvas. To apply my transformation I need to move the canvas 128 pixels to the right and 128 pixels down.

Once I have snapped the canvas to this location (admittedly translate is a lousy method name for a newbie to understand) I am able to consider rotating the image.

My angles are set as increments of 45. So I have 8 possible positions thru 0 to 315 degrees.
So I rotate the image using the .rotate() method (note the important use of Math.PI / 180) and then draw the image.

But there’s one vital thing left to consider.

I have moved the canvas context to be relative to the image that I have just rotated.

The 6th and 7th parameters in drawImage() need to reflect this since they position my sprite to an x and y on the canvas.
You might think therefore that since my sprite is sat at 0 , 0 on the canvas (since the canvas context snapped to the x and y of the sprite) I could just specify 0, 0 here.
But that would give the effect of the sprite spinning around the top left point of the graphic. I don’t want that. I want the sprite to spin on its axis.

So I specify a negative number. The sprite is to be drawn at minus half the width and minus half the height of the sprite.

The “half” bit is vital in pin-pointing the centre of the image.

Effectively I have now drawn the image to less than the top left of the canvas context.
For an image of 32×32 this means that the image is drawn at -16, -16.
This gives the impression of the sprite spinning on its central axis.

Finally once all the work is done I can restore the canvas state so as not to affect any other subsequent drawing.

You can see the final effect here:

This topic requires a good deal of thought and application on my part. I hope to revisit it shortly and offer new thoughts. It’s quite possible that I edit this post to correct terminology or my understanding of the process. But hopefully there is enough pointers here to help somebody through what is a different way of thinking in term of sprite application.

Castle Adventure and a possible remake

Just a couple of quickies.

My first JavaScript arcade game Castle Adventure is now online.

Hopefully it performs well. I had a lot of fun making the game 3 years ago and hope to revisit it some day soon. The thought of controlling a magic conjuring warlock through a ghoul infested castle still thrills me :)

You can see my first CANVAS attempts with a wizard character here:

SpaceStorm – the seeds of a new shooter

Well it’s pretty funny how developments lead to new ideas and cool games.
I’ve recently been developing a simple concept for a GUI that I decided to bring to life with some “game like” animation. Essentially I had a spark storm spawn as the mouse pointer passed over certain icons. I liked it so much that I played with it a bit and aimed for something almost Disney-like. The fairy dust approach if you like.

So I went as far as I could with the idea without exhausting it and then utilised the same code in a simple game framework. I drew a starship that you can move left and right with the arrows and spawned lasers with my standard fire buttons Z or CTRL. Since there are no aliens to shoot I set the lasers to KILL() at canvas edge. On kill the co-ordinates would be used to spawn a spark storm.

Being a nut for laser games I made it so that you could hit the fire button a ton of times and spawn countless spark showers.
I absolutely adore the resulting effect. Just need to craft a game from it now :-)

You can play it yourself at this link:

Simple JavaScript dungeon adventure and a bit of Warp Factor 9

I’ve really struggled to keep this blog up to date. A good many developments have come and gone in recent months that I’ve not had chance to chronicle on this blog. I’ll try and make amends.

Part of the problem with infrequent updates is my new found addiction to the World of Warcraft. I fought it for a long time but eventually caved in about 2 months ago and bought the game with a 60 day game card. My fascination and love with fantasy is fed in spades by this game and as always fuels my creativity. So much so that I went back and took a look at some of my NetHack style ideas.

You can see one such test at this link: Dungeon.html

And here’s an extra little JavaScript thing. I tried to create a space warp with randomly generated stars. Check it out: Spacewarp.html

Hoth Strike – AI modifications

The latest upload of Hoth Strike contains some AI changes. I had wanted to present a game where the player deals with varying alien behaviour. Up until last night much of the behaviour was predictable and samey so I decided to revisit it.

probe_0_1The probe is essentially the probe from the movie. I loved the dangly leg thing that was going on in that so it made sense to base it closer to the ground. I set the threshold to be about 3 probe heights from the base of the canvas. Better still I wanted it whizzing around like a probe on a mission. i.e. sniffing out rebel pilots. So I set a couple of new properties .floatdir, .upthresh, .downthresh.

Each of these new properties controls which way the probe is floating by way of a modification to the alienmove() function. The code sniffs for the sprite class and if it’s “probe” performs the modification. A floatdir of 0 sends the probe floating up and a floatdir of 4 sends the probe downwards. Better still I modified the speed of the probe and set it off at pace as it changed direction finally slowing down to almost a stand still before it flicks back the other way. The result is satisfying and from a player’s perspective a wee bit trickier to hit with the lasers. I’m happy with it since it ought to be close to the ground and now it is.

pod_0_1 I also modified the pods (the pink energy balls) and had them track the player a bit more by way of a simple modification based on tileDirection. They appear to linger a bit more now rather than just zip off as they did before.

mutant_0_1Finally I addressed the mutant. Defender’s mutants were horrible wobbly things that were a complete swine to hit. I wanted something similar so I modified the alienmove() function once again for spriteclass “mutant” and simply wobbled the sprite in a random direction by a random small amount.

I also added a special effect in the form of spawnSnow() which as you might gather spawns a snow flake. I perform this every time the probe or the player is in close proximity to the ground. The effect being that such close proximity would probably throw some snow up in the air. It’s particularly satisfying as you swing the speeder around !

Just now I have an issue with waves not ending properly. You could wipe out the bad guys and have rescued all the rebels but the wave would not terminate. It’s a checksum issue and something I’m looking at.

You can play the latest game here:

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 !