Category Archives: JavaScript Game Library

Hoth Strike completed

hothstrike-beta1

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.

CLICK TO PLAY THE GAME

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

MAY THE FORCE BE WITH YOU

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

Advertisements

Hoth Strike – Game Instruction Booklet

I thought I’d have a bit of fun making a simple manual for my game in the same vein as the old Atari VCS games. I used to love the mini-stories that each game carried. Their ability to suspend your disbelief was awesome. For a kid with a fertile imagination these games and their colourful instruction books were hugely inspirational :)

Hoth Strike

hothstrike4

Introduction

Scattered throughout the icy wilds of Hoth are remote rebel outposts that double as safe havens for stranded pilots.
Sadly since the initial AT-AT strike on the rebel base all communication has been lost to the outlying sectors.
Dozens of rebel pilots are lying stranded with no hope of survival !
Worse still the Empire has launched a calculated attack on Hoth to eliminate any surviving rebels and time is running out to rescue your comrades.
You must fly with caution between the numerous outposts rescuing pilots and destroying every trace of imperial aggression.

Objective

1) Rescue the stranded rebel pilots
2) Destroy all alien probes

To pick up a rebel pilot simply fly your speeder directly over them. They will hold on to the speeder until you fly them over the rebel outpost.
If you fail to rescue a single rebel pilot you will lose and the game will end.

Rebel intelligence has gained valuable information on the enemy.

Probe
Floating spy probes with semi-intelligent targetted laser bombs.

Raider
Pest probe that hones in on stranded humans and carries them away producing..

Mutant
..an awful hybrid of twisted metal and human flesh. Mutants turn innocent humans in to rabid killers and will pursue the player across the landscape !

Pod Launcher
Dumb “mother” probe with no weapons just a belly full of radioactive baby pods.

Pod
High energy balls of alien waste that bounce around the level until they collide with the player.

Good luck and may the force be with you …

hothstrike3

Hoth Strike – playable prototype

hothstrike-title

http://www.rebelideas.co.uk/proto/empire/ (arrow keys to move, Z to fire, X for bombs)

There’s enough in the prototype of Hoth Strike to share and invite some feedback. I’m looking for pointers on performance. Before you click consider these knowns issues:

  • Main game loop is broken in Internet Explorer (will address in the next few days)
  • Radar is double-wrapping
  • Only 20% collision detection in just now
  • No image pre-caching
  • AT-ATs are placeholder (i.e. NO animation)

As always I encourage anyone wanting to play my arcade games to download and use Google’s Chrome browser.

It’s quite possible that the game will run like a dog on your machine. If that is so then please let me know you system spec. The game is capped at 24 FPS.

All 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.

Hoth Strike – Empire Strikes Back inspired JavaScript Defender clone

hothstrike11

hothstrike21

You wouldn’t believe how long it’s taken to get that wonderfully smooth spaceship-gliding-left-and-right at the touch of a button polished. The result is quite simply stunning.
In a departure from Defender I have also included bombs as well as super fast lasers.

I am so excited about this game just now and think it will be enormous fun to play.

Atari memories and a JavaScript games book

Growing up in the late 1970’s early 1980’s I experienced first hand the wonder and amazement of early home computers.
In the beginning I got hold of a ZX81 and pretty much played every available game on it. I still remember being terrified at 3D Monster Maze.
It wasn’t long however before I needed to progress to colour and Christmas 1982 I got a Dragon 32. Wonderous times indeed and the games of Ken Kalish in particular stood out. Danger Ranger has inspired a number of my own game designs and I intend to relive its magic some day in one of my JavaScript arcade ventures. Unlike most I loved the Dragon 32. It had colour and sound and for me that was enough at that time. I’d always felt that the Atari was the way forward but at that point I was content with the Dragon.

Then one magical day some time in 1984(ish) I clapped eyes on Star Raiders. My life changed forever. I grew up with Star Wars and loved it. Everybody my age loved Star Wars. At least the guys did. To actually play at being Han or Luke on your own home computer was quite simply essential for anyone of my age at that time. It took some pestering but thankfully my Dad saw the potential for these machines and also saw that I was starting to program for them as well. Christmas 1984 I unwrapped an Atari 800XL. I’m pretty sure I got no other present that year :)

Galaxians, Pole Position, Star Raiders… they were all there and all utterly fantastic. Atari were synonymous with arcade gaming and I was instantly smitten with them. So much so that I saved up dinner money to buy the magazines of the day that carried program listings. This was to be my way in to programming my own games.

Atari BASIC worked. It wasn’t so clumsy as people though in hindsight and allowed you to generate sound and colourful graphics with reasonable ease. I devoured countless magazines worth of code and before long had my own library of BASIC arcade games running on the Atari. I saved them to cassette and took them to the local computer store to show the store owners who myself and my friends had got to know quite well. The largely favourable comments I recieved urged me on and I soon knew that a life of games programming was for me.

Sadly education, girls, work and all other stuff got in the way and my Atari gathered dust before finally being “given away” by my Mum. By the time that happened I really didn’t care so much such were the demands of my life at the time.

Zoom forward 10 years and in to the internet boom of the 1990’s and I started dabbling with web page creation. HTML was criminally easy and JavaScript allowed for a certain amount of flexibility. Several iterations later and now with full DOM support writing JavaScript to power screen sprites becomes super simple.

The other night I was putting some work in to a simple JavaScript shoot ’em up when it dawned on me that I was experiencing the exact same thrills I’d experienced as a young teenager making those Atari BASIC games. I had managed to rekindle my enthusiasm. There was no marketing or project management stopping me from expressing myself with my code, I was happily making my own game. It was all my own doing and I was loving it. If I wanted green missiles and a slightly faster scroll speed then I could do that and nobody would stand in my way. If I wanted a squelch sound for an explosion or a puff of smoke when the bombs hit the desert below then I could code that and it would stay in. Nobody was going to tell me to take this stuff out.

This personal expression is important to me and right then I considered the fact that it might just be valuable to thousands of other like-minded game designers out there.

JavaScript, the DOM, computer power and web browsers are at such a wonderful stage just now that I feel the time is right to spread the word.

I had been sketching out an idea for a book called “Writing JavaScript Arcade Games” for a little while but this sudden rennaissance gave it some gusto. I am happy to report that the book is 100% sketched out and I am about 50% through writing it.
The book covers everything. I explain JavaScript and the DOM for beginners and go right in to detail about advanced sprite design techniques (I used to work in Acclaim Entertainment’s art department as Lead Artist), animation and collision detection for the more adventurous.

I’m currently looking for a publisher willing to take a chance on it just now. If you’re a publisher and like the idea of a book that taps in to the huge combined market of web designers and arcade game enthusiasts then please drop me a line.

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.

Mutant Mayhem – another JavaScript arcade game

It’s been a couple of months since I updated this so I figured I should write a little something about my IFM follow up.
I currently call the game Mutant Mayhem which I admit is purely naff but the thing is you need a name for your game when you start out or it just gets called “GAME” and that doesn’t really inspire me to move it forward.
So I ripped the core of IFM out and reworked it to handle a scrolling environment.
I actually didn’t need to put much effort in to it to be honest since the game is designed to handle countless “sprites” at once.
Collision remains an issue but in terms of stitching tiles together and handling alien movement it was very straight forward.

The player controlled ship remains central in the screen and currently moves in 8 directions. The fire button spits out a fireshot in the direction that the player is facing and alien collision is handled as in IFM (including the same recoil from the alien).

There is so much to work out in this game and I suspect that I will wind up creating a web based game/sprite editor to manage the content.

You can play the current proto of Mutant Mayhem at http://www.rebelideas.co.uk/proto/mayhem/

Invaders from Mars Version 1.0.3 Released

For the last few months I’ve been developing an arcade game in the style of the games I adored as a child. That means colour, action, fun and all things Atari / Nintendo packed in to one game. As with all my favourite games the objective is to wipe out the bad guys with lasers and achieve the highest score possible.

Invaders from Mars

Invaders from Mars

There really isn’t anything more to it than that. My design document was a single sentence. “Shoot, shoot and shoot some more !”

Throughout this blog you will find some entries that detail the game’s design and development process. If you haven’t been here before the first thing that may surprise you is that the game is written entirely in JavaScript. I don’t even use everyone’s favourite library JQuery. No need for it. I just decided one day to sit down and have some fun recreating the golden days of my youth.
Invaders from Mars is the first in a series of games that I aim to create and I already have some firm designs for the next game.

I hope you enjoy playing Invaders from Mars as much as I enjoyed crafting it. I always welcome feedback and reply to any mails.

Play Invaders from Mars JavaScript Arcade Game

I heartily recommend Google’s Chrome browser for the best game experience. The game should work in all browsers. Please let me know if you have problems.

Some object theory and a little sprite improvisation

With Invaders I was pretty much following the natural course of events during some research in to classic DHTML sprite manipulation. I had looked in to HTML5 and the much talked about Canvas element and it’s many benefits but I wasn’t happy that I’d explored JavaScript enough to pursue it.

I started at the start and created a base “class” that all sprites in the game would be instantiated from. Literally everything that moved in the game would have its properties set in line with this one object definition. It started to get messy since it made no sense, for example, for the player’s ship to have an attribute harmPlayer. By the end of the game I had got quite sick of examining attributes for sprites that just didn’t need them.

With the next game I am going to deliberately split out the object definitions and it was this that got me thinking about the types of sprite that I will present.

There will always be a player object. The character, ship, car or object that is under direct control of the player. In many respects this is a unique element of the game since it is potentially the only object that doesn’t carry aggression. With Invaders I was sure to set an aggression level for each sprite which was aimed toward the player object. Most other actions that the sprite could perform centred around this attribute.

But I needed to take a step back from this. I needed to look at the necessary actions that the game must take to make it all happen. I simply boiled it down to this:

  • Move
  • Animate
  • Collide
  • Die
  • Fire

With Invaders I had two functions handling movement. The first function was also bound to the animation function. You can see this between levels where the second method is employed whilst the aliens form the pack. There is no animation on the on-screen sprites !

The new game will completely separate Movement from Animation and handle it independently in the game loop. Collision will also be handled on the game loop as in Invaders. Death frames are handled within Animate but it is a unique state in its own right none the less. Firing of missiles is actually a trigger the object handling is a separate consideration.

Further breaking down the model I will consider a number of sprite types (which I’m careful not to call classes since JavaScript doesn’t employ that concept).

  • Alien
  • Player
  • Missile
  • Tile
  • Effect

Taking in to account the earlier problem of sharing attributes I will now be able to assign specific attributes to the sprite based on its role within the game.
For example, missiles are only concerned with movement, possibly animation and being tested for collision. They are not concerned with the triggers of launching missiles. Similarly the alien is concerned with all aspects and is by far the most complicated sprite since it will naturally employ intelligence of some kind. Alien movement can be a complicated and expensive affair. Coupled with collision detection and animation based on circumstances the alien is complex. The player controls his own sprite so much of the complications of intelligence and behaviour are removed.

Towards the end of Invaders I dabbled with the concept of spawning. This proved useful for generating such things as explosions and puffs of smoke. I also used it for the green gunk that the Beholder dropped on dying.

I used what I called a bucket approach for this. I defined an infinite bucket array that would handle each sprite. When something was spawned I dropped another sprite in to the bucket. The game loop handled every sprite object in the bucket and at the end of the level (or on player death) I emptied the bucket and reset the array index to 0. It worked beautifully and I ran several hundred spawned objects at once without any impact.

In a future entry I will post up some object definitions based on what I’ve written here and some basic code for handling the game’s sprites.