Category Archives: JavaScript Game Template

Thinking about text adventure games and a new arcade project

I’ve been thinking a fair bit about a new project. In fact I’m a compulsive thinker of new ideas. Even whilst I was trying to bring Hoth Strike to a tidy close I was off in cuckoo land dreaming of a fantasy universe with fancy map and character editors. I still love the idea of having this super rich world with different races living side by side each with their own geo-political issues. I love the idea of different races, communities and individuals having their own particular agenda and I absolutely love the idea of dropping the player right in to the middle of it all. I even started to code a framework to put some flesh on the bones of the idea.

But mid way through something dawned on me. I hadn’t even considered the application for the game. I had no idea how the game would be played and no consideration for the visual appearance / appeal of the game.
I am essentially an arcade gamer. I love the ability to dip in to a game, wreak havoc, obtain a score (high or otherwise) and then just leave it all behind until next time. The games I play are pretty much this sort of game. For some reason I have just harboured this love of computer fantasy role playing and always thought it would be an interesting challenge.

Growing up with a love for Infocom’s Zork probably didn’t help this much. In my youth I wrote all manner of linear adventure games in BASIC. You know the sort, YOU ARE IN A ROOM. DO YOU GO LEFT OR RIGHT. > YOU WENT RIGHT. YOU HAVE FALLEN DOWN A PIT. END. Hmm. Should have gone left.
Those kind of games were littered with GOTO statements and were pretty dreadful to be honest. All the fun was in the creation.

A step beyond all that is the Fighting Fantasy style. These were huge in my youth. I particularly remember Citadel of Chaos for it’s rich definitions and grotesque characters.

mapI got a pen and paper out and sketched out my own idea for a game earlier today. It came out something like the map above. What struck me as fascinating about this was just how easily it translates in to a coding structure. Using JavaScript to create this sort of thing would be a breeze with every location an instance of a Node class of some kind populated individually with specific attributes to prompt the player in to having decisions to make.

So I set about coding a simple structure for this kind of game.

Using JSON I defined the following type of structure:
var locations = [
id : 0,
title : "The Entrance Chamber",
description : "You are standing in a tall but rather narrow chamber. Paintings from a long forgotten time adorn the walls and portray past members of the household. They appear to watch your every move. Quietly you turn to face the open door behind you. It creaks in the wind then SLAMS shut. Darkness falls and you are suddenley met with a shiver.",
prompt : "A staircase leads up away from the chamber. A dusty old chest sits in a dark corner.",
actions : [
text : "Climb the stairs",
nextlocation : 1
text : "Open the chest",
nextlocation : 2

As you can see that array definition could easily go on for several megabytes more. And indeed it will.
Locations 1 and 2 are naturally going to hold information relative to the Staircase and Chest.
I could expand on the location definition to include attributes for light level, HP damage (e.g.poison), gold, inventory items, monsters and so forth. All the game code would be concerned with is picking the details out for that element and presenting the player with a number of choices. As with the map diagram above all roads would ultimately lead you back to the central “spine” of the game until ultimately you reached your goal.

There are two reasons why I particularly like this approach to a game.

Firstly, it’s 100% flexible and easy to replicate. By administering a data source you could rip out a data.js file and bang a new one in there that is a completely different game ! This appeals since I could probably think of countless adventure scenarios.

Secondly, it’s playable on the move. I could simply render text and providing my handset supports JavaScript, CSS and HTML I get a reasonable game experience.

But for the game to really capture my interest it would need a separate combat element. A means of accumulating enough strength, experience, dexterity, intelligence etc to actually do some damage in battle. Further in to the story / game you would then come up against some tough adversaries.

This loosly linear approach to a game also gives me the chance to flex my atrophic literary muscles. I love the idea of being able to go to town describing a location and situation. Better still I could crank up photoshop and sketch out the location with a simple JPG. Where an image exists I simply present it above the text.

There are a great many creative positives to a side project like this. I could have a serious amount of fun just pencilling out the map for the adventure and coming up with a ton of tricky scenarios in which to plant the adventurer.

Check out my extremely roughly coded example here:

Take a look at the data.js file for the structure. You will see that only a couple of locations are coded. But it’s an interesting starting point.

Meanwhile…. I am preparing some graphics for my next graphical arcade game. I’ve already done my own takes on Space Invaders and Defender. Next up I hope to apply a similar spin on Robotron. Somewhere in between Robotron and Gauntlet you will hopefully find my next game, set in a very familiar and extremely popular universe. More soon.


Hoth Strike completed


Well I’m happy enough for this game to be called finished. I may tweak it a little in the future but for now it’s a pretty intense and (I think) rewarding game.
I’ve deliberately left the code un-obfuscated so that people can see how I constructed the game. Warning! It’s not pretty since despite my best intentions to write perfect JavaScript I wound up just cobbling the code together to get a game out.

Future games will make better use of global namespaces and JSON, for example.


I hope you enjoy playing the game as much as I did crafting it :-)


ps. my top score just now is 58,850.

Hoth Strike – Beta

hothstrike-beta1I’m finally happy that Hoth Strike is a playable and enjoyable experience. There are still a few issues that I want to resolveĀ  but hopefully nothing that will stop the show. So I’m offering the game as a Beta release to anyone that stumbles upon this page.

Play the game at this link:

hothstrike-beta2As with any Beta release I welcome all comments regarding bugs and general “playability”.
I will generally now focus on tidying up the code for the game including implementing a ton of stuff I’ve learned from books by Douglas Crockford et al. It’s come as quite a surprise just how inefficient my coding can be. More on that in due course. For now please play and (hopefully) enjoy the game :)

