Race'n'Chase game design
Race'n'Chase game design, version 1.05
March 22, 1995
© 1995 DMA Design Ltd.
This document specifies a design for the gameplay of a game with the provisional title "Race'n'Chase". It is based on elements discusses in various meetings held since 23rd January 1995 and involving Dave Jones, Mike Dailly Robert Parsons, Stewart Graham, Steve Hammond, Chink, Oz, Keith Hamilton and David Kivlin. This document is intended to be read by programmers, artists and producers involved in the design, implementation and testing of Race'n'Chase.
The DOS version will use a DOS extender so that it can use the 32-bit flat memory model. It will require 4MB of RAM. This limit may have to be raised to 8MB to accommodate all of the graphics which will be required. The game will run in either SVGA mode 10th (640 x 480) or VGA mode 13th (320 x 200). Both models use 256 colours from an 18-bit palette. A very fast processor (e.g. Pentium) will be recommended for the SVGA mode.
The 32-bit Windows version will require 8MB of RAM. It will use 8-bit or 16-bit graphics, depending on the card fitted. Both PC versions of the game will be supplied on one CD-ROM. There will be no floppy version.
Development system and software
Race'n'Chase will use the overhead perspective engine developed by Mike Dailly. The DOS version will be developed using Watcom C/C++ v10, Microsoft MASM 6.1 and Rational Systems DOS extender (DOS4GW) v1.97. The Windows 95 version will be developed using Visual C++ v2.0.
The aim of Race'n'Chase is to produce a fun, addictive and fast multiplayer car racing and crashing game which uses a novel graphics method.
The game will be set in a present-day world.
There will be three cities with a different graphic style for each city (e.g. New York, Venice, Miami). There will be many different missions to be played in each city. This is so that players can get to know the routes through a particular city.
In each game type, it will be possible to progress to different cities only when certain goals have been attained.
The PC game will be playable by multiplayer across a network or by one player at a standalone machine. Console versions will allow two players at one machine. This facility may be added to PCs.
Players will be able to drive cars and possibly other vehicles such as boats, helicopters or lorries. Cars can be stolen, raced, collided, crashed (ramraiding?) and have to be navigated about a large map. It will also be possible for players to get out of their car and steal another one. This will mean controlling a vulnerable pedestrian for a short time. Trying to steal a car may result in a alarm being set off which will, of course, attract the police.
The objective of the game will vary depending on the game type. The player can choose to play one of four different games:
This is a straight race across the city where the winner is the first player to drive from 'A' to 'B', taking any route. Best times could be saved. Pole positions could be set depending on each players best time round a practice route.
Computer-controlled cars could be included in the race. Progressing to the next level would require finishing ahead of the computer cars.
The players can drive anywhere in the city. The aim is to cause damage to the other cars by crashing into them. The winner is the driver who survives the longest.
Alternatively, players whose cars get wrecked could get a new car back at the start, so the winner is the player who wrecks the most enemy cars.
Bank Robbery (Robber)
The player drives a getaway car and must escape from the police by reaching a particular location (e.g. cross safe line or get to safe house). There will be many different missions available - with varying start point, end point, police presence, etc.
When enough crimes have been completed, the player can move on to a different city. The robber's game is up when he gets killed or is captured by the police.
Bank Robbery (Cop)
The player controls a police car and must stop a getaway car from escaping. Other police cars are controlled by the computer or by other network players.
The landscape will be viewed from directly above, with perspective. Different scenes are possible, e.g. urban, countryside, seaside, etc. The landscape will be built from 64 x 64 x 64 pixel blocks, which are drawn with a texture map for each visible face. Some faces will be animated. Some faces will be transparent.
The screen will scroll left/right/up/down as the player's vehicle moves so that it is approximately centred. The screen will not tilt or rotate, but it will be possible to zoom in and out. The screen will zoom to different levels automatically depending on the action. For example, it could zoom out as the car drives faster, or zoom in to show a crash in more detail. At maximum zoom in, individual people will be clearly visible. The maximum zoom out which is practical will depend on the speed of the PC.
A reduced detail mode will be included for PCs which are not fast enough to display the whole perspective view. In this mode, the sides of building will not be drawn and the tops will be drawn on the ground. This will result in a landscape looking like something like the original Sim City.
The perspective landscape must be drawn as fast as possible. Looping versus repetition for line draws is being investigated.
Objects (e.g. cars) will be drawn using come scaled and rotated sprites (see below for more details). Each will be around 64 x 64 pixels. Cars will always be seen from above.
All object graphics will be based on rendered models
There will be around twenty different cars per style.
Overlaid on top of the landscape view will be the instruments of the current car. These will include:
- Rev counter
- Damage meter
Miniature pop-up windows could appear occasionally to show animations of what is happening, e.g. arrest being made, car being wrecked.
Different weather effects will be investigated, for example:
- Snow (swirling effect white pixels)
- Thunder and lightning (flash screen, darken palette)
As the light source is directly overhead, rotation can be done in software. This means storing only three frames per car (the up/down rotation). Deltas will be drawn onto the car sprites to show additional detail, such as brake lights, police lights, damage.
Some form of compression will be used to store the world data. This should aim to produce a world which takes at least two minutes to drive across but which can be held entirely in memory. This may mean around 256 x 256 x 6 blocks.
Buffer loading could still be used, but only for major change, e.g. crossing into a different state.
- Store 2-byte pointer for each block, instead of five faces and type
- Store 2-byte pointer for each column (no bridges then)
- Store blocks run length encoded upwards.
These compression methods will be investigated.
Landscape face graphics will require: Bytes per face: 64 x 64 Faces per style: 255 Total: 1,044,480 bytes
Code space will amount to 1MB.
Space for sound (samples, etc.) will amount to 1MB.
The playing world will be very, very large - multiple screens. There will be a number of clear landmarks to ease navigation. A large printed map will be supplied as part of the package. It will be necessary to refer to this during gameplay. Usage of the pause key may be restricted so that players cannot keep pausing the game to look at the map. Instead, they must park somewhere to stop and look at the map.
The landscape will consist of:
- Roads (small roads and freeways)
- Water hazards
The landscape is not fixed, and can be altered by player actions. The landscape will include a number of levels so that, e.g., a road could be on a bridge across another road. This means that slopes will be necessary to get from one level to another. The landscape will be, in a city, highly populated: there will be lots of incidental things to see like traffic, pedestrians, etc.
Roads will be constructed using a map editor from a number of fixed pieces, e.g. corners, junctions, straights, etc. Lanes will be one block wide.
Pedestrians will normally walk on pavement blocks. Cars can drive on road or pavement. Pavements will be one block wide.
Buildings will be constructed from cube-shaped blocks but can be any shape. It will be possible for cars to cause damage to buildings when they crash - e.g. plate glass window on side of building is seen to smash.
Types of ground will include:
Objects which can appear include:
- Road blocks
- Road signs
- Traffic lights
- Inanimate objects, e.g. bins
There will be player controlled cars, intelligent other cars, and simple drone cars. It will be possible for cars to sustain damage and continue. The damage will be shown by the car slowing down, wobbling, pulling to one side, or emitting smoke. It could also be shown by damage deltas drawn onto the car sprite.
If a player-controlled car has a serious crash, it will blow up after a short time. Hence, the player must get out of the car and find another one.\
Cars will not run out of fuel.
Intelligent cars will be able to navigate themselves about the city, plotting the shortest route to another car or to a particular location.
Lorries will be treated as a separate car and trailer, where the trailer just has to always follow the cab.
Pedestrians will be wandering about all of the time. They can be run over by cars. They will tend to walk on pavements. Types of pedestrians could include:
- Schoolchildren and lollipop lady
The police will communicate with each other by means of radio messages which the player will hear as sampled speech complete with radio crackles.
Getaway drivers will have a scanner which is tuned into these police broadcasts. Messages will be of the form "X seen on Y street" and will be sent to all other police cars when the robbers are spotted. The printed map will have to be used to see where the street in question is.
The police will be able to get out of their cars and shoot at the robbers.
The game will be controlled by mouse or keyboard.
When using direct control (i.e. when driving one car), the controls will be:
- Turn left
- Turn right
- Change gear - forward/reverse
- Sound horn
- Get in/out car
The radio-control car method will be used, i.e. directions are always relative to the car. The steering will auto-centre. That is, it will tend to turn back towards straight ahead. The amount of turn will increase as the steering key is pressed. A handling method must be developed which will permit the player to perform stunts with the car such as handbrake turns, spinning wheels, etc.
The Thrustmaster steering wheel, and possible other devices, will be supported.
An indirect control method (using mouse to co-ordinate various intelligent cars) can be added to the game at a later stage if necessary.
There will be a pre-drawn/rendered animated introduction to the game.
The game will use a simple menu system, as in Doom, for selecting options.
The editor used for Race'n'Chase will produce a 3D array which can be used by both the perspective and isometric engines, so that it can also be used for other games. It will consist of a grid editor which is used to place blocks on a grid, with a separate grid for each level. The editor will allow any block to be placed at any level. Each block can be assigned texture maps for up to five faces (top and four sides). A standard data format will be used to represent this.
|Keith H. and Robert P.
|Ultra 64 programming
|David K. and two others
|Chink and three others
|Official start date
|April 4, 1995
|Complete game design
|May 31, 1995
|Milestone 1 - Engine
|July 3, 1995
|Milestone 2 - Look and feel
|October 2, 1995
|Milestone 3 - 1st play
|January 3, 1996
|Milestone 4 - Alpha
|April 1, 1996
|End of project
|July 1, 1996
- Cityscape data structure
Version 3.10 - March 21, 1995 - DMA Design Ltd.
- Pedestrians in Race'n'Chase
Version 3.00 - March 14, 1995 - DMA Design Ltd.
- Vehicles in Race'n'Chase
Version 1.00 - March 14, 1995 - DMA Design Ltd.
- Traffic control in Race'n'Chase
Version 1.00 - March 15, 1995 - DMA Design Ltd.
- Screen display in Race'n'Chase
Version 1.00 - March 16, 1995 - DMA Design Ltd.
- Comms in Race'n'Chase
Version 1.00 - March 17, 1995 - DMA Design Ltd.
Document revision list
|K. R. Hamilton
|January 25, 1995
|K. R. Hamilton
|January 30, 1995
|Revision after meeting of 30/01/95
|K. R. Hamilton
|February 6, 1995
|Revision after meeting of 06/02/95
|K. R. Hamilton
|February 20, 1995
|Revision after meeting of 20/02/95
|K. R. Hamilton
|March 6, 1995
|Revision after meeting of 06/03/95
|K. R. Hamilton
|March 22, 1995
|Revision after meeting of 22/03/95
- Race_n_Chase1 - Scanned document posted at Flickr by Mike Dailly.