To be clear, we’re only going to be diving into the technical side of the game for this one, so if that’s not your sort of thing then hopefully the next article will be more to your satisfaction.

Also, got to point out, I am (unfortunately) human, I make mistakes and every day is a learning experience. Not to mention going over all this turned my brain into mushed peas. If I’ve made an error anywhere, let me know about it, so I can correct it, rather than immediately blasting me into orbit!

DVD Contents 📀

Okay, so let’s start getting our hands dirty.

I’d give you a complete listing of all the content as I’ve done before, but there’s a far too much for that, so we’ll just go over the things that matter.

I’m going to be looking at the final EU release of the game here, so SLES-51209 specifically. There is a pre-release build out there, from August 2002, which I’ve looked at too - but we’ll save more details about that for a future article. For now I’ll just reference it in passing where it makes sense to do so.

In the root directory of the ISO we can see the following.

Oct 14  2002 DATA           ; where the game data is stored
Oct 14  2002 DLL.DAT        ; package with a collection of .rel files
Sep 27  1999 DUMMY.DAT      ; null padding file
Oct 14  2002 SLES_512.09    ; main game executable
Oct 14  2002 SYS250         ; system libraries
Oct  9  2002 SYSTEM.CNF     ; typical PS2 config file

As indicated in my notes above, the DLL.DAT file is actually using a package format which we’ll need to deal with. Fortunately, unlike some other formats I’ve looked at of late, the filenames are not hashed. That said, they are stored in a rather unusual way, as we’ll find out. Nothing’s ever simple… 😒

As also indicated in my notes, the DUMMY.DAT file is used for nothing more than padding the DVD and contains nothing interesting. Given the modification timestamp on it, I’d guess this exact same file may have been used for padding in some of their other titles, heh.

Next looking under the DATA directory, we can see the following.

Oct 14  2002 BIN            ; contains content used for each of the planets in the game
Oct 14  2002 CSFX1          ; various sound effects using the common PS2 VAG format
Oct 14  2002 ENGLISH        ; english dialogue audio as PS2 VAG format
Oct 14  2002 FRENCH         ; ditto but for french
Oct 14  2002 GERMAN         ; ditto but for german
Oct 14  2002 GSFX1          ; various sound effects using the common PS2 VAG format
Oct 14  2002 HSFX1          ; various sound effects using the common PS2 VAG format
Oct 14  2002 HSFX2          ; various sound effects using the common PS2 VAG format
Oct 10  2002 INTRO_25.PSS   ; one of the pre-rendered cutscenes featured in the game
Oct 14  2002 ITALIAN        ; italian dialogue audio
Oct 14  2002 LSFX1          ; various sound effects using the common PS2 VAG format
Oct 14  2002 LSFX2          ; various sound effects using the common PS2 VAG format
Oct 14  2002 LSFX3          ; various sound effects using the common PS2 VAG format
Oct 14  2002 LSFX4          ; various sound effects using the common PS2 VAG format
Oct 14  2002 MUSIC          ; VAG music
Oct 14  2002 MUSIC2         ; VAG music
Oct 14  2002 MUSIC3         ; VAG music
Oct 14  2002 PSFX1          ; various sound effects using the common PS2 VAG format
Oct 14  2002 RWLDS.DAT      ; another package, this holding models, scripts and other data
Oct 14  2002 SPANISH        ; spanish dialogue audio
Oct 11  2002 VID_PAL.PSS    ; a making-of video, which curiously shows an older build of the game
Oct 14  2002 VSFX1          ; various sound effects using the common PS2 VAG format
Oct 14  2002 VSFX2          ; various sound effects using the common PS2 VAG format
Oct 14  2002 WSFX1          ; various sound effects using the common PS2 VAG format

Lots of audio! The VAG format is a common audio format used for PlayStation 2 games. You can find a handy tool to convert them to WAV here.

As I also indicated in the list above, the VID_PAL.PSS video is actually one of those “making of” videos titled “Beneath the Surface”. Anyway what’s rather curious about it is that it seems to show a build even older than the August 2002 build mentioned earlier, as the HUD has a different design.

An area shown in the video, which I’ve captured in the screenshot above, also appears to be the same starting area as the August 2002 build (with some of the same quirks), though we’ll talk about that more in a future piece.

We’ve also got yet another package, this time RWLDS.DAT. It’s much bigger than that last one we looked at, and seems to hold the bulk of the game data.

If you’re curious about its name, this is seemingly an abbreviation of “realworlds” which was possibly a working name for the game, or the technology. We’ll touch on it a little more soon.

Alright, next up we’ll have a look under the BIN directory before looking at the contents of the RWLDS.DAT package. “Bin” is a pretty classic vague name for a place to throw binary files.

Oct 14  2002 AURIA          ; folder for planet-specific data (see below)
Feb  8  2001 CUBE.BIN       ; ...
Oct 14  2002 EXARCO         ; folder for planet-specific data (see below)
Oct 14  2002 FERRA          ; folder for planet-specific data (see below)
Oct 14  2002 FERVEN         ; folder for planet-specific data (see below)
Sep  2  2002 MKSPACE.DAT    ; package containing .pnt (texture) files
Oct 14  2002 NEQUAM         ; folder for planet-specific data (see below)
Oct  8  2002 SYSTEM.RW3     ; some unknown data + planet textures

./AURIA:
Oct  8  2002 HEIGHTS.RW3    ; presumably height information for the planet terrain?
Aug  9  2002 NOISE.PNT      ; noise... :)
Oct  9  2002 PATCHES.RW3    ; unsure
Oct  9  2002 PLANET.RW3     ; some unknown data + planet textures
Oct  9  2002 TEX004.RW3     ; holds textures for the planet in specific sizes (4x4)
Oct  9  2002 TEX008.RW3     ; holds textures for the planet in specific sizes (8x8)
Oct  9  2002 TEX016.RW3     ; holds textures for the planet in specific sizes (16x16)
Oct  9  2002 TEX032.RW3     ; holds textures for the planet in specific sizes (32x32)
Oct  9  2002 TEX064.RW3     ; holds textures for the planet in specific sizes (64x64)
Oct  9  2002 TEX128.RW3     ; holds textures for the planet in specific sizes (128x128)
Oct  9  2002 TEXNDX.RW3     ; unsure

[As the types of files under each sub-dir are the same, I've ommitted the rest]

So as far as these immediate folders go, I think we’re done for now with that. Before we jump into anything else, let’s first take a quick look at the executable (SLES_512.09) which we saw in the initial root directory.

Disassembling 🔍

One of the first things I’ll typically check for are debug symbols, or at the least, symbol names, which can sometimes help the poking and prodding process.

It turned out that there’s an interesting quirk with the executable in this game; the main executable is actually just an unpacker, and the real executable is contained within, compressed.

They used RNC ProPack for the compression, for which TT’s Nu2 framework (often described as an engine, but I’d personally call it a framework) provides the methods for decompressing the contained executable into memory when the game launches. I’d ended up using this to decompress it.

You seemingly can make the game run just fine directly from the resulting executable once done, so besides providing an unpacking solution, it doesn’t seem that the main executable was doing anything else particularly special.

Why did they do this? I’ve got no idea. Originally I’d assumed it was some sort of crude anti-tamper method, but that doesn’t make any sense.

This allows us to open the resulting unpacked executable in Ghidra, a popular reverse engineering tool (well, with the necessary extensions.) Much to our joy, there are at least symbol names but nothing too extensive as far as debug data, but hey, better than nothing.

It’s rather interesting to see the structure of the project, which was broken up between the Nu2 libraries (such as nucore, nusound2, numath, nu3d, nups2, gamelib. mp2play, edtools and coblib), a library called realwlds and finally of course the game itself. The primary libraries, nu2 and realwlds, seem to be post-fixed with the target platform, so in this case .ps2 (for instance, ..\nu2.ps2\nu3d\nuscene.c and ..\realwlds.ps2\frcube.c).

The realwlds library seems to manage all the systems behind the planets and their terrain. In the credits, it seems to be referred to as the “Fractal Render Engine” and is credited to Richard Taylor and Alistair Crowe (the latter of whom appears to still work at Traveller’s Tales).

The fact that it’s developed into a separate library makes me wonder if there was perhaps an intention to use this technology for other titles. No doubt something that Haven’s sequel, which never materialised, would’ve retained.

And unsurprisingly all of this was written in C (queue song).

With Ghidra at our aid, there are a great many additional things we can discover. Such as a selection of command-line arguments that can be passed to the game!

But unfortunately these arguments are actually hardcoded in CD/DVD builds of the game (like the ones we have), however if you open the ELF in your favourite hex editor and go to address 0x507100, you can change at least a few of them to anything of your preference.

So for instance, in the PAL version of the game, there’s a pal argument which switches the game into a 50hz mode, but if you null it out, you’ll be able to run the PAL version at 60hz instead.

Or, if you null out startpoint, you’ll get a level select screen!

This is very similar to what you’ll see in the August build, only with a lot more options available.

Alternatively, if you leave the startpoint argument as is, the argument that proceeds it is actually the argument for startpoint, which by default is jp_startgame. You can change this to some hardcoded points such as sp_bonus8, to spawn at a point later in the game.

All the start points, however, are available via the level select screen, so I’d recommend just going with that instead.

With the ELF unpacked, we can also use it alongside PCSX2 to see all the globals available that we can tweak to our amusement.

So, as you can tell, this is just scratching the surface. I’ll leave the rest of that to someone with a lot more time on their hands though.

DAT Package Format 📦

So before we can get at anything else, we’ll need to figure out how everything is packaged.

I’m not going to lie, this one gave me a little bit of a headache.

First, within the package, the file table is stored at the end of the file rather than the start. This is followed by a table of null-terminated strings, which are the folder and filenames. The first four bytes of the package indicate the offset of the file table. There’s no filename hashing or compression, so that makes things very easy here.

Seems simple enough so far.

But there’s a catch (of course there is). Strings for each file are not handled quite in the way you might expect, and instead it’s organized as some sort of tree? For each entry in the string table, there’s an offset into the end of the file, where the strings are located, but then two 16-bit integers that seem to indicate the relationship per file and directory.

That basically gives us a structure like this. This is in the binary template format supported by REHex.

struct TTHavenDatHeader
{
	uint32_t tocOffset;
	uint32_t tocAllocSize;
};

struct TTHavenDatIndex
{
	uint32_t offset;
	uint32_t size;
	uint32_t compressedSize;
	uint32_t flags;
};

struct TTHavenDatTocHeader
{
	uint32_t unknown;
	uint32_t numFiles;
};

struct TTHavenDatHeader header;

FSeek( header.tocOffset );
struct TTHavenDatTocHeader 	tocHeader;
struct TTHavenDatIndex 		files[ tocHeader.numFiles ];

struct TTHavenDatTreeIndex
{
	uint32_t 	offset;
// these are awful...
	int16_t 	l;// if positive, followed by directory, next index before pop
	int16_t 	r;// if zero, indicates directory
};

uint32_t numTreeEntries;
uint32_t numB;

struct TTHavenDatTreeIndex tree[ numTreeEntries ];

I couldn’t quite figure it out but came up with something that seems to be good enough, but certainly isn’t anywhere close to how you’re supposed to be handling these.

Someone with a brain, unlike myself, could probably do a better job at figuring out the correct way to deal with this. Do let me know if you do!

	unsigned int dirDepth = 0;
	DirIndex dirStack[ STACK_SIZE ] = {};
	// i = 1 because first is an empty dir, indicating root, 
	// so we'll just skip for simplicity...
	for ( unsigned int i = 1; i < numStrings; ++i ) {
		// current string
		const char *c = &buf[ tree[ i ].offset ];

		// last string is a special weird case... meh
		if ( i < numStrings - 1 ) {
			// if r is zero, seems to be a directory
			if ( tree[ i ].r == 0 ) {
				dirStack[ dirDepth ].string = c;
				dirStack[ dirDepth ].index = i;
				dirDepth++;
				continue;
			}
		}

		// build up the string here based on stack ...

		// if r isn't equal to our index, and it's not zero, 
		// it's probably the index we want to pop back to
		if ( tree[ i ].r != i ) {
			for ( unsigned int j = 0; j < dirDepth; ++j ) {
				if ( dirStack[ j ].index == tree[ i ].r ) {
					dirDepth = j;
					break;
				}
			}
		}
	}

With that out of the way, we can pretty much get everything extracted from the package with a good majority of the filenames intact, as far as I can tell.

You can find my implementation of a loader for the format here, to give you a more complete idea if the above isn’t clear enough. Just mind it’s a bit of a mess, as it just needed to extract the packages to satisfy my own curiosity and nothing more.

So, the time has come! Tally-ho!

What’s that left us with? Hm, well with the RWLDS.DAT package extracted, let’s take a look.

There’s a lot here! Just what I like to see. 🤤

We’re not going to go over everything today, but let’s make a start taking a look around.

Game Flow 🌊

First, in the root directory, we’ve got a collection of .flo files. These are used for a number of things, from specifying areas of the game to load, transitions betweens areas of the game, cutscenes and more. Generally, they control various parts of the games flow, through commands. Probably hence the extension, flo.

Internally, perhaps unsurprisingly based on what I just said, this is referred to as the Game Flow.

Per haven.flo, which is the main script that’s loaded on startup, we’ve actually got some documentation on the various supported commands and what they do (and if it’s not obvious, a semicolon is interpreted as a comment).

;-----------------------------------------------------------------------------------------------
; Reserved System Commands;
;-----------------------------------------------------------------------------------------------
;
; Traditional Semaphore support
;
; AddSem    <sem> <val> <rng>   - 
; ResetSem  <sem>       	- state[sem] = 0
; SetSem    <sem> <val> 	- state[sem] = val
; SignalSem <sem>       	- state[sem] = state[sem] + 1
; WaitSem   <sem>		- while(state[sem] = 0); state[sem] = state[sem] - 1
; WaitSemMulti <sem0...sem31>   - for n=1 to numsem; if state[sem] != 0 state[sem] - 1, break; next
;
; Using Semaphores as crude variables
;
; WaitSemEQ <sem> <val>		- while(state[sem] != val);
; WaitSemLT <sem> <val>		- while(state[sem] >= val);      
; WaitSemGT <sem> <val>		- while(state[sem] <= val);      
; WaitSemNE <sem> <val>		- while(state[sem] == val);      
; IfSemEQ   <sem> <val> <lab>	- if (state[sem] = val)  pc = lab
; IfSemLT   <sem> <val> <lab>	- if (state[sem] < val)  pc = lab
; IfSemGT   <sem> <val> <lab>	- if (state[sem] > val)  pc = lab
; IfSemNE   <sem> <val> <lab>	- if (state[sem] != val) pc = lab
;
; Flow Control / Debugging
;
; GoTo	    <lab>       	- pc = lab
; GoSub	    <lab>		- stack[sp++] = pc; pc = lab
; Return			- pc = stack[--sp]
; Pop				- --sp
; PopAll			- sp = 0
; Break				- temporarily releases program flow 
; Halt				- suspends program flow indefinitely
; DebugMsg <message>		- type message to tty
; BeginGuard <name> <lab>       - if the named guard is set, jumps to label, otherwise sets the named guard
; EndGuard <name>               - clears the named guard
;
;-----------------------------------------------------------------------------------------------
; Haven Specific Commands;
;-----------------------------------------------------------------------------------------------
; --FRACTAL STUFF--
; RWInitLevel	<level>
; RWBuffer	<bufftype - HIGH/LOW> [<buffsize>] - omitting buffsize will cause either the current planets buffer size or the current size of the rw buffer to be used - set initlevel to 2 to release it
; RWPlanetMesh	<ON/OFF>
; RWPlanetRender<ON/OFF>
; RWProcessEnable <arg> - arg 0 - processing disabled, arg 1 - processing enabled, -ve - processing disabled in -ve frames
; RWTextures	<ON/OFF>
; RWDontRenderPlate <plateid or -1>
; SkyVisible <ON/OFF> - allows level with sky off to be overridden
; SeaVisible <ON/OFF> - allows level with sea off to be overridden
; RWSetPlanetTime <planet name> <time of day 0-24>
;
; --LEVCON STUFF--
; StopLogic	  <flags>   - stops internal logic from running - flags are a combination of WORLD ISLAND or LEVEL - no flags equates to all flags being present
; SyncLogic	  <flags>   - brings internal logic into sync with current state, allows logic to run if its been knocked out - flags are a combination of WORLD ISLAND or LEVEL - no flags equates to all flags being present
; ShowLevel	  <levname> - allows a loaded level to draw
; HideLevel	  <levname> - stops a level being drawn
; PreLoadLevel	  <levname> - loads a level without activating it
; LoadLevel	  <levname> - loads and activates a level (just activates if already loaded)
; PreLoadLevelNB  <levname> - loads a level without activating it - non blocking variant - script continues
; LoadIsland	  <islandname>
; LoadWorld	  <worldname>
; IfLevelProgress <levname> <bit ix> <label>
; IfNotLevelProgress <levname> <bit ix> <label>
; SetLevelProgress <levname> <bit ix>
; SetSpecialVis    <levname> <specialname> <ON/OFF> - sets the visibility state of the specified special object - setting is lost in the event of a reload
;
; --CONFLICTS--
; ResetConflict <conname> - calls the Reset() function of the conflict
; LoadConflict  <conname> - loads the named conflict
; DumpConflict  <conname> - requests the dumping of the named conflict
; DumpBuffer	<LOW/SUB/HIGH> - requests a dump from the specified buffer
; ConflictSpawnDelay <delay> - prevents auto spawning conflicts (space, sky etc) from occurring for <delay> frames, -1 stops them happening ad-infinitum
;
; --CUTSCENES--
; PlayLevelCutScene <levname> <cutname> - starts the cutscene - cutname, in level levname
; WaitLevelCutScene <levname> <cutname> [time offset] - waits for the cutscene - cutname, in level levname to finish - the optional time offset allows you to wait for a point n frames into the cutscene (+ve) or n frames from the end of the cutscene (-ve)
; Fade <out/in> [<black/white>] - fades the game to black or white - black by default
; WaitFade                      - waits for fade command to complete fade in or out
; PlayFMV <fmvname> <HIGH/SUB/SUBLOW/SUBHIGH/LOW> - plays an fmv file then waits for it to finish
; TexAnimSetSignal   <sigid>            - sets the texture animation signal identified by sigid to ON
; TexAnimResetSignal <sigid>            - sets the texture animation signal identified by sigid to OFF
; OnCutEvent         <val> <label>      - adds an event handler for the "FlowEvent" locator in cutscenes. When the animatable parameter is set to <val> and the locator is made visible, <label> will be called
;
; --GAMEPLAY--
; PlacePlayer <x> <y> <z> <ay> - puts the player at a specific location and resets the game camera
; PlacePlayerAtLevelStart <level> - puts the player at the setup start location for the named level
; SetCheckPoint [<x> <y> <z> <ay>] - sets a checkpoint at the current player position / orientation - if the optional parameters are specified, these are used to place the checkpoint instead
; IfPickupEQ <pikname> <val> <label> - if the pickup - pikname - equals val, then jump to label - valid piknames are "BLUEFEATHER","REDFEATHER","ANTIDOTE","GOLDCOG","HEROSTONE"
; IfPickupNE <pikname> <val> <label> - if the pickup - pikname - doesn't equal val, then jump to label - valid piknames are "BLUEFEATHER","REDFEATHER","ANTIDOTE","GOLDCOG","HEROSTONE"
; IfPickupGE <pikname> <val> <label> - if the pickup - pikname - is greater than or equal to val, then jump to label - valid piknames are "BLUEFEATHER","REDFEATHER","ANTIDOTE","GOLDCOG","HEROSTONE"
; IfPickupGT <pikname> <val> <label> - if the pickup - pikname - is greater than val, then jump to label- valid piknames are "BLUEFEATHER","REDFEATHER","ANTIDOTE","GOLDCOG","HEROSTONE"
; IfPickupLE <pikname> <val> <label> - if the pickup - pikname - is less than or equal to val, then jump to label - valid piknames are "BLUEFEATHER","REDFEATHER","ANTIDOTE","GOLDCOG","HEROSTONE"
; IfPickupLT <pikname> <val> <label> - if the pickup - pikname - is less than val, then jump to label - valid piknames are "BLUEFEATHER","REDFEATHER","ANTIDOTE","GOLDCOG","HEROSTONE"
; JonSave <startpoint>               - saves a startpoint
;
; --VEHICLES--
; EnterVehicle <vehicle name> [USECOBPOS] - puts player into vehicle - only works with VEHCRAFT type at the moment - usecobpos makes the vehicle use its cobs current matrix rather than what's in its savegame structure
; LeaveVehicle <vehicle name> - [NOJUMP/CUTCON] takes player out of vehicle - only works with VEHCRAFT type at the moment - options not really supported at the mo.
; VehicleCameraEnable - Activates the vehicle camera - needs Chris to explain this
; SetNavigator <wldname> <islename> <x y z> - sets the location of the navigation beacon - wldname or islename can be substituted with none
;
; --MISC--
; BizarreFlags <flag> <val> - Bizarre flags are app specific variables that can be set and easily picked up by the application and used for any purpose.
; Currently assigned are;
; 0 - if 1 - sea status is overriden and the sea is drawn
;
;-----------------------------------------------------------------------------------------------
; Haven Specific Semaphores;
;-----------------------------------------------------------------------------------------------
; edit_mode        - set to 1 if running in edit mode otherwise 0 - reference this if a levels script needs to 
;                    behave differently in edit mode 
;		   
; rw_init_level    - set to reflect the current state of rw_init_level - can be used to change behaviour conditionally
;                    on the current state of the fractal
;
; in_craft_biplane - if 1, player is in the biplane
;
; in_craft_wasp    - if 1, player is in the wasp
;
; in_craft_shuttle - if 1, player is in the shuttle
;
; in_craft         - if 1, player is in one of the craft

;-----------------------------------------------------------------------------------------------
; Haven Reserved Labels;
;-----------------------------------------------------------------------------------------------
; Start - Initial entry point when starting a game
; Restart - Position in script that we jump back to when restarting the game

This pleases me. The glorious bastards even kept this documentation updated between the August and final build.

That said, there are actually three additional commands that aren’t documented. The #include at the bottom of haven.flo, for instance; these look like pre-processor macros you might see in C/C++ but they’re actually handled through the same command system as everything else.

And then there are two others that are undocumented, #strict and #sloppy. These actually work together; the #sloppy command just disables the #strict state.

But what is the strict state? If it’s enabled, and the parser encounters an invalid number of arguments for a command, it’ll throw an error rather than silently spitting out a little message that might be missed. As far as I can tell, that’s it.

#strict is unused in Haven, and #sloppy is explicitly set right at the start of execution per haven.flo. This is despite the fact that sloppy seems to be the default state? Though perhaps that was different for debug builds, or used to be the case but changed before shipping.

You probably noticed there’s an edit_mode semaphore that’s mentioned. This toggles a global variable that’s in memory called game_editmode, which actually does a lot of different things that’s a little hard for me to summarise, but it will for instance give you a different (more primitive) start menu with a screenshot option.

And otherwise it’ll skip a lot of the rendering, and particularly skip much of the world rendering and simulation. So you’ll still be able to load into levels and run around, but otherwise anything involving the fractal rendering will be invisible to you.

I’d not had the time to verify it to the same extent but as far as it appears, this works much the same in the August build.

When looking at things in Ghidra, we can see that all the custom Haven commands are registered per an InitGameFlow method which is called on startup. This seems to register each command through a handy little method called gfcAddCommandType, while each semaphore (variable) is registered via a gfcAddSem method.

/* gfsupp.c */

undefined4
InitGameFlow(undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
            undefined4 param_5,undefined4 param_6,undefined4 param_7,long param_8,int *param_9,
            undefined8 param_10)
{
  [...]
  
  gfcInit();
  sem_edit_mode = (undefined *)gfcAddSem(0x603f28,game_editmode,1);

  [...]
  
  gfcAddCommandType(0x603f38,executeResetConflict,parseResetConflict);
  gfcAddCommandType(0x603f48,executeLoadConflict,parseLoadConflict);
  gfcAddCommandType(0x603048,executeDumpConflict,parseDumpConflict);
  gfcAddCommandType(0x603f58,executeSkyVisible,parseSkyVisible);
  gfcAddCommandType(0x603f68,executeSeaVisible,parseSeaVisible);
  gfcAddCommandType(0x603f78,executeDumpBuffer,parseDumpBuffer);
  gfcAddCommandType(0x603f88,executeRWInitLevel,parseRWInitLevel);
  gfcAddCommandType(0x603f98,executeRWBuffer,parseRWBuffer);
  gfcAddCommandType(0x603fa8,executeRWGetBuffer,parseRWGetBuffer);
  [...]

And all the system commands are registered in the gfcInit method that we can see called via InitGameFlow just before the Haven commands are registered.

/* gameflow.c */

void gfcInit(void)
{
  gfc_num_cmd_types = 0;
  gfc_num_sems = 0;
  gfc_num_guards = 0;
  gfc_global_data_ptr = 0;
  gfcAddCommandType(0x602c30,0,gfparseStrict);
  gfcAddCommandType(0x602c38,0,gfparseSloppy);
  gfcAddCommandType(0x602c40,0,gfparseInclude);
  gfcAddCommandType(0x602c50,0,gfparseAddSem);
  gfcAddCommandType(0x602c58,gfexecuteResetSem,gfparseResetSem);
  gfcAddCommandType(0x602c68,gfexecuteSetSem,gfparseSetSem);
  gfcAddCommandType(0x602c70,gfexecuteSignalSem,gfparseSignalSem);
  gfcAddCommandType(0x602c80,gfexecutePollSem,gfparsePollSem);
  gfcAddCommandType(0x602c88,gfexecuteWaitSem,gfparseWaitSem);
  gfcAddCommandType(0x602c90,gfexecuteWaitSemMulti,gfparseWaitSemMulti);
  gfcAddCommandType(0x602ca0,gfexecuteWaitSemEQ,gfparseWaitSem);
  gfcAddCommandType(0x602cb0,gfexecuteWaitSemLT,gfparseWaitSem);
  gfcAddCommandType(0x602cc0,gfexecuteWaitSemGT,gfparseWaitSem);
  gfcAddCommandType(0x602cd0,gfexecuteWaitSemNE,gfparseWaitSem);
  gfcAddCommandType(0x602ce0,gfexecuteIfSemEQ,gfparseIfSem);
  [...]

There are two callbacks passed into the gfcAddCommandType method, one for handling the actual execution of the command and another for parsing the arguments for that command. The first argument is of course the name of the command (Ghidra is just showing the addresses to those strings here, rather than the strings themselves).

You can see that nothing is provided for the execution callback for the first four commands above, under gfcInit, and this is because they’ll set up what they need through the parse callback instead.

So, without going over the entire implementation of the damn thing and spending another 1,000 words explaining everything as I’d be so tempted to do; it’s all quite powerful but all exposed through a fairly tidy API. Unfortunately, there are several other types of scripts, and each has its own way of doing things. Sigh…

Their script syntax here is actually case-insensitive, so for example the documentation above specifies IfSemEQ but you’ll more typically see it written as ifsemeq instead. As a matter of fact, it looks like even labels are case-insensitive too… Wouldn’t have been my choice, but hey.

As mentioned earlier, when the game starts up, it will execute from the start of haven.flo as that’s the primary script that’s explicitly loaded by the game. From there, all the commands up until the Halt are executed, but the rest of the script will continue to be parsed.

At the end of that same file, you’ll see includes for the other .flo files we also saw in the root directory. Each of these are additional scripts that consolidate everything for each given planet, so the ferra.flo script contains everything for the first planet in the game, Ferra.

A little extra tidbit is that there is a Start label just above the Restart label near the beginning of the file, but as far as I can tell it’s not actually referenced (instead, only the latter is used), which is just as well as both of them will result in the same thing.

Start:


Restart:
	SetNavigator none none 0 0 0

	ResetSem  LevShaftCutSceneEnded 
	ResetSem  guard_stationactivate 
	ResetSem  guard_testsiteend     
	ResetSem  guard_volctop	        
	ResetSem  ferry_loading
	Resetsem  newhilltotopguard     
	ResetSem  in_craft_biplane
	ResetSem  in_craft_wasp
	ResetSem  in_craft_shuttle
	ResetSem  in_craft
	ResetSem  hometownLoadScript_sem

	ResetSem  DenyInputVehicles
	ResetSem  guard_puffdragon
	
	ResetSem  MineEntSem
	ResetSem  inhibit_ml_mos
	ResetSem  inhibit_ml_ref

	ResetAllGuards

	TexAnimResetSignal 0
	TexAnimResetSignal 1
	TexAnimResetSignal 2
	TexAnimResetSignal 3
	TexAnimResetSignal 4
	TexAnimResetSignal 5
	TexAnimResetSignal 6
	TexAnimResetSignal 7
	TexAnimResetSignal 8
	TexAnimResetSignal 9
	TexAnimResetSignal 10
	TexAnimResetSignal 11
	TexAnimResetSignal 12
	TexAnimResetSignal 13
	TexAnimResetSignal 14
	TexAnimResetSignal 15

	;; Hack

	BizarreFlags 0 0	; clear frig-o-sea enable
	BizarreFlags 1 0	; tailgun hold off flag
	BizarreFlags 2 0	; level/atmosphere sorting control

	ConflictSpawnDelay 0	; reset spawn system
;;	SetLevelProgress village 2
;	SignalSem  no_sky_battle	; uncomment this line to disable the sky battle - for free flight around the planet with no attackers

; Main idle point. Script sits here most of the time waiting for subroutines to happen.
	Halt

I’d guess at some stage Start was used and executed some additional commands that were since scrapped, and they stopped bothering to use the label at all.

We could probably keep going, but hopefully you’ve got the idea on how these work now.

Dialog Script 🗣

So for this one, we’ve only got the one script which is dialog.txt. There’s no fancy file extension, so no fun for us there. That said, there’s some very limited documentation provided which makes things a little easier for us to understand.

;;
;; Commands
;;
;;	ACTOR id name colourcode eyelevel
;;	BEGINSCRIPT id
;;	  ORIGIN x y z
;; 	  RANGE n
;;	  ONCE  
;;
;;	  SETPOS actor pos x y z face actor 
;;	  CAMPOS actor shot[back|side|front] transition[cut|pan] nframes
;;        CAMTRG actor
;;	  TEXT actorname "text"
;;	ENDSCRIPT
;;
;; The actor and script id's are used directly by the code 
;;  to setup the dialog so changed to these will require
;;  changes in the code. Everything else can be changed freely
;;  

This isn’t everything though, but it’s a start. There are actually a couple extra commands available.

• move <actor> <x y z>
• face <actor> <actor>

The following is then provided at the start of the dialog file, just after the documentation, essentially outlining the details of each actor to be used in a conversation.

ACTOR  1  Teque  "Haven"  "#0#"  0.7
ACTOR  2  Bloke2 "C2"	  "#13#" 0.9
ACTOR  3  Bloke3 "C3"     "#13#" 0.9
ACTOR  4  Bloke4 "C4"     "#13#" 0.9
ACTOR  5  Bloke5 "C5"     "#13#" 0.9
ACTOR  6  Bloke6 "C6"     "#13#" 0.9
ACTOR  7  Bloke7 "C7"     "#13#" 0.9
ACTOR  8  Bloke8 "C8"     "#13#" 0.9

If you refer to the documentation from earlier, you’ll notice it doesn’t quite align with it, as there’s actually two names provided here, but the first appears to work essentially like an alias and then the second name is what will actually be displayed.

Evidently given this and the two other missing commands, the documentation at the start of the file is a little out of date.

You may have also noticed that Haven (which if you hadn’t guessed it, is the name of the main character) is referenced as Teque here.

This is quite likely an earlier name for the main character, as this name is used in a some other spots too (for instance, Haven’s house is referenced to as teqhouse, and a second copy of Haven’s model is stored under lowteq).

There are a number of test and placeholder conversations left in here.

So for instance, here’s an entry with an ID of zero, clearly to catch any instances where the ID provided for a conversation somewhere else has been left unset. This was quite likely done so either the developers or QA would notice and remedy it.

;;;;;;;;;;;;
;; no script
BEGINSCRIPT 0
;;  FACE    teque nobody
  
  CAMPOS  scene side pan 30
  CAMTRG  scene
  TEXT	  scene "My dialog script id has not been set"
  TEXT    teque "Oh dear"
  TEXT	  scene "Please find someone to set my dialog script id"
  TEXT	  teque "OK"
ENDSCRIPT

And then we’ve got another test or placeholder script following that.

;;;;;;;;;;;;;;
;; start bloke
BEGINSCRIPT 2
  ;; Script global settings
  ORIGIN  -546.5 19.2.5 117.2
  RANGE   1

  ;; Script dialog & camera sequence  

  FACE    teque bloke2

  CAMPOS  teque back pan 30
  CAMTRG  bloke2
  TEXT	  bloke2 "Welcome to Hero Island"
  
  CAMPOS  scene side pan 30
  CAMTRG  scene
  TEXT    teque  "Hello, my name is Haven"
  TEXT    bloke2 "You have no nose"
  TEXT    teque  "Dont say it"
  
  CAMPOS  bloke2 front cut
  CAMTRG  bloke2
  TEXT    bloke2 "How do you smell"
  
  CAMTRG  teque
  TEXT    teque  "AARRRGGG"
  
ENDSCRIPT

This one’s rather curious as the “bloke” in the conversation suggests that Haven doesn’t have a nose, which may be a reference to an older design featured in the video by Jon Burton here.

Or it’s nothing more than a silly joke, and I’m reading too much into it.

The entirety of this file is filled with unused, placeholder dialog, some of which was still in use in the August prototype but is otherwise left unused in the final game. And with that said, as far as I can tell, this entire dialog system actually goes completely unused in the final game, and instead it uses cutscenes (an entirely separate system, internally) to convey dialog and story to the player.

It’s curious why this is. Perhaps it was decided having cutscenes for these situations simply looked better. Perhaps originally the game was to feature more dialog, and that ended up not being the case? Who knows, but it’s surprising that it seems it was cut fairly late in production given that cutscenes likely would’ve taken more work.

The dialog system is entirely bespoke to Haven, but the system used for cutscenes is actually a system Nu2 appears to provide (though Haven has its own intermediate scripting language for cutscenes which we’ll briefly cover later).

If you’re curious what the dialog system looked like in action however, you can see it here per a video on our YouTube channel.

Placements

Amongst the files, there’s a placements.pmt file. This can be found in the root of the extracted data. It’s likely .pmt is just an abbreviation for placement.

There isn’t much to it, so I can just give you the contents below.

"SamSite"
"Fuel"
"Waypoint"
"mosshield"
"fervenshield"
"restart"

In the earlier August build, you can access the placement editor that lists the contents of this file, though it’s not really immediately obvious to me what they are and what they should do.

You can see some footage of the placement editor here.

Curiously, the last three, mosshield, fervenshield and restart were added sometime after the aforementioned August build, but as far as I can tell they’re not referenced anywhere?

Again, like the dialog system, the placements system seems bespoke to Haven. That said, as far as I can tell these are only really relevant to the placement editor? And even then I’m not entirely sure if I’m understanding what these actually do from there.

From how the editor displays them, depending on what you do, they look like waypoints. Anyway, let’s move on.

Randomisation 🔢

Under the extracted content, there’s a bin/rand.dat file. This appears to be unused by the game, and instead the game uses a table in memory, which matches the rand.dat data.

I’m not really sure if I entirely understand the purpose of having a fixed table for randomisation in this instance. Why they didn’t just do this algorithmically is a bit strange?

Just to explain a bit further, essentially there is a pointer initially set to the start of the table in memory. At the start of each frame, it’ll check to make sure that the position has not moved out of scope of the table. This is then used to produce “random” numbers in the game, as the position in the table is gradually incremented at points during the frame.

It’s very possible there’s something I’m missing, but it almost wouldn’t surprise me if the position could or does go out of scope of the table, given the check appears to only be at the start of each frame and the position is incremented at multiple points during the frame.

Probably a calculated risk… Anyway, let’s not worry about that. Nothing to see here.

Universe 🌌

We’ll take a quick look at the new.uni script which is included in the root directory of the extracted data. The extension for this format, if you couldn’t figure it out, seems to be an abbreviation of universe.

These are a lot more complicated to explain than the game flow scripts we looked at. They outline each available “world”, each of the “islands” on that world, then the “levels” on each island.

There’s at least some basic documentation provided within the script itself via the ; comments.

RWCONFIG HIGH 	9000000							; Assign a buffer to the fractal - global setting, may also be done per world
TEXANIMFILE 	"texanim.cfg"	40960					; name of texanim cfg file and buffer size for texanims

[...]

;;BEGINWORLD testworld
;;	RWCONFIG HIGH 	9000000						; Assign a buffer to the fractal - may ultimately be done on a per level or world basis
;;	PATH		world1						; where to look for bits specific to the world
;;	WBSCENE		clouds						; scene containins atmos,clouds,sea etc....
;;;	RWNAME		forest forest5					; name of realworld data set to load - 2nd parameter is wacky directory override
;;
;;	BEGINISLAND testisle
;;		PATH		island3					; where to look for bits specific to the island
;;		LOSCENE	lo_isl2						; name of low res scene
;;;;		PLATEID 	863					; fractal plate we're sat on
;;		PLATEID 	852					; fractal plate we're sat on
;;		PLATEPOS 	0,1410,0                		; origin offset on the plate
;;		ACTIVERANGE	1000					; range at which to activate island
;;		LOADTRIGGERS	island3					; loadtriggers file for this island
;;
;;;;		BEGINLEVEL boattest BUFFER high 5000000	
;;;;			PATH		boattest			; where to look for bits specific to the level
;;;;			HISCENE	boattest				; name of scene/terrain/etc file to load
;;;;;;			POS		0,0,0				; location of level - used by visibility guff
;;;;			STARTPOS	-66.4 5.26 -15			; starting position for player
;;;;			PARTICLES   particle
	
[...]

This sets everything up in conjunction with their fractal rendering engine, and this involves multiple different formats, which we would need to look at individually.

One of these formats is at least .gsc. These seem to contain textures, geometry and other data. They’re usually used to provide the main geometry for a level.

And another is .rw3. They’re found under DATA/BIN/, with each subdirectory then providing the data for each respective world. They contain textures and other data. The TEX*.RW3 files provide different sized textures for the terrain, which presumably are streamed in and out.

There are several others, but we’ll skip those for the sake of time.

It’s possible to edit the universe script, as I’ll demonstrate later on, to load in other locations but can, probably unsurprisingly, crash the game if you’re not careful.

Curiously, the way this is implemented suggests there was perhaps going to be support for loading other universe scripts? Or they just wanted to keep things flexible.

There’s only one of these scripts in the final version of the game, which is the rather curiously named new.uni. The August build has a few alternate revisions of that script. Some warning messages seem to indicate it may have been called game.uni at some point.

There is a start-up argument, uni, which will allow you to override which universe script is loaded on startup, but as we covered before, these arguments are hardcoded in the builds we’ve got.

You can see the end result of a lot of this working together, here. The player is able to approach a world from space without any loading screens, different main areas of the game can be seen which are the islands, represented by their LOSCENE geometry, and then once a player lands they move into the actual level instance itself.

Apologies this is a little vague. I’d failed to document my findings when editing these, so for the sake of time, I’ve decided to skip on a lot of this for now, and there’s so much to cover that it would probably be better served as its own article.

Models

Model used by the game have a .ghg extension. They are all stored under their own subdirectories alongside their animations, under the chars directory, within the RWLDS.DAT package.

From what I’ve understood from looking around a little bit, there’s a variations of this format used for other titles using the Nu2 framework, but it doesn’t look like there was any work done towards the version used in Haven specifically.

I’d unfortunately not finished entirely reversing them, and don’t think I’ll do so for the time otherwise we’ll be here forever, but I did learn some things to share.

Below is a rough outline of the initial structure of the files. This is in the binary template format supported by REHex.

// Trike, 18 joints?

// Texture block 672
// Pal 349 / 289~
// Header is 144 for texture? NOPE! Size isn't fixed...
// W & H are 80 bytes into the header? NOPE! Not fixed either...

struct Nu2TextureHeader
{
    uint8_t     unk0[ 80 ];
    uint32_t    width;
    uint32_t    height;
};

struct Nu2GHGHeader
{
    uint32_t fileSize;   //?
    uint32_t version;    // 0 per Haven
    uint32_t numTextures;
    uint32_t textureTableOffset;
    uint32_t numMaterials;
    uint32_t materialsOffset;
    uint32_t unkNum0;       // ? 12 per Trike
};

struct Nu2GHGHeader header;

FSeek( header.textureTableOffset );
uint32_t textureOffsets[ header.numTextures ];

for ( local uint32_t i = 0; i < header.numTextures; ++i )
{
    SetComment( textureOffsets[ i ], 0, "Texture" );
}

SetComment( header.unkOffset0, 0, "Unknown data 0" );

As you can tell, there’s still a lot to figure out here, as this is only for the header.

But these files not only contain the mesh and skeleton, but the textures too. For instance, if we take a look at chars/lowteq/rest.ghg, we can find it contains textures for Haven’s main character, Haven, including a texture for his beautiful face.

In this instance, these textures use a palette that’s included in the header of each texture contained within the file, but it appears they can be different formats besides that too.

Alas, that’s all I’d had time for. Though it would be nice to revisit these in the future.

Strings 🧵

Going to pass on this one quickly. There’s a set of strings.* files in the root of the extracted data, with the * being an abbreviated name of a country.

Each one of these contain a list of strings with an index so the correct text can be used depending on whichever language you want to play in.

Under strings.uk, you can find the following rather amusing set of strings from a seemingly distressed developer.

400 "task 0  Find level programmers"
401 "task 1  Ask them how the levels work"
402 "task 2  Add new level progress strings to the strings.uk file"
403 "task 3  Add level progress info to level.hlp file"
404 "task 4  Find out it doesn't quite work"
405 "task 5  Look for level programmers who have now gone home"
406 "task 6  Panic about what to do cos it was all left to the last minute"
407 "task 7  Bodge bodge bodge bodge bodge bodge bodge bodge bodge bodge"
408 "task 8  Shout across the office at who ever come in next"
409 "task 9  The solution to all problems is more hours"

More Scripts, Because Sure, Why Not? 😩

Didn’t we already cover some other types of scripts already? Yes. Yes we did. And there are still more.

Why you would have this many different unique script types, each with their own interpreter, loader and everything in between is beyond me, but perhaps this is the result of each developer having their own area they were in charge of and going in their own direction with that. Either way, this is pain.

Let’s go over this quickly.

There are two others I’ll just quickly touch on.

SCP Scripts 🗒

For a change, these are scripts that aren’t bespoke to Haven and are actually implemented under their Nu2 framework. Which implies other games they’ve developed probably use these. Why they implemented the game flow scripts rather than utilising this existing scripting language for the same purpose, I don’t know.

If it wasn’t capable of things they needed it for, I don’t understand why they didn’t just extend it. Am I grumpy about this? Yes, give me a time machine, so I can correct it.

The .scp extension is probably an abbreviation of script? You know what, I don’t even care at this point.

Here’s an example of what one of these looks like.

SCRIPT cgate1
	IFPARAM 2 0
		STARTCUTSCENEINST cgate2
		APPCOMMAND SoundFX "sylex door"
		SETPARAM 2 1
	ELSE
		STARTCUTSCENEINST cgate1
		APPCOMMAND SoundFX "sylex door"
	ENDIF
ENDSCRIPT

Once again, the commands used here are case-insensitive.

The APPCOMMAND appears to allow you to call a custom command that the game has registered. So for instance, Haven implements a GameFlowCall app command that allows you to execute from a label in a .flo script. So a method was essentially exposed here from Nu2 to allow games to extend the abilities of these scripts without actually requiring changes to Nu2 itself, which is nice.

Otherwise, internally these scripts are parsed by a NuScriptLoadCommands which has a fairly nasty nested structure… Though altogether we can see it supports all the following commands.

• SCRIPT
• STARTCUTSCENEINST
• PLAYCUTSCENEINST
• CHAINCUTSCENEINST
• REPEATCUTSCENEINST
• RESETCUTSCENEINST
• PAUSECUTSCENEINST
• UNPAUSECUTSCENEINST
• SETTRIGGERFLAG
• RESETTRIGGER
• ENABLETRIGGER
• IFTRIGGERPULLED
• IFTRIGGERNOTPULLED
• IFPARAM
• SETPARAM
• ELSE
• APPCOMMAND
• SETVISIBILITY
• ENDSCRIPT

Just mind a lot of these are contextual, so obviously you wouldn’t use an ELSE command on its own, you’d need to match it with an IF*, and then end it with an ENDIF; although I don’t really want to start getting into how structured programming works.

Let’s move on.

CSC Scripts 🎥

Unlike the above, these are again bespoke to Haven. These essentially pick the actual .cut file to load and setup some states for that.

What’s a .cut file? They’re binary blobs for the cutscenes silly. I’ve not had the motivation or time to look at those in depth.

Curiously, the PLAYSTREAM command, which streams audio from a VAG file, goes unused and PLAYSTEREO, which is the same but allows you to specify and left and right VAG file to use for audio, is used instead.

As far as I’ve understood, the VAG format doesn’t typically support stereo audio, so I guess the developers worked around this limitation by just producing these L and R files instead, and then streaming them into the respective audio channels. You can see all the usages of PLAYSTREAM commented out, to be replaced by the latter.

The requested VAG will get mapped to a directory matching the current language, so for instance CUTSND3L\eLcityD.vag will get mapped to english\CUTSND3L\eLcityD.vag if your chosen language is English.

Exploring the Unseen 👀

Okay, this isn’t actually all the unseen elements in the game, but a selection of items you might find interesting. This is probably what most of you are going to be interested in.

I’d mentioned earlier that there’s a pre-release build from August 2003. Surprisingly there’s actually very little in that build, as far as unused content goes, which isn’t actually also left in the final game. Though the build from August does certainly make it a lot easier to view in-engine so that’s what I’d used to take these screenshots.

The majority of these were accessed by simply modifying the universe script we discussed earlier. I believe there was one which required me to amend one of the game flow scripts, but in my great wisdom I didn’t document that (mostly as a result of me flailing around figuring out how everything worked).

Mind all of these are found within the RWLDS.DAT package.

Hometown

I’ll start off looking at the hometown at the start of the game as this one will be a little confusing without more context. This area was completely overhauled in the final game, and is much more linear there, but originally was intended to be a much more open area.

So here's a fun little thing. In the August '02 Haven proto, you start in an version of the hometown which was overhauled before released, but it turns out there's an older version of the area in the files with different plants (and without the messed up geom). (left is old, right is new)

[image or embed]

— hogsy (@hogsy.me) July 16, 2025 at 3:16 PM

Essentially, there’s a dayht.gsc file under ferra/isl1home/hometown, which is in both the August build and final, which seems to feature an older(?) version of that area.

You can find some footage I recorded showing this area in more detail here while also comparing it against the one used in the August build. We’ll probably talk a little more about this in future.

dhone

This is found in the files under ferra/isl1home/tempscn/dhone.

There’s another version of this. Not entirely sure how they differ compared to the final version?

oxtest1

This is found in the files under ferra/isl1home/tempscn/oxtest1.

An appearance from our friend Crash! 😮

This is actually a huge area, unfortunately untextured. Crash is about 2 pixels in size in the second image, which hopefully gives you an idea of its scale!

tempscn

This is found in the files under ferra/isl1home/tempscn/tempscn.

Appears to be a huge unfinished area. Fairly sure this did make it into the final game, though I believe it looks a little bit different to this? Well, besides being finished.

The last image shows the camera pulled really far back, showing how massive the area is, for some reason.

test2

This is found in the files under ferra/isl1home/tempscn/test2.

The other test level, if you’re wondering, just features the same geometry as this one.

lightbox

This is found in the files under ferra/isl1home/tempscn/lightbox.

tek

This is found in the files under ferra/isl1home/teqhouse/tek.

As mentioned earlier, Teque seems to be an older name for Haven (the character, not the game). And that’s often abbreviated as just Teq. Though weirdly the actual files for the scene itself (.gsc and .ter) are named “tek” instead… Probably a mistake.

I’m also probably mistaken myself, but I don’t believe any of this is used in the final game? Haven’s house looks entirely different to the one featured in the final game, for instance. And an appearance by the tower in the last screenshot is also replaced by a pre-rendered cutscene in the final game, as far as I’m aware.

Scenes from here do at least appear in a trailer for the game, which you can find here.

One more Crash

And finally, this is under fonts/testfont.bmp.

I’m fairly sure this same font sheet was documented as left-over in some other TT game over on The Cutting Room Floor wiki.

This is far from everything, and I’ll probably leave that for the future piece on this game, or I’ll just encourage you to try checking it out for yourself! There’s only so much I’m going to have time to look at.

One other thing that was noteworthy, but I didn’t have time to properly document, is that under ferra/island3/doomroom, there are actually multiple revisions of this area available, each one featuring slightly different designs. These exist in both the August build and final release.

Revision History 📜

One thing that stood out to me upon extracting all the data was a cvs directory; CVS is… Er, was, a fairly popular version control solution back in the day, and it stands for Concurrent Versions System. It basically lets you keep track of your changes.

This has all since been superseded by things like Git and Perforce.

This directory here basically exists because the content was checked out from their remote CVS repository, and someone forgot to delete this particular folder. Looking inside we can see three files leftover here.

In the cvs/root file, we can see a ddootson mentioned, which is David Dootson, the head programmer on the game. Perhaps it’s him to blame for this folder being left over?

Anyway, ignoring all that, we’re rather fortunate that some of the files here actually include the revision history in their header. Specifically, the .flo, .uni and strings files.

I’m not going to paste the entire revision history for each one directly here for obvious reasons, but I’ve linked each file below for you to check out if you’re interested in that.

• auria.flo
• exarco.flo
• ferra.flo
• ferven.flo
• haven.flo
• nequam.flo
• new.uni
• strings.uk
• strings.sp
• strings.it
• strings.fr
• strings.de

Curious as to who’s who in the revision history? Well, in no particular order…

If any names above are written incorrectly, blame autocorrect! If I’ve missed anyone out, well blame me (and preferably let me know.)

An article published here a couple of years after Haven shipped seems to feature a few of the developers mentioned above.

Finishing Up

So that’ll probably do for now, on the technical side. Probably. There’s actually still a lot I didn’t cover here but if I did this would’ve gone on for a long time, and there’s always the possibility of revisiting this in the future.

Working on this has made me realise that in future it may be a little more wise to just pick one aspect to focus on, rather than trying to work through everything all at once. As that certainly burnt me out a bit.

If you’ve made it to the end, with your sanity intact, and you enjoyed it, I’ve previously done pieces on Titan A.E., Wild Water Adrenaline and Creation, which you may also enjoy.

And as usual, if you want to keep up with what we’re doing, want to get involved, or have things to share, then feel free to join our Discord server.

It seemed odd that there was so little information available about the game in the wild, and absolutely no information that I could find explaining why it was cancelled.

Back in 2021, I was very fortunate to be able to get in touch with producer Goran Milisavljevic, 3D artist Aleksandar Novta, and programmer Marko Djurovic, to get some more information about the title which I’m finally sharing here. Unfortunately, due to how long it’d been, there was only so much they could share.

Additionally, as I couldn’t find any existing footage on YouTube of the prototype, I’ve provided some gameplay footage below recorded on real hardware.

The video above may be blocked due to copyrighted music used in the prototype, in which case I’ll be putting the video up elsewhere soon.

edit: turns out that PtoPOnline had already captured footage, so an alternate capture is available here.

These answers were kindly provided by Goran Milisavljevic, the producer on the game, based on a series of questions I’d provided. I’ve laid them out below in a Q&A form.

How far along were you in developing the game before ceasing development?

We developed a working prototype for the Xbox platform. Besides the prototype that contained one complete medium size mission, we also had a well-developed game design document with detailed description for the complete game, covering all levels, enemies and collectables. Also, concept art was around 75% finished.

Did the game use a custom engine, or is it based on something else (i.e. RenderWare)?

We were accepted to Microsoft’s Xbox Registered Developers programme, so we received two Xbox dev consoles and were using Microsoft’s XDK. Besides this, we were using RenderWare for rendering, FMod for sound, Bullet for physics and everything else was developed in-house.

How big was the team working on the game?

The team had 4 programmers, 5 artists and 2 game designers.

Were there any plans to bring it to other platforms, or was it being developed specifically for the Xbox only? If so, what were the motivations?

We were misled by a “big name” consultant who insisted that we should develop for Xbox exclusively. At GDC 2005, we found out that this decision was fatal for the company, since the publishers we had contacts with showed us that their plans for the next 5 years didn’t include any Xbox titles, only titles for the next gen consoles (Xbox 360 and PS3).

Based on this prototype at GDC 2005, people from Sony offered us to develop for them a PS3 game based on the “Starship Trooper” movie. However, our investor declined this offer and this meant the end of the road for us.

Marko Djurovic, a programmer on the game, also recounted details behind the development of the game and the prototype.

The idea was that Beyond should be a space TPS.

The initial idea was that NPCs have some kind of primitive AI, but later that idea was abandoned, and in demo, the NPCs were script driven.

I’m not entirely sure what was meant by script driven here, as the NPCs in the prototype seem to have some basic level of AI. However, this may explain why internally in the demo there’s a BStupidNPC type? Though this wasn’t something I was able to confirm.

Target platform was the original Xbox.

I can’t remember the full story now, but the team spent months developing the story behind the game. The engine was a mix of an in-house engine with some commercial engine (can’t remember name). For animations, we used motion capture with the help of professional models.

Sound and music was made by professional musicians.

The commercial engine referred to here was likely RenderWare, as mentioned by Goran Milisavljevic.

As far as I’m aware, we unfortunately don’t get to hear any of the custom music that was produced for the game in the prototype. Much of the music there seems to be pulled from the Animatrix and The Matrix Revolutions, very likely as placeholders.

I think at that time members of the team were the best game developers in the region. Unfortunately, after a successful demo, we ran out of funds (through the fault of the CEO).

Sorry this was a long time ago, so I forgot many things, but I can remember it was hell of the ride. We were young and often working 40 hours without a pause.

I originally provided much of this for a since unlisted video produced by Techmo Snowspark; hence why there’s been a wait on getting these published on the site.

Big thanks to them for answering my questions about the game. This provides some more context for the prototype and its fate.

Until next time! 👋

Update: Andrew Borman, a director at The Strong National Museum of Play, kindly alerted me to the fact that the developers released two design documents related to the game online at some point in the past. I’ve now mirrored these here and here.

We’ll be publishing more about this version of the game on our blog in the new year.

As mentioned in the video, some modifications have been made just to make it easier to capture. A cap for the frame rate was introduced. Some issues that resulted in crashes were also resolved, though otherwise much of the rest has been left as-is to remain as an accurate representation of the game at the time.

If you have any questions, feel free to join our Discord server, here.

Hope you all have a great Christmas and new year!

This time we’ve got Halo: Combat Evolved, specifically generated from a pre-release build found here, and Legend of Alon D’ar, which was produced from symbols included in the retail US release (oops).

As you can probably see, and might have known already, much of the original Halo was written in C.

As for The Legend of Alon D’ar, it seems much of that was written in C++. The latter is referred to as FireFly, which was apparently an early working title (at least according to MobyGames, which provides no citation, because of course). Another working title was Eternal Blade.

Enjoy!

Keep in mind that there is no actual code here, but just the tree representing how everything, or more specifically the source code, was laid out during development. This might give you some ideas, clues, or just generally, hopefully, be interesting for you to see—personally I’ve found some of these rather inspiring when deciding how to set out my own projects.

I should also emphasize that this is derived from an early debug build released here, so it’s likely things may have changed as the game continued development.

That said, you can already see how the developers had divided the code in a tidy manner between the game and the engine; much of the tech behind this game ended up getting used for other titles by the same studio, SCE Cambridge, such as Ghosthunter and 24: The Game.

If you’d like to see what that early debug build looks like (without having to launch it up yourself), I produced a video covering some of it a while ago, which you can find below.

A version of the video with some rather questionable commentary is also available here if you want to hear my boring voice.

As you can see from the source tree I’ve uploaded, the project was internally referred to as “Fable”. Given Lionhead’s Fable was called “Project Ego” at the time Primal was announced, it seems unlikely the name was changed to avoid conflicts there, so it may have simply been a placeholder.

This earlier title or internal name used for the game can actually be seen in some public pre-release material too, such as these Maya screenshots (note the “Fable Map Objects” menu along the top and, again, the “fable” directory).

After many attempts to play through the game since it was released, I’ve recently been working my way through Primal and finally find myself close to completing it. I’ve really enjoyed and admired just how unique and refreshing the universe the game takes place in is. Very impressive just how far the developers pushed the PlayStation 2 hardware.

Enjoy!

Oops. This has only been waiting two years. Alright, I guess it’s about time to get this out the door.

Titan A.E., if you didn’t know already, was a game that was being developed by Blitz Games. I’m not going to go too much into the history and details of the game itself, as there’s been a fantastic amount of research into this already published here by Edward Kirk.

Anyway, for this reason, I decided to focus on more so on the technical side of things, rather than the game generally. This tends to be my usual trend anyway.

Let’s Dive In!

Into the box of adventure we go!

So we’re taking a look at the demo for Titan A.E. that was released in 2000, around early June? I couldn’t find a date specified online, but judging from the modification timestamps amongst the content on the CD, it seems likely that’s when it was printed. The debug menu says “May 31 2000” in the top corner, which is probably when it was compiled. Regardless, not too far off before the game was cancelled near the end of July.

I’m not going to go too much into the game itself as mentioned already, but you can find a series of videos via the playlist below from our YouTube channel.

The additional levels were accessed using the debug menu which was activated using the GameShark codes available here. I’ve also provided them below.

D006F6A8 0001
3007066E 000D
D006F6A8 0001
30070324 0001

With the level select, there’s a lot to explore!

When recording footage for YouTube I was a little concerned the music might get flagged (or grate a little as it’s fairly repetitive), so I’d disabled the music by hex editing the executable. That said, if you want the music, you can grab it below.

Download

Download

Download

Download

Download

Reviewing The CD Contents

After extracting the contents of the CD, we’ve got the following directory tree.

.
├── BOOT.EXE
├── SLUS_900.82
├── SYSTEM.CNF
├── TITAN.DAT
├── TITAN.MAP
├── VIDEO
│   ├── BLITZ1N.STR
│   ├── FOX_1_N.STR
│   ├── GAMEDEMO.STR
│   ├── ROLDEM_N.STR
│   └── TITAN_N.STR
└── XA
    ├── FLYING.XA
    ├── LEVELS1.XA
    └── TESTALL.XA

I’m not entirely sure what BOOT.EXE does. From looking at the strings within, it certainly sounds like some sort of bootstrapper? Though the main executable, SLUS_900.82, doesn’t appear to make any references to it, so it might be unused? Regardless, not too interested in that for now.

The TITAN.MAP file is a linker map, which was probably unintentionally included on the CD. It provides all the addresses for the various sections and functions, etc.

    Start     Stop   Length      Obj Group            Section name
 00018000 0001B8E3 000038E4 00018000 text             .rdata
 0001B8E4 000655CF 00049CEC 0001B8E4 text             .text
 000655D0 0006D68B 000080BC 000655D0 text             .data
 0006D68C 0006D733 000000A8 0006D68C text             .sdata
 0006D738 0006F5CF 00001E98 0006D738 text             incbins
 0006F5D0 0006F5D3 00000004 1F800000 dcache           cachedata
 0006F5D4 0006F643 00000070 0006F5D4 bss              .sbss
 0006F644 0007D6C3 0000E080 0006F644 bss              .bss
 0007D6C4 0007D6C7 00000004 0007D6C4 explore          explore$SN_OVL_explore
 0007D6C8 0007FB63 0000249C 0007D6C8 explore          explore.rdata
 0007FB64 000CD177 0004D614 0007FB64 explore          explore.text
 000CD178 000CD8E3 0000076C 000CD178 explore          explore.data
 000CD8E4 000CFE9F 000025BC 000CD8E4 explore          explore.bss
 
[...]

 00020F8C MATHS_SqrtFull
 00020FC4 MATHS_ATanFast
 00021138 MATHS_AngleDifference
 0002116C MATHS_Magnitude
 0002124C MATHS_MagnitudeS
 0002132C MATHS_Magnitude2D
 000213E0 MATHS_Rotate
 00021490 MATHS_ProjectPointForward
 00021544 MATHS_ProjectPointDown
 000215F8 MATHS_ProjectPointRight
 000216AC MATHS_GetPointDistanceFromLineSegment3D
 00021AD0 MATHS_GetPointDistanceFromLineSegment2D
 00021D04 MATHS_Get2DLineSegmentsIntersectPoint
 00022164 MATHS_LineSegmentsIntersect
 00022214 MATHS_ShortAntiClockWise
 00022278 MATHS_VECTORCrossProduct
 0002233C MATHS_TSVECTORSafeCrossProduct
 00022400 MATHS_NormaliseVECTOR
 000224FC MATHS_NormaliseTVECTOR
 000225D4 MATHS_NormaliseTSVECTOR
 000226E4 MATHS_NormaliseTSVECTOR2D
 000227BC MATHS_LineSegmentIntersectPlane
 
[...]

The files under XA and VIDEO use fairly standard formats as far as PSX games are concerned, and you can view/extract them using existing tools.

The file we’re most interested in is TITAN.DAT, as this is what holds the bulk of the data used by the game.

Turns out this DAT container is a common format amongst some other games Blitz developed at the time, such as Chicken Run and Action Man: Destruction X. There are probably others, but I’d confirmed those two at least.

I’ve documented the general structure as the following here.

struct
{
	int32_t magic;// '78563412'
	int32_t numFiles;
	struct
	{
		int32_t hash;
		int32_t block;
		int32_t length;
	} files[ numFiles ];
} header;

local int i = 0;
struct Data( int &i )
{
	FSeek( 16384 + ( header.files[ i ].block * 2048 ) );
	char chunk[ header.files[ i ].length ];
	i++;
};

struct Data data[ 0 ];
ArrayResize( data, header.numFiles, i );

This format is heavily oriented around streaming from a PSX CD, which has sectors sized at 2,048 bytes each—so to get the file offset, it’s 16384 + (block * 2048).

That doesn’t seem so bad, right? But hang on, there’s a problem…

Hashed Filenames

If we were to extract the data right now, we wouldn’t know what any of the files are actually called as they’re identified by a hash. I’m not sure how many formats I’ve come across now that feature hashed filenames, but it’s one too many.

So the first problem to solve here is the hashing algorithm that was used. On this occasion I got a little lazy and took a quick look at the Chicken Run code for clues, and it turns out it can be found under islutil.c per utilStr2CRC. Essentially, this code generates a hash based on a pre-existing table (likely done for the sake of speed).

unsigned long utilStr2CRC(char *ptr)
{
	register int i, j;
	int size = strlen(ptr);
	unsigned long CRCaccum = 0;

	for (j=0; j<size; j++)
		{
		i = ((int)(CRCaccum>>24)^(*ptr++))&0xff;
		CRCaccum = (CRCaccum<<8)^CRCtable[i];
		}
	return CRCaccum;
}

After studying the code a bit, I’d ended up writing my own variation of it to use for matching names.

The next thing to do was to determine all the original filenames, which is uh, a little trickier. In the end, through a combination of scraping the executable, scraping through much of the extracted content and guessing based on naming patterns, I’d managed to match a reasonable amount, though sadly not everything.

51.53% matched (675/1310) for Blitz package “TITAN.DAT”

I don’t think I’ve got more in me for now. At times, it felt like a game of battleship. You can find all the matched names here. Mind that the last section in that list is for SPT files, which we’ll talk about later.

Reviewing The DAT Contents

Right so we’ve first gone over the files on the CD and found where the bulk of the game data was stored, spent a silly amount of time trying to determine the filenames, and now we’re here. Your secrets can’t hide from me!

Oh look, folders…

As you can see, we’ve got a number of files that still don’t have valid names—we’ll ignore those for now. But hey, we’ve also got a number of folders here too.

• BIN
  • This contains different binaries of logic for different areas of the game which are loaded as needed. Likely to save on memory, they are separate from the main executable, which is not all uncommon for PSX games.
• EXPLORE
  • This contains all the assets specific to the explore mode, i.e., when we’re not flying a spaceship. This is, unsurprisingly, given the number of levels for this mode, quite a significant amount of data.
• FLYING
  • All the assets specific to the parts of the game involving flying spaceships along a fixed track.
• GRAPHICS
  • Graphics that I’d figure are shared between both modes of gameplay, including assets for the frontend.
• MODELS
  • Fairly self-explanatory as to what this contains. Many of these are actually specific to the explore mode.
• SOUND
  • Holds sound banks used by the game, for, well, sounds.
• STRTMENU
  • More frontend assets.

There are additional folders under some of these for further organisation.

There are also a number of different formats used by the game, all proprietary, of course. The below doesn’t even cover everything.

PSI

These are the models used by the game and also appear to be a common format used by some other Blitz titles. It was my plan to write a tool to convert these in time for this piece, but it kept tumbling down my list.

You can find a rather limited write-up of the spec below.

struct RGB
{
	uint8_t r;
	uint8_t g;
	uint8_t b;
	uint8_t padding;
};

struct
{
	int32_t magic;  // 'PSI\0'
	int32_t version;// 1
	int32_t flags;
	char    name[ 32 ];// typically seems to be blank...

	int32_t numMeshes;
	int32_t numVertices;

	int32_t numPolygons;
	int32_t polygonOffset;

	uint16_t firstFrame;
	uint16_t lastFrame;

	int32_t numSegments;
	int32_t segmentOffset;

	int32_t numTextures;
	int32_t textureOffset;

	int32_t meshOffset;

	int32_t radius;
} header;

// textures
if ( header.numTextures > 0 )
{
	FSeek( header.textureOffset );
	struct
	{
		char name[ 32 ];
	} textures[ header.numTextures ];
}

There’s more here but not much. At some stage I’d like to look at these again.

XED

Not sure how you would pronounce this one in the real world. Zed?

Anyway, these appear to be scripts that outline the objects that are placed in the world and their properties. There is one for each level.

// MAP: Drej_3

SEGMENT
{
	INDEX {0}
	POLYGONS {0}
	VERTICES {0}
	TYPE {LANDSCAPE}
	NAME {NAVROOM}
	POS {0, 0, 0}
	ANGLE {0, 0, 0}
	SIZE {4096, 4096, 4096}
}

[...]

LIGHT
{
	POS {2880, -600, 6401}
	VAL {158, 69, 194}
	RANGE {2481}
	AMBIENCE {0}
	BOOST {2500}
	INFINITE {0}
}

[...]

SWITCH
{
	TAG {T34SWTCH}
	TAG_CRC {488158572}
	NAME {CSWITCH}
	POS {0, -125, -1251} // x,y,z
	ANGLE {0, 2048, 0} // 0->4095
	LINK {0}
	STATE {0}
}

DOOR
{
	NAME {CONDUIT}
	TAG {TP34}
	TAG_CRC {-1266880023}
	POS {683, -220, -268} // x,y,z
	ANGLE {0, 1024, 0} // 0->4095
	ID {0}
	STATE {0}
}

AUTO_DOOR
{
	NAME {CONDUIT}
	TAG {EMITTER3}
	TAG_CRC {-1416931696}
	POS {2831, -491, 6867}
	ANGLE {0, 0, 0} // 0->4095
	RADIUS {10}
	STATE {0}
}

[...]

The SEGMENT type appears to be referencing entries in the LND files, so my guess is that these are specifying what chunks of geometry are being used for the level and where. Otherwise, many of the other chunks are somewhat self-explanatory.

FUK

These are located under the EXPLORE/EVENTS directory. There is usually one per level, but some levels don’t appear to have one at all.

They’re similar in syntax to the XED files, however, these are used for adding in some basic logic for handling level-specific events. They also have a rather unfortunate file extension.

At the start of the file, the number of events and atoms (variables) are specified like so.

TOTALEVENTS	{35}
TOTALATOMS	{152}

Following this, there’s then an entry for each event, such as seen below.

[...]

EVENT
{
	NAME	{STARTUP}	//sets poly colours for emergency light

	ONESHOT

	TRIGGER
	{
		NUMATOMS {1}

		OR { TRUE, 0, 0, 0, 0 } // TRUE. ALWAYS FIRES.
	}

	SCRIPT
	{
		NUMATOMS {2}

		// - set flatcolours
		DO {FLATCOL0, 10, 255, 255, 3 }
		DO {FLATCOL1, 20, 255, 255, 3}
		
		// - cheats
		//DO { WRITETOK, 944488308, 1, 0, 0} //frank
		//DO { WRITETOK, 1519763642, 1, 0, 0} //dave
		//DO { WRITETOK, 725827994, 1, 0, 0} //geoff
		//DO { WRITETOK, 1245070714, 1, 0, 0} //wayne
		//DO { WRITETOK, 2059165261, 0, 0, 0} //titan code off
	}
}

[...]

Given these looks like they’re created by hand, I’d wager it must’ve been a pain keeping the TOTALEVENTS and TOTALATOMS updated. I’d figure that these are provided so that the script interpreter can pre-allocate storage for the required events and variables up-front for speed.

SPT

These are containers for either a single image, or multiple.

enum SptFlags
{
	SPT_FLAGS_END = 1,      // indicates that it's the last image
	SPT_FLAGS_8BPP = 2,     // if this flag isn't set, it seems to be 4bpp
	SPT_FLAGS_ALPHA = 16,
};

struct SptHeader
{
	uint32_t dataOffset;
	uint32_t paletteOffset;
	uint8_t  width;
	uint8_t  height;
	int32_t  unk0;
	uint16_t flags;
	uint32_t hash;
};

You’ll notice the last variable is our friend, Mr. Hash. Fortunately, this uses the same hashing algorithm we looked at earlier, though we still need to put in some work to figure out what the names were, so we can match them.

In the end, I’d managed to match a number of them by scraping the texture names mentioned in the PSI files. You can find the end result at the bottom of here.

As mentioned, the SPT format doesn’t contain just one image but multiple—the last is denoted by an end flag. An example of how you could iterate over each of these is provided below.

	struct SptHeader header;
	do {
		if ( !parse_header( file, &header ) ) {
			break;
		}

		// save this so we can restore our position after
		PLFileOffset offset = gInterface->GetFileOffset( file );

		// code here for parsing and converting the image goes here...

		gInterface->FileSeek( file, offset, PL_SEEK_SET );
	} while ( !( header.flags & SPT_FLAGS_END ) );

There appear to be two possible formats an SPT can be - 4bpp or 8bpp, which is denoted by a flag (2) - if the flag isn’t present, the image is 4bpp but otherwise 8bpp.

You can then convert it like so. Just keep in mind I’m not currently handling the alpha channel here as I’d encountered some oddities there.

#define AAA5( x ) ( ( ( x ) << 3 ) | ( ( x ) >> 1 ) )
#define AAA6( x ) ( ( ( x ) << 2 ) | ( ( x ) >> 4 ) )
	PLColour *pColour = ( PLColour * ) &image->data[ 0 ][ 0 ];
	if ( format == SPT_FORMAT_8BPP ) {
		for ( unsigned int i = 0; i < size; ++i ) {
			uint16_t c = pal[ img[ i ] & 0x0F ];
			pColour->r = AAA5( c & 0x1F );
			pColour->g = AAA6( ( c >> 4 ) & 0x3E );
			pColour->b = AAA5( c >> 10 );
			pColour->a = 255;
			++pColour;
		}
	} else {
		for ( unsigned int i = 0; i < size; ++i ) {
			uint16_t c = pal[ img[ i ] & 0x0F ];
			pColour->r = AAA5( c & 0x1F );
			pColour->g = AAA6( ( c >> 4 ) & 0x3E );
			pColour->b = AAA5( c >> 10 );
			pColour->a = 255;
			++pColour;

			c = pal[ img[ i ] >> 4 ];
			pColour->r = AAA5( c & 0x1F );
			pColour->g = AAA6( ( c >> 4 ) & 0x3E );
			pColour->b = AAA5( c >> 10 );
			pColour->a = 255;
			++pColour;
		}
	}

Once that is all out of the way, we end up with this.

There were a couple interesting things I’d noticed once everything was converted for easy viewing.

For instance, under D72B9099 (hashed value as I didn’t find a match), there’s what appears to be an early wrench icon?

And then under FC3B0030, we find the same wrench icon alongside what appears to be an old icon for a gun, health and ammo.

All the converted results can be downloaded here for you to do your own sleuthing.

RAW!

The RAW files are images that seem to all be displayed directly on the screen. There’s no header or anything fancy to them. 512x256 and RGB555 format.

I ended up implementing the following to convert them.

	static const unsigned int RAW_WIDTH = 512;
	static const unsigned int RAW_HEIGHT = 256;
	static const unsigned int RAW_SIZE = RAW_WIDTH * RAW_HEIGHT * 2;

	[...]

	const unsigned int shiftR = 0;
	const unsigned int shiftG = 5;
	const unsigned int shiftB = 10;

	PLColour *colour = ( PLColour * ) &image->data[ 0 ][ 0 ];
	for ( unsigned int i = 0; i < size / 2; ++i ) {
		uint16_t c = htole16( buf[ i ] );
		colour->r = ( ( c & ( 31 << shiftR ) ) >> shiftR ) << 3;
		colour->g = ( ( c & ( 31 << shiftG ) ) >> shiftG ) << 3;
		colour->b = ( ( c & ( 31 << shiftB ) ) >> shiftB ) << 3;
		colour->r |= colour->r >> 5;
		colour->g |= colour->g >> 5;
		colour->b |= colour->b >> 5;
		colour->a = 255;
		colour++;
	}

You can find the converted results below, though these are just the identified files I’ve converted here—there may be more.

STRTMENU

The first four of these are displayed when the player dies or the level ends. The one showing Cale on the floor, dubbed GAMEOVER.RAW, is possibly unused (the game references it, but I do not recall seeing it).

The screens with the controls are shown when starting to play either of the exploration or flying levels from the main menu.

The very last is used as the background for the main menu.

GRAPHICS/FRONTEND

This gets used as the background for the debug menu.

FLYING/BACKDRPS

The last image, VOLCANO.RAW, might just be a placeholder as it matches an image used for many of the other exploration levels.

EXPLORE

Most of these are just duplicates, so I’ve only included the first unique ones.

Bonus Section

These are just some minor things I wasn’t really sure where else to throw.

Source Code

We’re rather fortunate that another game by Blitz, Chicken Run, had its source code uploaded to the web a while back which can be found here (side-note: if you know who/where it was uploaded it originally, let me know, so I can provide a citation on our archive).

By using the linker map as a reference, we can see some common ancestry between Chicken Run and Titan A.E.

Overall, judging from the Chicken Run code, at least, I wouldn’t really say Blitz had an engine at this time but rather some common libraries/code their games shared. Not all uncommon for the time. Eventually, they would go on to develop Blitz Tech but that seems to have come much later (curiously, the PC Gaming Wiki suggests their technology was called Babel Engine prior to 2009, but there’s no citation, and I’d wager that still likely postdates Titan A.E. and Chicken Run.)

Shadows

I’d posted about these on Mastodon back in April.

They just use sprites essentially projected to the ground plane from each part of the model, so it’s a really simple system but not something I’ve seen very commonly on the PSX. At least as of the code recycled in Chicken Run, there can be up to five shadows projected that are emitted from lights marked to cast shadows.

Loading Screens

The screen displayed when loading a level is denoted by its corresponding RAW file; for instance, you load up the Shooting Gallery level, and it’ll use EXPLORE/SHOOTGAL.RAW for the loading screen. Despite this, most of the levels unfortunately just use the same duplicate image in this build of the game. It’s likely this probably would’ve changed had the game continued development.

The End

That concludes this poking and prodding session for now. I’m hopeful that at some stage we might see more show up in relation to this game.

If you want to support what we do, we’re not accepting donations at this time, but any feedback is appreciated. Feel free to join our Discord or leave a comment letting us know what you think! Alternatively, you can follow me on Mastodon for any of my general rambling.

In the meantime, I shall vanish back into my hiding place.

Resources

Some of these are more specific to the film than the game itself, but I thought they were still interesting, and so I’ve included them here.

• Ice Planet: The Lost Worlds of the Titan A.E. Game
• Thomas M. Adams Portfolio (includes some very nice screenshots of the tools used to develop the game)
• Titan A. E. ( USA) ( Demo) (patched) (a patched copy of the demo that makes more content accessible)
• Unseen64: Titan A.E.
• Unseen64: The cancelled Titan A.E. game is almost restored
• Titan AE : the Wake Angels (a fan-site that covers the film and other media)
• Living Lines Library: Titan A.E. (2000) - Concept Art
• GFL Animation Studios: Titan AE (concept art produced for the movie)
• Heritage Auctions (a collection of concept art that was sold in 2022, navigate along the top to see more)

And uh, yeah, some mysteries here could be solved by simply disassembling the game, however, I felt lazy and just poked at the files on this one—as I said, maybe this will spark something for someone a little more interested than I was, heh.

If you’re not familiar with Wild Water Adrenaline, it’s a uh, not fantastically well-received PlayStation 2 game produced by Fresh3D; essentially the guys that were involved in working on Outcast 2 (which, I’m not going to lie, is the sole reason for my interest).

While Fresh3D still seems to exist in some capacity, it turned out Franck Sauer, who is listed on it’s website, no longer actually works there, leaving just Yann Robert I guess. Unfortunately, I did not have any luck getting in touch with Yann, but it seems they’ve since moved on to work for Epic Games.

So that’s another reason why this piece is so short, or another excuse.

I’ll confess, though, as I’m sure you can appreciate from the footage above, Wild Water Adrenaline is absolutely gorgeous for a PlayStation 2 title. Though that makes it all the more disappointing that the tech behind it didn’t get used to produce something a little more compelling (you know, like Outcast 2…)

You can read more about Wild Water Adrenaline’s development here, as written up by one of the developers involved with the game.

If you’d like to learn more about the ill-fated Outcast 2, there’s some great information available here written up by the same developer. That said, I’ll throw a spoiler warning in there as I understand this was later removed from their current website as elements of this earlier design are being used in the upcoming Outcast: A New Beginning title.

Anyway, I digress, let’s get on with it.

When viewing the contents of the disc for the game, we see the following.

.
├── DATA.BIN
├── PS2
│   ├── IRX300
│   │   ├── IOPRP300.IMG
│   │   ├── LIBSD.IRX
│   │   ├── MCMAN.IRX
│   │   ├── MCSERV.IRX
│   │   ├── MTAPMAN.IRX
│   │   ├── PADMAN.IRX
│   │   ├── SDRDRV.IRX
│   │   ├── SIO2MAN.IRX
│   │   └── STREAM.IRX
│   └── NAMES.BIN
├── SLES_535.95
└── SYSTEM.CNF

Can you guess where the actual data for the game is stored? If you guessed DATA.BIN then you guessed correctly!

DATA.BIN

It’s a pretty uninteresting package format, and the content within is aligned to blocks of 2,048 bytes, which was quite likely done for more effectively streaming the data off the disc.

The header of the package is as follows.

struct Header
{
	char ident[ 8 ];
	int32_t unk0[ 2 ]; // <- these are 0, so I've no idea
	uint32_t numFiles;
	Index indices[numFiles];
};

And each Index is the following.

struct Index
{
	char name[ 12 ];
	uint32_t blockNum;
	uint32_t size;
};

The blockNum variable confused me for a little bit before I realised it’s just simply how many blocks of 2,048 bytes to reach the offset of the file in question.

Oh, and note that the names are not null terminated but instead space terminated, which you’ll want to account for if you decide to write your own tools to dump/repack the files.

If this isn’t sufficient for you to understand the format, for whatever reason, I’d thrown together an implementation here.

We’re finally left with this.

Right, so we’ve got that out the way and extracted the DATA.BIN file - what are we left with?

A big ol’ blob o’ more files… (click here if you want to skip)

.
├── 111.DAT
├── 112.DAT
├── 114.DAT
├── 211.DAT
├── 213.DAT
├── 214.DAT
├── 222.DAT
├── A_CA_1.MIC
├── A_FR_1.MIC
├── ALTISS.PSS
├── AMBIENT.LUA
├── ANIM.LUA
├── ANIMS.PAK
├── A_NZ_1.MIC
├── ASTICK.PAK
├── A_US_1.MIC
├── AUTOEXEC.LUA
├── BONUS.LUA
├── BONUS.PAK
├── BOOT.TGA
├── CA_BACK.PAK
├── CA_BONUS.GAM
├── CA_CAM.PAK
├── CA_COLL.PAK
├── CA.CPS
├── CAMTRIG.LUA
├── CA_OCCL.PAK
├── CA.PAK
├── CA_SFX.PAK
├── CA_SNOW.PAK
├── CA_STREA.GAM
├── CA.TEX
├── CA_TRIG.GAM
├── CD.LUA
├── CHARS.TEX
├── CREDIT.MIC
├── CREDITS.LUA
├── CURVE.PAK
├── E_CREDIT.VAG
├── EFFECTS.LUA
├── ELEC1.MIC
├── ELEC2.MIC
├── EMITTER.ANM
├── ENDRACE.LUA
├── ENGLISH.LUA
├── E_TIME.VAG
├── F3DSPLAS.ANM
├── F3DSPLAS.PAK
├── F3DSPLAS.TEX
├── FEMA_M.PAK
├── FEMA.PAK
├── FEMB_M.PAK
├── FEMB.PAK
├── FEMC_M.PAK
├── FEMC.PAK
├── FEMD_M.PAK
├── FEMD.PAK
├── FIELD.ANM
├── FINISH.VAG
├── FLAGS.TEX
├── FLUID.PSS
├── FONTS.PAK
├── FONTS.TEX
├── FR_BACK.PAK
├── FR_BONUS.GAM
├── FR_CAM.PAK
├── FR_CLOUD.PAK
├── FR_COLL.PAK
├── FR.CPS
├── FRENCH.LUA
├── FRESH3D.LUA
├── FRESHENG.LUA
├── FRESH.LUA
├── FRESH.MIC
├── FRESH.PAK
├── FRESH.TEX
├── FR_FLARE.PAK
├── FR_OCCL.PAK
├── FR.PAK
├── FR_PART.PAK
├── FR_SFX.PAK
├── FR_STREA.GAM
├── FR.TEX
├── FR_TRIG.GAM
├── GAME.LUA
├── GAMEPLAY.LUA
├── GERMAN.LUA
├── GETREADY.LUA
├── GLOBALS.LUA
├── HELMET.PAK
├── HELP.LUA
├── HOMA_M.PAK
├── HOMA.PAK
├── HOMB_M.PAK
├── HOMB.PAK
├── HOMC_M.PAK
├── HOMC.PAK
├── HUD.LUA
├── I_BALISE.VAG
├── I_BAR.VAG
├── I_CANCEL.VAG
├── ICON.SYS
├── I_NAV.VAG
├── INDIE.PSS
├── INTERF1.TEX
├── INTERF2.TEX
├── INTERF.PAK
├── ITALIAN.LUA
├── I_TEXT.VAG
├── I_VALID.VAG
├── KAYAK.LUA
├── KAYAK.PAK
├── KIMPACT1.VAG
├── KIMPACT2.VAG
├── LANG.LUA
├── LOADING.PAK
├── LOADSAVE.LUA
├── MAIN.LUA
├── MEMCARD.LUA
├── MENU.COL
├── MENU.LUA
├── MENU.PAK
├── MENU.PSS
├── MENU.VAG
├── MSCREAM1.VAG
├── MSCREAM2.VAG
├── MSCREAM3.VAG
├── MSCREAM4.VAG
├── MSCREAM5.VAG
├── NAMES.BIN
├── NZ_BACK.PAK
├── NZ_BONUS.GAM
├── NZ_CAM.PAK
├── NZ_COLL.PAK
├── NZ.CPS
├── NZ_OCCL.PAK
├── NZ.PAK
├── NZ_PART.PAK
├── NZ_RAIN.PAK
├── NZ_SFX.PAK
├── NZ_STREA.GAM
├── NZ.TEX
├── NZ_TRIG.GAM
├── OCCLUDE.LUA
├── PADDLE.PAK
├── PAGAIE.PAK
├── PARTICLE.ANM
├── RAFTG.PAK
├── RAFTKAYA.TEX
├── RAFT.LUA
├── RAFT.PAK
├── RANKING.LUA
├── RECORDER.LUA
├── RECT.LUA
├── RIMPACT1.VAG
├── RIMPACT2.VAG
├── RKMENUS.LUA
├── ROCK1.MIC
├── ROCK2.MIC
├── ROOT1.MIC
├── ROOT2.MIC
├── ROW.VAG
├── RWATER1.VAG
├── RWATER2.VAG
├── SMOO1.MIC
├── SMOO2.MIC
├── SOUND.LUA
├── SPANISH.LUA
├── SPLASHG.PAK
├── SPLASHG.TEX
├── SPLASHM.PAK
├── SPLASHM.TEX
├── STICK.LUA
├── STYLES.LUA
├── TEAMMATE.LUA
├── TEXT.LUA
├── TIME_OUT.VAG
├── TRAINING.LUA
├── TR_BACK.PAK
├── TR_BONUS.GAM
├── TR_COLL.PAK
├── TR.CPS
├── TRIGGERS.LUA
├── TR.PAK
├── TR.TEX
├── UI.LUA
├── UNDWATER.VAG
├── US_BACK.PAK
├── US_BONUS.GAM
├── US_CAM.PAK
├── US_COLL.PAK
├── US.CPS
├── US_OCCL.PAK
├── US.PAK
├── US_PART.PAK
├── US_RIDE.PAK
├── US_SFX.PAK
├── US_STREA.GAM
├── US.TEX
├── US_TRIG.GAM
├── UTILS.LUA
├── VIEWER.LUA
├── VISUAL.LUA
├── WATFALLL.VAG
├── WATFALLM.VAG
├── WATFALLS.VAG
├── WSCREAM1.VAG
├── WSCREAM2.VAG
├── WSCREAM3.VAG
├── WSCREAM4.VAG
├── WSCREAM5.VAG
├── WSTREAM.LUA
├── WWA2.PSS
└── WWA.ICO

sigh

NAMES.BIN

So one of the files in here actually has a duplicate stored outside under the PS2 directory, and that’s NAMES.BIN. What does it do? I don’t exactly know, but it looks like a list of symbol names such as classes/structs, variables, and more. I’m not sure how much of it is actually used as some of them are nonsensical for a PlayStation 2 title, such as several Direct3D specific classes.

IDirect3D8
IDirect3DDevice8
IDirect3DResource8
IDirect3DBaseTexture8
IDirect3DTexture8
IDirect3DVolumeTexture8
IDirect3DCubeTexture8
IDirect3DVertexBuffer8
IDirect3DIndexBuffer8
IDirect3DSurface8
IDirect3DVolume8
IDirect3DSwapChain8

Anyway, as I was reading through the strings in this file, I’d realised something was a little bit amiss when there were references to guns, explosions, worms and other things that didn’t really make much sense for a game about rowing a boat through water (unless there’s some incredibly hardcore and well hidden bonus mode I was unaware of).

mClipSize
mBullets
mDamageType
mFireRate
mLastFire
mBulletSpeed
mTeamSoldierLifeCycle
mTeamSoldierFlee
mSoldierPos1
mSoldierPos2
mSoldier1
mSoldier2
mExploding
BULLET_IMPACT_NEAR
mIsCutterSeen
mAssaultGun
mShootSound
mHandgunBulletSpeed
mHandgunBulletDamage
mHandgunClipSize
mHandgunFireRate
mSniperBulletSpeed
mSniperBulletDamage
mSniperClipSize
mSniperFireRate
mSniperDamageType

“What? Rowing boats with guns!?”

It’s actually likely these are carry-overs from the Outcast 2 prototype that can be seen below, as some of the symbol names here seem to align with some of the features we see. To support that theory too, some of the symbol names explicitly mention Cutter, the protagonist from Outcast.

What I posted above is not everything, otherwise you’ll be scrolling forever, so I’ve just dumped all the strings to a file you can find here. Obviously, the meaning behind some of these strings is going to be up to speculation (unless a prototype is released 👀), but some implications are rather intriguing.

Also, before you get too excited, I’ve got a hunch that none of this functionality still exists in Wild Water Adrenaline, but I’d be happy to be proven wrong.

Loadsalua and Modding

Oh, Lua! We know Lua. Yeah, not too surprising when you read up the specs of the engine here (see Fresh Scripting); much of the game logic for this game is actually implemented through Lua which is certainly a first for me when it comes to PlayStation 2 games.

This lead to an interesting thought, what if we could make changes to the scripts here and then repack the game? Hehe, delightfully devilish!

With the files already unpacked, I proceeded to whip up a tool to just repack the data and then recreated the ISO using the following command.

mkisofs -udf -o WILDMOD.ISO ./Wild\ Water/

Aaaaand, nothing.

To troubleshoot, I proceeded to edit a file in the original package just to rule out that there wasn’t some sort of checksum on the package, and that seemed fine.

After some further fiddling and some fixes to my repacking tool, there was still no luck, so on a whim I decided to repack the files in the original order they were in (so basically making a 1:1 copy), and that worked. Okay.

Next I went ahead and edited one of the Lua scripts with some extra additions, but again, nothing.

Long story short, it seems that if the files are any larger, then it doesn’t work, but if the files are smaller they will work fine. This suggests to me that the files are possibly loaded into some sort of fixed-size buffer in the engine. Or as my notes put it…

[...] changing 'English' to 'Butt' worked fine...
But changing it to 'ButtButtButt' did not work, file size increased marginally.

Once again, this is something I probably could confirm by just checking the disasm, but I’ll leave that to someone with a little more time and motivation on their hands. You can find the source code for my repacking tool here (just be aware it depends on this).

They did have documentation for Lua available on their website at some stage (seen here), but much of that has unfortunately been lost.

A’ight, what else?

PC Version

Wild Water Adrenaline never came out on PC, as far as I could see anyway, but a game that also used the same engine, Mountain Bike Adrenaline, did. Unfortunately, though, the way the data is stored in that version of the game seems different, and again, I decided it probably wasn’t worth the time. Not sure how the PlayStation 2 version looks in that respect either, but my bet is that it’s the same as the WWA.

PAKs

So many of the other formats here are proprietary, and I’d elected not to bother getting too in-depth with those, but have some theories as to how they’re structured. Though, the key one here seems to be the ‘PAK’ format.

Each PAK (PAK, GAM, ANM and TEX) appears to be a collection of different classes, each holding either just general data, textures, models or something else, and these are combined into the scene via the merge function that’s executed through the Lua scripts.

It seems once these are ‘merged’ into the scene, they can then be looked up to then perform whatever action as necessary. I’ve presented some examples below.

merge (EFFECTS_DIR.."splashM.pak")
ShaderSpriteParticlePS2.find("lambert2__X"):name("splash2")
ShaderSpriteParticlePS2.find("lambert3__X"):name("splash3")
ShaderHeatParticlePS2.find("lambert4__X"):name("splash4")

[...]

merge(LEVEL_DIR.."CA_Snow.pak")
local snow =Transform.find("SnowEffect")
self.rain = Transform.new("Snow")
snow:parent(self.rain)
snow:position(0,10,0)

[...]

local mesh = SkinMesh.find("Raft")
mesh:visible(false)
World.getActive():remove(mesh)

I don’t think the header for the PAK format is too complex and threw this together at a glance. Might provide a good starting point. But keep in mind it’s just an educated guess!

Should add, if it’s not obvious, but packageClass is a sized string, so the first byte determines it’s size.

Alternate Title

It also seems that their tooling stored the original paths for much of the content used in the game within the PAK files. Some of these even seem to suggest Wild Water Adrenaline had a different title at some point during its development.

R:/XTeam_Rafting/Gfx/Textures/Tex_balise_bonus.tga
P:/XTremeRafting/Gfx/Textures/Tex_Raft_H.tga

I’d figure ‘XTeam’ was a typo there.

Anyway, apologies for the sudden end but that’s about all I’ve got in me, but I do hope it was informative! As usual, if you have any feedback for us, feel free to leave a comment.

For the library, we’ll be making various pieces of documentation and more, easily accessible for anyone to read and search online. Right now, you can find copies of earlier DirectX and MSDN documentation available, and we’ll aim to add and expand on it over time.

You can find the new section here. We haven’t yet updated the homepage of The Data Dungeon to link to the library yet but will be doing so soon.

As usual, if you have any feedback, you can submit it in the dedicated channel in our server.

But nothing is ever quite that simple, is it?

After excitedly extracting everything from the ISO and examining it, it turned out that the ISO that was uploaded appeared to be corrupted in some way, resulting in some files to overlay others upon extracting. This is obviously a big issue as it would stop the build from running correctly on hardware and obviously puts a dent in efforts at examining the content.

Upon investigation, both myself and Daniel soon realised that, fortunately, it just seemed to be a matter of the offsets in the ISO being shifted back by 2048 bytes in certain (and most) cases. After some fiddling, we believe we’ve resolved this and you can find the data extracted correctly here (you can find the original ISO here).

As of yesterday, despite doing this, we still didn’t have any actual luck getting it running on physical hardware (even our “dev kit” with additional memory), so there’s evidently still something not quite right. That said, this has allowed us to view what’s here!

Many of the assets should happily open under any version of Unreal Engine 2, equal or greater than version 2226, if you want to check them out yourself, though this is barring the UKX meshes/animations as it seems they might have made modifications to the animation format. Viewing those in UE Viewer will require you to disable the animation option.

Happy spelunking! If you have any luck getting it running or want to collaborate a bit, feel free to join our Discord.

Aiming to change that, we decided to make an offer to the individual behind the channel, and after acquiring some better capture equipment and sending our Xbox off to have more RAM soldered onto the motherboard, here we are today!

If you’re just interested in downloading the prototype, then click here to skip to the end, otherwise read on!

Verifying the Date

Usually, before we get too deep in examining anything, we’ll try and verify when it’s actually from. When we checked the file timestamps on the Xbox XBEs in this prototype, we were a little puzzled as they did not align with when this particular build was supposedly thrown together. Odd. Pun not intended.

After using a tool to further inspect the other accompanying executables alongside the Xbox XBEs, it appears this prototype is probably from around the 22nd of May 2004 - that’s at least the time the builds were actually compiled, it seems.

Because the timestamps for executable files were wrong, it casts a little bit of doubt over whether any other timestamps in this build are necessarily correct, but unfortunately, we’ve not got much else we can use to date them. Generally, we’re dubious of any timestamp going as far back as 2000 or earlier as it appears to be the general pattern.

To add a little bit to the confusion, when you start the prototype up, there’s a brief splash screen that appears to display ‘JANUARY 2004’ on the bottom right. (Ignore the blue box on the top left, that’s being displayed by our HD upscaler.)

We figure there was probably some other build produced at that time, either produced for preview purposes or some internal milestone (we don’t know), and that splash screen was simply not replaced before this build. It may suggest that the build we have here is a little less formal than whatever was created back then.

Glorious PDBs!

As you probably noticed from the screenshot earlier, this prototype also includes the PDBs. If you’re unfamiliar with these, they’re essentially debug symbols that contain heaps of useful information! In summary, this is going to be a massive help to anyone reverse engineering both this prototype and the final game.

One of the things I personally also love about PDBs, besides the fact that they’re an abundant source of information, is that they usually include references to the original files used in the source tree during compilation, so from that we can get a rough idea of how the project was set up at the time it was compiled. You can see the results of that here.

You’ll likely note the root “exoddus” directory that Oddworld Inhabitants (OWI) used for the project, we’ll get to that shortly.

Stranger’s Engine

Going into this, we actually knew next to nothing about Stranger’s Wrath, especially when it came to the technology behind the game, so this has been quite educational. As it turns out, Stranger’s Wrath uses OWI’s own proprietary game engine, which is unlike the Oddworld Munch’s Oddysee title released prior, which instead used NetImmerse/Gamebryo (we actually confirmed this independently ourselves too, as we’re always a little wary when no citation is provided).

To my knowledge, there’s no formal name provided for the engine that Stranger’s Wrath used, but we’ll refer to it as “Stranger’s engine”, which is a term Lorne Lanning, a founder of OWI, used himself.

The capabilities of the engine were quite respectable for their time, with support for pixel shaders, shadow maps (only from characters), level streaming, SWF-based UI system, a C-like scripting language, a skeletal animation system utilizing Granny 3D, lightmaps, and more. Fancy! Additionally, as clear from nosing at the PDB, the game was written in C++ which isn’t too surprising for the time.

Like many others, OWI used a few third-party libraries to aid the development of the engine.

• Flex + Bison; these are very likely used to aid in the implementation of the scripting language.
• STLport; from the terrible days when compilers didn’t provide very good standard library implementations for C++, and developers usually just rolled their own. This library is still available but unsurprisingly appears to have fallen out of use.
• Granny 3D; mentioned earlier, this is used to provide the skeletal animation system. Quite a common library for the time which has fallen out of use in recent years.

But for the most part, excluding the Xbox SDK and other trivial libraries they might’ve used, that appears to be it and otherwise everything else is home-grown. I was especially impressed by their decision to write their own SWF player to use for the UI, which appears to have been quite ahead of the curve, as other engines later into the decade would adopt Scaleform to support flash-based interfaces rather than rolling their own solution.

It’s actually a bit of a shame as it’s the only title OWI ended up releasing to use this technology, despite plans to use it in their follow-up ill-fated title, The Brutal Ballad of Fangus Klot.

“[…] We wanted to take Stranger’s engine and basically re-skin something more hardcore […]”
Source

Fortunately, while described as an “Xbox-exclusive engine” during an interview, Just Add Water Ltd. eventually gave the engine a bit of love and brought Stranger’s Wrath to Sony’s PlayStation 3 in 2011, eventually followed by a myriad of other platforms.

Some quick reversing…

And that leads onto a little bit of poking and prodding at some formats here. This section is a bit shorter than planned, but we’re sure the community is going to be quick to fill in the rest.

From comparing the final game to this build, it became apparent there were a number of additional folders that the final game didn’t include, such as the following.

• data/fonts
• data/geometry
• data/levels
• data/prefs
• data/scripts
• data/shaders
• data/ui

I’d suspected that the prototype did not actually pull data from some of these locations, given their absence from the final game, and as it appeared a bulk of the data was packed into SMB files just as they also are in the final game (they’re a kind of package file, we’ll talk about them shortly).

We ended up confirming this is probably the case when we tried to run the prototype with the levels and geometry locations removed.

It’s quite likely most of these folders were left-overs from the packaging process used to produce the SMB packages under the data/bundles and data/global locations. Though, oddly enough there should also be a left-over directory for textures too, which appears to be missing, so that might get removed during some other stage of the process.

SMB/GEO Format

Let’s get the big one out the way first, I guess. ‘SMB’ here stands for Shared Memory Block, and the files are essentially a collection of separate data blobs. You could basically consider it a type of package/container file.

From the standpoint of reverse-engineering, the format is terrible to reverse because there doesn’t appear to be any mechanism for knowing up-front how large a given struct/class is going to be (meaning we can’t cleanly skip the ones we don’t want or don’t have reversed), but fortunately using the available PDBs, it was pretty easy to deduce elements of the format.

struct OIStringBuffer
{
	int32_t size;
	char    buffer[ size ];
};

/**
 * There is an older version of the format that uses
 * 0x600ddea1 as it's magic instead and does not have
 * a version number (engine interprets it as version '0')
 */

struct SMBHeader
{
	uint32_t magic;// 0x3a4b5c6d
	if ( magic == 0x3a4b5c6d )
	{
		int32_t version;// 5
	}
	struct OIStringBuffer fileName;
	int32_t               fileOffset;
	int32_t               headerStreamEnd;

	int32_t numContiguousBytes;
	int32_t numSystemBytes;
	if ( magic == 0x3a4b5c6d )
	{
		// if old format, both the below are the same as above
		int32_t contiguousSizeUnpadded;
		int32_t systemSizeUnpadded;

		if ( version >= 3 )
		{
			int32_t numResources;
		}
		if ( version >= 4 )
		{
			int32_t ioMode;
		}
	}

	uint32_t endHeaderMagic;// 0xbeef1234
};

struct SMBHeader header;

As you can see, there are various checks for different versions of the format indicating that the format was expanded on overtime, and the team were obviously keen to retain backwards compatibility. I was a little curious if the final game (or at least the HD PC version) could load any of the SMBs from the prototype, but sadly had little success with shuffling various files around—there are many reasons why this probably didn’t work.

Oh, and this format gets used for models too, which use a geo extension instead of smb.

I’d made a slightly further effort before deciding it was a bit more than I wanted to focus my time on at the moment. Below you can find the main MaterialDef structure outlined, but this is then used as part of the many other subclasses such as MaterialDef_Transparent, MaterialDef_SimpleTextured, MaterialDef_NormalMapped, and so on and so on.

struct MaterialDef
{
	int32_t version;
	if ( version < 19 )
	{
		uint32_t flags;
	}
	else
	{
		uint32_t flags[ 6 ];
	}

	float    glareStartFade;
	float    glareEndFade;
	float    reflectionStrength;
	float    mipmapLodBias;
	uint32_t glareColor;

	float lmTexelSize;
	float lmCreaseAngleDegrees;
	float lmNormalHardness;
};

struct MaterialDef_NormalMapped
{
	int32_t            version;
	struct MaterialDef materialDef;
    // i gave up here...
};

The MaterialDef_* classes are just one collection of many other classes that are serialised as part of the SMB, as you also have the actual geometry classes such as IndexedRenderableVB, PBIndexedRenderableVB and many others for all the various different sets of data that get serialised.

Something I’ll perhaps return to eventually, though I’m fairly sure the community will likely leap at this sooner and faster than I will.

TAG Format

There are seemingly two types of TAG files here, some are in a binary form and others just plaintext. A subset of the latter format can be seen below.

There are multiple types of tags here, which together appear to make up everything that’s featured in the given level.

// TagFile (version: 0, comment lines: 5)
//  ** EDITS TO THIS FILE ARE NOT PRESERVED **.  Change the .mb file instead
// 
// Tags Exporter, version 0.93
//  -       File Exported as: d:/Exoddus/Build/Game/data/levels/Region_01/transition_01_1.tag
// 

<WorldGeometry>
	begin
		m_tagName: ""
		m_tagZone: -1
		m_isInProxyZone: false
		m_tagTransform: 1 [3F800000] 0 [00000000] 0 [00000000] 0 [00000000] 1 [3F800000] 0 [00000000] 0 [00000000] 0 [00000000] 1 [3F800000] 0 [00000000] 0 [00000000] 0 [00000000] 1 [3F800000] 
		m_illuminationColor: 1 [3F800000] 1 [3F800000] 1 [3F800000] 1 [3F800000] 
		m_snapToGround: false
		m_groupName: ""
		m_startsInPurgatory: false
		m_castLightmapShadows: true
		m_scriptFile: ""
		m_scriptArgs: ""
		m_scriptEmb: ""
		m_pathToken: ""
		m_levelPrefs: block
		begin
[...]

My guess is that the plaintext files get converted into the binary format at some stage for speed (or the plaintext files are just an older version), given the binary variations of the format seem to contain the same data within them anyway and would be more optimal to parse.

Checking out a couple models

There don’t seem to be that many ‘test’ models left hanging around, though I can’t speak for the rest of the models available (it would take someone with a bit more knowledge on Stranger’s Wrath than us to identify what is of interest).

There were two test models amongst the files that I was particularly interested to take a look at; test_ajb.geo and test_dummy.geo. Given the annoying complexity of parsing the file format right now I instead opted to brute-force it by just identifying the given tag and then pulling the vertex coordinates directory, though unfortunately neither of these appear to be quite as interesting as I had originally hoped.

This first one seen below is the test_dummy.geo mesh, which is hard to recognise.

The second one here is test_ajb.geo which looks like a collection of shapes.

There are a few other test models and other leftovers amongst the files, but they didn’t sound particularly interesting to me, so I didn’t get round to taking a look at them. And no, as far as I could tell, there don’t appear to be any particularly interesting characters or cut enemies as far as I could see, but I’m hopefully wrong!

It would be great to see the community whip up a model viewer which probably wouldn’t be too difficult at all with the information available in the PDBs, and such a thing could be used to more easily identify the models and any differences.

“Exoddus”

When poking around various files, we stumbled upon references to “Exoddus”, which appears to be the internal location that Stranger’s Wrath project was developed under, at least.

But why “Exoddus”? Given our own lack of knowledge on the Oddworld franchise at the time, Abe’s Exoddus sprung to mind, which didn’t make any sense given that was a 2D game developed with an incredibly different engine, quite a significant amount of time before Stranger’s Wrath. It was doubtful Stranger’s Wrath was built upon the engine used for Abe’s Exoddus.

As we soon learned, there was intended to be a follow-up to Munch’s Oddysee dubbed “Munch’s Exoddus”, which didn’t see a release in the end. Initially, the only piece of information we could find was on the Oddworld Wiki - no citations though (the administrator has since added a notice on the front page underlining the situation with dubious content on the site). We tried a few other fan sites, such as this, this, and stumbled upon this video, but again, no citations. There was a reference here but again, it’s just a passing reference of the title.

All we wanted to determine was 1) was Munch’s Exoddus actually a title in development at some point, or just a rumor, and 2) did Stranger’s Wrath have any relationship with it?

Grinding my teeth into paste at this point, I eventually jumped onto the Oddworld Discord and asked for help, and fortunately, the community there pointed us in the right direction and introduced us to the fantastic site, Magog On The March, and there it was…

Stranger’s Wrath was Munch’s Exoddus, and actually there is a build somewhere, on Xbox, which has Stranger and Munch hopping round the world. And it’s like OK, this is a bit weird now.
Source

Given that then, it seems reasonable to conclude that the Exoddus directory then that Stranger’s Wrath was seemingly located under during its development was a result of it being originally intended as the follow-up to Munch’s Oddysee before it evolved into the game we know it as today.

Taking a Listen

We thought it’d be interesting to see if any sounds here were different from what ended up shipping in the final game. Originally I was going to write our own tool for doing this, and then realised tools already existed after wasting about a day on it. Me smart. Brain big. Smack rock.

On Windows, WinMerge is usually a great tool for this sort of thing, as it lets you quickly compare multiple directories for instance, so we can point it on one side to the prototype and on the other, the retail release (if you’re a Linux user, like us, Meld seems to be alright too, but I’ve not used it quite as much).

Initially, it looked pretty promising.

Unfortunately, as it turns out, the XWB files in the retail release don’t seem to retain the unique names for each of the audio tracks within, making quick comparisons tricky without spending a lot of time on it. It means some of these might actually be exactly the same, but the difference is just the lack of names.

To add to the pain, the number of banks stored in some of these files has changed between the final release and the prototype, so some new sounds have been added and some old sounds have been removed, and it’s difficult to quickly determine what’s what because of the lack of names in the release.

You could probably diff the audio_master.h file between the release and prototype to determine what new banks have been added (or removed) to aid in the process of plundering the XWB files, but we didn’t have time to do this ourselves.

That said, it at least looks like some of the music tracks in the prototype are higher quality than those in the final release, which may be the case for some sound effects too.

Playing the Prototype

So we’re not sure many people are going to be able to run this right now. As it stands, we weren’t able to successfully get this running under Cxbx-Reloaded or Xemu. In the end we resorted to good ol’ hardware instead, but obviously not everyone has access to a modded Xbox with more RAM or an Xbox development kit, so we decided to record as much footage of the prototype as possible for others to analyse.

If you can run this, you’ll need to move one of the Xbox executables (the ‘xbe’ files) into the same directory as the ‘data’ folder.

Originally the plan was to split these videos up based on the bounty, but that didn’t quite work out due to issues with video editing software, so you’re getting these videos pretty much untouched… So, forewarning; I absolutely suck at playing this game, so apologies for that.

There are so many differences here, mind that I’m not going to point out every single one but rather those that stood out to me the most.

For instance, as you can see upon starting a new game (1:11), there is nothing prior to the moment you start playing. We drop in at the first town immediately! No introduction cutscene, either. As a matter of fact, you’ll notice that the tutorials originally featured at the start of the final game in their own unique area (see here) are instead integrated with the rest of the general flow here.

As we move through the tunnel towards our goal (3:56), we meet two characters talking over the body of another character which then introduces us to the capture mechanic. This is all completely absent from the final game.

These two characters are in the same area in the final game but are simply wondering around instead.

Following this, we see how the bridge gets destroyed and are subsequently introduced to jumping to reach the area on the other side. When the player approaches this area in the final game, the bridge is already destroyed.

It’s curious why OWI decided to change this approach towards teaching the player the mechanics, as what they’ve done here certainly felt more natural. Instead, the tutorial introduced in the final game is, in my opinion, significantly more intrusive (as a matter of fact, I believe the Nintendo Switch release of the game introduced an option to skip the entire tutorial section).

Another curious change is at the Water Facility, which appears to feature a separate area for the boss fight, which is found at the top of the tower (34:20).

And again, much to our surprise, a cutscene plays out here introducing us to our bounty not featured in the final game.

You likely noticed a few other differences in our approach to the Water Facility. Moreover, at the facility itself, such as along the top of the building, there are additional barriers, making it much harder to hit the enemies on the roof (30:55).

Or that the door leading into the inner room of the building is wooden instead (31:13), allowing the player to break it (which makes sense given that in the final game this was likely changed to accommodate the change in location for the boss fight).

As stated earlier, there are just so many differences throughout this build it would be probably impossible for us to easily list them all, which is all the more reason why it’s going to be great to see this build out there for others to explore.

If there’s a desire to see more footage, let us know!

Download

And this is probably what most of you have been after; grab it here.

If you want to support what we do, we’re not accepting donations at this time, but any and all feedback is appreciated; feel free to join our Discord or leave a comment letting us know what you think!