Category Archives: JavaScript

HyperGunner – new screens

HyperGunner screenshot

HyperGunner screenshot

HyperGunner screenshot

Lots of colour. Lots of action. Chaos ! I love it.

HyperGunner – level / wave design theory

HyperGunner is turning in to something to be proud of. I’m very excited to be developing it just now and am thoroughly enjoying assembling different game elements – scoring multipliers, power-ups, hyperspace bonus phase etc.

hypergunner title graphic

HyperGunner titlescreen graphic

What I’m most thrilled about is the pace of the action.
When I first started assembling the game code based off the previous game – Wizard Wars – I fell firmly in to the trap of thinking it should be just another formulaic shooter a la Galaxians. As much as I loved that game in my youth I knew that it needed something more.
A brief foray in to manic shooters taught me a great deal about maintaining pace in a shooter and increasing the perception of pace through some visual trickery.
I employed as much as I could in HyperGunner.

 

I guess the biggest success in terms of game design was the concept of waves within waves.

Initially I created a screen full of about 32 aliens all jiggling across the screen and essentially lining up to be shot.
It was dull. I knew I needed something more and that something was to have the aliens move much more freely. Rather than simply being cannon fodder they needed to be cannon fodder with a bit of movement.
So I stripped the alien count down to 8 and implemented movement patterns.
Depending on which stage of the wave you are in you will see the aliens move in a certain pattern.

Naturally each wave was over very quickly since with just 8 shots you could dispatch the lot !

HyperGunner in-game action

HyperGunner in-game action

So I looked in to having layered waves. That is, waves within waves.
On the first level you have 3 waves of aliens to clear before you officially complete the stage. Or level. Depending on which terminology you prefer.
On later levels you can have up to 25 waves of aliens to clear.
Each wave to be cleared is represented by a small flag icon in the lower part of the screen. This visual indication is vital to show the player what he must achieve.

 

I implemented 4 movement patterns for the aliens and it plays very well. But again it needed something more.
So I looked in to having a wave that is quite different. For this I looked at an old Atari game Threshold. This game had swooping bird-like aliens falling down the screen and I loved the way that it broke up the standard flow of the game. It was quite simple to implement even though the calculation for adjusting the x co-ordinate took some playing with. I’m still not totally happy with the movement of the swooping aliens (they tend to fall in to line too easily) but there’s enough in there for a challenge. For now.

 

HyperGunner in-game action

HyperGunner in-game action - older version

So with the core challenge figured out I set to looking at the bigger picture. After all, it’s fine blasting through countless waves of aliens but it’s important (I think) to focus on greater goals.
I was obsessed with the idea of hyperspace. So much so that I wanted to encourage the player to aim for hyperspace. I also wanted to have the visual effect of hyperspace with the stretched stars falling down the screen at high speed.

So I implemented an energy bar that is boosted with the collection of stars.
Bright gold stars fall down the screen when aliens are shot. Essentially the aliens release them. The more stars that the player collects the larger the energy bar. When the energy bar reaches right across the screen the player enters hyperdrive !

Hyperdrive is both a visual diversion and also an opportunity to score double points for each alien hit.
It currently lasts for about 10 seconds. I also went to the trouble of affording the player 5 lasers per button press as opposed to the normal in-game maximum of 3. The effect (I think) is stunning.
The rewards to the challenge of collecting so many stars without losing a life are great on both levels – visual and interaction.

By the time the hyperdrive phase is complete the player could have easily scored an additional 10,000 points.

I will discuss the game elements in detail a bit more once the game is complete. I have quite a bit more to do before I can call it complete. But for now it is, I think, a hugely thrilling game to play.

New game – old game: HyperGunner

I’ve been very busy this last few days turning Wizard Wars in to a vertical scrolling shooter.
It was very easy. Some things cropped up en route that I thought were worth a mention.

When I designed Wizard Wars I made sure that the pipeline was simple. That is, I define the images and animation specifics in the code and then I’m free to go off in to Photoshop to create some sprites. I wanted to be in a position where I could comfortably hit F5 and see my new artwork in an instant. (Chrome’s inexplicable caching aside this has been fine)

Lifting the Wizard code and turning things around a bit wasn’t so much of a challenge. I implemented some simple stars that varied in shades of grey and had them tumble down the screen at varying speeds to give that oh-so-familiar starfield depth impression. I also lifted the sprites from Invaders from Mars and had them shift across the screen whilst the player shuffled his laser cannon back and to taking shots etc etc.

Making Space Invader style games is easy. I got bored of it almost instantly.

So I shelved it and went off to play a few classic shoot-em ups in MAME.
Giga Wing, Esp RaDe, Don Pachi, Loop Master… they’re all up there in my favourite list. I played them all to death.

When I got back to my own game I realised that it was all very pedestrian and lacking in colour and depth.

So I changed the image files for most things to create richer colours.
It was whilst I was adjusting the star sprites that I realised I was doing it wrong.

All I wanted from the stars was the impression of space. I could achieve this with the simple drawing of dots / lines.
I’d draw lines and shapes on the canvas before so I changed the code and hey presto I had a starfield made up of very short lines instead of graphics. I also used context.fillStyle = “rgba(r,g,b,a)” to create some colours mathematically and with varying amounts of alpha.
Not only did I have a nice colourful starfield and some added performance I also had more control. So I played with the numbers.

I’m drawing my stars using context.fillRect(x,y,w,h).
By adjusting the width and height values I could achieve a sense of hyperspace. I also increased the amount which the stars move down the screen. This changed everything. I now realised that I had a game that would be played at pace. Even if the foreground aliens, bombs, lasers etc were moving fairly slow the background pace would make the whole thing seem pretty rapid. I loved the effect. So much so that I made hyperspace one of the mini goals of the game.

Whilst the game was in its infancy I also took the time to play with the drawing.
My initial concern was that the clearRect() method was killing performance.
So I tried a newer method: g.canvas.width = g.canvas.width;
There was no improvement.
I also went to the trouble of calculating the empty spaces left by each sprite and only re-drawing those areas on every tick. When I got the code right (it was very untidy to begin with – stray pixels here and there) it worked well but there was no real gain in frames.
The biggest boost I could find was transfering the actual drawing from using HTML ImagesĀ  to primitive canvas shapes – in this case rectangles. Whereas previously I had 100 + star images cascading down the screen I now have 100+ shapes being drawn.

Google’s Chrome has easily the best performance so far. Running flat out at 250 FPS.
Firefox is the poorest at around 80 – 100 FPS flat out.
But even then the game plays very well across all browsers.

I hope to put a link up soon.

How Galaxians changed my life

Something I always wanted to write up but never really worked out the right approach for was how and why I became interested in making these simple / crude / amateurish JavaScript based games.

To get the full picture we have to go back to some time around 1980 / 81. As a young boy I used to beg, steal and borrow any coins I could get and race to the cricket club at the end of the road.
On a Saturday afternoon during the summer the club was open for business and a bunch of largely stuffy old men sat and watched the delights of leather on willow. I slipped in to the clubhouse un-noticed.
In one corner there sat a cocktail cabinet of Galaxians. (See something similar here)

If I was lucky I had 20p. Two coins. Therefore two “goes”. But generally I just had the one.

The walk to the cricket club was about 5 minutes. With every step I would be processing my previous go on the game and trying to figure out my tactics for the next one. So much so that when I sat down to play I was a combination of excited and nervous beyond belief.

I got pretty good at Galaxians but soon grew tired of the ritual of begging and walking to play the game. This was the time of the emerging home computer scene.

Zoom forward a couple of years to Christmas day and I unwrapped my new home computer – a Dragon 32.

The graphics weren’t great, the sound was pretty poor and the entire contraption felt like a big biscuit tin. But I loved it. I picked up a few books on how to program BASIC and saved up coppers to grab the occasional Dragon User magazine.
I devoured the long badly printed listings from the magazines (submitted by other amateur BASIC programmers) and frantically sought to achieve the same effects that they had produced.
I admired the professional coders but knew that I was a million miles away from them in terms of capability.
Every once in a while I would catch some machine code in Dragon User and just stare at it. How on earth could anybody understand that nonsense ?

For me it was all about the BASIC programs. It seemed so devilishly easy to accept keyboard input and produce a few audio/visual effects. Such little effort.
Before long I had some very simple games knocked up. Most were text adventures but some were little blocky Space Invaders style arcade games. (I can still remember writing code to check for collision based on pixel colour !)

A year later and I’d grown tired of the Dragon. I needed to play better games.
I was lucky. My Dad was interested in the stuff I wanted to create. I whined enough for him to cave in and get me an Atari 800XL for Christmas 1984. This time I had struck gold. Awesome graphics, awesome sound and a wealth of games, books and magazines to go at. Atari was (and is, for me at least) the definition of gaming.

I adored those days of my early teens. In the years before girls and the high jinx of college took hold I could be found beavering away in my bedroom on any number of game projects. All in Atari BASIC and all very crude. But they were mine. My ideas and my creativity at work.
I would sketch out all kinds of games in class at school. Weird detailed sketches of Manic Miner style levels and bizarre characters. (So much so that a school friend quickly nicknamed me Wilf after Wilf Lunn who at that time was well known for his mad inventions on UK television).
My friends would share their ideas. Such wild and creative ideas that were, I suppose, just rip-offs of the big home computer games of the day; Jet Set Willy, Manic Miner, Suicide Express, Ant Attack, Jet Pac (still an awesome game).

I so much wanted to create my own Galaxians. I desperately wanted to create my own Spy Hunter (my favourite arcade game of the day). What could be better than a James Bond romp through all environments in cars and boats that shot at things in their way ?

Magical times where as children we were unimpressed by fancy coding routines or other such low level excellence. It was all about what our games were going to do and of course look like. It was all about the characters, the guns, the story. Ever since those days I’ve had a love, indeed passion, for arcade games in which the sole requirement is to shoot stuff.
I think you get the gist :-)

I’ve always wanted to re-capture that passion from nearly 30 years ago. I’m not a coder. I can’t do the low level stuff. C++ or *shudder* machine code turns me to ice. I code C# in work but I’m no expert. I don’t follow technical forums. It’s generally an exercise in knocking those that don’t do it the same way that you do.

I’m a dreamer. I love nothing more than dreaming up a game scenario and putting enough code in place to go and get stuck in to crafting sprites. I love Photoshop. Just watching it load and anticipating the opening up of a new document (32 x 32) fills me with delight. I have my own palettes stored and pick one for the game based on its style. Just sitting pixelling my little characters and then dropping them in to the game to me is pure pleasure. It’s personal. In many respects I’d rather not ever show them to anyone. In many respects I also feel a bit like the Ed Wood of computer games. I have all the passion but not necessarily the technical expertise. Frankly I couldn’t care less. I’m having too much fun.

So I guess to the point of this post.
For me, even as a rapidly regressing 40 year old who should know better, it’s still all about the fun. The ideas. The “what if I make him jump and shoot as well as just jump” style ideas.
When I have to be concerned with the technicalities of making this stuff happen I get bored.

That’s why I love open web technologies. I love the fact that I can open a text editor and Photoshop and see the results with the push of a button in a web browser. I’ve waited a long time for this when I think about it.

HTML5 being adopted across the board is going to allow me to not only recapture the passion from my youth but actually push it further. A lot further. There are things that I can write now with JavaScript that I simply couldn’t do back then with BASIC. Of course there are. And that’s what is so much fun. I can create almost as quick as I can dream these ideas up. I don’t use libraries or frameworks. There’s no need. The blank canvas of a new project is too exciting. I like getting my hands dirty. (Notable exception: the SoundManager2 API)

I like to keep development times short. If a game is taking more than a month to become playable (bugs and niggles aside) then I’m getting something very wrong. I’ve most likely lost sight of the initial vision. If I can’t decide on visual styles or content then I’m definitely getting something wrong.
What excites me is when ideas just fall in to place organically.
You’d be amazed how often I create a simple sprite and just walk him around the screen with no regard for collision or other such game specific things. I walk him around, watch him move and just dream a game up around it. What would be fun ? What action would be cool to do ? – Hoth Strike was initially a helicopter game in which you fly low over a desert blasting gun turrets. The more I played with it the more I was amazed at how fast it all moved. The game needed to be a bit more frenetic.

Hopefully my point is made :-)
I love making games. I love drawing the graphics. But most of all I love dreaming up the ideas and seeing how far I can push them. You don’t have to be an expert coder to make this stuff happen. You just have to have the desire.

Wizard Wars on HTML5 games

I’m really proud of this. My first little HTML5 project Wizard Wars is featured on the excellent html5games.com website.

Play the game here: http://html5games.com/2010/11/wizard-wars/

Wizard Wars game for iPhone

Lesson #1 – Frame rate / canvas / HTML5 and iPhone

Writing a simple arcade game for a handheld device (and even then to be executed through a web browser) is quite different from the luxury of writing for the desktop. Not only do you have to consider the scale and colour of everything but you have to be careful with just how much you throw around.

I no longer use DIVs and IMG files instead opting to use the Canvas element courtesy of HTML5.

IFM screenshot

Invaders from Mars - optimised for iPhone

When I first started writing with the iPhone in mind I thought I had run in to some serious canvas limitations. I was essentially doing the same thing with the same routines but somehow the approach seemed to yield a far lower frame rate. It didn’t make sense to me since iPhone is pretty powerful, right ?
I scratched my head. Could it really be that wiping the entire screen and then redrawing everything (regardless of whether it has moved) was such a drain on the device’s performance ? I certainly didn’t want to go to the trouble of detecting which sprites occupied certain regions before clearing the canvas down. Besides that would probably be an even bigger ask.

But the it dawned on me that my methods were not ideal.

I’ll try to explain.

When I populate the game with entities I essentially pick them from a pot.
During initialisation I build arrays of entities. In most cases for things like explosions I create a pot of about 50 objects. Same goes for alien bombs and player lasers. I also tend to throw around spark effects and various other niceties.
When the game loop requests such an entity it enters a loop and looks for the object that isn’t currently visible.
Where there is a lot going on on-screen this can stretch to pretty much the array length.
When it finds an object to use it simply breaks out of the loop and returns the object.

In total I was probably asking my game loop to step through an array of around 300 elements 20 – 30 times a second.
I then pass these objects in to the relevant method – draw(), move(), collision() – and have each method handle the situation in its own container.
Where the object being passed is not visible (i.e. it’s been destroyed / picked up, left the screen boundaries or hasn’t yet been used) I simply back out of the method.

if (!object.visible) return;

This works well and obviously saves a huge amount of crunching when you’re trying to perform the same actions several times a second.

So I put together a couple of tests.
In one corner I had my current and unedited game file.
In the other corner I had a new game file with the array sizes drastically reduced. A small and insignificant changes you might think !
Both files were running flat out.

I ran them both and took the diags.
Both were running in Firefox 3.6.

The first file gave me around 77 FPS.
The second (with the reduced array sizes) gave me around 90 FPS.

I’ve yet to test this on the iPhone but I would hope to see frame rates increase from the 16 – 18 FPS that I was experiencing earlier.
Something around 25 FPS ought to be acceptable for a simple Space Invader game.

I’m rather pleased to see this since the alternative was alter the game’s design.
It’s important for me to have plenty to shoot at. The first thing to go would have been the fancy sparks and screen full of entities. Never the aliens and explosions.
I also took the decision to reduce the amount of lasers that the player can launch and have on screen at any one time. It’s not ideal but will probably make for a more intense game.
Finally I dropped the alien bomb pot from 30 to 4. Only 4 alien bombs on screen at once !

To counter this I ditched the idea of an energy bar that gets depleted with every hit from an alien bomb.
Instead I went for the classic one hit and you’re out a la Space Invaders / Galaga etc.
Again this tends towards a more intense experience.

So all in all a worthwhile exercise. It sets me up a bit more for crafting such games for mobile devices. Something I needed to do if I’m to maintain the amount of games I’m hoping to produce each month.

new iPhone game – Wizard Wars

During the crafting of my Gauntlet-esque game I lost some motivation. The issue of rotation vs collision took its toll. I needed something to just jump in to so that I could get a game completed. It’s hugely frustrating for me not to finish something once I set my mind to it.

So I took a look at the iPhone. I’d looked at Objective-C and scratched my head enough to ask the question “Can I make games for the iPhone without Objective-C and Cocoa ?”. So much infact that I punched exactly that in to Google.
Incredibly a book available on Amazon called Building iPhone Apps with HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or Cocoa was returned. I wasted no time buying it.
When it came I devoured it. It’s not a big book but gives you every bit of markup and code that you need to present a game in an iPhone / iPod Touch.

Safari Mobile is sturdy and executes at a good pace. I tested the game using desktop Safari on a PC and my wife’s iPod Touch. Although the framerate drops on the actual device it’s certainly good enough to present a good game.

Wizard Wars game for iPhone (in development)

It’s not quite finished but you can still see it here: www.wilfscorner.co.uk/sandpit/iphone

I didn’t waste too much time on game design issues. I pretty much knew from the outset that I wanted a colourful game with a wizard battling another evil wizard in a fixed arena. I wanted the game to feel nice. When you touch the screen the character moves to that point. I also reflected the target position using a simple red blob sprite that fades over time. The effect when you drag the wizard is quite pleasing if totally accidental.

As a GameBoy artist I learnt very quickly that colour is vital. Bright, vibrant colours can make a simple game experience really enjoyable. So I set out to create bright colourful sprites.

The easiest way to achieve this was to wash out the backdrop. So I set the entire game on a patchwork stone floor that is actually quite dark. I then crafted a bunch of sprites using the opposite end of the spectrum. The effect is very nice and rather rewarding for an artist / game designer.

When I first set out to create the game I was concerned about frame rate. I needn’t have been. Safari Mobile handles things nicely. So much so that I was able to spawn my trademark spark flashes all over the place. The process of picking gems and stars up is dull if you don’t visually reward the player. The 8 way explosion of sparks is perfect feedback.
I also invested some time making this bob and bounce a little. So stars, gems and bonuses don’t just appear they drop a short height and bounce in to position. Very little code used for a thoroughly worthwhile effect.

I hope to blog a bit more about the game’s development once it’s complete. Just now I’m wrapping up the sound issues (AUDIO tag) and tightening up the code and resource files. I’m desperate to keep the whole project under 300k.

Have a look at the game. You can play it on a PC using the mouse to click the arena or the keyboard arrow keys to move the wizard.
Let me know what you think.

Brief analysis of Atari’s Gauntlet – Monster Movement

I am focusing my efforts on the behaviour of the monsters in my Gauntlet-esque game.
I want the player to be able to move freely shooting anything that comes at him. Similarly I want the monsters to move convincingly around the level effectively trying to sniff out the player.

I decided to take another closer look at Gauntlet courtesy of YouTube.

What struck me was how unintelligent the monsters actually are. In my mind the ghosts and wizards had walked around the walls to seek out the player. What actually happens is that they line up against the wall in a big huddle waiting for a clear shot at the player.
In essence they are happy to correct one co-ordinate at a time. That is: where the PlayerX co-ord is less than the MonsterX they will run to correct the difference. If a wall stands in their way they continue to correct the X co-ord but simply bump up against the wall.
Where the Y co-ord is different the monster will simply slide up and down the wall in an attempt to correct that co-ordinate as well.

What doesn’t happen is the monster intelligently looking for another route. At least I didn’t see that kind of behaviour.

This is hugely encouraging since my own game code would take an enormous hit if I had to implement paths.

Sprite movement

Sprites "hunting" the player - but not intelligently

It all boils down to what is acceptable to the gamer as a challenge. I am convinced that if I can get close to Gauntlet’s style of play I will have enough of a gaming challenge. I literally do want the monsters to line up and be shot. I want them to fall in to position such that I can hurl magic at them. I will have to address the one strike and your out element of the game just now. Perhaps re-employing the health status as before (and of course as Atari do it themselves).

A rethink on the level design / goals of “Castle Adventure 2”

I took a time-out to explore some game design ideas.

To start with I needed to write down what I had come up with so far with my game. I then mapped that on top of what I originally set out to create.
The results were interesting.

So far I have created the following game mechanics:

Each level is populated with monsters to be avoided and items to be collected. Collecting certain items reveals an exit to the level entering which ends the stage and prepares a new one.
The monsters can be dispatched by magic powerballs which are collected at various points around the level. One shot to kill one monster.
The crux of each stage is avoidance and collection.

