Artist / Designer: Ben Everett (Asute)

Blog by Julian Scott

I have always loved the classic Sega arcade game OutRun, which was  released to a wowed audience back  in 1986. I don’t think there has been a better driving game made since then. It manages to create an incredible sensation of speed, and playing it requires a perfect combination of learning the tracks, and reacting to AI vehicles, as well as perfecting your control of the car’s handling capabilities.

I didn’t set out to make a copy of the classic, but instead to create an updated homage, incorporating some of the classic elements from the arcade game.

Prototype: Can Flash Handle It?

The original arcade game incorporated some incredible hardware for the time, enabling hundreds of massively scaled sprites to be drawn at 30fps. Over 20 years later can a compiled bytecode language come close?

I did some tests using the Flash BitmapData.Draw() command in AS3 to determine how the Flash internals handle sprite scaling.

I’ve been involved with writing lots of low level sprite software over the years in the computer games industry, so I knew there are a few different techniques which the Flash designers could have used. Some methods are optimized for up-scaling, others for down-scaling. From my tests it seems that Adobe have taken a balanced approach. Starting with a middle sized sprite and scaling up and down from that appears to yeild the best results.

I was fully prepared to store multiple versions of each sprite to aid rendering speed, but my benchmarks indicated that this was unnecessary.

PCs (and Macs) are all different though, so I’m sorry I can’t help it if Flash runs poorly on your particular machine!

Well, we can’t dump as many sprites on-screen as the dedicated hardware of the original. No surprise there. So we had to design with this in mind and spread out the roadside objects accordingly, while still maintaining an impression of speed.

The Road

OK, so Flash can just about handle it. So the next step was to work out how to recreate the famous Outrun road. This was a strange experience for me. I’ve spent much of the last 10-15 years writing ‘real’ 3d games and low-end polygon engines. Designing this road system was like stepping back in time to the days of the Megadrive to revisit the techniques we used back then.

The beauty of the original road, and one of the reasons why it’s better than many modern equivalents, is the fact that its 3D’ness is ‘faked’. Playing Outrun you can see that the roads are a physical impossibility. If you tried to model them in a 3D package you would find that the hills aren’t possible in real life! ‘Real’ 3D just won’t cut it!

The technique I use for actually rendering the road is top secret. It’s pretty quick, as there is no overdraw, although rendering the billboards and vehicles behind or in front of peaks in the road requires some fiddling!

The function is by no means optimum, and will be improved in the next version of the game (popularity permitting). Having said that, judging from my benchmarks it isn’t actually the bottleneck in rendering speed. the slowest part is actually the rendering of the billboards. That’s handled internally in Flash, so there’s very little I can do about it.

Laying Out the Levels

Even though visibly the road is very hilly and windy, it is defined logically as a straight line. Parts of the track are given attributes such as rate-of-change in the X and Y axes; X describing the turns, and Y describing the hills. I defined bends in the track by specifying a start point, end point, and rate of change over that area.

For example to desctibe a bend from z position 1000 to 3000, with a maximum turn rate of 2 units I would use a command like this:

Bend( 1000,2000, 2);

Overlaying a series of commands like this make it very easy to create long interesting roads.

Many other road details are specified in the same way; including billboards, road surface types, AI vehicle density, edge details, sound types, checkpoints, etc.

In actual fact, I use XML to describe the road layout, using something similar to this:

<road>

<hill start=”1000″ length=”2000″ rate=”2″ />

<bend start=”2000″ length=”3000″ rate=”-2″ />

My system allows the XML file to be reloaded on the fly, so tweaking the road involves editing the file and pressing a key in-game to reload it. Therefore any changes can be viewed instantly, and iteration time on level design is reduced significantly from storing the data directly in code and recompiling each time.

Side note: You would be surprised and amazed how many ‘professional’ and very well known console game companies completely fail to grasp this sort of technique, and in doing so throw enormous amounts of money down the drain during the game design process.

Ben created a rough drawing of each level on paper, almost as a schematic, so that he could make each track work as a whole, with nice varying segments to maintain interest. He then re-created the design in text commands in the XML file, adding new billboards and road textures in to Flash as and when necessary.

We weren’t sure how many levels to make, but 10 seemed like a good number as this enabled us to borrow the branching nature of the original Outrun track design.

To me this branching design is the perfect system for this sort of game. The player gets to make decisions, and can work out for themselves which route to take for a fast time, as well as offering the incentive of seeing the different end animations, one for each route.

Potential sponsors persuaded us that this sort of branching design isn’t really suitable for today’s flash gaming audience, so as a comprimise we added in the ability to restart the game at any previously reached level. One thing we kept is this: the ability to submit a high score is only available if you play the game from the beginning.

Personally speaking, I feel that this is a shame, as it dilutes the experience, but it’s an acceptible compromise. Are we here to give the audience what we want, or to give them what they want? It’s a bit of each, I think.

No game these days is complete without Achievements. We added these, and for simplicity linked them directly to vehicle upgrades. It’s possible to complete the levels without getting achievements, but the player will need a lot of upgrades to get a good score.

Graphics

We wanted to retain the look of the mid-80s. Ben built the vehicles and roadside objects in 3D, and rendered them out to bitmaps suitable for importing in to Flash. Vehicles were rendered from multiple angles, so that we could give the impression of turning and going up and down over hills. The player’s car has more frames than the other vechicles because it’s the primary focus. It is also stored in a less compressed state than the other objects in the game. Most objects move so quickly past you that we were able to store them with fairly high Jpeg compression, freeing up valuable file space.

Controls

The biggest difference between arcade games like Outrun and their Flash equivalents is actually the controls. We can’t reproduce the analogue steering wheel and accelerator and brake pedals from the arcade, so the vehicle control has to change somewhat. We only have digital keys to deal with.

I used the trie and tested aproach for steering which is effectively to tuen the steering wheel when the left or fight keys are pressed, but to turn it faster the nearer it is to being straight. The movement decelerates as the wheel reaches the extremities of its turn.

The accelerator and brake work similarly.

The car’s engine has a very steep curve defining its acceleration. It can reach 90% of its top speed fairly quickly but from there takes a long time to reach 100%. this works well gamepay-wise because the player is rewarded for keeping the accelerator pedal down for as long as possible, hopefully encouraging risk taking round the long sweeping bends.

Turbo

When developing our last major driving game, Drift Runners, we added a turbo to the vehicle, but removed it (amongst other things) as we felt it was an unneccesary addition. We found the complaints about the lack of Turbo quite amusing. But we felt that the addition of a Turbo to Heat Rush would add something. We worked hard to make it a useful feature, and I think we succeeded.

Using the Turbo drastically increases the players’ speed for a short time, increasing their chances of crashing, so it’s up to the player to decide when best to use it. (Round a series of tight curves is probably a bad idea!)

We added a simple blur effect when the turbo is in operation to enhance the feeling of out-of-control speed.

Reception

The game received a low score on both Kongregate and Newgrounds. We were quite surprised by this, I have to say. though it was viewed by only a couple of thousand players on ecah site. We know from experience that only a small percentage of voters on Newgrounds actually play the game, so we don’t consider the score to be particularly meaningful.

Even without a decent score the game was picked up by a large number of portals and reached a million plays within a few days.

It has now done around nine million plays in two months. We’re happy with the figures. they mean that a sequel will be forthcoming, and further developments in driving games are worthwhile for us. We’re looking forward to pushing both the technology in new (and old) directions.

CycloManiacs is the most recent release from LongAnimals and RobotJAM

It was sponsored by the nice guys over at Kongregate, after getting quite a lot of attention from other sponsors.

RobotJAM and I always have a lot of trouble between games deciding what to do next. We had noticed that moto-cross games seem to be pretty popular, so we thought we’d knock a quick one up in a week or so just to see actually how many plays they generate. We’d done KCA Rush for Addicting Games, but that was a contract job, so we couldn’t really put much of our own gameplay in to it.

KCA Rush from Addicting Games

I’m not quite sure what happened though, because the next thing we knew, the game now had 20 different riders, 26 levels, and 70 achievements to unlock. This isn’t exactly what we had in mind to begin with.

CycloManiacs Level 1

In the beginning we weren’t sure what kind of game it was going to be, whether it was a race, time trial, or indeed a dirt bike game.

I built an editor in which to place objects to define the surface.  In very early versions we defined surfaces from sprites with fixed-angle surfaces so that we could place them together easier. We also had some girders (some of these made it through to the final game). The look of the road surface was originally going to be monochrome.

I got the rudimentary bike physics working very quickly, and Rob supplied a graphic of a creature on a bike to supplant my programmer-art. Then we spent some time trying to build tracks.

This didn’t go well at all. The editor was fiddly to use, and even with the ability to snap objects together it was a slow process. And furthermore it was difficult to get the collision joining up correctly with rotated objects.

Rob then had the idea of defining a floor section instead of making the track out of ‘bricks’. So I added this to the editor and knocked a few tracks up. The difference was amazing. The tracks worked so much better, and the time taken to create a level went down drastically. We combined this with overlaid objects (like ramps, girders, and rocks) to make interesting levels.

Picking objects from the Library

… 

Laying down trees

With the track editor now worked out, this led us away from doing dirtbike-type levels and on to faster race levels, as we could make the longer tracks with ease. However we decided to keep both types of tracks in for variety, but to concentrate more on racing.

We started thinking about how the AI would work, and it didn’t take too long to decide upon recording ourselves playing the levels and playing that back, with variations, for the AI. I wrote a quick recorder to check this out, and it turned out to be really nice with a few bikes on screen. (even though they were all the same) Quite a change from the usual dirt-bike game.

So after this became a definite feature, we both got more excited about the game, as we began to see it’s potential. Rob decided that cycles would be more fun than motorbikes (how right he was) and came up with a new design for RobotJAM riding a bike.

The flash movieclips for this are made from multiple parts. Two wheels, a bike frame, incorporating legs, and an upper body with leaning animation. This is so that we could lean forward and back independantly of the speed of the legs cycling movement. The wheels are added on as separate physics objects.

RobotJAM character in pieces

So now we had a rider and a track. What next? We decided to make a few cute characters on different bikes. The differences between the cycles would allow them to have different physical attributes, therefore different handling properties. We were excited by this as we thought it would open up the structure of the game. It would allow players to experiment with a variety of bikes to find the ones they like, and it would also allow us to be more free with the level design, pushing the faster and rockier courses.

Rob set off making a bunch of characters, and I got on with some level design tests. Because it was extremely quick to make courses, we soon had around 10-15 test levels in place. I tried to make all the variations I could think of. Long and straight, bumpy, big hills, uphill, downhill, rocky, etc.

With these levels in place I could start to tweak the bike physics to match the surroundings. Initially we had the gravity settings way too low; everything was rather floaty. I doubled the strength of the gravity and suddenly it started to play a lot better. The bikes spent more time on the ground.

Rob presented a great set of characters and I built the system to handle mutiple player bikes, so that we could try them all out, and sure enough, the handling was different on each one. We had Elvis on a chopper, who was very good at wheelies, and a helmeted rider on a racing bike who was good at fast speeds.

As it worked so well Rob went off and got carried away making loads of new characters in record time, and I got on with the gameplay. We were both really enjoying this.

I tried a few systems out for increasing player attributes and giving turbo boost etc. In the end we went for the idea of doing stunts to build up boost. This went through a few iterations, and required a lot of tweaking, but we were very happy with the result.

The player gains stunt points for doing wheelies, getting air time, and doing somersaults in the air. These were all balanced against each other so that the more difficult and risky ones were generally more rewarding.

This is a standard gameplay trait that I’ve used for many years. Any player should be able to have fun, but those who want to take more risks should be rewarded for their efforts. In this game you’re constantly faced with decisions whether to do one more forward roll, or that extra bit of wheelie.

The next bunch of characters included a couple of odd bikes with front wheels larger than the back wheels, so I added another stunt to the mix – front wheel wheelies.

We got to thinking about level structure, and pretty well agreed from the start to have five worlds each containing a number of levels. Rob came up with Dunes, Outlands, Volcania, City, and Lunaria, and started knocking up parallax scrolling backgrounds for each.

We decided to have one static layer and two layers of parallax looping backgrounds for each level to give it some nice depth.

The five main world backgrounds

Flash can handle multiple parallax layers pretty well. The two furthest backgrounds are drawn by blitting a large bitmap, which in Flash is very fast, while the nearest layer uses the Flash polygon-draw commands. incedental sprites such as cactii or rocks are placed on top of that.