We just released a Feb. 5 '89 prototype of DuckTales for the NES!
If you'd like to support our preservation efforts (and this wasn't cheap), please consider donating or supporting us on Patreon. Thank you!

Driven (GameCube)

From The Cutting Room Floor
Jump to navigation Jump to search

Title Screen

Driven

Developers: BAM! Studios Europe
Publisher: BAM! Entertainment
Platform: GameCube
Released in US: March 30, 2002
Released in EU: May 3, 2002


DevTextIcon.png This game has hidden development-related text.
GraphicsIcon.png This game has unused graphics.
ModelsIcon.png This game has unused models.
SoundIcon.png This game has unused sounds.
DebugIcon.png This game has debugging material.


For some reason, someone thought it would be a good idea to make a racing game based on the Sylvester Stallone flop of the same name. It's about as good as you'd expect, with CART Fury actually doing the job better (the movie being based on the CART FedEx Championship Series).

Hmmm...
To do:
Practically everything in this game, from the RenderWare models to the textures are all uncompressed and most of the code is in simple INI files; there's bound to be something in there.

Unused Batch Files

Located in the root folder of the disc are five batch files named CheckBinaries.bat, CheckFolder.bat, CleanBinaries.bat, CleanFolder.bat, and MakeWriteable.bat. The files themselves provide descriptions of what they're supposed to do.

CheckBinaries

@echo off
rem ---------------------------------------------
rem  Go into each track directory and remove any
rem  binary files that need to be re-calculated
rem  when a new build is done
rem ---------------------------------------------

call CheckFolder Arizona
call CheckFolder Californ
call CheckFolder England
call CheckFolder Germany
call CheckFolder NY_Day
call CheckFolder NY_Night
call CheckFolder ParisDay
call CheckFolder ParisNgt
echo:

CheckFolder

@echo off
rem ---------------------------------------------
rem  Go into each track directory and remove any
rem  binary files that need to be re-calculated
rem  when a new build is done
rem ---------------------------------------------

if "%1"=="" goto noname
if not exist "%1"\nul goto error

cd %1
if not exist CollGrid.bin echo CollGrid.bin missing from %1
cd models
if not exist track.bin echo track.bin   missing from %1
if not exist track2p.bin echo track2p.bin missing from %1
if not exist trkcol.cmp echo trkcol.cmp  missing from %1
cd..
cd Tex
if not exist level.txd echo level.txd   missing from %1
if not exist level2p.txd echo level2p.txd missing from %1
cd..
cd..
goto end

:noname
@echo:
@echo ERROR: No directory name was specified
goto end

:error
@echo:
@echo ERROR: Directory %1 does not exist

:end

ClearBinaries and ClearFolder say more or less the exact same thing.

MakeWriteable

@echo off
echo:
echo Making all files in GameDataWorking writeable
echo:
cd\Projects\DrivenGCN\GameDataWorking
attrib -r *.* /s
echo Deleting all VSSVER.SCC files (SourceSafe files)
echo:
zap vssver.scc /r
echo:
echo DONE!
echo:

Debug Notes

Hmmm...
To do:
See if anything works.

Also present in the root folder is a file named Debug.cfg, which contains notes on debug features. Note that it still refers to the PlayStation 2 version (which was released first), as well as the humorously-named feature "#ActivateCarTrackAndChampionshipCheatsForTomBecauseHeIsALazyGit".


////////////////////////////////////////////////////////////////////
//                                                                //
// Configuration file for the PlayStation2 DEBUG build of Driven. //
//                                                                //
// The settings in this file are read in, stored and accessed by  //
// the ConfigFile class. This uses the FileHandler class along    //
// with its overloaded ReadParam() functions to read in the       //
// settings. Therefore, configuration setting paramater names     //
// should be at the start of a line and preceded by a hash (#).   //
// Refer to the comments for the FileHandler class for more       //
// details.                                                       //
////////////////////////////////////////////////////////////////////

#PreviewDemo		false

#CreateDataFiles	false

#ReadTrackBinary		false

#ReadTextureDictionary	false
#WriteTextureDictionary	false
#UsePAK			false

#StartUpLevel		californ	
#CarEnvMapShininess	0.37

#DisplayTimerBars		false
#TimerBarFrameRes		2

#ShowSplashScreens	true
#ShowFrontend		true
#ShowHUD			true
#DebugFrontend		false

#RollingDemoOn			true
#RollingDemoInitialTimeout	60
#RollingDemoRunningTimeout	10
#RollingDemoDuration		45

#ActivateCarTrackAndChampionshipCheatsForTomBecauseHeIsALazyGit		true

#RecordZoneTimes		false

#WriteOutTelemetry	false
#PlayBackTelemetry	false

#GenerateCollisionGrid	false

#AllowCameraSwitching 	true
#AllowFrameAdvance	false

#PlayIntroMovie         true

#PlayAudio		true
#AudioFilter	true
#Music		true

#MotionBlur		true
#MotionBlurColour	255	255	255

#CarsInVisibilitySystem	true
#TrackSpritesInVisibilitySystem	true

#ScreenClearDebug	false
#VisibilityDebug	false

#ViewTextureCache false

#WriteCarBinary		false
#WriteTrafficBinary	false
#WriteFontBinary		false
#DebugMemoryHeap		false

#WriteCATFiles		false
#WriteDebugLogs		false
	
// NOTE: The FileHandler class currently cannot handle the case where
// a parameter value is at the very end of the file - so put all your
// configuration parameters before this comment.

There is also a file called Release.cfg, which is identical to Debug.cfg, save for referring to it as the "RELEASE build".

Both of these files have duplicates named Copy of Debug.cfg and Copy of Release.cfg, respectively.

Developer's Notes

A majority of the game's scripts are stored as simple INI text files, which means they contain a lot of (typo-laden) developer's notes. While there's too much to fully document, here are the interesting bits:

Filename(s) Text Notes
ai/chars.ini Purpose: Gives the different AI characteristics for the car models. This file controls the behavior of CPU cars, which are split into four categories: "Aggression", "Blocking", "Mistakes", and "Revenge".
[track name]/ai/catchup.ini Purpose: Gives catchup parameters used by RaceManager to 'manage' the AI cars during a race. Also contains multiplayer catchup parameters, which only affect human player cars. This file controls the game's rubber-banding.
car/physics/ability.ini NOTE: Currently, the values in this file will be ignored if the UseAbilityParams paramater in defcar.ini and aidefcar.ini is set to false. This file sets the values for each car's performance.
These set the maximum allowable values for each ability. Thus, a car with one of these values for a particular ability will have the best possible physical characteristics associated with the anility.
These specifiy whether to map the worst physical characteristics for each ability to correspond to the lowest value found for that ability or to assume that a value of 1 produces the worst physical performance. This is useful when the desired worst physical performance is known (the lowest top speed, say) but we don't want this to correspond to an ability value of 1, as this might make the car "look" too crap if these values are used for displaying the cars' characteristics in the game menus. For some reason they go very in-depth about the worst possible performance a car can have.
car/physics/ag0phys.ini and defcar.ini RICK: This specifies the offset of the centre of mass with respect to the rendered model origin. This is normally read from CarGeom.ini or aiCarGeo.ini, but I've temporarily placed it here because I want to be able to specify a different COM for each car model whilst we're tweaking the handling. Therefore, the final version of the game won't read this value. Notes about the model geometry. It is currently unknown who "Rick" is.
car/physics/ag0phys.ini, aidefcar.ini, and defcar.ini These values should be more accurate, but I've not sorted out what their interaction with the shift in the COM is all about... This message is placed before the values for the size (width/height/length) of the model.
These are multipliers for various aspects of the physical vehicle model (hence, a modifier value of 1 leaves the default value unchanged). They are scaled by the m_fSpecialModifierAmount parameter (which has legal values between 0 and 1, inclusive) to allow the vehicle's properties and aspects of the handling to be modified in a coherent way during the game. This is listed before various "special modifiers".
car/physics/aiCarGeo.ini These "ranges" are the volume of the car's body space corresponding to some event (typically a collision) that the game might use to trigger something (such as detaching a body part due to a big collision, or generating sparks, etc). Notes about car collisions. Riveting! Several of the following notes also appear in CarGeom.ini
This is pretty crude at the moment, since each zone is a cuboid, but that does have the advantage of being cheap to implement in terms of both memory and exectution time. Hopefully, this approach will be good enough for this game.
I've made this "artificially" low because the wing contact point is sometimes getting set at a lower position than expected when it hits a wall, at least. I'm not sure why, though it's probably just due to innaccuracies in the OBB-Poly collision detection This is listed under a heading for "Modern Car Zone Data". Several other sections are split into "Modern Car" and "Vintage Car" headings, so it likely refers to the different car models.
This data takes the form:
  1. <CarModelName>
  1. <FirstCarZone> R-value G-value B-value A-value ncp nbp
  1. <SecondCarZone> R-value G-value B-value A-value ncp nbp

etc

  1. <LastCarZone> R-value G-value B-value A-value ncp nbp

where ncp and nbp are the number of coloured (i.e., with the specified RGBA values) and black particles to emit per emission event.

Notes about particle effects.
Each car model that is loaded in the game must have a <CarModelName> entry. Only zones that are used (see above) need to have RGBA entries. Each RGBA value must be an integer between 0 and 255, inclusive. Note that the zones must be ordered as in the ECarZone enum.
The shadow data for the "modern" cars, i.e., all those except Joe's vintage model. NOTE: This data assumes the car body shadow will be made up of two individual shadows, one each for the left and right sides of the car. It also assumes that the same right sided texture is used for each side, with the U values switched for the car's left side. Finally, it is assumed that the texture actually includes 4 (half car) images, or "states", which cover the different states of suspension loss. Hence all the U values specified here only cover the range 0.0 to 0.25. Notes about car shadows, elaborating on the aforementioned "Modern" and "Vintage" classifications.
The "TopLeft", etc, refers to a corner of the texture, and the two parameters specify the (x,z) coordinates, in car body space, that that corner should be mapped to. They should definitely not be confused with left/right and front/rear car body coordinates, since the image of the car in the (mask) bitmap may be oriented any old how.
The shadow data for Joe's vintage car. This car doesn't have detachable wings or suspension. However, I've left the data in the "4 half car images per texture" form so that it's compitible with the code without having to restort to too many special cases. It would be more efficient in terms of texture size and rendering speed to just use a bitmap with a single half car, but I don't have time to set that up at the moment.
********** NOTE **********

These are currently the same values as for the modern cars. I don't know the appropriate values for the vintage car yet.

car/physics/aidefcar.ini Indicates whether (some) of the parameters below use the "car ability" system - see CarManager.cpp/h and DriveTrain.cpp/h for details. NOTE: This value should be left set to true since I've not set the code up to safely handle files with parameters set for both the new ability and original (non-ability) approach. If you want the original system you'll have to use a separate file. Seems to refer to car abilities relating to their physics.
(various files containing hand in the title) Sensitivity of the Dualshock mushroom in LINEAR mode An... interesting name for the PS2 controller, to say the least.
car/physics/CarSleep.ini Parameters used by each car when deciding whether it should be "asleep" or not. Presumably meant for when the cars are to remain static.
(multiple files) NOTE: The FileHandler class currently cannot handle the case where a parameter value is at the very end of the file - so put all your configuration parameters before this comment. This message appears at the end of several different files.
Watch out for the FileHandler end of file bug! This similar message appears at the end of some of the smaller files, mostly those relating to the courses.
[track name]/CollMods.ini The FileHandler "end of file" bug might still be around... Presumably the developers were able to fix the issue with FileHandler. That, or they developed a sense of humor about it.

Unused Models

ShadeTst.DFF

DrivenGC ShadeTst.png

Located in car/mdls is this unfinished model of a car. Judging from the name, it might have been used to test the game's shaders.

Unused graphics

NotFound.bmp

DrivenGC NotFound.png

Located in the root folder is this picture of a skull, likely used as a placeholder judging from the name.

zone.psd

DrivenGC ZonePSD.png

In SpecEffx/Zone, there is a Photoshop PSD file for (presumably) the "In the Zone" effect likely left in by mistake. It can still be read by Photoshop and opened like any other PSD.

Track Export Settings

That crust is thicker than the Earth's core.

The Models/max folder of each track (except for Arizona, NY_Day, and NY_Night) contains a (very badly compressed) JPEG image showing the rendering settings. While they're slightly different for each track, they're otherwise largely identical. The "Californ" folder contains a second image for the 2-player version of the track, while the one for England is misspelled as "Settiings".

Unused(?) Sounds(??)

Hmmm...
To do:
Figure out if this is actually unused, or if it's not actually supposed to sound like that. If it's the latter, then re-upload.

Loud sound warning! Located in AUDIO/SFX/raw are three WAV files named Copy of rev9, rev9, and rev9old, though they all emit an identical harsh buzzing noise. Given there's a folder in SFX/cmp named "Rev", it might be an unused sound of an engine revving.

Misc.

ZAP.EXE

Hmmm...
To do:
Figure out what this does - it won't run on my computer.

Located in the root folder is a mysterious executable named "ZAP.EXE". It is currently unknown what it is for.

"Exclude" files

Numerous folders contain an INI file named exclude.ini, which is (presumably) a list of folders/files that should not be loaded by the game.