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.

Target system

Race'n'Chase will be produced for the following platforms: PC DOS, PC Windows 95, PlayStation, Saturn and Ultra 64. This document is primarily concerned with the PC versions.

DOS

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.

Windows 95

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.

Specification

Concept

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.

Setting

The game will be set in a present-day world.

Game structure

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.

Players

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.

Action

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.

Objective

The objective of the game will vary depending on the game type. The player can choose to play one of four different games:

Cannonball Run

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.

Demolition Derby

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.

Graphics

Landscape

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.

Reduced detail

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.

Optimised display

The perspective landscape must be drawn as fast as possible. Looping versus repetition for line draws is being investigated.

Objects

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.

Screen display

Dashboard

Overlaid on top of the landscape view will be the instruments of the current car. These will include:

• Speedometer
• Rev counter
• Damage meter

Pop-ups

Miniature pop-up windows could appear occasionally to show animations of what is happening, e.g. arrest being made, car being wrecked.

Weather

Different weather effects will be investigated, for example:

• Snow (swirling effect white pixels)
• Thunder and lightning (flash screen, darken palette)

Data storage

Car sprites

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.

Compressed world

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.

Compression ideas:

• 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.

Faces

Landscape face graphics will require: Bytes per face: 64 x 64 Faces per style: 255 Total: 1,044,480 bytes

Code

Code space will amount to 1MB.

Sound

Space for sound (samples, etc.) will amount to 1MB.

Gameplay

World

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.

Landscape

The landscape will consist of:

• Roads (small roads and freeways)
• Pavements
• Buildings
• Water hazards
• Bridges

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

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.

Pavement

Pedestrians will normally walk on pavement blocks. Cars can drive on road or pavement. Pavements will be one block wide.

Buildings

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.

Ground type

Types of ground will include:

• Road
• Pavement
• Water
• Building

Object types

Objects which can appear include:

• Cars
• Road blocks
• Road signs
• Traffic lights
• Pedestrians
• Inanimate objects, e.g. bins

Cars

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.

Car intelligence

Intelligent cars will be able to navigate themselves about the city, plotting the shortest route to another car or to a particular location.

Lorries

Lorries will be treated as a separate car and trailer, where the trailer just has to always follow the cab.

Pedestrians

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
• Dogs

Police

Communication

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.

Guns

The police will be able to get out of their cars and shoot at the robbers.

Control

The game will be controlled by mouse or keyboard.

Direct control

When using direct control (i.e. when driving one car), the controls will be:

• Accelerate
• Brake
• 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.

Hardware

The Thrustmaster steering wheel, and possible other devices, will be supported.

Indirect control

An indirect control method (using mouse to co-ordinate various intelligent cars) can be added to the game at a later stage if necessary.

Front end

Intro

There will be a pre-drawn/rendered animated introduction to the game.

Menus

The game will use a simple menu system, as in Doom, for selecting options.

Development tools

Editor

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.

Team

Project manager	Keith H.
PC programming	Keith H. and Robert P.
PS-X programming	Cameron R.
Saturn programming	TBA
Ultra 64 programming	TBA
Programming	David K. and two others
Art	Chink and three others
Design	Stewart G.
Producer	Dave

Time

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

References

1. Cityscape data structure
   Version 3.10 - March 21, 1995 - DMA Design Ltd.
2. Pedestrians in Race'n'Chase
   Version 3.00 - March 14, 1995 - DMA Design Ltd.
3. Vehicles in Race'n'Chase
   Version 1.00 - March 14, 1995 - DMA Design Ltd.
4. Traffic control in Race'n'Chase
   Version 1.00 - March 15, 1995 - DMA Design Ltd.
5. Screen display in Race'n'Chase
   Version 1.00 - March 16, 1995 - DMA Design Ltd.
6. Comms in Race'n'Chase
   Version 1.00 - March 17, 1995 - DMA Design Ltd.

Document revision list

Version	Author	Date	Comments
1.00	K. R. Hamilton	January 25, 1995	Initial version
1.01	K. R. Hamilton	January 30, 1995	Revision after meeting of 30/01/95
1.02	K. R. Hamilton	February 6, 1995	Revision after meeting of 06/02/95
1.03	K. R. Hamilton	February 20, 1995	Revision after meeting of 20/02/95
1.04	K. R. Hamilton	March 6, 1995	Revision after meeting of 06/03/95
1.05	K. R. Hamilton	March 22, 1995	Revision after meeting of 22/03/95

External links

• Race_n_Chase1 - Scanned document posted at Flickr by Mike Dailly.