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.

Simple pleasures – mobile game design ideas from everyday life

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

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

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

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

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

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

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.

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

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

jetboy3 jetboy1

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

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

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

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

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

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

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

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

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

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

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

Sprite without rounding:

jetboy-sprite-blurred

With rounding:

jetboy-sprite

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

Some more thoughts on an HTML5 mobile adventure game

I’m determined to make an HTML5 adventure game so here goes with some more thoughts on the potential design of such a game.

The games that work best for me are the ones that are instantly accesible. Load assets (acceptable delay) > splash screen (acceptable and expected delay as long as it’s short) > title screen / menu > straight in to the action.
I employ this with all my games and simply offer a link on more recent titles to study a “how to play” screen.
For my adventure game I want to offer something similar that allows the player to simply pick up from where they left off with just a tap of the menu.

The game itself I would want to centre around the pursuit of experience (XP) and therefore higher levels.
Combat would be a huge feature in the game as would the collection of loot. All fairly standard for an adventure game so far.

Where I want the game to stand out is in its “randomness”.
I enjoy crafting structure to arcade games such that the player’s expectations for what he will see in each level are always met. Consistency is key in games where the player is chasing a high score.
But with my adventure game I want the experience to persist across multiple game sessions with the player finding himself in a new location / situation every time he comes to play.
In some circumstances that situation may be a confrontation and the player’s options will be FIGHT or ATTEMPT TO FLEE.
In other circumstances the situation may be designed to progress the story, say an in-game character attempts to talk or barter with you. The player’s options in such a scenario are varied.

In any scenario I would aim to present two buttons on the screen at any one time – the player’s actions being limited to simple A, B decisions.

Example 1 – interaction

The Inn-Keeper wants to talk with you.
[ TALK ] [ IGNORE ]
TALK selected.

The Inn-Keeper tells you a story about the fabled treasures buried within the dark castle’s dungeons and guarded by the spirits of the King’s fallen soldiers. -more-
[ CONTINUE ] [ STOP ]

Example 2 – confrontation

A GRUE stands before you and demands that you surrender your weapons and gold.
[ FIGHT ] [ FLEE ]
FIGHT selected.
The combat screen appears and the player must fight the GRUE to the death.
All adversaries drop loot.

I call each of these scenarios STAGES.
Stitching each stage together in a way that captures the player’s imagination and moves the story along is vital to the game’s success.
After each stage I would save out to localStorage all of the game’s data. Asking the player to save progress seems terribly out-dated to me.

Clearly this sort of a game experience works best when the player has limited time available to play.
Pick up the phone, launch the game, complete a stage, close the phone. Next time the player comes to play he finds himself that bit further on.
Indeed changing the location is very important to allow the player to feel that he is progressing through an adventure story.

What I haven’t completely thought out is how to present these stages when the player has perhaps half an hour to kill.
Although half an hour is an extraordinary amount of time to play a mobile web game it must be considered.
My initial thoughts are to use a map and have the player attempt to move between locations to unravel the story.
Another variation on that theme would see the player progressing through a randomly generated map with towns, villages, citadels and places of interest all popping up at loosly defined intervals to give the impression of a realistic world.

In a town or village the options system would change. The player would be in a safe zone so there would be no need for combat decisions.
In a “place of interest” the player would have a different challenge. Perhaps a stealth mission where the player controls his character around a maze whilst trying to avoid monsters.
If successful the player is rewarded with treasure.
In places of interest there would always be the threat of combat regardless of the underlying challenge to the player.

Another slightly more radical idea I have had is to make the game completely open-ended. No fixed goals. Simply let the player explore the world and discover new things whilst advancing his XP and level.

Still very much at the “brain-storming” stage but I’m getting closer to actually laying some code down and fleshing out the game.
I have that many concepts on the shelf just now it’s ridiculous. Hopefully one of these will see the light of day soon!

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.

Bubble Bust and HTML5 mobile casual gaming thoughts

I’ve been thinking a lot about some casual game ideas just lately.

In my notebook under future reference / potential game ideas I have so many things jotted down. Games such as:

  • Beach Head
  • Ballblazer
  • Bomb Jack
  • Jet Set Willy
  • Joust
  • Encounter!
  • Zork

…the list is about 20 long !
Zork obviously stands out here since it is a pure text adventure game. I actually wrote quite a bit of a JavaScript adventure engine a few years back. With minimal tweaking I reckon I could craft it in to a fairly useful mobile web game.

Bubble Bust ! screenshotBubble Bust!

But the point here is that regardless of this list the games that I’ve been playing a heck of a lot just lately are bubble popping affairs. Games such as Bubble Bust ! (above)
I’ve always resisted these games. Figured they were just mundane and far too repetitive for my tastes.
I was wrong. The challenges are clear and tough enough to keep me coming back for more on a pretty regular basis.

I’m a huge fan of any game that contains a strong core theme and with clever design presents numerous ways to challenge you around it.

For example, in Galaxians we shoot aliens. We also have to shoot them as they dive. Galaga expands on this and forces us to time our shots when the captured fighter is being flown around.

Bubble Bust! plays with its core design beautifully. Essentially we are in the business of matching colours (3 or more in contact pops the bubbles) but of course it doesn’t end there. Different bubbles presented to the player have different abilities. Bombs destroy bubbles in a small area. Rainbow bubbles can be used as a generic colour. Steel balls tear through bubbles destroying everything in their path. So on and so forth.

At its heart Bubble Bust! is a race against the clock.
As the bubble pack descends you have less time to think about your next move. The game ends when you either fail to clear the bottom most bubble before it crosses the line or when you pop the “key” bubble.

The pace of the game is high and for a casual game it’s perfect.

I know there’s a glut of games in this genre but of the ones I’ve played this one captures the excitement best.

So now I’m thinking about the whole “lots of decisions in a short amount of time” scenario and trying to apply it to some ideas of my own. Soccer, Horse Racing, Bingo … those types of things.

What’s more I want to try and honour the idea that if you fail you’re left with a sense of “with one more go I can crack it”. To achieve that I need to make the process of actually playing the game equal parts fun and rewarding.

It’s a new direction for me. To date I’ve pretty much made shooters in some guise or another. With my next project I’ll most likely be stood outside of my comfort zone !

 

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.

 

%d bloggers like this: