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!
This is something I’d been meaning to post for a while now but unfortunately didn’t quite get round to it, primarily because I wasn’t entirely sure if its content was right for this website. Having thought about it, this is a step towards helping preserve an old game that many otherwise may not have heard of before so it makes perfect sense to post it here.
Dominant Species was a game that was released in 1998, and it seems to me like a game that was somewhat lost in time with very little attention given to it as far as I’m aware but seems like a unique game for its time. It certainly has a charm about it.
If you’re not familiar with the game, it was developed by Red Storm Entertainment. The same guys that have developed countless Tom Clancy games. And it’s a 3D RTS, which according to Red Storm themselves, was one of the first 3D RTS games as well which definitely makes it quite significant.
On a whim I came across the game online and ordered myself a copy but I guess to no surprise the game struggled running on modern operating systems (such as Windows 7/8/10), in particular it failed to initialise a fullscreen instance of the game and it also fails at detecting the CD properly.
After spending a while poking and prodding the game though, I not only found a list of launch arguments for the game that allowed it to run in a windowed state, which worked around the issue initialising it in fullscreen, but I also managed to track down where the game attempted to check for its CD to ensure you had a valid copy of the game and disable it through the wonders of reverse engineering.
I did also experiment with a wrapper to try and get the game running in fullscreen but after discovering the launch arguments I didn’t go any further with this. It’s something I’d like to return to though at some point in time as it would be a wonderful learning experience.
Keep in mind that I’ve only done this for the singleplayer at this time, so right now the multiplayer menu will still ask you to insert the CD.
I guess you could probably consider this a crack? Maybe when I have some time I’ll get round to doing the multiplayer as well but this should be relatively easy to do. Unfortunately it’s been a long time since I did this so I don’t have my notes available right now but if anyone else makes an update to this then be sure to let me know and I’ll be happy to mirror it here.
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 they were introducing to the engine.
The Lighting Zoo, otherwise known as ‘lightingzoo’, is a level included in the pack of development VMFs that was leaked with Half-Life 2 back in 2003. It’s one of the lesser interesting levels in the pack of levels, but we’ll be covering it anyway just to quickly get it out of the way. Obviously on this occasion I won’t be bothering to produce a video but expect a number of screenshots demonstrating the level.
The map is marked as being last modified on the 6th of May 2002 but it’s hard to be sure as to who the original author was but it was likely produced by someone within Valve who didn’t work primarily as a level designer, more likely the work of one of the programmers at Valve. We can pretty much conclude this as the map features incredibly simplistic geometry, though includes a few different sections that seem to test the capabilities of the lighting tool, VRAD, at the time; displacements, animated lights and normal maps are featured in the different sections of the level.
Keep in mind that this obviously doesn’t reflect entirely how this level may have looked at the time as it was built using the Source 2013 level tools and of course the level was actually produced in 2002. My reasoning behind using the 2013 version of the Source Engine is purely just for stability and because I can make whatever changes as needed while demonstrating them. It’s unlikely we’ll ever see a build of Half-Life 2 from that period ever surface but we can dream.
Overall there seem to be four different sections of the level as you can see from the screenshot above. The first two sections (left to right) appear to primarily be intended to see how lighting was working for displacements. At the time I would guess that displacements were more likely to have been using per-vertex lighting, rather than having their own lightmap but it’s also possible this level was produced to test the introduction of lightmaps on displacements. It’s hard to know for sure but regardless, there’s quite a lot going on towards displacements in this level and how the lightmap is applied to those displacements in general.
For the first section of the level, we’re presented with a rather simplistic room with a skybox and a sand texture using a normal map. It’s likely this was to ensure the lightmap also included the correct directional data for it to influence the normal map on lightmapped displacement surfaces but apart from that it’s not particularly interesting to look at. The texture used for the sand was removed at some stage before Half-Life 2 shipped, so that had to be pulled over from the leak.
Moving on from that we also have the two middle rooms that contain a number of different displacements. I would expect that initially when displacements were first implemented in Source, Valve weren’t using lightmaps but instead used per-vertex lighting, though that’s purely speculation on my part but that being said it does seem like displacements didn’t support any kind of collision hull when they were first added to the engine as a few earlier maps also include brushes along with the displacements (thanks to H.Grunt for informing me about that). I thought it was worth pointing this out, as it might be easy to forget that a lot of the functionality, that we can sometimes take for granted in Source today, was very gradually introduced into the engine overtime through both development and prototyping with the rest of the development team.
The displacements included in these parts of the map aren’t your typical shapes, with displacements typically being used for terrain in Source (though they were also used for pipes and more in some circumstances) though this is also likely why the displacements included here are unusual in shape as it’s easy for issues to sneak past if level designers aren’t typically using displacements in this fashion, but I’d say more importantly is that it also lets you push and extend that functionality beyond the scope of what level designers might have been doing with that functionality at the time. Perhaps a good example of the influence that the programmers had on the design of the game, besides the actual designers of the game themselves.
In the section here, which is where the player initially spawns, we have a large displacement centered in the middle surrounded by a number of spheres at each corner and a number of lights at each corner as well. It’s an unusual set up, more unusual is the extra light on the bottom right of the room which you might be able to pick out from the overview earlier but it’s likely this might have been a simple mistake.
It’s possible this area was intended to test both displacements with environment mapping and normal maps as there’s a number of env_cubemap entities that have been intentionally set up in this section of the level, though for the material in question which was pulled from the leak, it’s difficult (or impossible rather) to see the environment map with how the material was set up, I changed this so that we can see the environment map on the surfaces more easily but I’m not quite sure why this was done; it could be that this was in error by someone at Valve.
I guess Valve can be glad to know this all still works, heh. There isn’t much more to say about this particular section, it seems quite evident that it was intended to test both environment maps, normal maps and lightmaps on different displacement surfaces, either to check for any regressions or to ensure the initial implementation was functioning as expected.
The next section we’ll take a quick look at is very similar though a little more simplistic. It features yet another sphere but this time without a normal map or environment map and instead just a simple diffuse + lightmap, it’s essentially identical to the others but with a different texture. It’s likely the intention here is similar to the other section we looked at but just lighting generally with unique displacement shapes.
There’s also two adjacent displacement planes we can find near the entrance which are slightly slanted from one another, with a light slightly shifted to the side of just one of them. From a glance it’s pretty unclear what the intention here was but my guess is that it was to check that the lightmap between two separate lightmap planes was smooth, as if they were a single surface; with displacements there aren’t any ‘smoothing groups’, instead the tools essentially treat any adjoining displacements as one surface and the normals are calculated automatically so that the lighting smoothly transitions over them (or that’s the intention anyway), this is likely why the light is shifted more so to one side.
There isn’t a whole lot more to this room so we’ll be moving now to the final section which is basically made up of two adjacent rooms which seem to mirror each other but feature different texture sets, one with a simple diffuse and lightmap, and the other with the diffuse, normal, environment map and lightmap that we saw earlier. Within these rooms there’s one coloured light in the corner, and then on one side we have a brush positioned above a displacement with an animated spotlight above it (likely checking that a shadow is correctly cast down onto the displacement), and finally a cylinder with smoothing groups applied and a spotlight cast through a slit made of brushes.
I guess we’ll start off with the brush placed above the displacement. Like I said, it’s likely this was to check that shadows were being cast onto the displacement correctly but otherwise there doesn’t seem to be any other purpose. The fact that there’s an animated light was also likely to ensure that the lightmap was correctly updated on the displacement.
I don’t think much more can be said about it so we’ll immediately move over to what’s on the other side of the room near the entrance (and we’ll skip the light in the corner). This isn’t so much to do with displacements this time but seems purely just for smoothing groups, typically for complex geometry like this you would change it to a detail brush to avoid any issues with CSG splitting the geometry up too much but interestingly this isn’t the case here which seems to have a negative impact on how the geometry ends up being lit.
From the screenshot provided below you can likely see how the different junctions produced during CSG have effected the overall lighting of the cylinder, with VRAD seemingly unable to completely trace some of the lighting to the rest of the geometry and also failing to keep the appearance of a smooth surface because of it, though the larger lightmap might also partly be to blame in this instance.
I would guess that this was intentional as it’s unlikely this was any different at the time but I’m unsure what the intended goal of this was, whether a solution was being explored or just to demonstrate it in general. The rest of the cylinder is otherwise fine and not effected by this (there is some issue with the light incoming from the hallway being applied to the cylinder). The same issue also appears on the cylinder in the second room but that’s unlikely to be surprising.
I think that’s about everything I can think of covering in this map, the only other thing noteworthy is that the map seems to use the same hallway structure found in other ‘zoo’ levels though slightly modified like the two larger rooms were slotted into it, but it’s very much just your typical hallway otherwise but as with most of these levels you’ll find it easier to use the ‘noclip’ function rather than walking through them.
If you found this interesting then do let me know and I’ll continue on with it, I know this is one of the least interesting levels in the leak but I like to cover things that most people would otherwise overlook. There’s a lot more than meets the eye they often say, though we can only really speculate on most of what we find in the leak and levels such as this. If anyone else has any comments or suggestions, or hell, anything, do let me know and I’ll update this accordingly but I do hope it was insightful!