Friday mobile game concepts

Friday is a cool day. We put Sublime Text to one side and break out the pen and paper to craft some concepts.

Here’s a couple.

Underwater Blob Thing – in search of food our plucky bubble fish type thing must avoid spikes and other sharp things.

Affectionately referred to as PacMaze – the flappy blob thing must swing left and right to avoid the maze walls and collect power pills whilst avoiding spitting ghost things.

Defining alien attack formations in a retro shoot em up

In our last game, Thundergun, we adopted a purely randomised approach to generating the levels. That is, the alien formations were predefined prior to the game loading but their formations for completely random.

For our next game, Akari: Battlestar (working title), we’re looking to plan the action with far more precision.

Our inspiration for this game is from the early 1990’s and games like Raiden.

Raiden was a tough game. Very tough. Our game will hopefully be a little more forgiving in the style of what were once referred to as manic shootersDo Don Pachi epitomised this style in which you pitched your fighter against hordes of formation-based adversaries who sprayed bombs (with some elegance) around the screen. Under normal circumstances avoiding the bombs would be nigh on impossible. But this genre used much tighter collision detection; often using just a single pixel in the centre of the player’s ship for collision reference.

We’ve already adopted a similar approach.

But it’s the fighter formations we’re keen to establish up front by way of an in-house level design system. The placement of aliens, cannons, collectables, mini bosses, tanks; you name it, will be handled by this system. Each entity will have all attributes defined and the resulting output stored in a JSON format to be read by the game.

The attack formations for Thundergun were based largely on Capcom’s 1943.

Fighters swooped in, curled around and then flew off. If you took the entire formation down you were presented with a bonus item.

For Akari we want to have a lot more variation.

Fighters will adopt one of several attack formations.
e.g.

  • Drift down from the top of the screen, pause, fire, drift off to the side
  • Drift in from the side, fire bursts, drift off to the side
  • (Tanks) trundle in from the side and follow a set path
  • Squadron formations from the bottom of the screen that fly off screen and return in slow formation

For Thundergun we introduced the concept of a game progress ticker. In code this was defined as part of the global namespace g{} and referred to as g.progress

g.progress bumps with every tick of the game’s main loop. This is consistent and in tune with everything else that the game loop handles (movement, animation, collision etc) so it’s a good base for defining the introduction of alien formations.

As g.progress counts its way through to several thousands for each level it passes what we refer to as waypoints. As each waypoint is triggered a new randomly but predefined alien formation is spawned.

The difference with Akari is that there will be no randomisation. Everything will be delivered from a level data file.

At set intervals in Thundergun the action was interspersed with a mini boss; a larger fighter that drifted into view and bullied the player. Formations continued to spawn around it.

For Akari we’ll suppress the formations and halt the bumping of g.progress while the mini boss action plays out.

With the mechanics for the mini boss developed we have pretty much 90% of the code written to handle a proper end-of-level boss. The main difference will be in defining the scale of the boss and any sub-elements such as wing-mounted cannons.

Level structuring isn’t a new thing for us. We’ve employed it for our platform games and the C64 style shooter Crossfire.

Hopefully we can get a demo up and running in the near future. Exciting times in arcade game development!

Road Rage development update

In wrapping up the development of Road Rage I hit one or two snags. This annoys the hell out of me since it is largely due to big holes in the game’s design.

I’m a designer who likes to have the core stuff ironed out long before I get my hands dirty with code and graphics. The central mechanics of the game are the first thing I figure out and everything else gets built around it.
For Road Rage the central theme is the winding road that shifts at pace beneath the action and provides a rapidly changing restriction to the player’s movement. If the car veers off-road it incurs significant damage.

HTML5 arcade game screenshot

This all worked out well initially. I’d used the code base for Spy Chase as a foundation and built upon it with layers of activity. The problem was that the game was actually far too easy to play and I wasn’t willing to compromise any of the design features. 
The road movement look neat, the laser fire from the player’s car worked well, the missile fire from the enemy looked great and the explosions and special effects all added a wonderful depth to the game. But it was just too easy.
The player’s movement was limited but fairly swift in the x axis and his laser fire was rapid. This I liked. Everything played out smooth and it felt like the most complete arcade game I’d ever made. 
Injecting the time limit was a late addition and it really intensified the challenge. 

Then it occured to me that the fundamental issue was with the player’s ability to shield damage from bombs, cars and the off-road. This increased the player’s chance of survival through to the health regenerating Checkpoint between stages. 
I played with a few different means of punishing the player and settled on a single hit from a bullet or missile destroying the car. Bumping other cars and trucks took a small amount off the player’s “health” (pretty vital as bumping is a key feature in the game and a fair bit of fun) and running off-road added larger amounts of damage. I didn’t want to destroy the car for veering off road as in some cases it’s unavoidable. Better to add damage and encourage the player to return to the road at the earliest opportunity.

So the game dynamics are now set such that the player avoids enemy fire at all costs and shifts left and right to collect, dodge and shoot. So much so that you could pretty much remove the road and backdrop and it’d play out like an old school shoot ’em up. 

I think the game is a huge amount of fun and faithful to the arcade game designer’s ethos of short, challenging and intense fun for your coin. Hopefully it will encourage a high percentage of replays!

Road Rage will find its way to the PlayStar Arcade in the next week or so.

Balancing the action and using a classic for inspiration

Designing HTML5 arcade games with JavaScript has become something of a theraputic exercise. The combined thrills of pixelling, coding and designing the various elements of the action are proving to be quite useful in the stressful run up to Christmas.
Yet despite this I now find myself in that unavoidable “crunch” mode on two projects. I also set a target to finish these two projects by the new year.

A laugh at it now but I shelved my first project as it approached completion to pursue a fresh project. It was of course a diversion. I was deliberately avoiding the pain of that final 10% that takes an agonising amount of time to complete. Now I have doubled the pain!

It’s not all bad.
The discipline of developing arcade games has evolved and tightened over the years to become almost formulaic. This in itself isn’t always a good thing but it can be useful to have a blueprint for design when it comes to balancing, testing and code fixing.

For the most part at this stage I find that the raw code is cut and I’m largely playing with numbers. I play the games A LOT and talk to myself as I’m running through them – always making notes. Here’s such a conversation :)

There’s just not enough to challenge me here. The player character moves too quickly to be threatened by the bad guys. The bad guys need to target the player more. There’s too much room to move. The player isn’t developing any skills in his movement and bullet / entity dodging!

I kid you not. This was a recent note I took.
The beauty of all of this is that everything in the game is defined by numerics. The player’s movement is defined as a speed parameter that allows his co-ordinates to increment each tick. Similarly the other objects in the game perform against the same calculations. In the driving / shooting game (which I currently call Road Rage) the room in which the player has for movement is defined by the road object’s width and height. I applied a .nextthink attribute to the road container which ticks down every game tick. At zero I make another decision on how to scale and move the road.
With this method I can shrink or expand the road with ease after an elapsed amount of time. As a result of my testing and observations above I could see that the road needed to narrow more frequently. The player’s car going “offroad” results in a lot of damage and consequently Game Over so a shrinking road is a real challenge to the player.

HTML5 arcade game

As you can see in the screenshot the road is divided up in to slices. Each “slice” is an object that contains parameters for the ground texture, the road, the road’s verge and the lines that run down the middle.
The only artwork on display per slice is the ground and verge. The other two elements are solid colour blocks.

The tree decorations that overlay the ground are sprite objects and behave in a default sprite behaviour. i.e. emerge off screen, run the length and disappear without any collision detection.

Developing the shifting road wasn’t really much of a challenge. You could almost imagine the process as a series of around a dozen rectangular cards placed in order. By altering the x position of each road object as it is spawned off the top of the canvas (and subsequently allowing the object to increment its co-ordinate) you can create a satisfactory rippling effect that simulates the shifting road. The road width (the solid colour area) is known and therefore I can plot x co-ordinates for the overlayed verges.
Similarly any sprite object that sits on the road can be tested to see whether it has over-run the verge in which case I apply damage to it. Too much damage and it is destroyed. The impact on the random military vehicles in the game is a key part of the appeal as the player’s gleaming red sports car (modelled on a Ferrari 458!) can bump them off the road with a few well timed swerves in the right direction :)

For a long time in the early days of development I was playing the game and struggling to find a core mechanic for it. That vital element of the game that forms the player’s goal or goals. I knew that arming a sports car with rockets and allowing it to shunt other vehicles off the road would be fun, but as always I wanted an intensity to the action that meant there would be a ton of rockets and bombs on the screen. This can cause design problems in terms of setting a challenge since firing a huge amount of rockets and lasers only works if the stuff you’re aiming at is destroyed! It’s no good if the targets just bounce around a bit and are unaffected by your gunfire.

So I dabbled with all sorts of mechanics including collecting valuable items and avoiding oil slicks. They just didn’t work. The thrill of the game is in its pace and causing the car to spin or forcing the player to swerve and collect items just didn’t add up to very much fun. It needed to be a high octane experience with shooting, dodging, turboing and explosions set against an underlying need for speed.

So I fired up Out Run for a little inspiration. A wonderful game from the 1980s in which you drive a car at speed across an undulating terrain whilst avoiding other road users. The game is divided in to stages such that when you cross a checkpoint you are rewarded with a little more time to play.
This did it for me. It was obvious. A game in which you drive a car has to be a challenge of beating the clock.

I could still get away with blasting the bad guys I just needed to ensure that the core goal was to complete each stage in a set amount of time. Adding a timer was simple. I set it to 30 seconds initially and ticked down every second. At zero the car exploded and the game was over.

So the next question was how do I speed the car up and slow it down without having specific controls overlaid on the touchscreen.
This was a no-brainer. I implemented a turbo accumulator. The destruction of cars and military vehicles spawned turbo collectables that bounced around the screen. By collecting several of these the player built up their turbo bar sufficiently to engage a short (10 second) turbo mode in which the car’s speed doubled. The faster the car the quicker the player zoomed through each stage. So there was plenty of incentive for the player to destroy the other vehicles and go collecting the turbo shards.

But this wasn’t enough of a challenge. I wanted to add an element of dodging to the game so I stuck with the idea of the other vehicles launching missiles at the player. One hit and the car was destroyed! Unlike off-road damage or bumping the other cars, missile damage didn’t reduce the player’s “health”. It just wiped them out.

So I’m now confident that I have the game that I was after. As I play it now it’s pretty close to the original design and with the injection of the pulsating soundtrack and over-the-top sound effects I think it’s easily the best arcade game I’ve made to date.

I look forward to sharing it within the PlayStar Arcade shortly.

Building your own mobile web gaming portal – the games

I think that it probably goes without saying  that your games are your primary asset. They are the key to the success of your portal. Treating your games as such is a pretty good step toward achieving your goal of becoming a reasonably sized independent arcade.

It doesn’t take an astro-physicist to calculate that you stand a greater chance of repeat plays in your arcade if you have something worthwhile to offer.

Making sure you have enough quality in your games to keep a player engaged, challenged, entertained and ultimately rewarded enough to come back for more is of course a challenge in itself.
I have 15 games available. Some work well. Generally the older style shooting games. Some don’t work so well. For those that don’t work so well I am analysing the performance statistics to see if there’s anything I can do to improve the experience.

I think it’s probably worth exploring the world of mobile gaming in general and not just focusing on the burgeoning mobile web market. With a little investigation of the mobile gaming world at large we can probably get a good feel for what gamers will want and expect from a gaming portal.

Here’s a few key points.

Design with replayability in mind

Something that the arcade game designers of yesteryear proved to be very good at was designing enough to challenge and entertain the gamer whilst leaving enough behind to warrant another “go”.

This is of course linked to the need for a very visible and realistic target. In the arcades this target was ultimately a high score and the bragging rights that accompany having your name or initials flashing the brightest in the high score table.
But a good arcade game was split in to smaller more bite-sized chunks.

Scramble

Scramble arcade game

Consider Scramble. A tricky game and one that took most gamers a good amount of coins to master. The premise was simple: shoot, dodge, swoop and navigate your way through a deep scrolling maze. The game would throw more and more at you until your were hit or collided with a rock or a wall. It was intense and hugely challenging.

The ultimate goal was to take that top score. This was, in the early 1980s, very much a cultural thing. Gamers in those days would spend play times in school bragging about their scores. Although perhaps that has become less of a draw to modern gamers it is still very relevant to pitch your skills against your buddies.

Yet despite all of this I do believe that as gamers we invest an incredible amount on a personal level when we play. To that end I love the idea of designing stages within a game that must be conquered. On a personal level the gamer must go just one step beyond where they were in the previous “go”. Once this is achieved their attention turns back to the score.

“Right I beat that little challenge now what score do I get as a reward?”

So with that in mind I always try and design games that break down in to stages and also offer a wide range of points values for accomplishments therein.

In a later post I’ll go in to some detail of how I get data in and out of the games and in to a database.

Offering a niche

When I first set out to make mobile web games I knew that I wanted to make arcade games. Specifically the style of game that I grew up playing. They still to this day hold the most appeal.
As a result every game that I have in my arcade is an old-school style arcade game.

Just to ram the point home I even called the portal the PlayStar Arcade. I want gamers to identify with the portal as a source of arcade games. In my next post I’ll talk in some depth about the importance of branding your site.

So when a gamer comes to my arcade to play an arcade game they know roughly what they’re about to experience. The action is brief, repetetive and very much a throw back to the games of 25 years ago. This may not always be a good thing but I think on balance the decision to aim for this niche was a good one. I am engaging a certain type of player and my audience figures and play stats appear to show an increasing audience with a greater willingness to replay.

Something’s working!

I’m always reading about the importance of variety in a game designer’s portfolio. This is probably sound advice but it must be in line with your goals. It isn’t my goal to become a freelancing game designer. I just want to manage and administer my own niche arcade. I applaud those who are able to adapt to changes in the market and stay one step ahead. But it’s not for me. I guess you have to decide what is right for you and what your goals for your portal and your design ambitions are.

Rewards, rewards, rewards

This is a short and sweet one. Make the gamer feel good about playing your game. Reward everything that she does both visually and audibly (where possible). Don’t just display a “well done”. Shower the screen with tiny stars and let the little on-screen character do a little dance. Your gamers will remember it and come craving that feel-good experience in the future.

Screenshots, blurb, action and a challenge

This is a big one. I’m willing to bet that the primary reason for somebody clicking to play your game when it’s sat amongst a sea of games is the screenshot that is used to advertise it. In fact whether it’s a screenshot or an icon make damn sure that what you’re showing is the game’s key selling point.

If your game is a driving game don’t just show a stock image of a steering wheel with the name of your game over it. Show an in-game shot (or an adapted version of it) of a vehicle on the road in an interesting setting.

This of course links back to how you design your games. Designing with a screenshot in mind is no bad thing. When you construct your games try to visualise how it’s going to look sat alongside all of the other games in your arcade.

Those old enough to remember the glory days of arcade gaming will remember the artwork on the cabinets. The image of electro-invaders on the side of the Space Invaders cabinet or the bright yellow Pac-Man set against the largely blue hue of the maze that was in the masthead; both instantly identifiable and designed to pull the gamer in.

Similarly think about how you “talk” to the gamer. You want him to click and play. Give him something to fire his imagination. Calling a game Shoot the bridges is possibly not going to inspire a young boy’s imagination in the same way that River Raid does.

River raider

River Raider HTML5 arcade game

In my own game River Raider I wrote a small introductory paragraph which read:

Fly fast and low and blast everything to pieces. Your mission: destroy ALL bridges along the mighty river and neutralise the enemy threat. But watch your fuel and steer clear of the rocks. If you’re good there’s rank and glory to play for.

I worked hard to try and capture a young boy’s imagination and give him some motivation to jump in and play. I’d hoped that with just a few words somebody might pick up that gauntlet and take up the challenge of destroying bridges and blasting “everything to pieces”.
It also serves as a neat way to present at a glance what the player can expect when they press the start button.

So that’s it. A few starters based upon my own experiences designing games and attracting gamers in to play them.
In future posts I’ll go in to a little more detail about branding your portal and acquiring traffic. I’ll also discuss the tricky problem of converting casual visitors in to loyal gamers.

Tweaking games for a better challenge

I’ve been playing around with a few of my older games lately. Galactians 2 in particular has spent a good amount of time on the ramps.

598x158

Swoop, dodge, blast, bounce and splat

When I wrote it a year or so ago I was keen to just upgrade the graphics from the previous incarnation, Galactians, and boost the player ship’s laser power. My design document for the game was (as usual) a single sentence that roughly read “swoop, dodge, blast, bounce and splat”

To that end it came out pretty close to the design :)

It was a game that I’d enjoyed making and had tested to death before I unleashed it upon the portals. But I guess there was always an element of “am I making it too easy by giving the player so many laser power-ups?”
I still think I was. But the amount of fun that could be had wiping the screen clear of swooping aliens in under 3 seconds was just too irresistable to ignore.

3 second attack waves?

I’d played with the concept of short waves of attack with HyperGunner. It worked quite well in that game so I was keen to repeat it.

4I played Galactians 2 a lot this last week and of course my ability to rack up the high scores increased. Before very long I was in to the millions and the average game length was probably around 10 minutes.
It was only when I stopped to look at that number 10 that it occurred to me that it might just be a bit too long and a bit too easy. Should I be thinking about reducing the average game time?

My Google Analytic stats show me that the average amount of time on a game page is around 3 minutes. This isn’t exactly scientific. It only takes a handful of players to stay on the page for 10 minutes whilst the other lord-knows-how-many-thousand duck in and out within seconds to skew the figures. But that aside I stuck with the notion of 3 minutes per game. It seemed like a reasonable amount of time to be playing and quite possibly the optimum amount of time to trigger that all important I must have another go and do better.

So where next?

The frankly ridiculous jelly bomb

Well I didn’t want to mess with the core mechanics of the game.
I liked how the aliens peeled off the formation and swooped to attack. I also liked how later levels would see a non-destructable guided missile and the frankly ridiculous “jelly bomb”. It also seemed to work that on later levels just as the player was becoming comfortable with the repetition of blasting and splatting some aliens would target the player with their bombs rather than simply dropping them.

It was when I focused on the bombing habits of the alien bugs that I realised something fairly crucial to the game’s challenge / reward dynamic. The distance between the hovering alien formation and the player’s tank was fairly large. Around 200 pixels from the base of the lowest alien to the turret of the player’s tank.

Within that space the aliens would shift left and right whilst diving often in a sharp angle. On the shallower dives the player was pretty vulnerable. But on the steeper dive curves the player had a lot of time to react.
So I tweaked the game to shunt the player up by 48 pixels (I always work in 8’s with sizing in these games. No idea why?) and reduce the severity of the alien dive curves.

More challenging and more fun

The result was incredible. The challenge presented by reducing the player’s available response time was enormous. Better still it actually felt like the kind of arcade game that I grew up playing. I was thrilled.

My high scores were halved, as was my play time. Rarely did I score 1 million and rarely did I reach 4 minutes per game. But nothing was lost. In fact quite the opposite. The game was more challenging and consequently more fun.

The concept of reducing reaction times is now high in my mind as I shift my focus to some of the other games.
In particular Jumpin’ Jasper, which is nearly complete, is prime for applying this “rule” to.

There is of course another benefit to shrinking the play area in this way. The game suddenley opens up to a wider audience of Samsung Galaxy Y and iPhone 4 users. In fact my player sessions have more than doubled as a result.

An extremely worthwhile exercise.

The concept of Greed in game design

A concept that always intrigues me in game design is the concept of Greed. That powerful force that is strong enough to pull you away from your chosen path in the game to try and achieve something. You’re effectively taking a chance. You don’t need to pursue this extra “thing” to complete the game or even the level but the rewards for being successful are just too great to ignore.

capcom 1942

In shoot ’em ups we see it in the pursuit of power boosts to your guns / lasers. Classically in 1942 (above) you were presented with a formation of red planes. If you knocked them all out you were presented with a power-up.
I employed something similar in Crossfire. You didn’t need to hunt this special power down but you just knew that having that extra firepower would be a) more fun and b) pretty handy for completing the level.

With Jumpin’ Jasper I have a similar concept. When a bonus balloon drifts across the screen the player can leap in to it to burst it and take the rewards. Similarly when the Squirrel bounces on top of a monster the monster’s subsequent demise spawns a bonus item. Currently bonuses are purely a points boost. Hardly a real driving force for the player. So I’d like to create a mini-challenge by having a sequence of bonus items to collect. They appear ghosted out at the top of the screen – a strawberry, some cherries and probably a banana (yellow works well against the game’s backdrop) , an apple and an orange. Red, purple, yellow, green and orange respectively all work well against the game’s bluish backdrop.

As the player collects each item of fruit they populate the empty slots at the top of the screen and a special bonus is awarded when all are collected. Quite what yet I don’t know but it will hopefully be enough to see the player divert from his current path to try his luck with the bonus balloon as it drifts in to view. Or possibly take on the monsters to achieve the same result. Of course the random nature of the bonus items’ spawning means that the player could well go to all that trouble to spawn a bonus item that they’ve already collected.

I had initially wanted to run a story through the game and have certain side elements unlocked with progress. This could have been a neat way to involve the bonus items but on reflection I’d rather wait. My next game (which will use the same code framework) will probably lend itself to that approach more since it will be more of a science fiction affair.

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.

Screenshot

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.

%d bloggers like this: