Mobile game design – Zombies!

Concept

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)

Goal

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.

Sub-goal

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.

Control

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.

Audio

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

Dropzone

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.

Some thoughts on player interaction with HTML5 mobile games

I currently have a number of small side projects which are for all intents and purposes simple design tests. My current focus is with establishing new, reliable and aesthetically satisfying ways to have the player interact with the game.

Basic control – Touch, slide and first-touch free movement

Initially with Wizard Wars I stuck to the basics and the game centered around tapping the screen to direct the wizard.

Subsequent games have seen simple slide left and right controls implemented to steer cars and star ships.

More recent games have seen me register the first touch and allow free movement in all directions. I like this approach and generally find it to be the most satisfying to play. Games like Crossfire (my homage to the C64’s shoot ’em up heyday) and Desert Rescue really benefit from this style.
So for the most part all of my games exclusively feature one of those three methods of controlling the on-screen character.

The only time I veered from this simplicity was with Dungeon Adventure. With hindsight I’d perhaps concede it didn’t work out so well and the control system took a lot out of what was a potentially enjoyable game.

Feedback and limitations

With mobile game development – HTML5 or otherwise – it’s vital that the game’s design is wrapped around the limitations of the touch screen control. I have never implemented on-screen buttons and don’t have any plans to. It just doesn’t work for me. The whole point of pressing buttons to affect the action is in the touch > tactile response > on-screen action dynamic.
For example the process of a ships laser firing in response to a button being pressed is empty without that central bit – the tactile response to the player.

Feedback in games is important to me, as is the management of player expectation. In many cases it makes a lot of sense to automate basic actions. e.g. your on-screen character automatically runs and you simply tap the screen to have him jump.

With Danger Ranger I desperately wanted a platform game experience. To achieve this I placed a jump pad at the base of the screen. As the player’s on-screen character walked in to the jump pad he was thrust high in to the air. The player’s only control was in sliding their finger left and right to control the character’s movement.

So there are several genres that can be achieved even with the limitations of a touch screen. We just need to consider these limitations and design the game around them.

Classically of course ports of great arcade games have failed to deliver since they were designed for different interfaces. Defender springs to mind. A proper spaghetti control system if ever there was one. Not a great game to try and play on a sheet of glass.

Fusing a couple of ideas together

So moving forward with some new design ideas I’d like to try and fuse some of these touch styles together.

Initially I considered Bomb Jack as a project.
I’d always loved the game in the arcades and figured it was colourful and lively enough to translate in to a good casual / mobile game. Better still it could quite easily be shoe-horned in to my Danger Ranger code base.
The issue of course was in the control of “Jack” (I assume that’s his name).

Bomb Jack arcade screenshot

Bomb Jack (Arcade version)

So what is Bomb Jack ?
Well essentially you play the game by directing Jack around the screen with the joystick. and hitting a button to have him jump in the air. He only jumps when he’s on solid ground be it the base of the screen or one of the floating platforms.

This makes things quite easy in that I will always know when he’s NOT flying or falling. So if the guy is on terra firma any tap above him on the screen could be an instruction to launch him skyward.

Of course whilst he’s in flight the side swiping controls still work to control him albeit at a slower rate.
For this to work there would have to be a threshold set around the character since the simple act of tapping the screen with the intention of moving him left or right is also going to fire touchStart().

Jump vs movement

   A         B  <-- Any touch here results in a jump
  ------------- <-- Slide control threshold
                <-- Any touch in this region moves Jack left and right
        J       <-- Jack's position
  ============= <-- Solid ground

Hopefully the crude illustration above makes some sense.
J is relative to Jack’s position and the dashed line above him marks the uppermost region for touch events that result in his walking left and right.

Tapping in the A or B region will send Jack skyward to the left or the right respectively. In reality I would aim Jack to the point that the touch was registered to give greater granularity of movement.

Whilst Jack is in flight the illustration isn’t relevant and any touch on the screen will drift him left or right until he finds solid ground.

Pure theory right now but so far I’m happy with it. In fact if it works I’d be happy to consider more complex platform games.

New HTML5 game for Christmas – Rocket Santa

I’ve enjoyed playing with my game framework this past week or two since releasing Crossfire. A few bug fixes and tweaks and I’m once again in a pretty good position for making new and original games in a timely fashion.

Something I’ve always wanted to produce is a Christmas game. Something with snow, Christmas trees, pressies, snowmen, elves and of course Santa (Father Christmas to us English folk). I also wanted to produce it pretty pronto as I’ve at least 2 more projects that I want to undertake before 2013.
So I took a look at a previous game Danger Ranger and took to adapting it to fit the new framework.

Rocket Santa HTML5 Christmas Game Rocket Santa HTML5 Christmas Game

It’s amazing how satisfying and strangely warming it is to have snow tumbling down the screen !

The game is now complete and available to anyone wishing to licence a fun and colourful HTML5 Christmas game with a funky soundtrack and lots of other cool features :) 

Initial thoughts on an HTML5 football (soccer) game

I’m looking at producing a football (soccer) game for my next project. Looking around at the world of football in computer games is a pretty interesting exercise.
Thanks to sites like YouTube it’s not so difficult to perform quick comparisons between games from a variety of different platforms.

See for yourself what I found over a coffee break earlier today.


World Cup 90 Sega Megadrive


Versus Net Soccer Konami Arcade


Cyberball Not sure which platform – cool portrait view


American Football game – cool portrait view


Beautifully presented N64 J-league game


Excellent execution. Non-fluid game.


Neo Geo. Say no more. Beautifully presented.

I included some of the non-Soccer games to highlight their presentation. I typically like to produce games in a portrait orientation so the Cyberball game was particularly interesting to me.

As a huge fan of football myself I can say that the thrills of the game are in the attacks. The faster and more precise the counter-attacks in a game the more thrilling it is for the spectator.
I want to build a game that captures the very best parts of a football match. To that end I may well ditch the standard approach for making such a game in favour of purely concentrating on the arcade thrills of attacking football.

Throw-ins, corner kicks, offside.. they’re all pretty dull to an arcade gamer.

One idea that I’ve had is to start each as a set piece where the player has to defend a free kick. If the attacking team scores then the set piece is reset and the player must defend again.
If the set piece breaks down and the ball goes out then the stage is reset and again the player must defend.
If however the set piece fails and the player obtains possession then the thrill of the counter attack ensues.

I like simple controls so initially my thoughts are to tap left, centre or right on the screen to direct the goalkeeper when in defensive mode.
In counter-attack mode the AI for the advancing players will be handled by the code such that the player simply taps the screen to pass the ball. The theory is that the player taps ANYWHERE on the screen and the code will select the nearest team mate to pass to.
Once the team player with the ball moves beyond the overlaid 20 – 25 yard line he automatically shoots.

This is very much a dumbed down approach but it currently works for me to think like this.
I’m a huge fan of simple controls and simple execution.

 

New HTML5 game – Crossfire

My latest project – the Commodore 64 inspired Crossfire – is complete.

game banner

I used the project to refine my HTML5 game framework and to also try out some new functionality.
I’m thrilled at the resulting game and look forward to adding to the framework with subsequent games.

screenshot screenshotscreenshot screenshot

Crossfire is set to a scrolling landscape that (loosely, very loosely) resembles a Death Star style trench as viewed from above.
You control 3 fighters and are tasked with blasting countless formations of alien fighters whilst dodging numerous obstacles, bombs and cannon blasts. (Extra lives are available with progress)
The game is played at a fairly slow speed to allow for some fine-tuned movement and to also add to the amount of on-screen action.
Every couple of waves you get to challenge your reflexes with a challenge stage. These stages are played at a much faster speed and are very very tricky !
If you survive the challenge you will be met with a much harder stage the next time around.

For the super starfighter there is the opportunity to have your name in lights as Crossfire stores high scores locally to your device.
Note: Currently on mobile I could only find support for the high score table (courtesy of IndexedDB) on Firefox for Android. But I am sure that this will be supported across the board very soon.

The game will be available to play shortly on PlayStar.mobi and also Mozilla’s MarketPlace.

If you are interested in licencing the game and would like a closer look please don’t hesitate to drop me a line at wilcom1970@gmail.com

Crossfire progress update

My current project, the C64 shooter inspired Crossfire, is nearing completion.

All features are in place and the code is pretty stable just now.  I’m hoping to finish testing in the next two days and spend the following couple of days creating all the marketing materials.

I play through my games a heck of a lot. Last night I was blasting away when it occurred to me that the game needs just something extra. A stage that gives the player a break from the normal trench blasting and avoiding objects. So I created a Challenge Stage.

The challenge stage runs the trench at 4x its normal speed.
It’s automatically hellishly difficult to perform the usual blast and collect but is by no means impossible.
I set the challenge stage to appear every couple of waves and right now it looks and feels amazing.

Very excited to be finishing this soon and will of course be presenting it on playstar.mobi once its done.

C64-style HTML5 shoot ’em up and the SPIFF framework

I’m really thrilled to be finishing this little game up soon. It’s been a hell of a journey and a huge amount of fun.
I think it’s fair to say that this game truly feels like an HTML5 game in that it’s not just a case of painting the Canvas.

screenshot screenshot screenshot screenshot

This is the first game that uses my new “SPIFF” framework for building HTML5 arcade games.
Some of the tech inside now includes:

  • IndexedDB – High score table
  • requestAnimationFrame – improved rendering performance
  • Web Audio API – full soundtrack and sound effects
and some of the features:
  • full import and export of game data
  • intelligent screen resizing and scaling
  • rich front-end and in-game menu system
  • offline level designer
  • publishing tools
  • intelligent feature detection / rejection
  • in-game audio manager
I guess more importantly it’s a game that benefits from many hours of research across multiple platforms and browsers. I’m confident that this game will run comfortably in any browser and still looks great on the new iPhone 5 resolution.
There’s plenty more to be added but it’s pretty modular just now so bolting stuff on shouldn’t be a problem.

It’s the wonderful soundtrack (courtesy of a good mate and old school buddy – we grew up marvelling at the work of Rob Hubbard and Martin Galway) in this game that I think sets it aside from anything I’ve produced before. Having a full audio / visual experience in a game is just thrilling. Mobile web games have been mute for so long !

With SPIFF I hope to produce many new and original arcade games. Not all of them will be retro in their nature but they will hopefully all honour the design ethos of the classic games.

Perhaps one day I will make the code open source.

In the next few days I  aim to sit down and blog the challenges of creating a retro game based on the C64 colour palette, amongst other things.

HTML5 game framework, web audio and a new (old) game

I’ve spent a good amount of time lately working on my HTML5 game framework. It’s starting to pay dividends.

I think the thing I am most thrilled about is the support for Web Audio. Thanks to a bunch of great sites and their articles getting up to speed with producing sounds for the games has been a breeze.

I heartily recommend this site for a great introduction to the API: http://www.html5rocks.com/en/tutorials/webaudio/intro/

I currently support 3 files types: OGG, WAV and MP3. OGG files are generally larger than the other two. Generally speaking I aim to get the game code and assets in to 500k. For all audio I aim to use no more than another 500k such that the game fits in to 1Mb. Downloading a 1Mb game outside of WiFi isn’t a problem in 2012.

For the soundtracks that run through the game I use a very fine composer and old school buddy. You can find his work on SoundCloud. We grew up listening to the awesome music of Rob Hubbard on classics such as Sanxion. I can’t tell you what it means to us to be able to reproduce the arcade thrills and wonderful game music from almost 30 years ago.

Audacity logo

For the creation of sound effects I use Audacity. A wonderfully simple tool to use yet extremely versatile and rich with features. You will need a couple of plug-ins to export to different formats but the application will guide you through this.

As a source for my sound effects I fire up MAME and record the audio of a few games. Armed with a WAV file I launch Audacity and start to tweak the sounds until I’m happy that a) it sounds nothing like the original and b) it fits the game.

This is probably copyright hell but just now I’ve not used the work commercially. Most likely by the time I get to use production quality sound effects I will have commissioned them.

Adding sound and music to games is in many respects the final hurdle. Mobile web games have been largely mute this last couple of years. It’s just awesome to be able to offer rich multimedia gaming experiences.

I look forward to presenting my next project, Crossfire, in the next couple of weeks.

%d bloggers like this: