Jumpin’ Jasper – HTML5 SNES style platform game – development update

A considerable amount of work has gone in to Jumpin’ Jasper this last few days. I’m thrilled by the results of some intense pixelling. As always it’s the colour choices that end up defining the game and I think I got this one just right. Time will tell of course but I’m pretty sure this is the most complete game I’ve made yet using HTML5 tech.

I’ve made a conscious decision to shift towards a SNES art style. This is not a casual decision, it’s very much a direction I want to take my games in going forward. I think the market for HTML5 games is maturing quickly and in order to compete it’s vital that I step up the quality of my output. I enjoy the art as much as the coding and crafting these sprite-based retro games is very much a part of the thrill. Of course the research that goes in to coming up with the art style isn’t so bad either!

Jumpin' Jasper screenshot

So I’m definitely in to the closing stages with the game and am looking to tie up a few loose ends before I begin the lengthy testing process.
I have a few more features that have definitely crept in but they’re not huge and I’m happy to let them slip through the back door :)

Hopefully Jasper will prove to be a hit for me and I can build upon his character for future titles.

Jumpin’ Jasper – a new HTML5 platform game in development

I’ve been working hard on my new HTML5 platform game recently and have had a huge amount of fun creating sprites and some interesting monster AI. It was always my intention to use the game as a vehicle for another new character and I’m pleased to present to you my lovable baby squirrel Jasper :)

html5 game title

I think I’ll probably call his first game Jumpin’ Jasper since that’s pretty much what he spends most of his time doing. The title frame above is my current placeholder being used in the development.

I thought it may be interesting to share my design document. It contains a single sentence:

Cute, cartoony and full of bounce !

It does make me smile when I read that back. To hell with lengthy discussions on what goes where in a level or how a monster should behave. That stuff happens organically for me as I code and test. I think as a designer I just know when something feels right and I can only achieve that by repeatedly playing the game and tweaking the code.


There’s still a ton of work to do with the art. I envisaged some nicely detailed backdrops to each level so the blue gradient won’t be quite so stark. I’m currently aiming to use a kind of Lego approach so that I can create elements and re-assemble them to create some varying background images. It will be very much a fantasy setting.

The game is currently all about jumping around the platforms, riding moving platforms, avoiding spikes and monsters (including the pesky wasp and wasp sting!), bursting bonus ballons and collecting bonuses and hazelnuts. I’ve tried really hard to keep the game moving. I didn’t want the player scratching their head trying to decipher what to do next. I think it works. I’m also very pleased with the powerups available. I think they’re fun. Especially the power boots!

Hoping to finish the game in the next couple of weeks.

Sprite creation for mobile web games – some thoughts on colour and composition

Back in my day as a Gameboy Advance artist we used to have some key rules for asset creation. Generally much of the design was handled externally via the client and we simply adapted any work for presentation on the small screen. But occasionally we were given some free reign to create new art. To achieve optimal presentation on the GBA screen – which don’t forget was not back lit! – we needed to use the brighter end of the spectrum. Few games on the GBA got away with using the darker palettes. I always thought that the Castlevania games let themselves down in this respect. Fine games in many respects but a dog to play without any additional light on the screen.
By contrast a game like Mario with its brighter colours obviously lends itself to the console’s display limitations.

Castlevania (left) and Super Mario Advance

Castlevania (left) and Super Mario Advance

In defining the graphics for my HTML5 arcade games I try to keep this simple rule in mind. I don’t need to. My target platforms are mobile and of course the world of mobile displays has improved no end. We now have elaborate screens in which each pixel is infact its own light source. Powerful stuff and extremely rich for the game experience. I could in theory get away with much darker palettes but there’s something about vibrant colours that I think is more attractive and more appealing to the gamer. It’s engrained in to me to use rich colour in games and it’s not something I want to turn my back on.

I remember as a young bedroom coder back in the early 1980s reading a copy of C&VG. In it gaming legend Jeff Minter wrote paragraphs about the importance of colour in games. He argued that people respond to colour in a far more powerful way than they do muddy or darker colours. Certainly for arcade games (which is of course Jeff’s forte) this is true and back then on systems like the C64 and Atari 800 range rich colours were a key feature.

So much like the GBA days I start out by defining a palette. For this I use Photoshop. It’s not the best palette tool in the world but it allows for a selection of colours that can be used across the game’s assets.
I start out by using the colour picker and heading for the top right corner for the brighter colours.

Photoshop colour picker

Photoshop colour picker

I try to visualise in my mind how the colours will separate across the game screen.
I am trying to picture the player’s on-screen character sat on top of the game’s backdrop and sitting alongside the other key game elements. This helps to define the colours that I will add to the palette – or swatch in Photoshop parlance.

Photoshop swatch

Photoshop swatch

Dropping new colours in to the swatch is simple and you can quickly build up a bunch of saved colours.
I skip down the spectrum in the colour picker and pick out the colours that I think will best suit the sprites, backdrop and effects. I also try to bear in mind additional colours that could be used as highlights or shadows.
For example, if I want a shiny glass ball sprite it’s useful to have colours nearer to white to add as a highlight.
I try to keep the palette to no more than 16 colours. It’s not always such an easy thing to achieve but it’s a good discipline to aim for.

For my current platform game project colour selection is quite simple. The main character is a squirrel and I’ve coloured him a nice vibrant orange with some light brown. It makes sense to me to have him sat on top of a blue hue since blue and orange compliment one another and always look appealing. But rather than have the blue sat in the same luminance range as the squirrel’s oranges I tone it down a bit. Something a bit more pastel-like.

squirrel sprite

Squirrel against two blues

I try to ensure that there is a clear visual separation between these “layers”. The foreground “active” layer if you like and the background layer.
For every other active game element (or sprite) I try to adopt the same rule. It helps to identify to the gamer which items in the game are important. There are countless other ways to achieve this but this is a good start.

html5 game screenshot

Platform game dev screenshot

Lately I’ve taken to adding a dark key line around the game’s sprites. In fact with the platform game I deliberately designed the game to use cute cartoon characters so that I could achieve this. It really lifts the sprites up from the background layer and for me is a neat style for mobile arcade games.

Within each sprite I also like to define key areas with a darker colour.
So for example with the squirrel you can see that I’ve separated visually his eye, arms, nappy and feet. This is important as it helps to create the illusion of movement and animation. If I’d merely used variations on the oranges and browns it’d be less easy to pick out the swinging arm and walking feet.

I adopt the same approach to any special effects that I use. Things like puffs of smoke and explosions. These are all foreground elements and need to be separated from the background. Again the explosions use the red / orange / yellow end of the spectrum which sits on top of blue nicely. Similarly yellow stars and white smoke will be clearly visible to the gamer and act more as visual rewards than anything else. Much like the character sprites I’ve taken to adding a key line to help separate them.
I’m a seasoned cartoonist so being able to pixel cartoons for these casual games is a huge thrill!

Hopefully that gives a quick insight in to my thought processes for creating the colour palettes in my HTML5 games.
In future posts I’d like to discuss sprite composition and scale in more detail and will also touch on how to create simple animation effects.

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.

Using HTML5 games to tell a story

I always wanted to use games to tell a story. Over the years I’ve scribbled down a ton of story ideas that might lend themselves to gaming and never really done much about it.

kyle cometMy current project involves a fourteen year old space hero and his fight to save the planet from an evil scientist / aggressor. Standard stuff. The kid is of course an ace starfighter pilot and perfectly capable of getting himself in to a scrape or two.
I guess the point of the exercise was to create a framework whereby the player could enjoy the action and just have the story unfold behind the scenes. To that end I am trying to stitch together a bunch of different arcade styles to keep the player entertained whilst the story is being told.

In some respects the story is irrelevant and in others it is pretty key. It’s also a useful dynamic for leading the player in to a situation and teaching them how the game should be played. To better accomplish this I’ve built in achievements.
So for example, in the first chapter of the story the hero is faced with a deep space minefield. The mines can be destroyed and for each mine that is destroyed a ton of energy is released. The more energy that is collected by the player the more charge goes in to the starfighter’s super laser. When the super laser is fully charged the player can reap havoc on anything that comes close.
This is clearly going to be of some use throughout the game so for the first chapter’s challenge I use it. i.e. Challenge #1 – collect enough energy to power your starfighter’s super laser.

If the player doesn’t achieve this it matters not. It’s purely a bonus. But I imagine that most players will achieve this as it is very simple. Not to mention hugely rewarding.

To drive the story I’ve created some cool characters.
The main character (the player’s character) is young Kyle. Kyle Comet to give him his full title. The somewhat precocious product of the Deep Space Academy that appears to know no fear.
His best friend and radio assistant is Lexa. A young girl who keeps an eye on the galaxy for trouble. She is an extra pair of eyes and ears for Kyle and operates from the safety of the space station.
The bad guy is one General Vore. A former scientist and good guy. A big brain and now a huge threat. He was cast out of the peaceful planet Tranquis (this appeared in a previous game) that Kyle and Lexa call home and now plots to return and take the entire planet for himself. Not only that he’s amased a sizeable army to help him.

Making games is a huge amount of fun. Making games to tell a story is just thrilling. I am at heart a story teller. I love games but I love crafting stories and adventures just as much.

I intend for this story to be the first in a series of stories that chronicle the life of my deep space hero Kyle Comet. Just now I call it Kyle Comet and the Dreaded General Vore. A pretty lame title but it gives me something to work with whilst I complete the game.

Hope to have it ready by new year.

Great Boulder of Death and in app purchasing in HTML5 games

Every once in a while a new game emerges that I think is worthy of a closer look. Recently I downloaded Pik Pok’s Giant Boulder of Death (GBoD). As with one of their earlier titles, Flick Kick Football, the key to the game’s appeal is in that nagging “if I just have one more go I’ll improve…” dynamic. It really does work a treat.

Flick Kick Football is a tight game. You can launch and be playing within seconds, the controls are very basic and the challenge is enormous. A perfect game experience in every respect.

Giant Boulder of Death Giant Boulder of Death Giant Boulder of Death Giant Boulder of Death

GBoD is the same. Well almost. It takes just a little longer to start playing and the adverts and in-app purchasing breaks are a distraction. This aside though and the game is just too perfect to ignore.

Note: I initially titled this post Great Boulder of Death – a study and blueprint for making fun, challenging and market friendly games.

So what is this game?
Well essentially it’s a love story between two boulders. Man boulder sits high atop a mountain rock whilst woman boulder sits as an ornament in the village at the foot of the valley. A man with a chisel hacks the woman boulder in to tiny pieces and from afar man boulder seeks to exact his revenge by rolling at pace down the mountain destroying everything in its way.

This game is just loaded with tiny elements that go to making a wonderful challenge and overall experience.
As you hurtle down the mountain (itself an extremely satisfying experience) the town mayor orders some defences. Spiky walls, spike ball hurling contraptions, giant spiky robots… the more you unravel the game the more you will see.

To steer the boulder you tilt your device. I play on iPad Mini. It works a treat. To leap over stuff you tap the screen.

Initially your tilting effectiveness is pretty minor. As is your ability to jump. But the more in-game coins that you earn the greater your ability to “pay” for upgrades. As with all good games that use this model you don’t have to spend a single real-world penny. You can just play the game. The more you play the better you become and the more dib-dobs you earn. Spending your money wisely results in improved control, reduced adversaries and an overal greater chance of obtaining rewards.
The balance is perfect. No goals seem too distant. There’s always an upgrade within reaching distance.

My own experience developing Distant Orbit showed to me that achieving this balance is not the result of guess work. It takes a tremendous amount of testing to get the right balance of challenge to reward.

So the game is essentially an exercise in swerving around obstacles, destroying targets (sheep, ramblers, cars, horses, houses…) and accumulating enough coin to upgrade and make future games fractionally less challenging and therefore more fun. The carrot that is dangled by suggesting that a few more coins could increase the speed or height at which your boulder can slide or leap is enticing. The thought that you could reap even more destruction on the world by spending hard-earned game currency is a real thrill.
And that is also a key factor in the game. The process of actually playing the game and taking on the challenges is fun. Why? Because you are destroying stuff. Whatever could be more fun?

By combining speed with destruction and injecting a liberal amount of chaos the developers have, I’m sure, tapped in to what we as humans crave – total control and a little bit of madness :)

I should say right here that this game is not easy.
Dodging spike bombs is hard. In fact maddeningly so. You are left with a sense of frustration that it wasn’t actually humanly possible to avoid certain obstacles. In some scenarios the seemingly random nature of the object generation really does conspire against you. I’ve never encountered a dead end – let’s face it that would be a fairly neat way to hack someone off and never see them again. But I have encountered situations where an emerging pathway is suddenly blocked and only the mightiest of leaps would get you through.

But this is nit-picking.

Where GBoD succeeds is in its tying together of all of theses wonderful elements.
As a gamer I’m left with that holy grail of gamer emotions – just one more go.
I love games that focus on the score and on the importance of achieving as high a score as possible.
Some of the targets in the game focus on achieving high scores. This has to be the ultimate in “if I have one more go I’ll beat it”.

I’d really like to include as many elements from this game as I can in my current project. My current project is the start of a series. I’d like the gamer to feel that the first game in the series sets a precedent. I’d also like to leave the door open for in-app purchasing should any of my publishers require that feature.

In almost every conversation I have with clients these days in-app purchasing features.
I have code written to handle this but it’s my code. Integrating with 3rd party APIs will of course differ from solution to solution (assuming they’ve not gone the route of plugging in one of the off-the-shelf solutions).
I don’t like in-app purchasing models. They’re not a gamer’s solution. But I have to support them.

In-app purchasing is probably another post. For now I urge people to go and download Pik Pok’s impressive Great Boulder of Death.

A rough .gif rendering of the corridor-on-rails concept

Further to my previous post about the potential for a zombie / mutant shooter in which the player moves between locations via a pre-rendered sequence, I have knocked up an extremely rough concept.

Flipping through these frames (320×240) and overlaying a weapon in the lower right corner runs very smoothly on the devices I tested on.
Note: I drew that bio-weapon for a ditched Gameboy Advance project about 12 years ago! I’ve been dying to use it ever since :)

corridor-conceptThe execution needs some tweaking but I think it’s on the right lines just now. I’d like to render some decoration on the walls and ideally texture the walls.
What would follow then is a case of sitting down to figure out every situation and therefore every frame to render.


Thoughts on a creepy take on the mutant/zombie genre

I’m mid way through the design of a zombie game just now where the hero is surrounded by advancing hordes of the undead armed only with a shotgun. I’d pretty much settled on the graphic style and had had some success in spriting the majority of the game’s characters.
Then something happened.

The other night I found myself wandering around the house in the small hours with just the light of my mobile phone. Possibly through playing far too much Doom/Quake etc 20 years ago I found myself thinking “hm, could be something around that corner / behind that door !”
It occurred to me that this is how you should approach a game containing zombies and or mutants.

I target mobile with my games so my first thought naturally turned to how on earth would I create a game in the first person perspective that was convincing and responsive enough to do the concept any justice.
I’d been down this road before a couple of years ago and given up. OS/canvas implementations just weren’t up to the amount of drawing I’d wanted to do. Back then I also deliberately didn’t try to move the game at speed down corridors. Further to all of that I really couldn’t be bothered with coding the other niggling things like occlusion.

This time around I’m coming at it slightly differently.
I want to move the player between waypoints. At every waypoint I then give the player options for which direction he can take.
So essentially the corridors are prerendered and take up around one third of the game screen. In portrait I’d probably letter box the main playing area in the centre and hand over the top and lower regions to present the player with icons for weapon selection and movement. Not sure yet.

So to try and explain what I’m thinking imagine that you are walking down a plain corridor.
You can give the illusion of movement quite simply by having lines in the wall scale. Since there’s no freedom to look around you’re only concerned with moving the content past you until you’ve moved the set amount and the animation stops.

The way I’d figured it you’d only need to prerender a certain amount of scenarios.

  • straight forward corridor progress – no doors or turns
  • corridor movement to a crossroads
  • corridor movement to a T-junction
  • corridor movement to a left or right facing door
  • corridor movement to a closed door

I would really want to instil a sense of “there could be something just around that corner or behind that door!”
To do this I’m thinking of having a simple HUD that displays two sensors:

  • motion sensor
  • life sensor

Both mutants and zombies trigger the motion sensor but only a mutant will trigger the life sensor.
This presents the obvious scenario of being able to frighten the bejesus out of the player.

So what do I have so far in all of this theory.
Firstly I have the creepy environment. A prerendered facility with gloomy corridors and the occasional neon light. Two sensors beep and blink intermittently to alert me that ‘something’ is nearby.
I have the option to move first and foremost.
The game tells me the options: forward only.
So I move forward. The game runs through its animation sequence and I’ve moved probably around 10 steps. I’m in a new location. What do the sensors tell me? Well the life sensor is blinking quickly. Something is VERY close!
I have the option to move forward or turn right. Whatever it is that’s nearby is most likely around that corner or 10 steps straight ahead.
I select the option to turn right.
What do the sensors tell me now? The life sensor is red and the motion sensor is now blinking rapidly.
I’m looking in to the darkness of the corridor ahead. My shotgun is readied. I have 3 shells…

For the emergence of the monster I want to run through another little animation.
Since the corridor is always soaked in darkness I can present a simple 3 or 4 step animation showing something emerging from the shadows until I get enough of a view of it to take action.

If I sense something terrible then I simply tap the screen where I want to shoot. If I hit the ‘thing’ before me it should drop to the floor and I can loot it and move on.
But wait… It’s not as easy as all that.
What I really need to spice all of this up is the option for friendly fire. Yup, civilians!

If I paint a backdrop of being on a rescue mission then gunning down the good guys is clearly counter to the objective.
So the player is faced with that awkward ‘is it or isn’t it?’ scenario. Which I love.

Rescue on Fractalus - Alien Attack

Rescue on Fractalus – Alien Attack

Older gamers may remember the awesome alien-at-the-window sequence in Rescue on Fractalus. This is without question the influence for this sequence. It’s a moment in computer gaming that has stayed with me since I first saw it as a teenager back in the 1980s.

It’s a huge thrill to be designing again and I’m excited by the promise of such a game.

What’s more this kind of execution is possible on current hardware. Add a few creepy audio effects and simple touches like muzzle flashes and blood spray and I reckon I’m on a winner.
As always the concept needs proving so I shall now take myself off to Photoshop to see what I can dream up!

A quick look at the potential for HTML5 gaming on Nintendo’s Wii U

Once upon a time I worked as an artist for a company that developed games for Nintendo’s handheld devices, amongst other things. I remember back then (2001 ish) wondering whether web technologies would/could ever produce the kind of environment suitable for good quality gaming. I suppose looking back then it must have seemed ludicrous that you could pull up a web browser and play a pretty performant arcade game with fluid animation and full audio support. We certainly wouldn’t have imagined such an experience being available on the consoles we were developing for – Gameboy, Gameboy Advance. Not even the next-gen stuff of the day – PS2, Xbox (1st generation).

Desert Rescue HTML5 game on Wii U

Desert Rescue HTML5 game on Wii U

So it’s with some interest that I continue to read about the level of JavaScript support within Nintendo’s Wii U:

Nintendo itself is clearly keen to push the capabilities of its browser out to the indie community. What’s more with a considerably lower barrier to entry than traditional console development, it’d be great to think that Nintendo could pave the way for bedroom programmers the world over to find a new route to market.

Quite how Nintendo would control this potential demand from developers is another question but it’s certainly encouraging to see that there is once again huge potential for carving out a livelihood for yourself from the comfort of your own home.

A cool looking retro-styled game called CrossCode appears to be in consideration for publishing on Nintendo platforms.
You can play a sample of the game here: http://www.cross-code.com/en/play

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.

%d bloggers like this: