Category Archives: HTML5

Ballblazer test using JavaScript and Canvas

Ballblazer test

Ballblazer in JavaScript

I can’t tell you how proud I am of this.
As a kid I spent hours in the arcades. I’ve written about it on here in spades. But when it came to more personal gaming thrills I had my beloved Atari 800XL.

The king of Atari games for me was Lucasfilm’s stonking future sports title Ballblazer.

I recently ditched the idea of crafting mobile games (at least for now) so I felt like diving in to something a bit meaty and very personal.

Ballblazer’s green shaded grid provided just the challenge I was after.

I’ll write up on how the development is going in the future.
For now you can spin left and right (with arrow keys) across the playing grid here:



Some more thoughts on mobile browser based games

Ever since my first attempt at making games with JavaScript I’ve wanted to remake the games that I grew up with. Galaxians, Space Invaders, Defender, Scramble, Spy Hunter…
These are the games that turned me on to video games and hold a special place in my heart.
Using the newer HTML5 technologies I continue to pursue my goal of re-crafting those special games from 30 years ago.

When I bought the book Building iPhone apps with HTML, CSS and JavaScript I realised that there was scope for extending my HTML5 games to mobile handsets. Suddenly a whole new world of game development opened up. I quickly (too quickly) reshaped my first HTML5 game Wizard Wars to fit on the iPhone and implemented some touch screen controls. The result was pretty nice and I managed to get some valuable exposure for it. Naturally I was super excited at the potential for having my desktop games also playable on my phone.
So I followed it up with HyperGunner (again developed for the desktop and shoe-horned in to a mobile format) and more recently Spy Chase.

I had of course blindly assumed that any game, regardless of its content and style, would be just as attractive to mobile gamers as desktop gamers. Surely the rules of game design are laid down such that they are relevant to any format ?
Well life works best when you learn stuff and I’m learning more about game design all the time.

Some recent activity in the HTML5 gaming community has steered me towards rethinking my approach to designing games for mobile devices.
I decided to ask myself some key questions. The answers to which could potentially come very close to challenging my own thoughts on the relationship between my beloved retro arcade games and today’s mobile games.

If you are playing a game on a mobile phone what are you looking for ?
Is it all about limited time to play or is there room for a longer game experience ?
How important are the visuals ?
Do the traditional rules of challenge and reward count for anything ?
and less crucially but just as relevant.. what is the profile of your typical casual mobile phone gamer ?

The more I research the market for casual mobile games and the more I repeat those questions in my mind the more I see a disturbing trend towards what I consider shallow games.
I’m not interested in over complicating my games but I do enjoy layering the challenges where possible. I certainly didn’t rekindle my interest in designing games to create game experiences with no substance. I did it because I want to explore rich gaming experiences that can be enjoyed at a stretch not hurled in to the bin after 2 minutes.

Now I’m happy to hold my hands up to the fact that I may have fallen short in my first attempts at creating games. But I do believe that I have used some tried and tested techniques in creating their challenges and setting their various stages.

Not everything I’ve seen is cause for concern. There are some fascinating exceptions. Anything with physics for example works a treat for me. But by and large the casual mobile browser gaming sector is swamped with throwaway games with little or no challenge. If I see another game involving changing the colour of a brick or matching 3 diamonds in a row …..

I always have new game ideas. I sketch them in to a book that is brimming with characters, challenges and game styles. They start as seeds and I develop them over time to be more rounded and what I would consider a full game experience. For example, I had an idea for hurling a character vertically in to the sky from a catapult. As the character descends with a parachute you steer him away from spikey objects and try and stay airborne for as long as possible. That in itself might be an interesting game but I soon set about adding things to flesh it out a bit.

In all my games I try to involve the ability to shoot at stuff. This can cause problems on a touch screen but if handled well is a nice experience. In my parachute game I’d figured a way to spray bullets downwards from your character. I needed stuff to shoot at. Before long the game’s design was full of mini challenges and layers of complexity. It’s this that thrills me.

But in what I’ve seen of successful mobile browser games the very first step of hurling the character in to the sky would pretty much suffice. Nothing more, just catapulting your character high in to the sky as far as you can..

So I’ve temporarily changed direction. For the time being I won’t focus on creating mobile browser games. My brain just doesn’t think that way. I’m always trying to add to a design to flesh it out. I wouldn’t ever have that sense of “finally it’s done”. I’d always be looking to move it along a bit. I enjoy a certain amount of complexity.

I am in complete admiration for anyone that can create successful mobile browser games but there is a certain discipline required that I just don’t possess.
Most important of all though, I’m simply not interested in that style of game design.

Saving some frames by throwing a canvas at drawImage()

My next project is to be a maze game. I’d already ditched the idea of recreating a Gauntlet style romp through multiple dungeons because I wasn’t happy with the behaviour of the monsters. Getting stuck on walls and bunching up to block an open doorway was driving me mad. That’s when I started HyperGunner.

Two games later and the diversion has done me some good in that I now want to go back to the idea of a maze style game.

With all that I’ve learned in the last 2 months about controls and presentation on mobile devices I figured it ought to be a good project. The first thing to change was the screen resolution. In with 320 x 480 and out with the ridiculous 800 x 320 of the previous attempt.

I called the game Mutant Mayhem.
This is an old title for me that dates back to my days at Software Creations where a young coder and I teamed up to put 3D on a GameBoy Advance. Well, raycasting but the effect was the same. It was essentially Doom and performed beautifully. I’d created some cool weapons that the player could view as if in first person mode. I’d pixelled the hands (with twitching fingers during idle times – was very proud of that) and a whole array of monsters. I thought it was good work.
At this time we both read about how Doom’s designers had found the whole scientists over-run by lab experiments style of game a bit cliched and tired. Hence why hell came through the teleports on Mars rather than mutants running riot. But we liked the former idea and stuck with the title Mutant Mayhem. It was to be a similar game to Doom in that you run each level blasting mutants and locating keycards to escape.

Almost 10 years later I want to revisit the concept in a 2D view.
I have my level editor which I developed for the Gauntlet game and adapted it for a tighter resolution with neater graphics.

The trouble was each wall tile was around 32×32 in a 320×480 canvas. For a level with many walls the game loop was potentially performing drawImage() on each tile several hundred times per second.
Performance was atrocious.

So I threw the question to the group and found a solution.

The theory is simple.
Because I only really need to build the tile map once at the start of each level I simply create a canvas and draw the tile images to its context in a single loop.
I then pass this canvas in to the drawImage() method in the actual game loop.

Step 1: Create the new tile canvas in my init() function. (Note: I have a global namespace defined as g)

g.tileset = document.createElement("canvas");
g.tileset.setAttribute("id","tileset"); = "none";
g.tileset.width = g.canvaswidth;
g.tileset.height = g.canvasheight;

g.tilectx = g.tileset.getContext('2d');

Notice how the canvas is not visible. Very important !

Step 2: Draw all tile images based on the level data to the canvas on level load

g.tilectx.clearRect(0, 0, g.canvaswidth, g.canvasheight);
for (var a=0;a<levels[g.level].tiles.length;a++)
  var o = levels[g.level].tiles[a];

You can see that all my level data is held within the levels[] array.

Step 3. Use the canvas in my main drawImage()

g.ctx.drawImage(g.tileset, 0,0);

The alternative to this would have been something like this:

for (var a=0;a<levels[g.level].tiles.length;a++)
  var o = levels[g.level].tiles[a];

.. on every game loop. Which is a crippler !
You can see what I’ve done so far here:

Ignore the car ;-)

Final changes to Spy Chase

A clear problem of being a one-man-band game developer is that I don’t get access to rich game testing resources. As much as I play the game to death whilst developing it I just don’t get the right kind of feedback to help push the game over the line.
Indeed one of the issues is that I get just too close to the game and probably accept its problems and limitations.

With Spy Chase I resisted adding guns and missiles to the player’s car since I’d always wanted it to be a game about dodging obstacles. But the more I played it the more I realised that I needed to offer some effective resistance to the chopper. The chopper is a big feature in the game and I didn’t want to lose it. But it was proving a real pain and disrupting the natural flow of the action.
So I implemented the auto-firing missiles and without giving it too much thought called it “done”.

The trouble was I’d instantly undone a ton of hard work. The game became so simple that you could just leave the controls alone and still capture the spies.

My last post generated its fair share of inbox activity with numerous suggestions for how I might improve the game.
Now I’m not your average developer when it comes to this sort of thing. Many developers that I know would quite arrogantly dismiss these suggestions but I actually read them through and valued the input. If you take the time to type it I’ll certainly take it on board.
Several suggestions were not relevant but some were excellent. So I took the excellent ones and played with them.

One of the first things to change was the auto-firing weapons. I love auto-firing weapons in mobile games and had got it in to my head that it was the only way to implement weapons. But of course it isn’t. Weapons should be a bonus. As such I made them collectable and further set them apart by changing the firing rate on bullets to be much faster than missiles. Missiles naturally deliver a bigger punch.

The biggest change I made though was to the effect that the obstacles had on the player.
Previously I’d penalised the player for hitting an oil slick or road cone by decreasing their speed. But this was wrong. It just felt bad that the player had to protect his speed. The largest part of the fun in the game is the high speeds that can be achieved. I wanted to maintain that.
So instead I hit the player in the other area that he cares about – car damage.

This was actually a huge improvement since it meant that the player could no longer just leave the controls alone and progress.
For every collision with an obstacle I hurt the player’s car. This really counts since the further in to the game you are the more likely it is that you will face such obstacles.

Finally to help give the player a fighting chance I reduced the maximum speed of the road from 32 to 28. Believe it or not the extra 4 pixels of movement in the road makes a huge amount of difference and can be the difference between deliberately aiming for something or being able to steer out of the way.

What I liked about this process was that a) people felt like they could offer suggestions and b) I was able to consider and act upon them with ease since I’d structured my code to be flexible enough. In short this is an exercise in creating a rich array of properties and variables such that at the end of the day I am simply playing with numbers.

A valuable couple of days.

The final game is here:

Spy Hunter homage almost complete

Spy Chase screenshot

Spy Chase screenshot

Spy Chase, my Spy Hunter inspired arcade game, is motoring along and very nearly complete.

I finally got around to adding guns and missiles to the game which for me was a vital final piece of the game’s design. I think I balanced the action pretty well so that the player, with a little skill, can be the dominant force in the game.

I like to design my games based on a countering method to the obstacles and challenges.

From the outset the player faces the challenge of simply steering to remain on the road. At the head of the screen the player sees a radar. Before long it becomes apparent that the white blip is the player and the black blip is the target spy car.
Collecting flags increases the car’s speed such that steering becomes more of an issue. To avoid that becoming a breeze for the player I penalise him for hitting the road verges by a) slowing the car down and b) adding damage (reflected with a red damage bar).

This in itself is enough of a challenge to carry the game along a bit but I wanted a lot more early on.
So I added other cars to the road. Initially I intended to have the cars run the player off the road but ultimately I settled on having them as a distraction. The player can bump them from the road and earn a points bonus after each stage. It’s still a challenge just to bump them (or shoot them) from the road.

Finally I added a chopper which at set periods drops oil bombs on the road.
If the player collides with the oil his speed is reduced, the car spins and loses the missiles powerup if the player has collected it.

All in all there’s some high-speed fun to be had en route to actually capturing the spy.

Once the game is complete I’ll add some more detail to these design notes.

The game is designed with mobile devices in mind and has been tested on iPod Touch, iPhone, iPad and HTC Desire.
Any feedback from other handset owners would be gratefully recieved ;-)

You can play the latest version here:


Spy Chase – HTML5 game based loosely on Spy Hunter

Here it is:

There’s a ton left to do but I’m quite excited about  what I have so far.

I really want to work on getting the pace of the action right. It’s vital to me that the game feels fast and like a proper James Bond chase along narrow roads.

As I’m sure you will see I have a bit to do just yet to achieve this. But it’s going in the right direction.

You control this game with the mouse or if you’re on a touch screen device by touching and sliding your finger to move the car.

All feedback welcomed.

Some brief insight in to my new HTML5 game Spy Chase

Development on my “Spy Hunter” game is progressing at a rapid rate. I actually call the game Spy Chase and the player adopts the role of law enforcement on the hunt for foreign spies. It’s a high speed chase through several different environments and even includes a night section where the car’s headlights come on ! I’m pretty thrilled by it.

Spy Chase
Spy Chase back-end

It’s important for me to keep up the pace in the game since the real thrill is in closing in on the enemy. As the radar blips move closer together the enemy slowly comes in to view. When the blips collide you have captured the spy !
The more spies you capture the greater your score. That’s pretty much the size of it.

What I’m really interested in is the mechanics of the chase.

Since it’s vital for me to maintain a sense of speed with the chase I’ve been careful not to litter the road with too many obstacles. Here’s how it currently works.

Player collects flags to increase the speed of the car. The more flags the faster the road speed.
Player can also ride over a speed strip and achieve a short speed boost.

To counter the boosts I placed a couple of obstacles – an oil slick and a balloon. (I was short of inspiration that day !)

The oil slick spins the car without any control allowed from the player and resets the road speed to the default.
The balloon merely bumps the car and slows it temporarily.

Of course hitting the roadside verge also temporarily slows the car down.

This game is currently aimed purely at mobile devices so the touch screen is the only input. I’ve positioned the car about 1/3 up from the base of the screen so that the player can slide his finger left and right beneath the car without obscuring it. I think the effect is pretty tidy.

Link to follow.

New HTML5 mobile game based on an old 8-bit classic

I’m currently developing a simple driving game that takes its lead from Spy Hunter.
The format is simple. You steer a car through a cascading landscape with a varying sized road as your boundary.
If you strike the verge your car slows dramatically. If you collect the flags or hit a booster your car speeds up permanently or temporarily depending on which item you struck.
To counter the boosts you lose all your speed or spin to a stop if you hit balloons or an oil slick !
Initially I designed it to be a kind of James Bond road race much like Spy Hunter but I since decided against it. Just now it’s a lot like a rally game but I rather like the idea of out-running the police amongst other things.


The Great American Cross Country Road Race

As a kid I played The Great American Cross Country Road Race to death on my Atari 800XL. I’ll bet it’s still an awesome game to play and is certainly helping me to create a fun game just now.

When there’s a bit more to see I’ll post up a link and some screens.

HyperGunner – collision detection improvements

Something that I should have paid more attention to with the development of HyperGunner was the collision between the player’s starship and the alien’s bombs. During the more intense battles it’s not uncommon to see the player trapped within a mess of bombs with very little room to move.
The problem was that the collision detection worked on the bounding boxes of both sprites. Unless the sprites contain pixels drawn to the very edges the illusion (and resulting loss of life) will be less than satisfying for the player.

Take a look at this graphic.

Collision detection

Here you can see (on the left) how I was previously performing the collision detection. Where things happen quickly and on a larger scale it’s rather more forgiving to have this style of detection. For example – the player’s laser colliding with an alien. Generally speaking players are far more forgiving when the resulting effect is in their favour !
But with a slow moving alien bomb drifting down the screen it can be highly irritating to “die” when you’re fairly sure you’ve missed it.

So I took a leaf out of my beloved manic shooters and shrank the collision box. In those games it’s fairly common to have just a single pixel in the centre of the player’s ship to collide with. But my game just isn’t that chaotic !

The net effect here is of course that you can generally be pixel perfect and watch the alien bomb pass through the outer 4 pixels of the player’s ship. But that is far more acceptable than what we had previously.


HyperGunner update

HyperGunner screens

I’m in the final stages of tidying up my new frantic shooter HyperGunner.
I’ve loved putting this game together and thoroughly enjoyed playing it. It’s a huge step closer to creating something in the mould of my favourite manic shooters – Ikaruga, Don Pachi, Esp RaDe et al.

I still have concerns with the collision box but essentially the game is playable.

I’m now working on streamlining the game for mobile devices. Specifically iOS and Android.