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.

  • 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!

Some (more) thoughts on a football game

It’s World Cup year. As a football lover I love the world cup finals. This year we are in Brazil, the home of traditionally the most exciting team in the world. Brazil are generally the neutrals favourites and have, in years gone by, come to epitomise a free flowing style of football that is both easy on the eye and extremely effective at opening up the opposition’s defence.

I’ve thought about making a football game before but have never really settled on a design that suits the nature of the touchscreens that I target.

Lately I’ve been thinking about a game in which the player controls an attacking player with the sole goal of dodging oncoming defenders.
For as long as he has his finger on the screen the player is controlling the movement of the player. It’s all about timing. When an approaching defender looks as though he is about to slide in the player must lift his finger off the screen. This triggers a jump from his on-screen attacker.
If the jump is well timed the play continues until the attacker reaches the edge of the box.

Now it’s about position. As the player steps on to the edge of the 18 yard box the game automatically shoots. But it’s not over yet, the player just has the keeper to beat. To maintain the momentum I don’t want to completely stop the action for the player to place his shot. Instead I’m going to give him as long as he has earned!
For each well timed jump to avoid the defenders the player earns valuable time. Also, to distract the player in to changing direction during his run toward goal I will drop bonuses on to the pitch. The more the player collects the longer he has to aim his shot at the goal.

After each attack it’s the turn of the opposition to attack. But I’m not interested in displaying that. For that I’ll roll a dice and present whether or not they scored to the player. I want to get right back in to the attacking phase so that the player is primarily concerned with scoring goals.

I think I could probably take this design forward in to an initial concept with some crude graphics.

Adding dynamic tweet functionality to HTML5 games

My current focus is with the PlayStar Arcade. I’m keen to push it as a platform for playing my HTML5 games. A lot of work has been carried out “under the bonnet” as we say in the UK and now I’m in to the slightly more entertaining areas of adding bells and whistles.

Something I was always keen to pursue was the ability for players to share their scores via social media. Twitter was my first port of call.
Thanks to their Tweet button script placing a button inside the game was a fairly simple exercise.
The flow that I wanted would see the player complete the game and reach the “GAMEOVER” status. At this point I would present the <div> containing the Twitter code.
The player would then be prompted to share their score and tap the Twitter “Tweet” button. All I had to do at this point was switch the text inside of the code that Twitter gave me with my own text. This replaced text would be what appears in the dialogue box for the player to tweet.

tweet score from html5 game

But there was a problem.

The attribute that I need to change to achieve this is the data-text attribute of the <a> tag in the Twitter script. But dynamically changing this attribute proves useless. 

When the Twitter script executes it converts the <a> tag in to a <div>. Any subsequent calls that I make to amend the tag fail.

I appreciate that this is largely theory so rather than post my own code solutions I’m going to link a site that covers it neatly with code examples.

This guy had the exact same problem and solved it beautifully. 
I now have the ability to let the player complete a game, rack up a score and then share it with the world courtesy of Twitter. Facebook is next.

The importance of quickly proving a game concept with JavaScript

I have what I’m sure is probably considered a primitive style of coding JavaScript. It’s never really evolved in to anything that a purist would adopt over the years. To be frank it doesn’t concern me. What’s most important to me is that I understand my code and more importantly perhaps; it works.

The benefits of knowing my own code and the intimate relationship that I have developed with it have time and again proven useful. Not least when I’m approached by clients and 3rd parties to implement their own code and / or extract data from the game. Simple modifications and tweaks are simpler because I know my code inside out and the upside to all of that is of course that such changes are quick. Or at least quicker than they would have been if I’d had to first figure out how the code works.

There’s another huge benefit to writing and understanding my own code which for me comes in to its own when I’m considering a new game. I often daydream about a game or take inspiration from the most random things. I’ve got sketch books full of ideas and documents on my computer full of code snippets and high concepts.

HTML5 arcade game screenshot

To try and explain I’ll briefly explain the process of developing one game.

Some time last year I was driving home after a long journey across country. Not too far from home I remember pulling off the motorway and as I approached the traffic lights on the slip road I watched the striped yellow lines on the road. As I slowed to stop I remember clearly thinking how cool it would be to create a game in which the player controls a jet fighter that flies low over a striped landscape. Inspired by the illusion of the lines cascading beneath the car I turned over in my mind how the code might look. It didn’t take much to figure it out and that game turned out to be Distant Orbit (pictured).
I could prove the concept quickly because I knew how to adapt my code base to implement the stripe objects that form the planet floor. Better yet I visualised the game loop and could understand how to scale the alien bugs as they emerged over the horizon. There was nothing overly complicated in it and using the same approach I could quickly implement the tower that forms the player’s primary target in the game. The thought processes in understanding scale rates and how to manipulate such events per game “tick” came to me pretty quickly and because I understood the underlying code that handles the drawing and moving / scaling of objects I knew pretty much how the code would look.

What’s valuable to me is being able to take a concept, process it in my mind (and therefore visualise it on screen) and then move quickly in to code. It’s only by being able to do this that I can quickly dismiss an idea or take it to the next step – design. I like to have one quirky feature per game:  striped floors, scrolling terrain, 3D trench, starfield; and it’s generally this feature that I’m focusing on at the concept stage.

Much of this is always done using “defaults” for sprite art and defaults for audio. All objects have default behaviours as sprites in my code and adapting them to behave differently is 5 minutes work. At least to prove the concept. Fine-tuning can happen much later on as part of a balancing process.

So in short it’s crucial for me to be able to very quickly get in to coding. When I have a vision for something I spend a short amount of time poring over the approach that I’ll take and then it’s all about cutting code.

In future posts I’m going to break with my own tradition of not sharing my code. You can see for yourself just how ugly code can render some pretty cool looking arcade games :)

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 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.


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.

A little side project and some thoughts on touch control in an HTML5 platform game


Screenshot from Bouncy

Spent a little time on a side project this last few days. It’s a pretty simple platform game that involves guiding a hedgehog / porcupine type animal around the screen collecting valuable items and avoiding the bad guys.

When I first came up with the control system I had intended for the game to not involve platforms at all. It seemed to be a lot of fun just hurling the spikey creature in to the air and have him pop balloons. But the more I developed the touch control the more it seemed to make sense that the player could jump and walk with ease.

I’ve never wanted to overlay touch controls on to a game. I really don’t like them. So for this game I’m using touchMove() to guide the character around and touchEnd() to initiate playerJump().

The theory is quite simple. When I initiate TouchStart() I set a time with a straight forward function to return the number of milliseconds since some moment in 1970. (I think!)

function time()
var d = new Date();
return d.getTime();

I store this value in something like m.player.firstTouch.
Then when touchEnd() fires I do the same and store it in m.player.lastTouch.
A simple test to see whether lastTouch is significantly higher than firstTouch tells me whether or not the player has tapped the screen or tried to move the character.

With a bit of fine tuning I’ve also managed to make the character’s movement pretty smooth and of course relative to the player’s first touch on the touchscreen.

The effect is nice. If there’s one thing I’ve learned making these simple arcade games it’s that if your controls are a mess the game will have no appeal whatsoever. According to my Analytics I enjoy a high percentage of repeat plays. I see this as a target to maintain.

I don’t have a title for this game just yet so I call it Bouncy :)
It’s very much a work in progress with still a fair amount of place holder art. But it’s moving along nicely and has given me a valuable distraction from my work on Kyle Comet’s first adventure in space ! As with Kyle my intention is to develop game characters that I can expand on and potentially brand for future adventures.

You can check my dev page for notes and updates on the game’s progress.

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.