Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/27/d312880249/htdocs/spacemonsters.co.uk/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 77

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/27/d312880249/htdocs/spacemonsters.co.uk/wp-content/plugins/jetpack/_inc/lib/class.media-summary.php on line 87
Game Design – Page 2 – in search of Space Monsters

HTML5 platform game – progress update

Development on my platform game project is coming along nicely now. It’s always nice to break the back of the game’s “engine” and then settle down to tweaks and minor mods. For the most part just now I’m playing with numbers to get the best “feel” for the game.

HTML5 platform game

For example – initially I had the player’s character (a squirrel that I currently call Jasper) leap in to the air with a tap on the screen (or mouse click / Z or CTRL on keyboard) and fall at the same rate that he jumped. It looked great as the squirrel span quickly and then landed with a satisfying thud. But when I tested it on a mobile handset it was proving difficult to control the character. So I slowed the rate of descent and also reduced the spin speed as the squirrel descended. The result was and is equally as satisfying and much more fun to control.
I have to say that playing the game on the desktop with the keyboard is a lot of fun. It feels great and very responsive. But crucially on mobile it works extremely well. A fine balance.

My level editing suite allows me to drop features in pretty quick. The resulting JSON that is spat out is simply dropped in to the game transparently such that when I fire up the HTML it’s just there. This gives me the freedom to chop and change at will and more importantly it allows me to have a lot of fun creating levels.

I currently have 4 monsters all of which are mutated bugs of some kind. Two bugs crawl along the platforms, 1 spits acid and another drifts in and targets the squirrel if he’s hanging around too long on the level. Kind of like the saucer in Defender.

Using this same codebase I’ve already started designing a game similar in some respects to the excellent Metroid. I like the challenge of creating more sophisticated SNES style graphics. In fact there’s a lot of similarities between some SNES titles and my own art style. I’m not the world’s best pixeler but I do enjoy it.

I’m currently targetting the first week in December to complete this game and then I’ll go back to the cartoon space adventure starring my young intergalactic ranger Kyle Comet.


Some research in to smaller HTML5 arcade game projects

My larger Kyle Comet project is moving along nicely and today I’m enjoying spending a little time researching a couple of smaller side projects.
I have a real love for quirky Japanese arcade games that involve super simple challenges and pretty much demand that you drop another coin in to have just “one more go”.

I’ve taken to MAME to explore a few of these and am enjoying trundling through the likes of Bomberman, Bomb Jack and Diver Boy. Simple games with a clear and simple goal. Better still they have extremely simple controls. Generally it’s a case of move the guy and press a button for a single character action.
Naturally this kind of simplicity lends itself to simple touch screen gaming where user input is a little restricted.

Bomberman arcade game Bomb Jack arcade game

I currently rather like the idea of a game where the player spends his time avoiding obstacles whilst leaping around collecting moving items. It’s a simple premise and ought to be a straight forward development. The appeal in the game will extend to its presentation and such things as a quirky soundtrack that bounces along in the background as the player’s character leaps about the screen.

Kyle is my primary focus but I’m a big fan of smaller diversions every once in a while.

Kyle Comet – dev update

kyle comet screen

Dev screen with placeholder art

Pretty much finished the first draft of the story script. Each character is fairly well defined and I think the plot is pretty well established. Good guys chasing bad guys through minefields, asteroid belts and such against a backdrop of the threat of Earth invasion. Standard stuff but great to write for.

The mechanics and structure are in place – Intermission (story and goals) > Action (challenges, blasting stuff, collecting stuff etc), Summary (more story), In-game shop (power up your ship etc) and repeat.

I’m not entirely happy with the controls for Kyle’s ship on desktop. The mouse feels a little clumsy. But this is primarily a touchscreen game and to that end it works just fine.

Considering a cool Jet Force Gemini style soundtrack.

Starting to plan alien attack patterns. Need to consider what I want the player to learn in terms of movement and skills. Will base alien movement on this. Some will pursue the player others will simply move in formation. All will shoot.
Collecting stuff is a big feature of the game. Need to make sure that “greed” features.

Simple pleasures – mobile game design ideas from everyday life

It’s amazing just where we take our inspiration from sometimes. An ordinary Sunday morning drinking coffee and catching up on yesterday’s news, when the kids come through with some bread to feed the birds.
So I’m stood in the garden hurling lumps of bread across the grass. Before long the birds arrive. There is of course the natural pecking order amongst the bird life. It’s fairly easy to feed the larger birds but the smaller ones seem to struggle. Especially when their big ugly neighbours show up.
So right there is my first challenge. How on earth do I ensure that the smaller birds get enough to eat? In fact that’s pretty much the goal of my game.

Of course my mind to turns to scoring achievements and how I might reward success. A crow chewing down some bread scores just 5 points. But a robin or smaller bird can score, say, 100 points.

Maybe there’s some strategy in hurling the larger lumps of bread toward the far end of the garden to attract the big birds and keep them busy? Smaller bits of bread can be hurled toward the starving chaffinches.

Better still how about awarding points based on the size of the bread that the bird eats in relation to its size. So the crow eats a large piece of bread! Big deal. Scores just 5 points.
But the wren finds its way to a large piece and flies off. A bumper 250 points!

There is of course one other angle to explore – predators. What do you attract if you put a bunch of birds all in one place? Yup, cats.
So there again is another challenge. Make sure you don’t fill the screen with birds since when the cats come the party’s over!

I might keep this simple idea sketched up and clipped to the notice board since I can see it being pretty straight forward to develop. No levels, no saved progress, just simple jump in and aim for a good score. Possibly look at achievement unlocking but nothing too fancy. This has got “5 minutes whilst I’m waiting for the bus” written all over it.

Some thoughts on a context based HTML5 platform adventure

I’ve been toying with the idea of an arcade game in which the player controls a character that must escape from a dark and creepy tower. In fact being extremely inventive with my naming I’m calling the game The Dark Tower !
The premise is simple; your character is stood on the uppermost platform of a series of seemingly endless platforms and must decide what action to take to get off that particular platform.
If successful the character will drop down to the next platform where he is presented with another challenge. So on and so forth until the player guides his character out of the creepy tower.

The challenge in the game centres around the timing of tapping the screen to perform the character’s action. Depending upon the context of the platform the action will vary from jump, walk, run, duck or shoot. At least that’s what I have for now ! I guess it’s a kind of Temple Run concept.

So as an example the character stands waiting at the far left or far right of the platform and spins to face the direction he needs to move to get off the platform. At the far end a strange object periodically spits out a poisoned dart. You have a second to consider this and realise that the height at which the dart is travelling means that tapping the screen will result in your character jumping.
You tap the screen and sure enough he jumps over the dart and starts to walk forward. Another dart comes, you tap, the character jumps and continues to move forward. A health icon is overhead. You tap to jump collect the icon and moments later you tap again to leap over a dart. At the end of the platform the character drops down and spins to face the next challenge. This time he starts to walk on his own. From above a boulder smashes down. You tap the screen and your character stops. Tap again and he starts to walk. Another boulder crashes down before you. Tap and tap again and you’re on your way… So on and so forth.

It’s either a challenge of escaping from a predefined number of platforms or simply seeing how many platforms you can complete.

My plan is to randomise the platforms with the simpler stuff at the start and the more demanding platforms later on.

Impossible Mission screenshot C64

Impossible Mission – Commodore 64

The key for me in all of this is the animation of the game’s central character. Much like Impossible Mission from the 1980’s golden age of gaming I want the player to engage with the game based upon the silky smooth animation of their on-screen avatar.
Update: Play a Desktop JavaScript version of Impossible Mission at http://impossible-mission.krissz.hu/

More as I have it.

Zombie game – a quick thumbnail sketch and some more thoughts

I hope that this hasty thumbnail sketch does justice to my current thinking for a mutant/zombie survival game.
Essentially I want yet another excuse to fill the screen with cannon fodder. Our hero sits central protected by fragile barriers and the monsters advance toward him (or her) from all angles.


Some zombies drop goodies and bonus items but most don’t.

Using the touchMove controls I want the player’s character to swing through 360 degrees. The moment the finger touches the screen the hero opens fire. Toying with the idea of a crosshair just now. This may or may not negate the requirement for on-screen bullets. I’ll implement them both and see which feels right.

To draw the monsters in the correct order I’ll run through their y-position and draw in order from low to high. This of course includes our hero and his barriers as well as all bonus items.

Finally (at least for this round of thinking) I’ll preserve the central floor area for a muzzle flash effect.

Mobile game design – Zombies!


A game in which the sole survivor of a zombie/mutant uprising stands barricaded in the centre of the screen armed only with a pistol.
Zombies initially advance from off-screen and are picked off with just a couple of bullets. As play progresses the zombies rise up from the floor close to the player. To counter this additional weapon / ammo / health cannisters can be shot and collected.

The gimmick

Not sure yet but the style of the game will be decidedly cartoon-like so I may research some cool animation techniques.
Also, I’d like to have a story running beneath the game possibly illustrated by spinning newspaper headlines.
A key feature of the game will be the liberal splattering of blood :-) (Configurable of course between red and green)


The game is divided in to territories and the player must clear each territory to advance. Each wave comprises just one of a set number of waves per territory. I’d like to theme each territory. Possibly have a shopping mall (of course), abandoned school, cinema, car park… you get the drift.


Develop your character to be a bad ass! Armed to the teeth with guns, ammo and bombs etc. Ideally also boost your hero’s maximum health so that you can withstand more in the later stages.
An additional idea (if I have time) was to collect mutant cards. A zombie is a zombie but for mutants I figured it’d be cool to collect a set of cards depending upon which mutants you’d discovered. This would add around 4 -6 weeks to the dev time based on the amount of art required.


The player controls a crosshair that can be moved around the screen to shoot stuff. Shots will only be fired if the crosshair is over an item or monster. This leads to the player being conscious of conserving resources. Always a neat trick in a zombie game. I don’t plan a reload function. Largely because I hate them.
The uppermost area of the screen (just below the score / high score / audio control panel) will be handed over to weapon selection. Tapping each icon (assuming the weapon is available) will ready that weapon.

Weapons and items

Currently I plan the obvious. Pistol, shotgun, Uzi, Grenades. But a couple of bonus weapons may occur to me as the game unfolds.


As with all my newer games there will be full audio and a soundtrack courtesy of the web audio API.
I rather like the idea of a John Carpenter style soundtrack and good bassy gun shots. Alas I may succumb toa cheesy, almost jolly soundtrack. We shall see.

Visual style

Cartoon. Colour. Exaggerated comic violence.

Special features

All the usual including combo bonuses for multiple kills.
May also play with the idea of friendly fire targets. Civilians. Not sure how that would work yet given the auto firing nature of the game.
Speed bonuses are always a nice addition. Reward those with an eye for a shot and handy with the weapons.
Since the bulk of the art challenge is in designing a framework for the main character animation I may also like to have a character selection screen. Initially just a male and female selection. Largely at the behest of my daughter who always likes to play the female heroine in games :-)

I always wanted to make a zombie / mutant game. Got quite far once with a pseudo-3D affair but canned it due to my running out of steam with the concept. Losing focus with the game is a killer!

Area 51 screenshot

Area51 – canned HTML5 project

Hope to add more to this design as the ideas occur to me.

An introduction to designing mobile arcade games

Before I start to present some thumbnail views of potential mobile game designs I just want to recap a few thoughts on the control system and a rough structure for the design of each game.

So much in designing games for mobile (be it an app or a mobile web game) is dictated by the control system. The lack of buttons to press is both a blessing and a hinderance. Far too often with console games I’m left put off and baffled by the spaghetti-fingered controls so I find the relative immaturity of the touch screen interface refreshing.
But of course the moment you want your mobile on-screen character to walk, run, jump and shoot you have an issue.
As I’ve blogged many times before I never overlay a joystick and buttons.

I have several games that sit on my developer’s shelf just now that never made it beyond concept phase. In many cases this is due to continuing to scratch my head about the controls. Automating certain actions is the obvious way forward (player movment, auto-firing weapons…) and balancing this with giving the player something to control that relies on developing a skill is where the mobile game designer spends a good deal of his time.

Generally speaking I centre my games around a single “gimmick”. Something a bit quirky such as the pseudo-3D effect in Distant Orbit or the scrolling trench in Crossfire. For me it goes hand in hand with the formation of the central challenge.
Recently in Super Jet Boy I hit on the idea of controlling a character with thrust alone. As a boy I’d played Dropzone to death and wanted to emulate the way the spaceman rotates on the x-axis. This formed the core of the game for me.

Dropzone screenshot


In my design documents I always start with a small section called Gimmick :-)
I then expand on this to identify and develop the core challenge and any sub-challenges. The one thing that (if I got the design right) is never a challenge is the control itself.

So with my designs I will initially try to present a rough genre, style, visual style and high concept. I will then expand to explore what it is I want the player to actually achieve in the game and of course identify what it is that stands in his way. From this I expect a bunch of challenges to fall out and this is where the game starts to come to life. Exploring where the real fun of the game can be found should be fairly organic.

All questions welcome and of course if you have your own thoughts on mine or your own designs feel free to share them.

Talking about HTML5 games and cool game designs

I love sketching out game ideas. The thrill of designing a spaceship or game character and trying to figure out what monsters and challenges lie ahead has never left me.

photoshop worksheet

Designing sprites for the HTML5 game Galactians2

Right back when I was a young teenager in the early 1980s I got a buzz out of watching a TV show or film and dreaming of how the events therein might translate in to an arcade game.

To this day I keep a sketchbook in the car or an iPad mini at my side should I have inspiration. The one thing I don’t do (which I really should) is share my thoughts on here. So all of that is going to change. In an attempt to breathe some life in to my much neglected blog I intend to spill my design thoughts on to here a bit more frequently. There will of course be an obvious bias toward mobile web gaming and the technologies of HTML5 / JavaScript. But generally I just want to get back in to the habit of talking about games and cool designs.

Super Jet Boy – a few thoughts on touch-screen control and sprite presentation

Jet Boy (or Super Jet Boy to give it its full title) is a game about a boy with a rocket pack who embarks on an adventure to recover some mystical golden statuettes. High above the kingdoms of his homeworld a series of enchanted sky temples play host to an array of weird monsters charged with one simple task – protect their master’s golden treasure.

jetboy3 jetboy1

Jet Boy has no special powers. For once I resisted the urge to load my game character up with bombs & lasers and throw explosions around the screen. All I wanted with Jet Boy was a simple case of learning how to control a character with a rocket pack.

Much of the work in creating the game was already written thanks to my work on Crossfire.
In that game I defined a pretty neat way of designing challenges using my own tools that ultimately spat out some JavaScript with enough data to construct a level. The logic for actually assembling that level and its obstacles and entities is elsewhere within the game’s core.
I pretty much lifted most of that logic when constructing Jet Boy and adapted it to respond to gravity and bi-directional movement.

The real challenge in developing the game was in the control of the main character.
I knew that I wanted movement in all directions and also the concept of thrust to lift the character higher up the level. When no thrust was applied (either through no screen press or lack of fuel) the character would simply fall until they reached the base of the level. At this point the player would be looking for bonus ballons carrying fuel to re-enable the rocket pack.

So how do you acheive all of this without using on-screen buttons in a touch screen environment?

The obvious conflict was in the distinction between simply touching the screen to move the character and touching the screen to apply thrust to the rocket pack. As soon as I tap the screen both would apply. I may only want to shift the character from left to right in a horizontal fashion but by virtue of the fact I’m touching the screen the rocket pack would fire and the character would raise.
I initially figured this would be acceptable but the moment I fired it up it was anything but. In fact it was maddening.

So I set a new attribute on the player object that essentially ticked down to zero. At zero the character would start to rise.
It’s a kind of pre-thrust thrust if you like.
The player touches the screen, the ticker is set, the rocket pack engages, the ticker begins the count down, a second or so later the ticker hits zero and there is enough thrust to enable the character to rise. If the player releases the touch before the ticker hits zero the ticker is forced to zero.

This worked quite well as it allowed for a reasonable amount of horizontal movement before the character started to rise up the screen.
To aid this I deliberately set horizontal motion to be very loose. In other words when the player slides his finger quickly across the screen the character zips left to right (or vice versa) at speed.

As usual when you implement this kind of thing to solve a problem you are often treated to a few surprises. One such surprise was in how nice it felt to have the character free-falling down the level and gaining speed through gravity, only to have that descent cut short in a smooth fashion thanks to the application of thrust. There is no fancy physics engine beneath all of this it is simply a case of fine tuning the numbers until I’m happy with the results.

Finally I would like to mention here that to achieve the smooth motion I deal a lot in floating point values. i.e. 1.2345 rather than 1. This affords a decent amount of granularity. But when it comes to drawing on the screen using context.drawImage() I cannot apply those floating point values to the x/y co-ordinates of the sprite. The result is a blurry mess of a sprite.
To combat this I simply round the figures down to the nearest integer with Math.round() / Math.floor() — round up and round down respectively.
All of my sprites contain an ‘angle’ attribute so rotation occurs on each sprite regardless of whether the angle is always zero.

/* g.ctx stores the 2D canvas context, o is the sprite object, the spritesheet property stores all the sprite image data */
g.ctx.translate(Math.floor(o.x) + (Math.floor(o.w/2)),Math.floor(o.y) + (Math.floor(o.h/2)));
g.ctx.rotate(o.angle * (Math.PI / 180));
g.ctx.drawImage(o.spritesheet.image, o.frame * o.spritesheet.framewidth, o.row * o.spritesheet.frameheight, o.spritesheet.framewidth, o.spritesheet.frameheight, Math.round(-o.w/2), Math.round(-o.h/2), Math.round(o.w), Math.round(o.h));

(I will document my approach to spritesheeting at some point in the near future)

Sprite without rounding:


With rounding:


So that’s it. The game is still very much in development and I’m spending a healthy amount of time enjoying the process of designing levels. When the game is complete it will be available through the usual portals and of course Mozilla’s MarketPlace.

%d bloggers like this: