Evoking retro memories with box art

We’re huge fans of the golden days of Atari. The box art was a huge inspiration and that wonderful feeling of being transported away from real life is something that we’re keen to evoke with our own games.

Take a look at this concept piece for some promotional artwork for our forthcoming arcade game Thundergun.

The art department are nerds for Atari box art and artists such as Steve Hendricks.

What do you think?

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.

Game Design Theory – Goals, Consistency and Controls

I love this article on Game Design Theory written several years ago for the book Atari Graphics and Arcade Game Design. Everything about it I find compelling and valuable in terms of considering the player and his requirements as a gamer. It goes in to detail about the benefits of well defined and above all fun challenges. It even touches on the player’s ego and its relevance to the broader game experience.

Naturally it was written at a time when arcades were king and home computing was still very much on the back foot. In fact the whole point of the article is how we as designers can capture the thrills of the arcade for the home gaming audience. It really is a perfect chapter for someone like me with a retro fascination in arcade gaming and a future that is very much about designing arcade thrills for mobile phones.

I’ve written about this several times before but I do believe there is a link between designing for the arcades of 25 – 30 years ago and designing for today’s casual mobile experience.
So let me pull just a couple of sections out of the article and try to make sense of them.

For a game to be considered challenging, it should have a goal where the outcome is uncertain. If the player is certain to reach the goal or certain not to reach it, the game is unlikely to present a challenge, and the player will lose interest. It is very easy to introduce randomness into the game either by hiding important information or by introducing random variables that draw the player toward disaster. Be careful not to overdo this, since a totally random game lacks a skill factor. Players quickly discover that they have no control over the outcome.

How many times have you played a game and quickly lost interest because you are just not challenged ? I see evidence of this quite a lot and have myself fallen foul of it. ( My Dragons game needs a better challenge, for example. It’s something that I aim to address at some point. )
The point about randomness is of course totally valid. As designers we probably rely on the randomisation of events a little too much.

A clear structure to your game with a well defined but out of reach goal is a great starting point for any design. Look at PacMan as an example. A maze full of dots and an animated mouth is a very clear instruction to the player of what she should achieve but is still quite clearly a) a big task and b) tricky.

 

pacman

Pac-Man

One of the more important design elements in any game is a logical set of rules. The rules can be extremely simple or utterly complex, but they must make sense. Since the game must follow its theme, any rules or variations should stem directly from that theme. It is pointless to throw in game elements that simply don’t belong just because you think that confusing the player would make the game more difficult. For instance, Donkey Kong, one of the best jumping, climbing arcade games, doesn’t require the player to shoot everything in sight, just avoid obstacles to reach the goal. Similarly, a tough, shoot-’em-up game like Galaxian keeps its fluid alien attack uncluttered by distracting game elements.

 

Donkey Kong

Donkey Kong

I suppose this is straight forward.
Whatever you define as your challenge for the player to overcome it should make logical sense. You really cannot afford to switch the rules of controlling the game, for example, just to add complexity. It doesn’t do that at all it just confuses and irritates the player.I have myself learned this lesson the hard way.
That said a game’s design that I was always proud of was Wizard Wars. It was consistent in its execution and extremely simple to pick up. Just tap the screen to move the Wizard and collect the shiny things whilst avoiding the nasty things.

The ideal arcade game should foster the illusion of winnability at all levels of play. One important factor is a clean and simple game design. Too much detail or too many rules may intimidate the player. If a player believes that his failure was caused by a flaw in an overly complex game or by the controls, he will consider the game unfair and quit. On the other hand, if a player perceives failure to be attributed to correctable errors on his part, then he believes the game to be winnable and will play repeatedly to master the game. It’s as if the player teases himself to play one more time.

In modern gaming this is epitomised by the game Angry Birds. Love it or hate it it is an immediately accessible game and one that we all feel that we can conquer with just one more “go”.  I mean what could be more simple than pulling the elastic on a catapult and aiming your bird to arc its way in to a fragile structure.

 

Angry Birds screenshot

Angry Birds

I guess the point I’m trying to make is that the controls are so simple that the player won’t ever attribute his failure to a problem with complex controls he will always assume that his aim or power was incorrect. Ludicrously simple to learn and yet extremely difficult to master. At least in one sitting.

These are just three of the numerous things that jumped out at me from the chapter.
There is a lot to take in within the chapter and I implore anyone with an interest in arcade game design to study it.

So what have I learned ? Here is just a short summary.

  • Define your goals well and make sure they are clearly visible to the player. Consider Pac-Man and how visible and obvious its challenges and goals are.
  • Be consistent. Be logical. Again consider Pac-Man and its very obvious and visible rules and restrictions. There can be no confusion. Your avatar is a chomping mouth. The maze is littered with dots to eat. The ghosts are coming for you. Surely that’s not fair ? What do the flashing dots do … ?
  • Make your controls simple and fool proof such that the player won’t ever confuse them with his inability to conquer the challenge. Consider Angry Birds. Simplicity is key. I’m sure there is further scope for analysing the balance between minimal input from the player in return for maximum chaos on the screen. A truly masterful game experience.

I really don’t wish to sound like someone who is obsessed with a formulaic approach to something that should be really quite natural. But I do believe that as designers we do well to learn from the experiences of the masters of arcade game design. These guys had nothing compared to modern gaming environments. Sometimes having very little forces some great innovation.

New art direction for my HTML5 shooter Area 51

I’ve had this game in development forever and I want it finished.
After spending some time this weekend playing the game I decided to give it a lick of paint.
One of the images that I use to help me paint pixels is a screen shot of the Atari 8-bit palette. The colours are just stunning. I simply use a single pixel brush in Photoshop and hit the ALT key to select a new colour with the dropper.
Pixeling is pretty much where it’s at for me. Sunday evenings were made for it ;)

I love cartoon and I love drawing cartoons so the style I’ve gone for is very much a colourful, outlined cartoon style. I just can’t do realism. Besides the weapons ( which I drew 10 years ago ) are of a toon style so it made perfect sense.
In terms of my colour usage I’m staying faithful to my love of Atari’s arcade games.
To try and illustrate the palette choice I took this snap of Vindicators from Mame. It’s not identical but it’s fairly close :)

Vindicators - Atari Games

I’ve almost finished the static floor monsters ( i.e. the ones that walk ) and will soon start on the floaty ones. The floaty ones are the ones that will hurl magic and energy at the player. The walking ones don’t have such an attack just yet. They simply reach the player and the player is “hit” ( i.e. the screen flashes red )

I’ve got a lot going on in this game and it’s designed for mobile use only. I really need to test it across devices.

In the meantime here’s some screens.

Area 51 screenshotArea 51 screenshotArea 51 screenshotArea 51 screenshot

Looking for inspiration again with old fantasy games

The last couple of times I’ve tried to create an original game I’ve ended up taking the seeds of a game off the shelf and completing it. I’m determined this time to actually explore something new.

I’ve been digging around the web ( well, YouTube mainly ) for some of the games that I enjoyed playing on friends home computers back in the day. There are some classics ranging from Elite ( still an astonishingly complex game ) to Knight Lore to Boulderdash to countless platform games to… well just about everything.
Something that struck me was the way that games were named back then. There was a certain romance about the title and the image that it conjured in your mind. Even if the actual game didn’t quite live up to the dramatic title.
It wasn’t uncommon to be buying games called “The Castle of Terror” or “Haunted Citadel”. Proper fantasy titles with action that centered around the exploration of dungeons and the hurling of magic and such.
I loved those games and have done my best to honour them with my earlier games. e.g. Castle Adventure.

 

Atari Gauntlet

Gauntlet

I’m quite intrigued by the notion of “buddy” games. Golden Axe, Gauntlet and other such titles. It’d be pretty cool to pick a character to control from a selection of, say, four characters. Then once you’re in the game the CPU controls the other three.
I’ve blogged about my love for Gauntlet before in some detail.
I like the idea of ridding randomly generated dungeons of all manner of hell beings and then counting up the gold at the end. Possibly with a shop or something to power your team up.

 

Atari Gauntlet

Atari's Gauntlet - screenshot

I’ll enjoy opening up Photoshop and doodling some character designs. Just to get a feel for what such a dungeon game might look like.

I’d also like to research putting the game on to Facebook and getting a multiplayer angle to it.

I can see the benefits of it. Imagine the following scenario.

You’re on Facebook and 3 of your friends are also online. You send them a quick message “Hey, let’s go play Dungeon Adventures” ( or some such title ). The game populates with 4 players and away you go !

Better still you could form a party that the game saves based on your Facebook login so next time it’s even easier.

All just ideas right now and quite exciting.

Galactians 2 – a new HTML5 arcade game with aliens that “splat”

It’s really quite simple – I always wanted to make a game where the aliens come diving at you and you pump some lasers at them such that they “splat” in glorious fashion all over the screen.

So that’s what I did and since it takes its lead from my Galactians game I call it Galactians 2.

The premise is very retro and very simple. It’s also fast becoming my signature style of game. Aliens line up in rows above you and you sit beneath them with a ship / tank of some kind blasting them all to kingdom come.
I should add that when writing down a high concept for this game I considered the following 3 things: Galaxians, Starship Troopers and the classic 8-bit Defender clone Dropzone.
Galaxians for its format, Starship Troopers for its relentless bug invasion and super splatting and finally Dropzone for its visual style.

Here’s how it currently looks.

Galactians 2

Galactians 2

To create the moonbase I took a long look at Dropzone and got a feel for how the developer used just 3 or 4 colours to create the effect. It’s far from finished but let me tell you there’s quite a thrill for an aging Atari nerd such as myself to have Photoshop and Wacom open in one window and an Atari emulator running the aforementioned game in another.

I would quite like to blog the creation of the moonbase at some point in the future. I haven’t kept each stage of the drawing on file but I could probably get around that by starting a new, smaller graphic and employing the same principles.

It’s a real thrill to be making good old arcade games again. I know I’m not always very adventurous with my games but who cares. It’s great fun :-)

Incidentally the game will work on desktop and mobile. Depending on how you start the game (mouse click, fire button, touch screen) determines how the game is controlled.
Naturally iPhone 4 users will struggle since it’s Apple’s decision not to currently give their paying customers any flexibility with browser / JavaScript applications. Let’s hope that the new OS due any day now goes some way to addressing this.

 

The Atari colour palette

After a little big of digging and some Photoshop tidying up I have an image that is essentially my approximation of the Atari 256 colour palette from the 800XL. I’m sure that this colour palette may have been available to other Atari home computers but I don’t have that knowledge.

Atari 256 colours

Atari 256 colour palette

It’s a beautifully rich palette and something that I intend to use as a basis for my future games.

Something that I’ve always wanted is a fancy tool that allows me to capture an indexed colour scheme and then order it based on any number of criteria. Photoshop allows me to sort based on Hue or Luminance but I really want to sort based on the actual colours used. Black through white, blues, reds, greens etc
At Acclaim we had a wonderful in-house tool that allowed us to play with colour palettes and export them to any number of formats. I’ve yet to find a decent palette manipulation tool out there.

The beautiful Atari colour palette

Atari screenshot

From the first time I made a JavaScript game (Castle Adventure 2005) I always wanted to capture the colour range that captured my imagination as a boy playing Atari 800XL games. I adored the graphic style in some of these games and loved the way that the developers played with the colours.
Some techniques stick in my mind since they were both very pleasing on the eye and also quite inspirational.
In Ballblazer (above) I loved the way that the designers added the simple glow of the horizon. You might think it doesn’t add much but there’s something about it that just gives you the sense that the game grid goes on for a long way in to the void.

Atari screenshot

Similarly with Stealth (above) you see your goal in the distance – the tall tower – set against what looks like a glowing sunset. At a time when 3D wasn’t working on home computers developers understood that with a bit of imagination (both on the part of the designer and the gamer) you could create a tremendous sense of depth and distance.

Atari screenshot

Encounter (above) was a personal favourite. Such a simple concept – shoot the saucer, avoid the bullets – executed beautifully and with the smoothness that few other games were achieving at the time. The colour palette really added to the sense of fun and adventure. You started on a green planet then moved to desert, snow etc. Wonderful stuff.

Elektraglide (above) was, and is, possibly the hardest game I ever played. Its unforgivingly nightmarish obstacles that infuriated you beyond belief (especially as the stunning music was reaching its climax) were only acceptable because the visuals in the game were so stunning. I remember saving my pocket money for about a month to buy this one and also remember the first time I booted it up. Just fantastic. I particularly loved the snowy levels which again played with the inspirational colour scheme of whites, blues and the pale glow of orange / yellow.

Atari screenshot

Last but by no means least Attack of the Mutant Camels (above) took it all a step further by animating the floor. I always loved the thick gradient style of the sky and indeed borrowed it for the title screen to my own Castle Adventure.

Castle Adventure

Even today when I start out visualising a new game I always take a look at the colour scheme of those early Atari 8bit games. They allow me to become a little nostalgic (itself a great source of inspiration) but also realistic in terms of which colours work well together in an arcade gaming sense.
I am (as I think you can probably tell) loving delving back in time to play these superb games.

 

Atari800XL Dropzone

Dropzone screenshotWhen inspiration dries up I turn to the games of my youth. There’s something quite thrilling and romantic about delving back nearly 30 years to play some of the games that defined my desire to become a game designer.

As a 14 year old boy I was mesmerised by Dropzone. I’d quite a collection of games by this point and played them all. But Dropzone seemed quite different to the other games. It actually felt like an arcade game, not just a simple home computer game.

It did of course emulate in many respects the daddy of all arcade games – Defender. Where Defender had action, lasers, explosions and pace Dropzone doubled it up with style.

Dropzone screenshot

I think it was the artistic style of Dropzone that did it for me. The simple yet highly illustrative graphics worked and worked well. The title screen has great balance with its chunky 3D title graphic and text/sprite display laid out beneath.
In game the graphics were split beautifully. The scrolling terrain and detailed scanner occupied around 1/3 the whole screen and the rest was taken up by pure action.

Like Defender Dropzone was a tricky, fiddly affair. Often you’d find yourself frantically spunking lasers across the screen but to no avail. The alien probes seem perfect at dodging your stream. But once you achieve the necessary fine-tuned control skills and actually enjoy swinging your jetpack guy around the screen there’s some real thrills to be had. Is there another game out there where the firing of lasers is so satisfying ?

I could write forever about the action / rewards at play in Dropzone. The game epitomises for me what perfect balance in arcade game design is all about.

If you have an emulator grab yourself the Dropzone ROM and see for yourself what I’m talking about.
If you need an emulator try Atari800WinPlus.

Distant Orbit – a new HTML5 game based loosely on Atari Stealth

Distant OrbitNow that Dragons is finally complete I’m going to have a bit of fun in returning to my first love – the retro style shoot ’em up.
Note: Dragons suffers some terrible performance on iOS and I intend to look in to this. When iOS5 is released to the masses next month I hope to see vastly improved CANVAS performance.
This time for my inspiration I’ve taken a classic 8-bit Atari game called Stealth. Stealth was a Broderbund hit around 1984 and at the time was probably competing with titles like Archon and Ballblazer for my attention. I adored these games and have always wanted to recreate them in some way shape or form with HTML5 and JavaScript.
So I took the Galactians code and sprite sheets and started to look at how I might achieve the effect of a moving pseudo 3D landscape.

Initially I started to play with around 8 stripes tumbling down the screen. On setup each stripe was either dark blue or light blue and I’d resize them based on their y position on screen.
But I then realised that it was pointless and I could half my drawing by simply colouring the background with CSS as the “off” stripe colour. The effect is the same. So now I just have to deal with 4 stripes hurtling down the screen at pace.

I looked long and hard at Stealth and its use of positioning and terrain handling and decided to break with the style a little. I wanted my fighter to sweep left and right and also to bank the nearer it was to the screen’s edge. Stealth moves the distant mountains and alters the way the terrain comes whizzing under your fighter. I didn’t want to do that. Not yet anyway. Not until I’ve exhausted my preferred method. We’ll see.

So just now I have some rotation going on with the main fighter sprite. I also go to the trouble of resizing the shadow that is beneath the fighter. When the fighter is banking at its sharpest angle I shrink the shadow to be quite tiny.

Once I was happy with terrain and fighter I added the lasers. For me the lasers needed to disappear to nothing and look as though they’re headed off to the distance. I shrink them based on their time on screen and then kill() them when they get to zero. The rest of it is just playing with numbers.

Finally, at least in terms of my initial tests, I spawned the aliens to emerge from the horizon, raise a little and then swoop off down the screen. They scale up as they descend – which in itself is an issue since we have some blurring to contend with – and then get kill()ed as they disappear off the bottom.

There’s so much work to be done here but I’m very happy with the initial tests. I suspect I will need to add a distance attribute to each alien and laser so that I can accurately gauge when and where any collision took place.

%d bloggers like this: