Road Rage – New HTML5 arcade game

Road RageRoad Rage is finally complete.

I put a lot of work in to this one in terms of balancing the action versus rewarding the player with plenty of on-screen action.

I’m not really in to doing post-mortems on my games but for this one I’d say it’s come out pretty close to how I envisaged it. I made a decision early on to keep the pace up and allow the player a fair amount of freedom to move and blast things. To that end I litter the screen with explosions, bombs, bullets and debris.
I’m hoping that it’s well received enough to justify the extra effort :)

Ultimately the question of “is it fun?” has to be answered and I’d have to say that the feedback from testing that I’ve had is extremely positive. Most of the comments returned highlight the soundtrack, audio fx and big colourful sprites. I’m thrilled to read such encouraging comments since it pretty much underpins my ethos for making games. It’s certainly something that will carry over in to my book.

Road Rage

You can play the game over at the arcade. Sign up, sign in and shoot for the top spot. Let’s see how good you are!

Using Google Trends to gauge the popularity of mobile gaming related search terms

Google offers a pretty neat trends service that attempts to illustrate the popularity of search phrases over a given period. I’ve been having a little play.

Here’s a few quick charts using some reasonably obvious mobile gaming related search phrases illustrated over the past 12 months. The use of the word Free is my own assumption that the world at large wants everything for nothing!

1. Free Mobile Games, Free Online Games, Free Arcade Games, Free Online Arcade Games

Google Trends

I removed the word “Free”:

2. Mobile Games, Online Games, Arcade Games, Online Arcade Games

Google Trends chart

Hardly a dramatic change.

3. Mobile Games, Online Games, Arcade Games, Online Arcade Games, Free Games (link)

google trends chart

Just for a bit of fun I added the straight forward search phrase “free games” in to the mix. A popular search phrase. No real surprises there.
Hardly scientific but an interesting way to spend a coffee break.

A selection of screens from my new HTML5 arcade game – Road Rage

I intend to complete this game very soon. I confess I’ve got a little carried away adding some special effects with sprites. The shards of metal that fly away from the damaged vehicles when struck with a missile or gun fire were just too tempting to resist.
I spawn them in the game with random trajectory, speed and spin rate. The effect is pretty neat. For the most part the metal shards whizz off the screen but occasionally you get a slower shard that just ambles off screen with a slow spin. It really adds to the impression of blasting everything to pieces. Hope to have the game completed over the Christmas break in time for new year.

9HTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshotHTML5 arcade game screenshot

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.

The relationship between visits, ad impressions and clicks

If you’re serious about monetising your mobile web games then you may well have considered placing adverts within them. You may well have also dismissed the idea as pointless based on previous failed attempts at raising any money this way.
Let me try and give you some encouragement to pursue it. I’ll share one or two of my own experiences whilst I try and decipher the potentially useful relationships between site visits and ad impressions. In a future related post I’ll also explore how you might expose your games to your audience for maximum effect.

Google AdSense

I’ve been using Google’s AdSense for a number of years and in recent months have seen a rise in revenues generated simply because I’ve paid more attention to it. Understanding where your traffic is coming from and how they use your site is very useful when considering how to adapt your strategies.

Back when I started to implement adverts on my web pages I had minimal traffic and it took two years to reach the threshold to receive a payment from Google.
Thanks to the rising popularity and accessibility of HTML5 games I am now going past that threshold in just a few hours every day.

I’ll dive straight in and take a look at the broadest groups that we would consider when discussing web advertising: visitors, adverts and clicks. More adverts = greater probability of clicks = potentially greater revenue; this makes sense. But one thing that I’m always curious about is how raw visitor volumes translates in to revenue. What are the steps and how can I measure it. What’s more once I’ve found a means to measure it how can I improve it?

Consider this workflow:-

VISITORS > ADVERTS DISPLAYED (IMPRESSIONS) > CLICKS > REVENUE

Essentially what I’m showing you here is a rather obvious and direct relationship between each step and the step that precedes it. Your visitors (i.e. each person to arrive on your web page) are clearly your starting point.
If I were to precede this step I may well consider Search Engines and other sources of traffic but for now I’m really only interested in what happens once we have our interested visitor.

CTR, CPC and IPV

There are some simple mathematics that can be applied to each step to give us some figures to play with and measure performance. The classic example is the relationship between steps 2 and 3; ADVERTS DISPLAYED > CLICKS. This is your Click Through Rate or CTR.

Web gurus the planet over will give you different answers to the optimum CTR. It really depends upon your site, its content and your audience.

The relationship between steps 3 and 4; CLICKS > REVENUE gives us the Cost Per Click or CPC. Here we see an average of just how much each click on an advert is worth.

Let’s apply some figures.

ADVERTS DISPLAYED = 1,500
CLICKS = 150
CTR = (150 / 1500) * 100 = 10%

A 10% CTR looks pretty healthy. One in ten of your visitors is clicking a link and therefore earning you cash. In reality this is probably (at least in terms of averages) a very high CTR. But regardless it gives you a starting point. Something to monitor, measure and maintain.

Let’s try some more figures.

CLICKS = 150
REVENUE = £22.50
CPC = £22.50 / 150 = £0.15

So each click is worth on average 15p to you. The mechanics behind all of this is of course in the guts of Google’s ad handling and the relationships that its advertisers create with its publishers in terms of bidding to have their adverts displayed. There are ways that you can improve your CPC but that is not for now.

I want to explore the relationship between steps 1 and 2. I’m no advertising guru so I’m unaware of an acronym to cover it. I’ll come to that in a moment.

On the face of it the relationship seems fairly obvious. If a visitor comes to your web page and you have 2 adverts within that page then you’ll register 1 visit and 2 adverts displayed. In advertising parlance these are commonly referred to as VISITS and IMPRESSIONS. So from now on I will do the same and I’ll call this relationship Impressions Per Visitor or IPV – the number of adverts display per visitor to my site.

It seems fairly logical that every time an advert is displayed it registers an impression. In Google Analytics I see roughly 1.7 times as many impressions as I do visits.
This may well be as a result of each game presenting an advert twice. Once on the title screen and once when the game is finished. i.e. at GAME OVER stage. I never display adverts during the actual game time.

But this in itself raises a question. Is the impression registered by virtue of the fact that the HTML element containing the advert is displayed again or as a result of a call to the Google servers to request the advert. The first scenario is really just a bit of CSS to render the element’s .display property as “block” and it seems ludicrous that this should register an impression. For all intents and purposes the advert was already there. Just not displayed.

If, as seems most likely, the only time an impression is registered is when the initial call is made to Google for the advert’s content then it seems to make sense that my games are being played on average 1.7 times per visitor. I only present the adverts in the games, not around the rest of the site.

Monitoring and using the numbers

An IPV of 1.7 gives me a starting point. But is it of any use?

What benefit could there possibly be in this figure. I know that raising my traffic volumes will have a direct impact upon my revenue by virtue of the fact that it will also raise my advertising impressions. Is there any point in encouraging this figure of 1.7 to rise?

Another thing to consider is that after each visitor has had 1.7 “goes” on my games they’re clicking a link. This effectively spells the end of their engagement with my site. They are now off to the advertisers web page and probably won’t be coming back. At least this is what I have to assume.

If I spend some effort in trying to encourage visitors to play on average 2 or 3 games and therefore raise my IPV to around 2.5 or 3 will it be of any benefit or am I simply delaying something that will most likely happen anyway? i.e. it won’t affect my overall click count.

To try and shed some light on it I trawled my Analytics data for the past few months. Here’s some figures.

August IPV = 1.53
September IPV = 1.53
October IPV = 1.59
November IPV = 1.72
December IPV (so far) = 1.83

What I can say is that I made a concerted effort to increase exposure to my games from within the PlayStar Arcade throughout October and November. I did this in a number of ways but mainly with some banner advertising to advertise my own portal. Some were placed in the games and some at the head of the site.

My IPV has risen. Prior to August the IPV was fairly static at around 1.5

Show me the money!

So crucially how does this translate in to revenue?

I’m not keen on divulging precise figures so here is a percentage shift through each month.

September saw a 2.2% rise on the revenue generated in August.
October (when I started to make significant changes to the portal in terms of promotion) saw a 37.72% rise on September’s revenue.
November a 26.48% rise on October’s revenue.
And finally December is I believe on target for a 32.36% rise on November.

So if you were to plot these on a chart you would see a dip but don’t forget this is a dip in rising figures. Although 26.48% isn’t greater than the 37.72% from the previous month it’s still a significant rise in the amount of money being generated.

A conclusion?

So there’s nothing entirely scientific in this just yet but a conclusion that I’m happy to draw is that by encouraging gamers to stay within the arcade (a good practice in any case) I am exposing them to a greater variety of advertising. This in turn appears to be converting more gamers in to “clickers”.

I naturally have a bitter sweet attitude toward this. My motivation for maintaining this arcade is not financial. I just love making games and seeing people play them. I don’t necessarily want to see every ounce of traffic disappearing to another web site because it’s a better option than playing my games. Sure any revenue generated is useful in maintaining my infrastructure but I won’t ever lose sight of the fact that what I’m here for is to make fun games.

I’ll go in to some detail shortly on the structure of the portal and how I’ve approached the challenge of retaining visitors and turning them in to loyal gamers.

HTML5 arcade driving and shooting game – short demo video

I installed the Camtasia Studio over the weekend and captured a few short videos of my development projects.
I couldn’t resist sharing the video for Road Rage as it captures everything I ever wanted in a game: colour, chaos, rich audio and a ton of explosions. Yup, I have an explosion fetish! The more the better. The louder the bang the better. In fact the more intense the on-screen action the better.

I hope to have it completed soon and upload it to the PlayStar Mobile Arcade where gamers can test their skills against one another and compete for the high score :-)

Road Rage – HTML5 arcade, driving, explosion-fest shooting game – screenshots

Some screenshots from my forthcoming arcade, driving, shooter, explosion-fest Road Rage. There’s some obvious rendering glitches and tiling to address but hopefully you can still get a feel for what the game is all about.

Here is the single sentence that I have guiding me through the game’s design:

So you stole the military’s top secret armoured stealth buggy and they want it back. But you’re having too much fun just to hand it over! Tanks, armoured cars, choppers, missiles… surely it’ll take more than that for you to surrender :)

I had a handful of images from Capcom’s Loop Master arcade game as visual reference whilst I was drawing the sprites and background art.
I think the Capcom colour scheme and striking explosion style has come out well.

Road Rage HTML5 Arcade GameRoad Rage HTML5 Arcade Game7Road Rage HTML5 Arcade GameRoad Rage HTML5 Arcade GameRoad Rage HTML5 Arcade GameRoad Rage HTML5 Arcade GameRoad Rage HTML5 Arcade GameRoad Rage HTML5 Arcade GameRoad Rage HTML5 Arcade Game

Building your own mobile web gaming portal – an introduction

I always wanted to operate my own virtual video game arcade. A place where I could focus on building arcade games for people to enjoy and compete with their friends.
I remember back when I was developing my first JavaScript game about 5 years ago it was my ultimate goal to build a suite of games that would interface with my own system where scores, players and stats would be stored centrally. As a data nerd the prospect of poring over megabytes of performance stats was and still is a huge thrill.

In  my first couple of years as an HTML5 game developer I have enjoyed the process of crafting games and then reaching out to the market to licence them and move on to the next project. The revenue generated each time providing a strong incentive to press on.

Increasingly in recent months it seems that portal operators want to provide broader functionality to their user base. As a provider of games to their portfolio I am understandibly being asked to integrate my games, via APIs, in to their systems.
I don’t really have a problem with this and my games are structured such that it ought to be straight forward.
But there is a darker cloud on the horizon in the form of In App Purchasing (IAP).

If you want to lose my interest quickly start talking about in app purchasing. I despise it.
It is not a gamer’s solution and I am convinced that it is not something that gamers want. Sure they appreciate the free game up front but IAP brings with it an uneven playing field. Offering IAP in a social environment seems to me like a nonsense.

So a few months back I started to think about my own portal system again. What’s more I’m looking at turning my back on the market (or at least the majority of it) and designing the portal to be self sufficient. i.e. generate revenue.

This is no small undertaking. Successful portals operate efficiently because they have a large userbase. Lots of traffic means lots of eyes on your adverts and increased potential for that all-important click that will earn you a few pence.
With several thousand clicks pennies turn in to pounds and with enough pounds in the bank you can of course fund the kind of marketing strategies that will increase traffic and loyalty.

So what are the obvious barriers to creating a self sufficient gaming portal for mobile web gamers?

Simply put, games, traffic and web development knowledge.

Here’s a very brief intro to some of the key areas to consider.

Web development

I’m a web developer by profession so the prospect of assembling a system to manage my arcade doesn’t faze me in the slightest. In fact I rather enjoy the challenge.
Using standard WAMP tech (Windows, Apache, MySQL and PHP) I aim to build a system that will be capable of entertaining countless simultaneous players whilst recording their stats.
As the system takes shape I’ll share some more thoughts on its development.

Advertising

I’ve had a lot of success (thanks to the portals) placing advertising within my games.

Actually it is pretty much my only option since I’ve never planned to invite other game developers on board via a licencing model. I want the games in my arcade to reflect my tastes – retro, pixels, bombs, lasers, explosions and frantic pace.

Advertisers are targetting mobile in earnest. A quick look at my advertising control panel sees that hundreds of advertisers are pumping their ads through my channels every day.

I use Google’s AdSense. The adverts are placed on the game page within the markup and this page is for all intents and purposes just another web page. I configure AdSense to allow for targetting by advertisers and make a point of defining the content as mobile. Specifically mobile games.

The response has been incredible and my CTR and CPC are increasing all the time.

Traffic

So how do you make advertising work?

Well you need traffic. Lots of it.

One fifth of the planet has an active Facebook account. Specifically 1.19 billion people use the site every month. This is staggering. Of these users 874 million access the service via a mobile phone every month.

Social networking is a huge shot in the arm for anybody looking to reach out to gamers and build their own audience.

Of the 874 million people that engage with Facebook every day how many of those do you think would happily play a casual arcade game on their mobile phone?

How many of those Facebook users do you think own a smartphone capable of playing such a game?

Even if the answer to all of this is 10% that’s 87 million people. To just wave your portal banner in front of 1% of this potential audience is significant.

So how do you do all of this?

Well I’m by no means an expert but I’m happy to share my current findings and the strategy which I use.

In recent months I’ve seen direct traffic to my web site increase from 10 to 15% to around 50%.
I’ve seen average play times stabilise around 3 to 4 minutes whereas previously they were less than 1 minute.
Now that the games are centralised I’ve seen a huge increase in the amount of “activity” and movement between games. The same player will play 3 or 4 different games in a single session where previously they played just 1.
And crucially I’ve seen revenue from advertising increase significantly.

To stand a real chance of establishing a decent gaming portal for mobile web gamers I have identified the following key areas to focus on.

  • making great games
  • obtaining traffic
  • converting traffic in to “users”
  • converting traffic in to revenue
  • effective communication with the user base
  • retaining users
  • recording reliable performance statistics
  • understanding the data

So that lays the foundation.

In the posts that follow I want to concentrate on each of the areas outlined above to try and shed a little light on my approach and what has worked / failed for me in the few months that I’ve been operating my HTML5 game portal.

One thing that I will share ahead of all of that is my strapline for this project:

“PROVIDE FUN. NEVER LOSE SIGHT OF THE FUN. MAKE GAMES NOT JUST A MEANS OF EXTRACTING MONEY FROM PEOPLE”.

I have this written above my desk :)

Thanks for reading.

Upgrading an old game

I am currently in the process of updating and modernising my catalogue of games. The main reason being that they run with out-dated setTimeout() functionality when we have better options available to us these days.

So I’m looking at Spy Chase. A car game that I wrote about two years ago and which still enjoys several thousand plays a day on my portal. It’s a popular game and consequently I’m reluctant to meddle with it too much. But it needs an upgrade.

So much about the game works well. The pace of the game feels about right but if there’s one thing I could happily change it’s the difficulty levels. It really is just too easy.
In my previous post I mentioned average game session times. It seems that around 3 minutes is optimum to trigger that “just one more go” in a player. Anything longer than that and I’m struggling to keep the player sufficiently challenged. The average game time for Spy Chase is around 10 minutes. It’s far too long.

Much of this was down to the limitations of mobile browsers at the time of writing it. There was a limit to the number of sprites and objects that I could litter the screen with back then. I pool sprite objects and pick them from the pool dynamically. The size of the entity pool was around 16. Entities such as trees and power-ups that whizz down the screen during the game would start to stutter on an iPhone two years ago if they went above 16 on the screen at any one time.
I could comfortably increase the pool from 16 to 160 today and they’d glide beautifully without any issues.

So I want to capitalise on this performance boost and create not only a different challenge but a different game.
I enjoy playing some of the “endless runner” games currently popular on the App Store and am keen to explore the potential for an endless running driving game.
Spy Chase was one long road dash broken down in to short levels that culminated with the player capturing a spy car. I may well remove the spy car all together and just heap increasing amounts of pressure on the player.

I have a few options here.
The dynamics of the game allow for collision with other cars. The player can repeatedly ram a car and force it off the road at the expense of some damage to his own car. Health collectables repair his car.
Other forms of damage come in the shape of obstacles such as an oil slick and a road cone. Finally if the player veers off the road the car will sustain damage.
So it makes sense that I could adjust the width of the road to present a challenge as well as increasing the number of obstacles to avoid. But I want to go a step further and put my trademark gun fire in there.
I was always a huge fan of Spy Hunter in the arcades. You could power your car up with guns and shoot at the enemy. This I like. Better still it makes sense that the enemy should fight back!
So on the more complex and challenging stages of the game the player is trying to stay on the road whilst dodging obstacles, enemy bullets and stray missile-launching cars and trucks.
I will also increase the base road speed to reduce the amount of time that the player has to react.

Designing and building these games is a lot of fun and rather surprisingly revisiting old games isn’t nearly as painful as I thought it might be. You have to love the advances in technology. Long may it continue.

%d bloggers like this: