Playing with sprites, walls and new game concepts

I’m always looking at new game designs and cool ways to implement them. I also have my own system for creating HTML5 games that has evolved over the last 12 months.
I don’t use frameworks or libraries or such, I just enjoy getting my hands dirty with my own code.
But if you’ve read this blog before you’ll know that.

I wanted to have a crack at building my own maze game.
I’ve created similar games in the past and enjoyed making them very much so the idea of bringing one to mobile web is quite exciting.

Initially I took the decision that I wasn’t going to build a level editor. I just don’t have the inclination right now. Perhaps that will change if this game works out pretty well.
For now I wanted to just hack around in JavaScript in such a way that I could visualise the level as I key in each element in to the level data array.

Something like this..

var leveldata = [];
leveldata[0] = [
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+, ,+,+,+,+,+,+, ,+",
		"+, , , , , , , , ,+",
		"+,+,+, ,+,+, ,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",
		"+,+,+,+, , ,+,+,+,+",
		"+, , , , , , , , ,+",
		"+, , , , , , , , ,+",

As you can see I have defined an array to contain all the level data in and then populated each element with another array. It is this second array that will store the level specific data.
What you see above is a representation of tiles. Each tile on screen is 32 x 32. So a level array with 14 elements equates to 14 rows of 32 pixel height = 448 pixels. This in turn equates to a total tile height of 480pixels. Perfect for my prefered game resolution of 320 x 480.
You can also see that I’ve left the last few rows full of tiles. This is due to the iPhone leaving its status bars in place by default and therefore chewing up far too many screen pixels.

In my code I iterate through each element in the array and parse the string for the comma “,”.
You can see this below.

function setWalls()
		var l = leveldata[g.level];
		for (var y=0;y < l.length;y++)
			var s = new String(l[y]);
			var a = s.split(",");
			for (var x=0;x < a.length;x++)
				switch (a[x])
					case "+":
		g.mode = "pregame";
		g.resetting = 50;
	catch (e)
		write("Set walls: " + e.message);

g is my global namespace. Quite a lot goes in there that is game specific as opposed to player or sprite specific.
spawnWall() is my function for pulling a wall sprite out of the sprite collection and assigning it a set of co-ordinates.
Something like this..

function spawnWall(x,y,row)
		for (var a=0;a < NUM.WALLS;a++)
			var o = m.walls[a];
			if (!o.visible)
				o.visible = true;
				o.targetx = x;
				o.targety = y;
				o.x = x;
				o.y = g.canvasheight + y;
				o.row = row;
	catch (e)
		write("Spawn wall: " + e.message);

I am positioning the wall tiles below the canvas height. This is deliberate since I want them to scroll in to view in between levels. In my move() function I have code to shift a sprite from its x co-ordinate to its targetx co-ordinate. Same for the y.

So back to the leveldata array and where you see a white space no tile will be drawn.
Where you currently see a “+” a wall tile will be drawn.
Eventually the + will be replaced by single characters that represent the type of wall tile I want to display.
For now it simply translates to my default wall tile.

wall graphic
You can see that this wall tile is 64 x 32 in size and contains 2 frames of 32×32. I am going to animate my wall tiles.

When I run the game in test mode I see the following screen layout.

castle screenshot

I have deliberately defined the wall tiles as sprites.
This gives me a tremendous amount of flexibility since the sprite class and methods allow for a lot of animation and movement. It also makes life a lot easier when I come to consider collision. Rather than “overlaying” a collision map I simply test for position based on a ton of sprites.
It also gives me the freedom to move walls should my design require it.

So just now I’m playing with ideas but ultimately I’d like to plant entity starting points in to the leveldata array.
Perhaps try a PacMan approach to a game where the whitespaces are taken up with “o” which will be translated by the game in to small coins that the player must collect.
I don’t know. It’s early days.
The most important thing is that my codebase allowed me to create this proof of concept in around 15 minutes.
Exciting times.

Pixelling the characters in Space Bug Racer

Space Bug Racer Photoshop screenshot

Space Bug Racer Photoshop session

Happiness is an uninterrupted hour or so in the company of Photoshop, a Wacom pen and a coffee. Today I’ve managed to find some time to put some more work in to Space Bug Racer my soon to be finished HTML5 game. I’m enjoying it all so much I thought I’d share the view from this chair right now :)

There really is no finer way to spend an hour than this. Poring over my daughters alien sketches and drawing them in to Photoshop then simply hitting F5 on the keyboard to see them in game.
I really am loving HTML5 game development just now. It’s rare to feel such a high level of control over a development.


New art direction for my HTML5 shooter Area 51

I’ve had this game in development forever and I want it finished.
After spending some time this weekend playing the game I decided to give it a lick of paint.
One of the images that I use to help me paint pixels is a screen shot of the Atari 8-bit palette. The colours are just stunning. I simply use a single pixel brush in Photoshop and hit the ALT key to select a new colour with the dropper.
Pixeling is pretty much where it’s at for me. Sunday evenings were made for it ;)

I love cartoon and I love drawing cartoons so the style I’ve gone for is very much a colourful, outlined cartoon style. I just can’t do realism. Besides the weapons ( which I drew 10 years ago ) are of a toon style so it made perfect sense.
In terms of my colour usage I’m staying faithful to my love of Atari’s arcade games.
To try and illustrate the palette choice I took this snap of Vindicators from Mame. It’s not identical but it’s fairly close :)

Vindicators - Atari Games

I’ve almost finished the static floor monsters ( i.e. the ones that walk ) and will soon start on the floaty ones. The floaty ones are the ones that will hurl magic and energy at the player. The walking ones don’t have such an attack just yet. They simply reach the player and the player is “hit” ( i.e. the screen flashes red )

I’ve got a lot going on in this game and it’s designed for mobile use only. I really need to test it across devices.

In the meantime here’s some screens.

Area 51 screenshotArea 51 screenshotArea 51 screenshotArea 51 screenshot

New HTML5 arcade game – Rebel Rescue

I’ve spent a fair bit of time lately trying to iron out all sorts of issues with Rebel Rescue. On the whole I’ve enjoyed making the game but like any reasonably lengthy (2 months) project you get a bit tired of it all whilst you push it over the line. Most games for me take around a month from the first pixel drawn in Photoshop and the first byte keyed in to EditPlus to completion.

Rebel Rescue screen shot

Rebel Rescue - HTML5 arcade game

For the most part in the last few days I was playing with numbers.
Balancing the speed of rockets, frequency of bombs and accuracy of laser shots is a pretty fine art. Making something worth playing takes a bit of patience.
I think the game is pretty cool to play.
To help the process I took two days away from it last week. The intention was to look on it again with fresh eyes.
It worked ! I instantly found new and better ways to challenge the player.

As with all my HTML5 games the game can be played on a mobile phone as well as the desktop. If anything this game lends itself much more to the touch screen since it allows for slightly more refined movement.

I took my lead from several sources with Rebel Rescue. My inspiration strangely enough wasn’t Star Wars. I merely used some assets that I had created from a previous game and created a simple arcade shooter. My inspiration was really the classic games of the 1990s such as Blazing Star. Yes the visuals don’t compare but then I am a one man band. I would love to create the visual beautifullness of the great NeoGeo titles. But now is not the time and I am under resourced.
For now I look more at the instant appeal of such games. I tried to identify what it was about such modern classic shooters that appealed on such a gut level.
The rapid lasers coupled with the predictable movement of the enemy and resulting explosion of bonuses and powerups fell right in to my lap and straight in to the game. HTML5 across most mobile devices (the ones that count) is pretty performant these days so littering the screen with sprites is a breeze.

I hope you enjoy what I came up with. If you’ve any bugs to report please mail me ( the address is on the ‘about’ page ) and I will look at them.

You can play the game at

Use the arrow keys and Ctrl or Z to fire lasers and start the game.
On mobile devices just touch / drag on the screen.

Have fun !

Playing with colours

I enjoy nothing more than opening up Photoshop and messing with the colours in my sprites and general game elements.

Galactians 2

The screenshot above is the original image of the game before I came up with another couple of alien sprite characters. Somehow the black sky and Dropzone inspired moon base didn’t quite work for me. So I messed around with it a bit and came up with a purple sky and (what I think is a) beautiful sunsetting gradient. I also coloured the moonbase setting.
Although the moonbase isn’t finished yet (I intend to add some setting sunlight to certain areas) I think it gives a pretty good idea of where I’m heading with it.

Galactians 2

Initially the aliens were green and I “splatted” them with mini particle-like effects. The green dots in the left hand image reflect this. But I later thought about changing the aliens to be a little less green and splodgy.
So the exploding effect needed to change.
I scratched my head a little and decided to have the spawned dots pass through a colour phase from bright yellow through orange and then to red. The effect is quite neat in that it looks for all intents and purposes like an explosion that rains down and settles to cool on the moon’s surface.

The main benefit to this new approach is that you stand a much better chance of separating out falling debris from falling alien bombs !


Galactians 2 – a new HTML5 arcade game with aliens that “splat”

It’s really quite simple – I always wanted to make a game where the aliens come diving at you and you pump some lasers at them such that they “splat” in glorious fashion all over the screen.

So that’s what I did and since it takes its lead from my Galactians game I call it Galactians 2.

The premise is very retro and very simple. It’s also fast becoming my signature style of game. Aliens line up in rows above you and you sit beneath them with a ship / tank of some kind blasting them all to kingdom come.
I should add that when writing down a high concept for this game I considered the following 3 things: Galaxians, Starship Troopers and the classic 8-bit Defender clone Dropzone.
Galaxians for its format, Starship Troopers for its relentless bug invasion and super splatting and finally Dropzone for its visual style.

Here’s how it currently looks.

Galactians 2

Galactians 2

To create the moonbase I took a long look at Dropzone and got a feel for how the developer used just 3 or 4 colours to create the effect. It’s far from finished but let me tell you there’s quite a thrill for an aging Atari nerd such as myself to have Photoshop and Wacom open in one window and an Atari emulator running the aforementioned game in another.

I would quite like to blog the creation of the moonbase at some point in the future. I haven’t kept each stage of the drawing on file but I could probably get around that by starting a new, smaller graphic and employing the same principles.

It’s a real thrill to be making good old arcade games again. I know I’m not always very adventurous with my games but who cares. It’s great fun :-)

Incidentally the game will work on desktop and mobile. Depending on how you start the game (mouse click, fire button, touch screen) determines how the game is controlled.
Naturally iPhone 4 users will struggle since it’s Apple’s decision not to currently give their paying customers any flexibility with browser / JavaScript applications. Let’s hope that the new OS due any day now goes some way to addressing this.


Photoshop worksheet for a new HTML5 arcade game

It’s been too long since I finished a new game so I figured it was time to sit down and put the finishing touches to a new Space Invaders style arcade game.

It has alien bugs that splat, a player tank that spits fireballs and a backdrop inspired by my love of the 8-bit classic Dropzone.

photoshop worksheet

A new HTML5 game in the making

Designing the probe sprites and AT-AT walkers in Photoshop

I think it’s interesting sometimes to see how people work.

Last night I spent an hour or so redesigning the probe from Hoth Strike to fit in to my HTML5 version of the game – Rebel Rescue. I’m using a full screen gradient that contains a fair amount of orange / yellow so I wanted to enhance the colours on the probe to better fit the backdrop. This involved adding a blue stroke to the sprite.

Photoshop screenshotphotoshop

Designing the viper probe in Photoshop

As you can see I colour fill the sprite to reflect the amount of damage it has sustained in the game. This is done with the Photoshop blending options – Color Overlay (Red 255,0,0)  > Screen. I adjust the slider to achieve the desired levels. The lowest sprite is pretty much 100% opacity.

I’ve clearly used a lot of license in creating these sprites !

I always find it useful to have the sprite at its 100% scale whilst I zoom in with a single pixel brush to add the detail. I added an in-game shot so that you can see how it should look in the final game.

AT-AT spriteThe AT-AT walker that you see buried in the snow started out as a 16 frame animation. I tried and tried to get a satisfactory level of animation but ultimately ditched it.

As you can perhaps see from the image above I  went to the trouble of articulating most of the “body” parts as separate layers in Photoshop. But when it came to actually performing some kind of stop-motion on them I just found it too hard.

That’s why the game changed from being an attack on the walkers to being about simply rescuing fallen pilots. I set the game some time after the events in the film and buried the walkers in the snow. Much easier :-)

The walker incidentally is hand pixelled. My source for the job was a toy AT-AT from my youth. Nostalgia at its best.

drawImage performance on iOS vs CSS

I noticed something interesting earlier whilst trying to improve the performance of Dragons that I thought I should share. When I first considered how the game would look I settled on a full screen scene. I blogged how excited I was about this and that I could finally sit back and create full screen renderings in Photoshop. I’m using .png files for the backdrops. I tend to use that format for everything these days.

The theory was simple in that I would run through setLevel() once per level and set everything up. One of the things to set up is the current stage backdrop. For this I set the backgroundImage property of the canvas’ style to be whatever background I choose.
Something like this: = “url(‘…’);”;

Very basic CSS stuff. g is my global namespace.
I figured that this would save me a hefty drawImage() call during the main game loop and therefore preserve some frame rate.
This was a poor assumption. At least on iOS. And even then it appears more so on iPhone 4.

I scratched my head as to why first gen iPod Touch could render the game at roughly 20FPS and iPhone 4 struggled along at around 6FPS.
So I played around with it a bit and took stuff out. I also killed shadows on text and cut back on the number of sprites on screen. None of it made a difference.

Meanwhile over on Android the game was flying along like a train.

I then decided to take a closer look at the “big” stuff. By big stuff I mean the operations that involve the most pixels. I use drawImage for everything so I reduced the size of the sprites and took out sprite scaling and rotation. No real difference was recorded. So I put it all back in.
I then took a look at the CSS call to paint the backgroundImage of the canvas in what I thought was a one-time-per-level operation that exists outside of the loop.
I stripped out the CSS bit and rendered the full screen scene on every game tick. To try and help it along a bit I also reduced the file size of the .png files from 43k to 3k. I also ignored diffusion since this doubles the file size even at 8bits.

I uploaded the new game code and assets and refreshed Safari on the iPhone4.

To my amazement the frame rate had more than doubled to (a still poor but more acceptable) 16-20FPS. Android was, to be frank, no different. It still motored on beautifully.

So the valuable lesson that I’ve learned here is that the best course of action on iPhone (at least it is right now before iOS5 arrives) is to do all full screen drawing with drawImage and not rely on CSS. Alternatively of course don’t do ANY full screen drawing.
One of the smoother games I’ve completed, Galactians, works against a plain black backdrop a la the arcade games of the early 1980s. Perhaps there’s something in this.

I’d love to hear some thoughts on this. I really am not a great coder so muddling through this stuff is often mesmerising at best. Be interesting to hear what other HTML5 game developers are doing to steal back some FPS.

Dragons – new HTML5 arcade game almost complete

Dragons screenshotI do love these final stages of game development where everything you’ve had scribbled down from ideas to character designs to neat little effects comes together and you get a screen full of activity.
I am a huge fan of keeping the screen busy but not too busy. There is a fine line.

I’m also loving handing some of my game assets over to static Photoshop created images. It gives me the ability to better match and marry the colour schemes.
I have a wealth of sprite / tile art on my machine so it’s always a thrill to sift through some work that is years old to find a cool new starting point. Sometimes the work just fits. Sometimes it needs a little tweak to fit the style that I’m after for the game.

Dragons screenshotI think I’m pretty close to completing Dragons now. (I had played around with different game titles but realised in the end I rather like the simplicity of calling a game Dragons.)
I have balanced the attack vs defence vs goals to a decent level – certainly enough to provide a casual challenge.
Level times are at around 1 – 1.5 minutes on average. Plenty long enough for a casual game.
What I hope to complete before I publish the game is some balance in the scoring system. Just now there isn’t much variety in the scoring and I’m a believer in spreading the scoring based on how much skill / effort was required on the part of the player to actually achieve the score.

All in all a good development and a thrill to be working with lots of colour again.
I intend to write about the development process in a little more detail soon as well as providing a few pointers on how I create my 2D sprites / tiles.

%d bloggers like this: