This document is something I’ve worked on, on and off, for a long time now but it’s something I’ve been keen to get published considering this is a game I have a special spot for.
So, what exactly is this ‘bible’? I guess one might consider it as an “all you need to know about” guide that details both the general state and mechanics of Prey during different parts of its development. I’d like to liken it as its own complete design documentation for the game, trying to make sense of what each of the teams that were involved in developing the game were aiming for, keeping in mind that there will be a lot of gaps which we can’t fill.
That being said, I really hope this document gives you a good sense of what each of Prey’s development teams were trying to accomplish while they were working on the game. It’s a lot to cover though, an era spanning from 1995 to 2006 with a huge number of people involved.
There’s a great number of games that have a great depth of history but I don’t think any of them come close to the history behind the game Prey. It’s gone through four different development teams to get to where it is today, and while some might want to brush its history under a carpet *cough* Zenimax Media *cough-splutter* I think it’s important that we work hard to preserve what we can for the future; especially for games such as this that represent a very different era in game development.
What you’re going to read has been collected from a great number of different sources, which I’ve tried to provide throughout, but the greatest source of information here will typically be from a package of Prey’s own design documents from ca.1998 to 2000 which were essentially in their “final form” as they were handed over to Human Head for yet another iteration of the game to begin. I’ll include links whenever possible to each of these and will try to mirror them myself just to produce an archive of articles concerning the game.
There’s always only so much I can dive into at a time and there’s likely a lot I’m going to miss here, so as usual, I highly encourage others to get in touch and to contribute any information that might otherwise be missing. I would have loved to have covered Prey 2 here as well, but that’s a completely different story altogether.
I’ve been meaning to do this for a while now, but we now have a Discord server!
Feel free to join up, chat about game development, cut content, reverse engineering, or whatever you feel you want to share with the rest of us. If you’re interested to see slightly more frequent blobs of updates then this will be the place to see them too.
I know very little of the Iron Storm game, admittedly, but Saturday evening I decided to take a look at the game and wrote a loader for it’s package format. The package format used in Iron Storm is made up of an LST file, which is basically an index of all the files within the IBF file – the IBF being the actual file that contains the data used by the game.
There isn’t a whole lot to say about either of these but I’ve provided the information below for prosperity; hopefully someone will make something neat out of it!
All the data used by Iron Storm that I’ve seen is unsurprisingly stored as little-endian, but this is worth keeping in mind if you’d like your loader to work on multiple architectures.
The LST format is very simple really. The first part of the file appears to be some sort of identification which will always be ‘_TSL1.0V’, I’m not aware of any exceptions to this, and this is then followed by a 32-bit unsigned integer, which represents the number of indices within the LST file, and finally this is immediately followed by the first index.
So in other words, you could imagine the header structured like so…
So first you have the name of the file within the IBF, this has a maximum length of 64 bytes. This is then followed by the actual offset of the data within the package and then the length, both of which are 32-bit unsigned integers.
Keep in mind that the names are null terminated, although there may be some garbage after each null.
What immediately threw me off while looking at the IBF format, is that Iron Storm appears to use the Resource Interchange File Format (RIFF) for not just audio data, which is typically where you’ll see this used, but for it’s textures and models as well. It’s certainly not something I’ve seen done before for game content, but there’s not really any reason why you wouldn’t do it I guess.
In the case of audio data, it’s worth noting the offset provided in the LST will actually skip over the additional RIFF information before the start of the actual WAV, which is very likely because the engine had no need of it itself and it’s only specific to whatever tools the developers were using to produce these packages.
Otherwise there’s nothing much else to say about the IBF format, if you use the offset and length from each index you’ll be able to find that data within the IBF which you can then copy into memory and do whatever with.
If you’re thinking of producing modifications and other alterations to the game, I think it would be possible to do by repackaging the IBF and LST when altering their contents (if the size is different anyway), but otherwise the game is quite clearly not produced with community modifications in mind. You’re going to be incredibly constrained by what you can do here.
That’s it for now, I’m planning on looking into both the model format and texture formats if I find the time. The texture format appears to be incredibly simple though and even provides descriptors within the RIFF block so that you know exactly what type of image data it is (DXT5 and TGA are two I’ve seen).
At the European Computer Trade Show, on September 6th 2000, Epic Games unveiled a technology demonstration of the Unreal Engine, showing new features and capabilities that they were introducing to the engine. A number of new features were shown that Epic Games were looking to introduce to the engine in the short term, along with PlayStation 2 support, but with the long term goal of producing a new engine entirely. This iteration of the engine eventually came to be known as the Warfare engine, now known as Unreal Engine 2, the predecessor to Unreal Engine 3.
The technology demonstration was unsurprisingly comprised of a number of different demonstrations but a lot of these provide some fascinating insight into the development of the engine and the upcoming games at the time. We’ll be going over each of these as they appeared in the video below and doing a short analysis on each.
The first scene in the video shows us a demonstration of the then new skeletal animation introduced to Unreal Engine. The model shown here, which you can see again in the above screenshot, doesn’t appear to be related to any particular game that was in development at the time, it merely appears to have been produced for the purposes of the demonstration. I do recall hearing somewhere that Epic Games outsourced the production of the model, but don’t take my word on that.
Previously, animations in Unreal Engine were done per-vertex, which meant that the engine would interpolate the vertices to a new coordinate on each frame, essentially by storing multiple copies of the whole mesh for each frame of an animation. For this, Unreal Engine had it’s ‘3D’ model format implementation which was split between two separate files; one containing the mesh and the other containing the transformation of the vertices for each frame of the animation.
It was a little inefficient but it was quicker for the CPUs of the time to process when compared to using skeletal animation, the only downfall was that it used more memory, which inflicted heavy limitations on the complexity of animations which artists could create. The same method was used by id Software for Quake, Quake II and Quake III, though Quake III extended on this to take greater advantage of the higher memory available on systems at its time of release by using greater precision for the coordinate of each vertex (the MDL and MD2 formats, used in Quake and Quake 2 respectfully, used a very low level of precision that resulted in a wobbly effect for animations).
This format saw continued use in Unreal Engine 2 certainly to a lesser extent than before. An example are the flags used throughout Unreal Tournament 2004, which took advantage of per-vertex animation.
The addition of support for skeletal animation to the engine meant that artists could introduce far more complex animations, as well as the ability to blend multiple animations together or for programmers to alter how bones moved during run time to allow characters to look in specific directions, without even requiring a predefined animations. Obviously the implications at the time were huge.
Skeletal animation saw a surge in use at the end of the 90s, and by 2001 almost all commercial games appear to have been heavily using skeletal animation over per-vertex animation. Regardless, the technology certainly wasn’t new, it was developed in the late 1980s and saw use within films such as Toy Story, released in 1995, and was a major hallmark of the cancelled game Into the Shadows, which was in development by Triton in 1995.
One key feature Epic Games seems to have chosen to point out here is the ability to add facial animations to characters, likely to demonstrate the level of complexity that artists could expect from the addition of this new technology. The system did not introduce anything on the level that we would later see brought by Valve’s Source Engine, which used a combination of skeletal animation for typical motion and per-vertex animation for facial animations, which gave animators a greater degree of control than was achievable from skeletal animation for facial animation.
From the screenshot below which came from Epic Games’ Unreal Developer Network, you can see the environment in which the facial animations would be produced.
Another downside of Epic Games’ implementation of facial animation, from my understanding, is that the facial animation wasn’t very flexible; the facial animation was only controllable from modelling tools such as Maya and would have been baked down into individual animations. This would have meant that any changes for an expression would have had to been made outside of Unreal Engine’s UnrealEd, then imported back into the engine again once completed.
To a limited extent, it was possible to export a number of different facial animations, each for various expressions, and for these to have blended together to be combined with animations for speech or other bits of animation, so that characters could express themselves using the same mouth movements without having to create unnecessary duplicates of animation, but this technique would have been very limited to those seen in the years to come that allowed more precise control over facial animation.
By comparison, Valve introduced a more flexible method which was supported by their own tool, rather boringly dubbed the “Choreography Tool”, or “Faceposer” as it’s more commonly known. By comparison, this tool allowed Valve to produce entire scenes, using their own library of animation overlays and flexing the faces of the characters throughout the scene, and then to preview them within the tool before placing the scene within a level.
It’s worth noting that skeletal animation was eventually introduced to Unreal Tournament in a subsequent update and also used widely for the PlayStation 2 release of the game, however it didn’t see such extensive use until developers began utilising Epic Games’ then new Unreal Warfare engine in 2001.
In an IGN article produced for the demonstration, Epic Games apparently put forward a statement on the new feature that reads the following.
The skeletal animation system, using quaternion-based interpolation, allows for both loss-less and lossy compression of the motion data. The rendering pipeline of the engine is being modified so that characters (and additive solid geometry) can be processed through the hardware T&L pipeline of Direct3D cards with that feature. That means the theoretical limit for polygons and, more importantly, the numbers of characters on screen jumps substantially for applications intended for Microsoft Xbox or computers equipped with hardware T&L-capable cards like Nvidia GeForce or ATI Radeon and the myriad of others that will follow. The new features of DirectX 8 in particular will enable skeletal characters to make full use of the hardware to accelerate rendering of smooth-skinned meshes.
It’s interesting to hear Epic Games refer to the Xbox here, considering that Unreal Championship ended up becoming an Xbox exclusive.
High Detail Models
This part of the video is one of the more interesting segments historically, as it shows a look at an early version of one of the Locust soldiers, which were later found in Gears of War, and at this point they were referred to as the Geist (a German word, meaning “Ghost” in English). At this time, Gears of War was known as Unreal Warfare (the same name that was widely used to describe Epic Games’ upcoming technology) and was in the very early stages in development; very different to the game we received in the end, in terms of both gameplay as well as visually.
The character displayed uses the symbolism of the Locust prominently on his front as well as on his back, which appears to be one of the few designs which has survived the evolution from Unreal Warfare to Gears of War. It’s evident from this that the symbolism of the Locust was established very early on and surprising that Epic Games retained this throughout the game’s development.
The character’s design here, especially with regards to the human appearance and de-saturated skin, seems very similar to what we saw in a later Unreal Engine technology demonstration shown in 2002, which also showed content intended for Unreal Warfare. It’s likely this design, at least stylistically, for the Locust, remained for quite sometime and likely wasn’t entirely thrown out until the team ditched Unreal Engine 2 around the end of 2003, after which the designs in the final game retained the humanoid appearance of some classes of the Locust and the de-saturated skin tone, but overall it seems Epic Games settled upon a more alien design.
It’s possible the reason a less human appearance was chosen for the Locust was due to the team changing focus towards a single-player experience, rather than the class-based multiplayer they had originally envisioned for the game. As this change occurred, the primary enemy of the player within the game became the Locust; this meant opening up the range of characters they would be pitted against and to introduce more variety. This also likely helped create more of a divide between both the Locust and Cog generally, and was intended to make the Locust appear considerably less friendly.
When the scene switches over to show the model from the back we can see a panel with the label ‘SLARIOUX’. It’s possible that this is the name of the character we’re seeing here, the implication could be that this was intended to be a character of importance? It’s unlikely we’ll ever know for sure but this certainly wasn’t something we saw retained in later iterations of the game, as the Locust eventually had their own language and generally their armour did not feature names of any sort. Considering Warfare’s multiplayer focus at this point in its development, another possibility here is that the name plate would feature that player’s own name – something that Unreal Tournament 2004 would feature to a limited extent, displaying the player’s name on the number plate of a vehicle they’re occupying.
While not featured within the video, we can see that the Cog also retained the same symbolism which we see widely used in the final game, which is confirmed by several screenshots featured on the UDN from around the same time. This said, the Cogs design in these screenshots remains very different to that which we see in the final game, and the overall cog theme is perhaps not quite as pronounced as in the overall design below. Again it’s interesting that Epic Games seemingly settled on the symbolism for both sides so early on.
In the above images, it’s certainly interesting to see that the Cog soldier appears to be using the same skeletal rig featured in Unreal Tournament’s PS2 debut, which introduced skeletal animation. It’s also interesting to see the Cog weilding the weaponry also featured in Unreal Tournament; a possible implication that Unreal Warfare was initially using Unreal Tournament as it’s foundation when it started development, this is perhaps further supported by screenshots showing featuring Unreal Tournament’s HUD while displaying assets intended for Unreal Warfare, one of which can be seen below.
Since the HUD here is from the PlayStation 2 version of the game, which introduced the support for skeletal animation, it’s perhaps not surprising to see the Cog soldier making use of the same skeletal rig and animation set. As a matter of fact, it’s very likely that the support for skeletal animation featured in Unreal Engine 2 is simply an iteration of the skeletal animation introduced in the PlayStation 2 version of Unreal Tournament, as that iteration of the engine continued to evolve internally within Epic Games. It certainly seems to be the case that Unreal Warfare, as a game, was built from the PlayStation 2 version of Unreal Tournament.
High Level and Texture Detail
Again, this segment of the video is quite interesting for historical reasons, because it possibly gives us some insight into how other games being produced, using Epic Games’ then new technology, were progressing at the time. Initially we see a map I can’t identify, which was probably produced purely for the purposes of the demonstration, but afterwards we see something interesting; a rather futuristic setting.
Several games that Epic Games were involved with at the time featured a futuristic setting, these range from Unreal Warfare, Unreal 2 and the working title, Unreal Tournament 2, so these screenshots could in essence show any one of these.
Unfortunately I can’t say for certain what we’re seeing here but I believe, on unfortunately very little evidence mind you, that this is Unreal 2. Why? Well there appear to be some subtle indicators here that we can pick out when comparing the shots to content that exists in Unreal 2. If this were the case however, Unreal 2 would have been at such a primitive state at this time – though there is certainly indication that the game was in development at this time.
Unreal 2, of course the sequel to Unreal, was in development outside of Epic Games, and was instead being produced by Legend Entertainment. Unfortunately after the release of the game and shortly after the release of it’s multiplayer expansion, the studio was closed down.
As you can see, there are some rather subtle indicators but of course it’s hard to know for sure – I believe there likely are other textures that match up though.
If there was more evidence to link this to Unreal 2, I would even go as far as saying that this appears to be an earlier iteration of the level found in this screenshot below which was released during Unreal 2’s development, in late May of 2002 (though this iteration of the level actually dates as far back as 2001, as it’s included in a leaked build of Unreal 2 from the time). It features the same crane mechanism, a similar looking table and uses textures from the same texture group, though clearly it’s considerably more varied and detailed, and that’s just speculation on my part.
If this is true, it does imply that the operating table, as it is, has the crane mechanism positioned in the wrong place in the video. Oops.
I hope you enjoyed this article! Eventually I want to cover more regarding the development of Unreal Warfare and the development of the Unreal Engine in general, so stay tuned!
I’ve kind of realised that I’m not doing frequent enough updates. Perhaps it’s time I got into the habit of doing weekly updates just so you know what’s going on and that I’m not totally idle.
So yes, I’ve certainly slowed down with producing videos. It’s not intentional but I’ve kind of lost the motivation a little due to how long the last few videos have taken to produce and the amount of crap I’ve had to deal with when it comes to the Source engine.
Generally I just don’t look forward to launching Hammer, dealing with the crap content pipeline and essentially basically showing things that I’d imagine most of you have already seen; it doesn’t make me feel especially productive. I’m looking to do videos on other things, but I’m afraid I don’t have anything in the pipeline quite at this time.
I’m gradually looking at switching my format to doing more analytical works which is something I’ve always wanted to focus myself towards, primarily in written articles as I can cover more than I could in a video. There are two articles in the works at the moment, one focusing on Unreal Engine 2 and another that covers the last Half-Life 2 video I produced.
On the side as well, I’m spending considerably more time now writing code for projects such as reverse engineering the model format in Requiem Avenging Angel and working towards my open-source Hogs of War project, though I’ve taken some time away from those two specifically to focus on a game I’m working on in my free time which unfortunately is unrelated to the purposes of this website but I might sneak a little plug in for it when it’s closer to completion in the future.
With regards to the Requiem Avenging Angel model format, I guess I might as well begin going into some of it here considering we already published some our work so far.
For starters, Requiem features two separate model formats. One specific for static meshes which is quite simplistic and then another for it’s models that use skeletal animation, which also appear to support multiple textures. Both of the formats use slightly different structures from one another but for the time being we’ve primarily focused on the more simplistic model format.
The very first byte in a static model is a flag that declares how the model will appear within Requiem’s engine. Through some experimentation we were able to determine that the default state for this, which is flag 0, causes the model to use standard Gouraud shading, where as flag 1 results in flat shading and flag 2 results in an unlit model.
After this the file then contains the name of the texture sheet the model will use. This begins with a 32-bit integer that lets us know the length of the string, this is a little unusual and doesn’t appear to have been retained in the animated model format as far as we could tell, but afterwards is followed immediately by the texture name itself. The texture name in each of the models never exceeds 64 bytes. We can then load in the texture name using the length provided within the file.
After which we then immediately stumble into some data declaring the rest of the contents of the model. This begins with a 16-bit integer outlining the number of vertices within the model, then followed by another 16-bit integer that unfortunately I don’t appear to have noted down, oops, and then finally one last 32-bit integer that lets us know how many faces the model features (I think we may have concluded that the vertices was a 32-bit integer as well? My notes suck!)
Finally, we can move onto actually loading the data of the model, such as the vertices and faces. This I will leave for a more dedicated article at another time; we’re planning on going over the model format again over the course of this week but I can say that the vertex coordinates made very little sense to us and they’re something we’re actually still very stuck on. The other noteworthy feature of Requiem’s model format is that faces do not use fixed sizes, and can have any number of triangles per-face (we’ve seen instances of at least 6/7 triangles per-face).
Anyway that concludes this weekly update, hopefully I can keep this up!
Below is a collection of thumbnails that were generated for Epic Games’ Gears of War, which were packaged with the game, and preview several different levels that were produced during the development of the game.
It should be obvious why these are interesting in a lot of respects, especially as they show a lot of content that didn’t make the final cut. Each of these previews appear to have been generated either for levels that were produced purely for testing mechanics of the game but as well as levels that were used to lay out prefabricated areas.
These songs were packaged with Star Wars Republic Commando, among some other things which we’ll discuss at some other stage in the future.
For those that don’t know what Unreal Warfare is, Unreal Warfare is what eventually became the Gears of War you know today. It was also often used as the name to describe the second iteration of Epic Games’ Unreal Engine, as it initially served as the driving force for many of Epic’s innovations at the time, and before Epic Games had dubbed their new technology as “Unreal Engine 2”.
It’s hard to know exactly when development began on the game, but it’s apparent that the game was in development from as far back as 2001 and didn’t cease to exist as Unreal Warfare until 2004, when Epic Games moved the project to the then in-development Unreal Engine 3 and recycled assets from the game for Unreal Tournament 2004.
Many of the key concepts, such as the Cog and Locust (known at the time as the Geist), the iconography and elements of the universe, were well established very early in the game’s development.
That being said, the game changed dramatically in-terms of gameplay during its development cycle, having originally been intended to be a tactical class-based first-person shooter before then becoming the over-the-shoulder experience when making the move to Unreal Engine 3.
I don’t currently have an article available here on the website regarding the game but it is something I would love to do at some stage. I’m sure a quick Google search should pop up some results.
If you’re interested in downloading the tracks then I’ve made them available here.
Most of these are taken from Epic Games’ UDN, and there’s plenty more there I haven’t included so I highly encourage people take a look!
If you’re not sure what Unreal Warfare is, it’s essentially what became Gears of War. The screenshots below show content from the game back when Epic Games were still developing Unreal Engine 2, which should give you a good idea of how long this game was actually in development for.
It’s been an incredibly long time since the last video, but the next one in the series is finally here.
Keep in mind that this ended up getting a little rushed in the end, as I wanted to get it out of the way so I could move onto other things. Turns out moving to Source Filmmaker ended up causing the video to take longer due to a few technical faults along the way, and then work got in the way, and it’s likely in future I’ll be producing these very differently to how I have been previously to save myself more time.
As usual, keep in mind that this series is solely focused on displaying the geometry of the levels rather than playing through each one individually. If you enjoyed this video and want to see more in the future then I highly recommend supporting me on Patreon, as this goes towards supporting the website, the archive and videos such as this.
This is part of a video series showing the gradual evolution of Half-Life 2. It’s not intended to demonstrate gameplay, as most of these levels, in their original form, weren’t playable. Because of the number of levels to cover and the amount of time it takes to clean them up enough to be viewable, these will be kept as quick glances.
This level is produced from the VMF, canals_01_15. The level was likely created by Aaron Barber.
A long time ago now, one of my many hobby projects was looking at how feasible it would be to produce an open-source reproduction of SiN Episodes, so that work on it could essentially continue (or to just otherwise bring it over to Source 2013). I decided to return to this today and felt it would probably be interesting for a few to share how this is going right now.
I actually ended up revisiting the project as a result of an article I was working on to explain how you can get the SiN Episodes SDK functioning again. Unfortunately it seems that the steps I used previously will no longer work as Valve has changed how Steam’s config is set up, which was part of both the solution and the cause of the problem to begin with.
Obviously not great but unfortunately this was going to happen sooner or later due to the SDKs inherit reliance on Steam and the lack of support it receives due to the obvious fact that Ritual Entertainment no longer exists. So the value in an open-source reproduction of sorts is quite apparent, or to me at least.
This initially led me to look into reverse engineering the SDK to try and figure out if it was possible to work around the check it was trying to perform. Keeping in mind here that it’s not something I’m highly experienced with.
From the looks of it (by looking at the leaked 2007 codebase) there’s a Steam check which then moves over to try and grab the Steam config (which is where the failure occurs) but there’s a separate path here which looked like it skips this check.
I spent a short amount of time in a decompiler to see if I could figure out where this check occurred by using the “%s=%s” string, as seen above, as a reference point and managed to get a rough idea where the alteration needed to be made. Unfortunately I did seem to be running in circles a little, as the decompiler was only showing one other string similar to this one which wasn’t the one I needed, which you can see in the image below.
After spending a little while longer on it, I did eventually find, roughly, where the line was that I was looking for but I’ve decided to leave it for another day for now before I spend some extra time on it, just to be absolutely sure.
Moving on, I ended up looking once again at my SiN “Reborn” project.
At the moment it’s being developed using the multiplayer branch of Source, and there’s a few reasons for that really… One; I would be more keen to get some sort of multiplayer game going as a starting point as it would be worthwhile, considering SiN Episodes: Emergence wasn’t released with any multiplayer support whatsoever. Two; my understanding is that the multiplayer branch of Source has had more TLC from Valve than the singleplayer branch, not that Valve have touched the Source 2013 release for a while now, but it otherwise has some features that aren’t available on the singleplayer branch (keep in mind it’s been a considerable amount of time since I last properly touched Source, so I’m just going by memory here.)
Most of my time today has been spent familiarising myself with everything again. At the moment there’s a rough outline of the Scattershot and the Magnum that have both been implemented with some rudimentary code for the melee attacks and special secondary attacks that were used in the game. As well as this, we’re happily parsing some of the extra data that Ritual added for the weapon scripts, and all the items have been implemented (besides the ‘ass’ aka Assault Rifle and health pickups). Easy parts out of the way.
Things like the HUD still need work, likely to come later rather than sooner, but it’s interesting to see that Ritual created weapon icons for each of the weapons in the game which work within Half-Life 2’s weapon selection HUD. It seems as if SiN’s HUD might have been considerably different in the game at some stage of its development and it does appear there are quite a number of unused textures for the HUD as well here, possibly just left overs from prototyping but it would be interesting to know for sure.
While I was looking through and tidying things up, I decided to alter the animation code a little as well to play better with the character animations used in the game. It makes sense to me to try and alter as very little of the original content as possible, so I wanted to see how well the animations would work for multiplayer.
This ended going surprisingly well (and I probably spent way too much time on it too), with support for different animations based on speed and the players current state now implemented, which you can see from the video below. An example being how the player switches between a more relaxed animation set before switching to a more active animation set upon either firing his weapon or getting attacked.
Looking pretty swell, even if I do say so myself. Unfortunately, as you can see from the video, it turns out that the Magnum world model seems to use a different bone for the attachment, hence why it’s in his groin rather than in his hand where it belongs. I’ll likely look to see if I can implement a workaround for this without altering the model.
My other concern here though is that a few of these animations may not necessarily be available for the other character models in the game, as quite a few of them appear to use their own animation sets. It’s something I’m going to need to take a look at but I really hope this isn’t the case.
Anyway that’s all I’ve got for today. I’m really going to try and post here more frequently about what I’m doing, and I’m interested to know what you guys think. If anyone is interested in contributing to projects like this then I really encourage you to get in touch as I’m always looking for help!