Earlier in the year I stumbled upon a demonstration build of Bullfrog’s cancelled Creation game that was shared publicly on the fantastic website, Internet Archive.

I don’t know the complete details of this demo but supposedly this was shared by magazine publications at some point so it’s not necessarily a “leak”, as I’ve sometimes seen it referred to. Yeah that’s right, you pal hasn’t got his hands on some super secret demo.

If you’re unsure as to what exactly Creation is, I highly recommend taking a look at the Wikipedia page regarding the game, as this gives quite a nice overview and also outlines it’s surprisingly dark backstory.

However, if you’re not up to reading the Wikipedia page, for whatever silly reason, then to summarise, Creation is described as a real-time strategy game in which the player controls a submarine and attempts to defend an alien world from a syndicate that seeks to harvest the planet of a valuable alien fungi.

If the story is getting you down, just pretend this is Chuck’s underwater adventure to reunite with his long lost Wilson.

And yes, it was intended to have links to Bullfrog’s Syndicate games, or more specifically, Syndicate Wars.

The demo itself is relatively simple on the face of it. It’s a cut down version of the full experience (unsurprisingly) that lets you move around a map viewing various objects that were to be featured in the game. It provides a teaser video setting a vague premise of the game, some instructions on how to play and then throws you straight into the deep blue.

I wouldn’t say the controls are fantastic, but this is 1995, and this was hardly the underwater Star Citizen in terms of budget and scope. And no, crashing into the ground won’t kill you or harm you - so fortunately you can flail as much as you like.

After a set amount of time the demo will take control away from you and begin moving you directly towards a specific point in the map, with absolutely no regard for the terrain, jeez where did this auto-pilot navigator thing learn to drive? Eventually you might see some textures representing what appear to be the ruins of something, I guess, before coming across a collection of egg-shaped pods; likely representing the fungi infestation of the planet.

After a few seconds, an animated tentacle appears, surprise, before the demo abruptly ends. This gave me the impression they may have been aiming towards providing an atmospheric but also creepy experience, but it’s quite hard to gauge by such a limited demonstration of the game.

Diving deeper

So as usual, we’re going to look a little beyond what they want you to see here and actually dive into the files, and this definitely turned out to be considerably more interesting than I initially anticipated, particularly because there is a substantial amount of left-over data here.

I would like to say great care was taken in packing this demo together but it’s not unusual for the time for bits of left-over or unused content to still remain, especially in a time before software solutions for version control were widely used.

Keep in mind that I won’t be going over the audio side of things in this article, I have taken a glimpse and I can confirm there are some basic music tracks in the demo, but I haven’t had the time to compile this information down into something I can easily present to you guys. The guys over at The Cutting Room Floor Wiki have made a start on this.

Fortunately for us, it looks like there’s more unused content here than what is actually used in the demo itself and while we won’t be able to cover all of it today, we will certainly be scratching the surface of what’s here to uncover.

Where are we actually diving?

One of the first things I began looking at was how the level was stored by the game, because simply being able to see the entire thing seemed like a pretty neat idea at the time.

If you want some more details in regards to the format itself, I would suggest checking out my notes, but basically the data for the terrain is stored in the game’s creatively named MAP format and the data for any objects spawned in the level is stored in this other LEV format - on launch the game will load the DEFAULT level under the LEVELS directory.

The game does also appear to have strings in the executable specifying levels prefixed with “cre8” followed by a number, which may have been the convention being used for levels that were intended for the full game at the time. Interesting huh? Nah, not really. Or maybe?

You may notice that there is a another LEV file here that’s named BDEFAULT.LEV, but the game wouldn’t load this unless we replaced the existing DEFAULT.LEV. Maybe it’s an earlier botched attempt? Whoops.

It is different from the LEV that the game loads, though I haven’t yet had the time to compare the two properly and won’t be doing so until I have this format completely figured out - loading it in produced nothing too different I could see from first appearances.

Wait, format completely figured out you say? Unfortunately at this time I haven’t had the opportunity to look at the LEV format in detail. Yeah I know, I’m sorry. So for now we’ll be looking at what’s provided to us in the MAP format.

The MAP format itself is essentially made up of multiple channels, which together provide information on each individual tile in the game - altogether there are 65,536 tiles - which form a 256x256 grid.

For each tile, the format provides details such as the height of the tile and the texture that tile uses, though while there is other data provided but it’s use is currently unclear, so we’ll be ignoring these for now.

If we were to display the height and texture channels as images, we get the following.

Height data for each tile.

Texture indices for each tile.

If we could see the entire terrain in 3D we would see something like the following which should give you a rough idea.

Textures used for the terrain are stored in a texture atlas, made up of 64 64x64 tiles. Each texture index provided by each tile translates to a slot on the texture atlas - from left to right and down, then repeat.

This is stored outside of the map data in a DATA/BLOCK64.DAT file, which is just a standard VGA image, meaning it requires a 256-colour palette.

There is also a DATA/BLOCK32.DAT file, but this isn’t used in the demo and there doesn’t appear to be any matching palette for it, so it’s hard to make any definite comment. A damn shame.

From what we know already from the 64 version of this file, we can probably safely assume that each tile here is 32x32. And again, if that’s the case then there are 64 tiles here.

Because there are so many tiles clustered together at the bottom, and because they all look derived from one another, it’s possible these may have been intended to be used for the ocean surface, a feature that’s sadly absent in the demo, but because of the incorrect palette I could be totally wrong; who knows!

And you probably spotted that odd single tile that doesn’t fit within the grid. No idea about that one, the little rascal, though considering the amount of empty space here, this was probably unfinished at the time of this demo. For all we know, that one tile was simply left there by the artist as reference for something to come, or just by accident.

Moving back to our wonderful 64x64 texture atlas. Each texture applied to each tile is 64x64 - if we were to represent the entire map as a single image it would work out to be 16,384x16,384; just over 800 megabytes of data, which really shows the value of using a texture atlas.

This is something I actually generated for this article originally, but I think it was pushing it a little bit for all you web people, so below is a significantly smaller and more compact version that should give you a good idea.

Unfortunately, yes, it’s a barren wasteland for the most part. This is why I’m keen to see what we’ll see from the LEV format, when I find the time!

If you’re absolutely insane, I’ve made the full-version of the overview available here. It’s a heavily compressed PNG, in a compressed ZIP, because I didn’t want to risk an unfortunate soul accidentally opening it on his Oric Atmos and subsequently burning down his entire house.

Can’t be going diving without a good overlay

In 1995, you couldn’t really expect to be able to have entirely 3D submarine internals, computers just weren’t up to it, heck your computer may still not be up for it, I told you to upgrade from that 486 already, didn’t I? So instead, Bullfrog decided to use an image overlaid on the screen instead.

It looks like this provided Bullfrog with an opportunity to speed up the rendering; your view is obscured by a window looking outside the overlay, which fortunately means we just need to draw what you’re able to see outside that window and ignore the rest.

While it’s hard to actually see this at work in the low resolution mode the game launches in, we can switch to a higher-resolution mode which doesn’t feature any overlay.

Pressing R let’s us see this in action, as it switches to an incredible 640x400 resolution - well that’s impressive for the time, okay!? Damn kids and their 4K HDR Ultra-HD OLED displays.

Rather than rendering to the complete 640x400 buffer, instead the game is actually rendering the world to a 516x400 buffer - saving us filling in 124 columns! Of course, those columns are then filled in by the overlay (or would have been), but an optimisation is an optimisation, no matter how small.

So where on earth does the overlay come from? Within the data files of the game, found under the DATA directory (who’d have thought), are several PANEL files. These should contain data that is used for the screen overlay seen in the demo, I mean you would expect them to, but we’ll talk about this further down.

├── PANEL.DAT       HUD panel image data
├── PANELHI.DAT     Highly detailed version of the HUD (UNUSED)
├── PANELLO.DAT     Looks like debug symbols ... ? Very odd (UNUSED)
├── PANEL.TAB       HUD panel index data

Only one of these is actually used in the demo but it’s cut down into a number of images and packed into Bullfrog’s standard sprite format - something that’s been in use since Syndicate.

The files that make this up are DATA/PANEL.DAT, which contains the actual image data that makes up the panel, and then DATA/PANEL.TAB, which provides a table of each sprite inside the DAT file.

As appears to be the case for all data stored in this format for Creation, the image data is compressed using run-length encoding, though luckily for us the Dungeon Keeper community had already developed tools that takes care of the conversion of these resources for us.

In-game screenshot showing the low-resolution overlay/panel.

Interestingly, DATA/PANELHI.DAT on the other hand is a 640x480 version of the panel that’s unused in the demo. This would have more than likely been used in the high-resolution mode that was to be supported in the game, though that uses a 640x400 resolution, hrm.

This particular image is stored as a standard VGA image, which when combined with one of the palettes provided in the game, produces the following image.

PANELHI.png

Yes, it does look vaguely similar to the lower-resolution version.

It’s a shame we didn’t get to see this displayed in the demo, as it proves to be a very nice rendition of the submarine interior - though very likely to be incomplete when considering the fact that the game was still in development at the time.

The blue/green coloured panels in the game were likely changed to different colours when loaded in by the game, we can certainly determine that the dark blue represented an alpha-channel here so we could see through it and into the ocean, it’s hard to know for sure how the other panels would have operated however.

The last panel that was included here was DATA/PANELLO.DAT, and of course the expectation here was that this would have been a complete copy of lower-resolution version of the panel, perhaps the same as the one featured in the demo, but instead what we see here appears to be some random debug data, though I can’t say for sure - regardless it’s certainly not what I expected.

I have a slight feeling that this file was simply overwritten with this data and was likely something else entirely originally, but it’s odd nonetheless. Curses.

Recording your own demo

Wow, bet you really want to show your friends how you played the Creation demo right?

Like a number of other Bullfrog game’s, the game features a few command line arguments that can be provided when launching the executable. These are typically provided in the fashion of a hyphen followed immediately by the argument/command.

Creation provides a few arguments for recording gameplay and playing it back - neat! And even better, they work - also neat!

-record      Works!
-playback    Works!
-movie       Works! (same as above?)

Above are some of my notes, and yes, they all work; use record and move around the ocean a little bit, and the game will be generating a RECORD.PKT file in it’s working directory.

Afterwards, you just need to specify playback on the command line, and behold! You’ll be able to see your slick ocean diving skills, and even share them amongst all your underwater friends, isn’t that great?

Where do maps come from?

I’m glad you asked that question little Timmy, it’s about time we told you.

So perhaps to the surprise of some, Creation was to feature it’s own level editor, which from the looks of things could have been used to change the terrain and very likely much more.

Some strings left in the demo, or more specifically, strings that reveal the original source-tree used to produce the demo, reference an editor.

    C:\CRE8DEMO\editor\edit.cpp
    C:\CRE8DEMO\editor.c

And even better, we can activate the editor via the demo which can be done by passing -editor as an argument when launching the game.

Oh my god, this is incredible! Well I’m afraid I’ll have to stop you there. Unfortunately it looks like Bullfrog made the approach to stub the editor out of this demo which shouldn’t come as much of a surprise - you don’t want people having too much fun right?

Once the editor mode is enabled in the demo, the only thing you can expect is the inability to move. It’s likely because the editor may actually be “active”, so the input is getting passed to whatever interface was to be in it’s place, but that code was evidently disabled and therefore you’re at the end of your adventure - or are you?

Fortunately for us, there’s a little bit more here, and perhaps something a little more exciting for some as well!

This comes in the appearance of resources that were intended to be used for the editor. Buttons, to be precise. Albeit displayed with the wrong palette as this appeared to be missing, but very interesting nonetheless.

It’s hard to know exactly what to take away from these buttons, some points I will be making further down in this article, but they give us a glimpse into the tool-set the Bullfrog developers had at their disposal during the game’s development.

So to recap; when a level designer working on Creation loves a design very much, he’ll create it in a dedicated pipeline built within the game itself and then maybe, or maybe not, see it ship with the game. Or maybe he’ll just get bored and produce something like this. So now you know, Timmy.

No escape!

A number of Bullfrog games allowed for levels to wrap-around (e.g. Magic Carpet, Powermonger, Genewars, Populous the Beginning). That is to say, if I keep moving forwards, I will never reach the end of the map because it will always continue to wrap around on itself; eventually I will end up at the same point.

It’s a creative way to avoid creating obvious barriers in levels to prevent players from going out of bounds and gives a good impression that the world is considerably bigger than it actually is.

This is something we also see exploited in Creation but unusually this applies to moving upwards in the demo as well - there’s no bound height when moving upwards. It’s more than likely an unintentional glitch due to a feature left out of the demo.

Why is that? Well to explain, it seems pretty evident that Creation was to actually feature an ocean surface that would have more than likely stopped the player if they were to go too high, which is a feature that oddly remains absent in the demo.

How do we know this? There’s plenty of evidence for it, some of the buttons featured in the editor show an ocean level as you can see below.

And then we have this incredible screenshot pulled from a magazine, courtesy of Unseen64, which shows a ship in the game drifting along below what looks to be the ocean sea level.

creation-bullfrog-production-05.jpg

Besides the buttons used for the editor, there don’t appear to be any other references to the ocean surface in the demo.

Conclusions?

It’s hard to tell from the demo how well Creation would have been received had it been released, as the demo seems to only give us a tiny tiny amount of what was in store for us.

Like so many other games out there, it turned out there was a lot more to see here than on the surface (ho ho, no). There’s plenty more I could look at here and I really do hope to eventually, but time is limited and I hope I’ve inspired others to perhaps get involved.

If you made it this far, definitely leave me a message and let me know what you thought. Now I’m off to play the new Red Dead Redemption 2. Cya!