Programmer / Designer: Julian Scott (LongAnimals)

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.