Controlling the Snowspeeder acceleration and turn speed in Hoth Strike

I thought I’d take the time to share my implementation of the Snowspeeder movement in Hoth Strike.

If you’ve played the prototypes of this game you’ll notice that the speeder is restricted to vertical movement. It sits static in the centre of the playfield and everything else moves around it. All sprites in the game have a speed attribute, including the speeder, but it simply ignores it. The player’s control of the speeder directly affects the ground speed (nGroundSpeed). Consequently all sprites react accordingly to the speed of the ground.

The AT-ATs walk at ground speed. Anything other than this would just look awful since the sprites would appear to “slide”. I hate that. The Probes use their speed attribute but it’s generally set to about 2 or 3 pixels. The explosions move North (0) only but like the Probe and AT-AT are directly affected by the ground speed. In short, when the player moves East (2) or West (6) across the terrain the ground speed increases and this is incremented to the other sprite’s x attribute. It’s quite simple to control.

But how do the player ship’s controls work ?

The firing of keyboard events is key.
onkeydown is used to trigger player input and onkeyup is used to cancel any player input.


If the left or right arrow key are pressed and the onkeydown event is fired I consider increasing the ground speed and moving everything in the appropriate direction. But there’s one catch ! The speeder might be moving at full pelt in the opposite direction. What I didn’t want was to snap the speeder to the other direction. It leads to an awful emotional response in the player and to be honest is quite a cheap trick. What I wanted was Defender‘s smooth sliding. To achieve thisĀ  I set an attribute on the player sprite – object.slowingdown.

So when the keyboard fires an event to move the speeder East or West I now check to see whether the speeder is in the process of slowing down. If it is I ignore the keyboard input. The impact on the player is minimal since the slowdown process is fast. In fact slowing down the landscape happens quite rapidly. I literally decrease the nGroundSpeed value by 6 pixels a time. I didn’t want the speeder sliding for miles before the player turned around.
In the game loop I watch for the slowingdown attribute and wait for the ground speed to reach just 1 pixel. Then I open up the controls to the player again. In the mean time I have registered the thrust attributes object.leftthrust / object.rightthrust accordingly.
The game loop flags the end of the slow down and instantly looks for the thrust attributes. If it finds them the speeder is instantly accelerating in the opposite direction.

One final thing to consider is the player opting not to thrust during the slow down. To cover this I set a object.cancelleftthrust / object.cancelrightthrust value so that the thrust code in the main game loop could override the thrust values if necessary when the onkeyup event fires.

I have played with the values quite a bit and in some cases the speeder slides beautifully for about 2 or 3 playfields. As enjoyable as this was from a spectator’s perspective it was hellish for the player. So I did 2 things. I increased the brake power of the speeder and widened the playfield. (It was originally 640 px wide and is now 950px wide). The effect is that the player can thrash it left and right and quickly respond to a probe coming in to view. Very, very satisfying to descend on a group of probes and blast them all to hell !

The Empire Strikes Back’s early sequences had some incredible photography. As a kid I was blown away by the emergence of the AT-AT walkers. I remember thinking that the cinema screen must have been a mile wide such was the nature of the shot. The imperial walker’s were stunning set against the snowy vistas of Hoth. I wanted the same sensation when playing my own game. Hopefully I’ve achieved some of it !

Comments welcome.

Hoth Strike – more information

The rebels are fleeing Hoth in spades. Skywalker has long since departed for Dagobah and Solo et al are off in to the depths of space. Meanwhile, back on the snowy wastes below remote rebel outposts are under attack as their faithful soldiers try desperately to track back to the base and join the evacuation.

The Imperial AT-AT walkers have increased in numbers and are almost certain to destroy the rebel base once and for all.
There is no time to lose if you are to rescue your comrades and make that last rebel carrier to freedom.

You climb in to your modified Snowspeeder, strap your helmet and comm line in and yank the thrust lever. Before you lies an intense battle but those are your comrades out there. You are their only hope.

I wrote this brief introduction to Hoth Strike when I first decided on the project and have it handy as I’m working on the game. I find it serves as a real inspiration as I’m clunking through sprite movement code and the more challenging aspects of collision detection.

I recently bought a couple of Atari 2600 game manuals off eBay. What I always loved about those games was the intro stories. The one that sticks out for me by far is Asteroids. There was a real sense of “I could make a difference” and “my God it’s HELL out there”. I always loved the fact that I had a laser cannon on the game and I could physically make a difference by blasting everything to hell.

I have tried to portray that same sense of wonder and excitement in my own story. By deliberately setting the action right after the events in the movie I also hope to appeal to Star Wars geeks ;) (of which I am clearly one)

So far the game hasn’t presented too many real challenges. Much of the action code is borrowed from Invaders whilst the newer features are merely extensions of what was already written. The scrolling landscape was surprisingly easy to assemble since they are just 2 sets of duplicated sprites that wrap.

I will begin to document more on this game as it progresses and have updated the worklog and game versions pages on this site.

I hope it’s as enjoyable to read and play as it is to create.

Designing a game around the action

Super Copter - in game shot

Super Copter - in game shot

With Super Copter I approached the project from a different angle. Instead of coming up with a design and then setting down the code I decided to implement the absolute core that I would like from the game. This included:

  • Scrolling landscape
  • Rapid fire lasers
  • Player bombs
  • Moving targets
  • Static ground targets

And that was pretty much it. I’d already designed the framework for the game (although I confess the code is quite ugly compared to some of the new developments I’ve been involved with – I’ll get around to bringing the game framework up to date soon) so I just wanted to drop in some sprites and have fun hitting the fire/bomb buttons to see if I could get a feel for a game design.

As a kid I enjoyed Defender, Falcon Patrol, Neoclyps, Attack of the Mutant Camels and countless other side scrolling shooters. They each had one thing in common – frantic action. I want to maintain this and therefore HAD to have rapid fire on the missiles. I’m still undecided as to the bomb descent, it seems a little harsh just diagonally thrusting the missile to the ground. Something a little more graceful with an arced descent might be more satisfactory for the player; as would a puff of sand as the missile strikes the ground. I’m ironing that stuff out just now. Thankfully the framework fully implements this animation without any new code.

So my time just now is taken up with playing this endless loop and waiting for a game idea to pop out.

Take a look at the current build here: Super Copter and drop me a line if you can think of a cool angle for the game.

Modifications, unifications and the JavaScript arcade game template

I recently sat down and decided to look over the code I’d written for Invaders from Mars. Sure enough there were a great many lessons learnt and a good many things that, given the time to revisit, I would do quite differently.


Last week I took a break from work and found myself without the internet and any external distractions so I set to the task of revising my code.

Initially nothing much changed. I designed a simple naming convention for variables and began overhauling the base sprite “class” that I had written way back for Invaders. Before long I realised the potential for improving my code in terms of the amount of information I stored within each sprite object. Previously I had defined global arrays to handle image data. This time I lumped all image data for sprites within the object itself. It just made more sense.

Something that I’d hated with Invaders was the way that I interjected game specific code in to what ought to have been a generic set of routines. It got ugly but because I had come so far I was loath to go pulling the engine apart for the sake of changing my coding style. This time I could do just what I wanted since I was starting with a blank canvas.

So I defined the core game code to operate independently of the code required for the actual game (or gameplay as most kids call it).

What emerged was a clear distinction between gamemodes. By adjusting nGameMode I could control which aspect of the game I was dealing with and then call out to an external component to handle such things as alien behaviour, environmental motion etc. The beauty of this is that when I come to design another game in the future the core handling of collision, “READY”, “GAME OVER”, scores etc is already in place and I merely work on the external components. And so it dawns on me that a templated approach to my work is the right way to go. This is not a library since I don’t use code that way. It is merely a pre-defined template that I can pick up off the shelf and start coding with for a new project.

I defined 3 presets for my templates based on the only 3 types of game I will ever create: ASTEROIDS, INVADERS and RTYPE. In each state the code knows how to handle the positioning of the player object and the firing of player missiles. Asteroids is the free-roaming , multi directional firing whilst R-Type and Space Invaders were fixed with single direction firing. (R-Type basically shot from left to right if you discount the add ons to the craft).

After a couple of days I was happy that the template handled everything. I could literally take it off the shelf and begin coding a new game safe in the knowledge that all my title screen, scoring, collision, player handling and movement, game over states etc were taken care of. So I knocked up a quick test and called it Super Copter. Originally I had wanted to design a Defender style game but I didn’t want to get tied down with the 2-way motion and radar handling. I wanted something a lot simpler that I could build upon. I’d always loved Jeff Minter’s games of old so I had no hesitation in hijacking his Attack of the Mutant Camels style for the game.


You can view the game at this link:

In actual fact there is no game. But you get a feel for it. There are also a number of things to iron out, namely collision. But you should get a feel for what I’m aiming for in my games. Arrows move the copter and Z fires the missiles.

The scrolling doesn’t come as part of the template rather it is a simple definition of 2 sprites that simply wrap. By default I designed the sprite to be about 4 times the width of the playing screen to avoid the Scooby Doo effect !

There’s a ton more I need to write about with this code and I am still avoiding the “Canvas” route. I want to get as much out of this “old school” approach before I move on. Besides canvas isn’t widely supported just now. But that will change and when it does I will move on.