My original design idea was to have a free roaming fantasy arcade experience where the lead character was free to shoot hordes of monsters. In the style of one of my favourite games as a kid – Atari’s Gauntlet.
I wanted the action to be quite frenetic in that it was to be a case of “player is chased through the level by seemingly endless monsters” until he finds a key and escapes.

Quite what went wrong during the “build” process I don’t know but I seem to have lost focus.

With Invaders from Mars and Hoth Strike I kept my design document (a single sentence scribbled on a post-it note) in view at all times. I hadn’t done it this time.
Losing focus is a killer.

So I took the time to re-address the design and try to steer the whole thing back on to the tracks.

For the most part it’s not a huge change to have the player firing at will and dashing around avoiding monsters. I did afterall force the restriction on the number of player missiles and monsters on screen deliberately at some point to slow the action down and change the direction of the game.
So I unlocked it all and let the player run and gun as previously intended.

To counter the fact that the player could wipe out the monsters with ease I set them to respawn. Previously the monsters respawned to their original starting point in the level. I changed this to have them respawn at a Magical Swirling Energy Source. All respawning monsters come through that portal. In the level designer I can set this point.
In the game the energy source is visible as a rotating sprite.

Magic in game

Magical swirling energy source - the monster spawner !

This gave me another dynamic and a useful goal. I already had the collection of the strange brown artifacts as the key to exiting the level. So I used the collection of all gold coins as a means of destroying the energy source.
No energy source = no respawing monsters !

I kept the magic balls for the player to collect and just had them granting the player a short burst of rapid fire. It lasts around 10 seconds.

The last thing I tweaked was the ability for the monsters to literally hunt the player down. I figured that a monster that had been shot would be pretty pissed off so I gave them the ability to sniff out the player. It currently doesn’t work so well on diagonals so will need to rethink that. But when the monsters actually hone in on the player it can get pretty scary trying to outrun them. Especially as the monsters are set to have x3 speed on respawn.

The key to the monster chasing player scenario is as much about level design as it is AI.

As the fourth version of this game takes shape I hope to have many more monsters on the screen at once. I am going to try a level without so many walls and see how it fares.

Play the latest version here: www.wilfscorner.co.uk/sandpit/4/castle.php

Building levels and refining the game experience

At some point the thrill of solving game design issues will give way to that final slog of packing the whole thing up in to a playable game. Such things as title screens, game over presentations and handling certain gamey elements. I also need to consider what happens after level x (where x = the final level). I’d like to present something nice to the player as a reward for his efforts in my ever-more-complex dungeons.

But for now it’s all about puzzles, rewards and designing cool scenarios and monsters.

As I’ve blogged previously I’m a huge fan of creating enough of a stable codebase to be able to play with graphics. I’m an artist first and foremost. In the not so recent past I worked as a game artist. It’s what I really enjoy the most. Being able to construct these game worlds and actually realise them is a huge thrill.

One of the things that I’ve been toying with is the regeneration of level entities following playerdeath().
In the past I’ve always respawned every gem, powerup, key, bonus etc after the player character has died. It’s just an easier way to handle things. But with this game I’ve decided to leave the level in the state it was in immediately prior to playerdeath().

So when the player dies and respawns back in to the level all the previously collected items do not reappear. Much like PacMan where the eaten dots stay eaten.

There are a couple of exceptions to the rule; keys and magicballs. Keys because you may have collected the key and died before reaching a door (doors remain open after playerdeath). Magicballs because they are designed to respawn mid-game anyway.

I think the result is much more satisfying and less daunting for the player.

An old school friend of mine (Gary Webster) has been busy with his own bit of nostalgia creating Commodore 64 style game music. As kids we marvelled at the work of Rob Hubbard and Martin Gallway. Back then the UK spawned the best of game talent (IMO of course) so it’s a great thrill to be able to actually honour something so personal from our childhood.
Webbo goes by the name TheLastWaltz and his work can be found on SoundCloud.

Whilst I’m figuring our the Audio element of HTML5 I implore you to give his work a listen whilst playing the game.

A great example of C64 style music can be found here: http://soundcloud.com/thelastwaltz/game-tune-2

The latest version of my game can be found here: http://www.wilfscorner.co.uk/sandpit/3/castle.php

Note: if you have problems viewing the game at the first time of asking hit F5. I need to figure out the problems and start pre-caching content.