Road Rage development update

In wrapping up the development of Road Rage I hit one or two snags. This annoys the hell out of me since it is largely due to big holes in the game’s design.

I’m a designer who likes to have the core stuff ironed out long before I get my hands dirty with code and graphics. The central mechanics of the game are the first thing I figure out and everything else gets built around it.
For Road Rage the central theme is the winding road that shifts at pace beneath the action and provides a rapidly changing restriction to the player’s movement. If the car veers off-road it incurs significant damage.

HTML5 arcade game screenshot

This all worked out well initially. I’d used the code base for Spy Chase as a foundation and built upon it with layers of activity. The problem was that the game was actually far too easy to play and I wasn’t willing to compromise any of the design features. 
The road movement look neat, the laser fire from the player’s car worked well, the missile fire from the enemy looked great and the explosions and special effects all added a wonderful depth to the game. But it was just too easy.
The player’s movement was limited but fairly swift in the x axis and his laser fire was rapid. This I liked. Everything played out smooth and it felt like the most complete arcade game I’d ever made. 
Injecting the time limit was a late addition and it really intensified the challenge. 

Then it occured to me that the fundamental issue was with the player’s ability to shield damage from bombs, cars and the off-road. This increased the player’s chance of survival through to the health regenerating Checkpoint between stages. 
I played with a few different means of punishing the player and settled on a single hit from a bullet or missile destroying the car. Bumping other cars and trucks took a small amount off the player’s “health” (pretty vital as bumping is a key feature in the game and a fair bit of fun) and running off-road added larger amounts of damage. I didn’t want to destroy the car for veering off road as in some cases it’s unavoidable. Better to add damage and encourage the player to return to the road at the earliest opportunity.

So the game dynamics are now set such that the player avoids enemy fire at all costs and shifts left and right to collect, dodge and shoot. So much so that you could pretty much remove the road and backdrop and it’d play out like an old school shoot ’em up. 

I think the game is a huge amount of fun and faithful to the arcade game designer’s ethos of short, challenging and intense fun for your coin. Hopefully it will encourage a high percentage of replays!

Road Rage will find its way to the PlayStar Arcade in the next week or so.

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.

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

Jumpin’ Jasper – HTML5 SNES style platform game – development update

A considerable amount of work has gone in to Jumpin’ Jasper this last few days. I’m thrilled by the results of some intense pixelling. As always it’s the colour choices that end up defining the game and I think I got this one just right. Time will tell of course but I’m pretty sure this is the most complete game I’ve made yet using HTML5 tech.

I’ve made a conscious decision to shift towards a SNES art style. This is not a casual decision, it’s very much a direction I want to take my games in going forward. I think the market for HTML5 games is maturing quickly and in order to compete it’s vital that I step up the quality of my output. I enjoy the art as much as the coding and crafting these sprite-based retro games is very much a part of the thrill. Of course the research that goes in to coming up with the art style isn’t so bad either!

Jumpin' Jasper screenshot

So I’m definitely in to the closing stages with the game and am looking to tie up a few loose ends before I begin the lengthy testing process.
I have a few more features that have definitely crept in but they’re not huge and I’m happy to let them slip through the back door :)

Hopefully Jasper will prove to be a hit for me and I can build upon his character for future titles.

Jumpin’ Jasper – a new HTML5 platform game in development

I’ve been working hard on my new HTML5 platform game recently and have had a huge amount of fun creating sprites and some interesting monster AI. It was always my intention to use the game as a vehicle for another new character and I’m pleased to present to you my lovable baby squirrel Jasper :)

html5 game title

I think I’ll probably call his first game Jumpin’ Jasper since that’s pretty much what he spends most of his time doing. The title frame above is my current placeholder being used in the development.

I thought it may be interesting to share my design document. It contains a single sentence:

Cute, cartoony and full of bounce !

It does make me smile when I read that back. To hell with lengthy discussions on what goes where in a level or how a monster should behave. That stuff happens organically for me as I code and test. I think as a designer I just know when something feels right and I can only achieve that by repeatedly playing the game and tweaking the code.

Screenshot

There’s still a ton of work to do with the art. I envisaged some nicely detailed backdrops to each level so the blue gradient won’t be quite so stark. I’m currently aiming to use a kind of Lego approach so that I can create elements and re-assemble them to create some varying background images. It will be very much a fantasy setting.

The game is currently all about jumping around the platforms, riding moving platforms, avoiding spikes and monsters (including the pesky wasp and wasp sting!), bursting bonus ballons and collecting bonuses and hazelnuts. I’ve tried really hard to keep the game moving. I didn’t want the player scratching their head trying to decipher what to do next. I think it works. I’m also very pleased with the powerups available. I think they’re fun. Especially the power boots!

Hoping to finish the game in the next couple of weeks.

HTML5 platform game – progress update

Development on my platform game project is coming along nicely now. It’s always nice to break the back of the game’s “engine” and then settle down to tweaks and minor mods. For the most part just now I’m playing with numbers to get the best “feel” for the game.

HTML5 platform game

For example – initially I had the player’s character (a squirrel that I currently call Jasper) leap in to the air with a tap on the screen (or mouse click / Z or CTRL on keyboard) and fall at the same rate that he jumped. It looked great as the squirrel span quickly and then landed with a satisfying thud. But when I tested it on a mobile handset it was proving difficult to control the character. So I slowed the rate of descent and also reduced the spin speed as the squirrel descended. The result was and is equally as satisfying and much more fun to control.
I have to say that playing the game on the desktop with the keyboard is a lot of fun. It feels great and very responsive. But crucially on mobile it works extremely well. A fine balance.

My level editing suite allows me to drop features in pretty quick. The resulting JSON that is spat out is simply dropped in to the game transparently such that when I fire up the HTML it’s just there. This gives me the freedom to chop and change at will and more importantly it allows me to have a lot of fun creating levels.

I currently have 4 monsters all of which are mutated bugs of some kind. Two bugs crawl along the platforms, 1 spits acid and another drifts in and targets the squirrel if he’s hanging around too long on the level. Kind of like the saucer in Defender.

Using this same codebase I’ve already started designing a game similar in some respects to the excellent Metroid. I like the challenge of creating more sophisticated SNES style graphics. In fact there’s a lot of similarities between some SNES titles and my own art style. I’m not the world’s best pixeler but I do enjoy it.

I’m currently targetting the first week in December to complete this game and then I’ll go back to the cartoon space adventure starring my young intergalactic ranger Kyle Comet.

 

New HTML5 game for Christmas – Rocket Santa

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

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

Rocket Santa HTML5 Christmas Game Rocket Santa HTML5 Christmas Game

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

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

Artwork and development for Distant Orbit

I’ve been working hard to create the visuals for Distant Orbit this last week. I know how much I enjoy looking over other developer’s workstations so I thought I’d capture mine and post them up here.

Developing the home screen

Developing the home screen and some as-yet-unused alien motherships

Designing the alien worlds

Designing the alien worlds and their inhabitants

I’m still undecided on the use of cartoon aliens. I like them but I’m not sure if it’s right for this game.

The 2nd alien world in action

The 2nd alien world in action with a half completed “monument valley” style backdrop. I use a Wacom tablet and Photoshop to create the artwork. Initially I use a broad pencil – 5px in width – and then I go dotting with a 1px pencil to create the finer details.

An early rendering of the energy tower on Tranquis

An early rendering of the energy tower on Tranquis – planet #1. I wanted each planet to have its own theme and style. This is the first planet and I wanted it to feel quite welcoming with the blue hues. The snow-capped mountains seemed to work well here and I love the completely alien tower as it rises from the horizon.

%d bloggers like this: