Noting the lack of documentation on this and desiring to take a bit of a break from what I’ve been working on, a fixation took upon me, and I did an incredibly normal sane thing; I took a look at every single model in the game, to see which potentially carried over from an earlier point of development, when the game used a different art style altogether, and provided supporting evidence where possible.

For those that don’t know, Infinite had quite a lengthy development cycle. So long it apparently warranted its own Wikipedia page. Given the prolonged development cycle the original BioShock also went through, and seemingly the new BioShock is also going through, perhaps this should be viewed as something of a tradition at this point, as Infinite evidently wasn’t unique in this respect.

Anyway, what we’re primarily interested in here is that at one point, very early on, the team experimented with a particular art style known as Art Nouveau.

A metro station entrance in Paris. A good example of the Art Nouveau style.

It’s beautiful, I love it to death.

It’s worth giving Robert Schmutzler’s Art Nouveau book a read here or Geoffrey Warren’s All Color Book of Art Nouveau here if you want to see more examples of the style. There are many others if you look under the topic on Internet Archive here. It wouldn’t actually be all that surprising if some of these are the same books the art team on Infinite referenced themselves at some point or another.

Mind, I’m not an expert on the subject, beyond an admirer of it, but a rather funny titbit that gave me a little chuckle is that Nouveau translates as New in French. So it’s uh, Art New. But in France it was referred to as Style moderne, so, style modern. And if I understand right, the term apparently originated in the UK where it was referred to as Modern Style? Very creative…

Below are some screenshots showing an earlier iteration of the game which incorporated this style. Some of these are from The Art of BioShock Infinite book, which I do recommend giving a look!

And some artwork, for good measure.

Why did they drop it?

At PAX 2011, it was said they felt the style was “… claustrophobic, too similar to Rapture”. This was again mentioned during an interview with Shawn Robertson, lead artist, with Engadget in 2011; “… first few maps we built might as well have been Rapture. We brought the clouds in, it was dark and stormy, the clouds had a greenish tinge to them, it was very claustrophobic.”

Additionally, according to Jamie McNulty, the lead environment artist on the game, “… we learned how hard it was to have so many french curves and round things in a level and running well on an xbox [360] and ps3.” So besides wanting to move away from Rapture a bit more, the decision may have also been due to technical concerns.

But this is why we’re here today! While the art style was ultimately dropped, it’s not entirely gone from Columbia, and elements of it do actually survive in the finished title. Very subtly, mind.

Interior Set

First up we’re going to look at a set of models referred to as Int_Set_01, which are essentially a collection of interior building blocks. These are actually used widely throughout the game, for all sorts of things. Even as part of a dressing table in one location!

Reusing models like this all over the place is a widespread practice. Without getting too technical, it’s a lot cheaper to do this instead of building your level out with lots of dense BSP details as the engine can more easily cache the geometry on the GPU and even use instancing; fewer explicit requests to the GPU and less work on the CPU.

You would be very surprised how many uses you can get out of rotating and scaling things around.

To my surprise there’s no Int_Set_02 etc., and the only other “Int_Set_” collection is called NrsyInt_Set_01, which is very clearly something produced after the change in art style (so we’ll be skipping that).

Below is a gallery of each model individually just to give you a better look (mind these are without the specular and normal map).

It’s worth mentioning that for some of these there are alternate textures.

The Art Nouveau aesthetic is quite subtle for these, likely why they’re still in such wide use, but you can see some of it seeping through with the curved organic elements coming through on a few of them.

I appreciate it if you’re not quite convinced or perhaps even confused for the moment. Perhaps, even afraid… Do not fear! To support my point, we can actually see some of these models in use in an old screenshot. Per my uh, rather crude overlay here.

So yeah, these, or at least certainly some of them, do appear to have been carried over from the earlier work on the game. Neat, right? It makes you really appreciate the legacy some props in the game might have that you otherwise might not have thought about.

That said, this isn’t all that surprising. Models are quite time-consuming to produce. And again, the style is very subtle for these; they still fit very well with the Columbia that shipped. So much so that I’d not even realised until working on this piece (I started off looking at something completely different when I’d started).

Something I’d noticed while working on the comparison above is that the taller columns are just the shorter columns stretched like so.

This is despite there being two taller columns in the set (here and here), which may imply that those weren’t yet created at the time they made the environment featured in the screenshot. Perhaps the level designers stretching the shorter column like this prompted the artists to create the taller columns?

They really got a lot of use out of this set of models in general. I don’t want to go too crazy, as we’ve got plenty more to look at, but even in some early paintovers you can see many of them being used; just as one example I’ve highlighted below where they’ve reused the same model with different scales applied to get a lot of use out of it.

See if you can spot some others! There’s another paintover where you can see some of these being used if you look close, but I think you get the idea. The team got good use out of these, and they survived seemingly almost from start to end!

As a final note of curiosity, in the September 2010 demo there’s actually an interesting variation of the set that appears to be painted with gold trims.

This is the only bit of public media I’m aware of where these show up, and this texture variation is apparently gone from the final game.

There’s a lot more I could say about that 2010 demo, but I’ll fortunately refrain, at least for today.

Furniture

Let’s look at our next models here, all part of a furniture set. I’m fairly sure a lot of people have noticed a couple of these already, but again, not really documented anywhere to my knowledge.

The names for each of these are prefixed with the name Nouveau, so they’re explicitly indicated to fit that style, and they certainly appear to do so. Well, certainly the first two. The others are just, uhm, rugs.

You can see some better renders of the chair and sofa produced by the artist that created them available below. The first one, which shows the high-poly version of the model, really gives you an appreciation for the amount of detail the artists put into these.

And as before, they’re used all over the damn place in the final game.

Clearly quite a favourite bit of furnishing in Columbia.

We can see what appears to be the sofa in the screenshot we did the comparison for earlier. There is also what appears to be the same chair, possibly tipped over in the foreground but certainly in the background at least.

I struggled a little bit more than expected trying to get it to match up, so only did so for the sofa. Which is still far from perfect, but you get the idea.

The rugs visible in the same screenshot may be the same as those within the same set, but it’s really too hard to tell for certain. Not to mention they look slightly redder? I think it’s quite likely to at least be the same model, but I just can’t be sure about the texture.

The only other texture variation I can see for the same model in the final game is called Nouveau_Runner_RugFink and that absolutely isn’t the same.

The chair and sofa, of course, also appear in the previously mentioned September 2010 demo, looking much the same as they do in the final game.

Glass Walkway

Next up is probably my favourite set just because it’s so distinct and yet so easy to miss. Particularly because you’ll never think to look up!

It’s quite clear from the texturing work on the glass here that these are following the Art Nouveau styling.

It actually took me a little while to track these down in one of the levels. At least the version of the model using the stylised glass. I’d spotted it while playing, then totally forgot where it was and wasted a good few hours feeling like I’d hallucinated it. Anyway, you can see an example of it used in the final game per the screenshot below.

What caught me off guard a little bit with this one is that we can see this in the paintover we were looking at earlier, as you can see below. I don’t think a full on comparison is necessary here as it’s very obvious.

But that’s not all! We can also see what appears to be the same models in this very short clip from the earlier iteration of the game, shown at PAX East in 2011.

It’s notable that there’s a special end piece visible in the paintover and other images above, allowing it to curve round. This specific model doesn’t appear to exist in the final game, though there’s still a spot for it that remains in the texture sheet.

Tesla Coils

These took me a little while when I’d first looked at them, because they don’t really have any distinct look going for them, so didn’t really pass the initial style test.

There were tesla coils visible in the earlier screenshots of Infinite, but did they really match? They certainly looked similar. And eventually, yeah, I did conclude at least one of them is most certainly the same model.

Below is another poor attempt at an overlay, apologies!

So while these don’t fall under the Art Nouveau style, they do appear to be yet another asset certainly carried over from the earlier iteration of the game.

These are particularly hard to match up due to the models having a lot more going on, often scaled up and down to various proportions, and the few screenshots we’ve got are not showing them fantastically clearly.

Here’s how they actually look in the final game. You’ll notice much like those earlier screenshots, the glass bulb near the bottom of the coil is supposed to be see-through.

One thing perculiar in this screenshot is that it looks like there are possibly other variations that are not in the final game?

What stood out to me was this detailing, which isn’t visible with the models we’ve got.

Well, unless I’m mistaken anyway. That’s enough about tesla coils.

Weapons

This is already documented elsewhere, but for those that don’t know, the older third-person variation of the machine gun featured in the Gibson Girl clip is still amongst the models in the final game, as seen below.

This is under a Weapons_Trashcan set, so, I guess they had already scrapped it but for whatever reason it still ended up being included.

The machine gun that ended up being used in the game has the same model name but is prefixed with “new”, so it was quite explicitly created to replace this older design.

Another weapon that survived, as you may have noticed earlier if you have a keen eye, is the Hand Cannon! We can see it featured in the PAX East 2011 clip from earlier (though in this instance I pulled these images from GameSpot’s feed, as it’s slightly clearer there).

Though the textures seem to have been altered since this point in development.

It also shows up in a short, clearly early, clip, during Shawn Robertson’s GDC presentation, Creating Bioshock Infinite’s Elizabeth, here.

This certainly looks like the same texture in use in the PAX East 2011 clip, so gives us a better look at it. Generally, it looks incredibly similar to the final Hand Cannon design from what little can be made out. Just generally more dull-looking, though this could just be down to lighting.

Awning

Thought I was done? So did I… There’s an awning model in the game with different textures.

The dark red awning seen above appears to be visible in the screenshot here. Due to the perspective in the screenshot, it was too difficult to do a proper overlay for this one, but I’m fairly certain it’s the same model.

So this appears to be another one that was carried over. Which, much like the interior set we looked at earlier, isn’t too surprising as it still fits in well.

Special Mentions

For the sake of time, I’ll just quickly run through some things that didn’t seem worth having entire sections about. These are mostly things that look like they might have come from the Art Nouveau iteration, but I can’t really prove it with any sort of solid comparison.

Planter

Another fairly distinct one, but only a couple of models appear under this set, appearing to only utilise the top part of the texture sheet, implying that other models are actually missing.

Worth adding the circular model in the first image does appear in the September 2010 footage as well, very briefly.

Bar Set

These I strongly suspect comes from the earlier era of development. Some of them appear in at least the September 2010 footage but unfortunately, aren’t visible in anything earlier. Hence, why they’re here under special mentions.

Once again, a very popular set in Columbia.

I think the first screenshot above is actually quite a good example of the difference in styling, where you can visibly see the clearly Art Nouveau inspired design sticking out a little alongside those produced after the shift.

Below are those assets side-by-side, so you can view the difference more clearly for yourself.

Furniture Tables

Yup, tables.

Like a lot of what we’ve looked at before, again, very popular in Columbia, apparently.

Bar Assets

A couple of lamps; one broken and one not.

The glass pattern on these is very similar to that of the uh, central ceiling chandelier light thing, visible in this shot, but not the same.

The non-broken version of the lamp can be found all over the place.

Nouveau Chimney

If it wasn’t for the name this uses internally, it wouldn’t have been mentioned.

Surprisingly, there are no chimneys visible in the earliest screenshots of BioShock Infinite, or earliest clips either, unless I’m blind. So I couldn’t verify it. Into the special mentions pit with ye!

Nouveau Grate

Not sure at all where this is still used in the final game.

Metal Grate

I know the first of is used in parts of the Hall of Heroes in the final game, but I’m not so sure about the others.

Bistro Set

This first image shows two models that are part of what’s internally called the Bistro Set. I’ve not noticed them in any of the pre-release material I’ve looked at, so it’s not outside the realm of possibility that these were introduced later in development.

Something about their texture sheet also generally looks a lot cleaner to me than some of the other models we’ve looked at until now, which also makes me doubly unsure if these weren’t just added later in development.

These bastards were also responsible for sending me down this rabbit hole in the first place. Shakes fist angrily at them.

The End

Oh my goodness, is it over? This was supposed to be a short piece! But it just kept going and going.

One thing I most certainly did not do, particularly because it probably would’ve driven me rather insane, is checking out all the textures in the game. This is a bit beyond my patience. But I’ve no doubt there’s probably more to see there.

Anyway, if you’ve enjoyed this, do let me know! If you want to submit any feedback, you can either do so via the comments section below or you can join our Discord server and share your thoughts there.

Until next time, farewell…

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.