HAHAHAHA. I have also got Moggie going through LPArchive.org now, specifically the Let's Play entries for the Thief series of games.
I first ran into Thief: The Dark Project while I was in college. I had a roommate who appeared to have survived to college age either by accident or manipulation -- she committed a lot of grievous roommate sins, like never cleaning anything, ever, and as far as I could tell, only leaving the tiny shared room for food and restroom breaks. One of these was playing computer games when I was trying to sleep and outright refusing to use headphones. Which was especially puzzling, because one of them was Thief, whose engine uses stereolocation to tell you where the guards are walking, which should work even better when you're not using crap PC speakers.
Still, at least I was being kept awake by a very pretty game.
Thief: The Dark Project (and the sequel, Thief: The Metal Age) was the brainchild of Looking Glass Studios, also responsible for the System Shock games, and -- according to Wikipedia -- a load of other things I've never even seen. The studio sadly went under in 2000; a lot of the same team responsible for Thief, Thief 2, and System Shock, migrated en masse to another company, and subsequently put together the BioShock games, which are a sort of spiritual successor to the System Shock series, and the third Thief game. All of the above are fucking brilliant. The Looking Glass people had a profoundly creepy attention to detail. First-person (and third-person) shooters are necessarily limited in the number of cutscenes they can contain before the player starts getting frustrated at the lack of interactivity, and the interface mostly being devoted to specific attack and defense moves, special gimmicks are restricted to anything you can put on a contextual 'use' button. Players now are used to collecting information about the plot and surroundings while they run around and kill things -- it's a well-established mechanic in the Metroid Prime series, for one -- but the heavy use of environmental sound and multimedia widgets for the player to trigger were kind of a Really Big Thing when Thief came out in 1998.
But the other Really Really Big Thing in the Thief series was that the entire game was built on a custom sneakabout engine. Called the Dark Engine, it was specifically constructed for the series, and one of its cleverest features was that it tracked the light levels in the environment in real time, not just for render purposes, but also for game mechanics.
In the Thief series, you of course play a thief, whose name is Garrett, and who is incidentally a goddamn awesome deadpan snarker with fantastic voice work. Being a thief, your goal is not actually to go through the map and slaughter all the enemies -- although you do have the option to do so, if you want -- but to tiptoe around and steal everything that isn't nailed down without anyone noticing. In order that you might do this without getting skewered by a guard, the environment is often quite dim. It behooves Garrett to stick to the darker bits, because the game keeps track of how much light is hitting him (or the volume it considers to be the player character, anyway; it's an FPS-like engine, and all you ever see of Garrett is an arm or two, when he wields various weapons), which in turn affects how well the guards can see him. The innovation of this is not to be underestimated -- Metal Gear Solid, which came out for Playstation the same year, works entirely on line-of-sight, and the generic mooks aren't nearly so bright about patrolling or alerting each other.
There are several ways to determine how much light is falling on a given part of the level geometry. The most computationally-expensive way -- brute force, more or less -- is called ray tracing. There's a bunch of objects, a light source, and a hell of a lot of math involved in drawing a jillion imaginary lines out from the light source and bouncing them through or off things to find out where the photons end up. (If you want to get technical about it, it's actually tracing photons backwards from an imaginary eye through an image plane to the light source. This is to prevent a lot of extraneous calculations for photons that turn out not to be visible to the camera in the end.) I remember back in the early-mid nineties, when the first (small, laborious) ray-traced renders started floating around what we thought of as the web. You whippersnappers with your Wiis and 360s and PS3s don't know how exciting it was to see a computer draw a crystal ball with stuff behind it. It was the teapotahedron of its time.
I'm not enough of a programmer to know exactly how the Dark Engine works, but it's probably backwards from the way you think. Figuring out how much light is falling on a spot in the geometry is essentially a form of collision detection, which is the nerd name for the part of the game framework that's in charge of figuring out whether you've bonked into an enemy or a wall or some other solid part of the level. Most people, I gather, if they've thought about it at all think that the game does this by working out the position of the player and the position of the other thing, and then, if they happen to have whacked into each other, specifically drawing out onto the screen the two things in a state of collision. They really don't. The easiest way to do this is to draw one thing, draw the other thing, and then go back and check to see if you have drawn any pixels of the second thing in the same spot as you've drawn pixels of the first thing. It's a bit more complex in 3D games, where things are also arrayed along a Z-axis (basically, the game checks the voxel render before it's output to the camera plane), but it's the same basic idea. It's been done this way since Pong.
The fact that the game doesn't actually know that you've run into Inky, Blinky, Pinky or Clyde until you've already done so is one of the reasons you can sometimes miraculously glitch through a corner of an enemy hitbox without taking damage (essentially, the player character's calculated motion is such that the time when player pixels and enemy pixels would be in the same place happens between frame draws, when there are no pixels to check), and part of the reason you get 'mercy invincibility', particularly in platformers. By the time the game draws both actors, performs the collision check, and starts the damage animation that lets the player know they've been hit, it's already several microseconds late -- if you didn't start blinking and go invulnerable for a bit, you'd have to basically be precognitive in order to move fast enough to avoid taking a second hit at the next frame draw. This is considered cheesy and patently unfair and tends to make your players throw the controller at the wall, and is avoided in good game design.
Light level detection is more or less the same thing, except instead of checking to see if one pixel is on top of another, you're checking to see what level of light is being applied to the render of a particular set of pixels. I'd need to pick the brains of a programmer to find out exactly what the Dark Engine considers to be the volume of the player character, but given where the Light Gem sits on your HUD in the first two games, it's entirely possible that that is literally what the game thinks of as Garrett, and that it's checking the color of pixels rendered on the camera-most face of the polyhedron in real time to find out how visible the titular thief is. It would also be a convenient way to implement the general rule that Garrett is always more visible when he has a weapon out, as the volume of the arms you see when he's got his sword, bow or nightstick out projects beyond where the gem is, and given how the light tends to pool, would usually bring them out of the deepest part of the shadows.
Thief 3, FYI, is built on an extensively-modified version of one of the Unreal engines instead, which is why it has a third-person view. (A bit disappointing, I have to say. For whatever reason, it's apparently really difficult to get the player model to do things like walk without looking like a chronic drunk -- the Garrett model looks all right when standing still, but tends to lack the grace I imagined while watching play for the first and second games. Ah, well.) Given the increase in processing power in the interim, and the fact that the engine wasn't custom-built for a sneakabout, the light-detection system in Deadly Shadows is probably entirely different than that of Dark Project and The Metal Age. I haven't a clue how UT2 handles environmental effects -- anybody want to enlighten me?
I first ran into Thief: The Dark Project while I was in college. I had a roommate who appeared to have survived to college age either by accident or manipulation -- she committed a lot of grievous roommate sins, like never cleaning anything, ever, and as far as I could tell, only leaving the tiny shared room for food and restroom breaks. One of these was playing computer games when I was trying to sleep and outright refusing to use headphones. Which was especially puzzling, because one of them was Thief, whose engine uses stereolocation to tell you where the guards are walking, which should work even better when you're not using crap PC speakers.
Still, at least I was being kept awake by a very pretty game.
Thief: The Dark Project (and the sequel, Thief: The Metal Age) was the brainchild of Looking Glass Studios, also responsible for the System Shock games, and -- according to Wikipedia -- a load of other things I've never even seen. The studio sadly went under in 2000; a lot of the same team responsible for Thief, Thief 2, and System Shock, migrated en masse to another company, and subsequently put together the BioShock games, which are a sort of spiritual successor to the System Shock series, and the third Thief game. All of the above are fucking brilliant. The Looking Glass people had a profoundly creepy attention to detail. First-person (and third-person) shooters are necessarily limited in the number of cutscenes they can contain before the player starts getting frustrated at the lack of interactivity, and the interface mostly being devoted to specific attack and defense moves, special gimmicks are restricted to anything you can put on a contextual 'use' button. Players now are used to collecting information about the plot and surroundings while they run around and kill things -- it's a well-established mechanic in the Metroid Prime series, for one -- but the heavy use of environmental sound and multimedia widgets for the player to trigger were kind of a Really Big Thing when Thief came out in 1998.
But the other Really Really Big Thing in the Thief series was that the entire game was built on a custom sneakabout engine. Called the Dark Engine, it was specifically constructed for the series, and one of its cleverest features was that it tracked the light levels in the environment in real time, not just for render purposes, but also for game mechanics.
In the Thief series, you of course play a thief, whose name is Garrett, and who is incidentally a goddamn awesome deadpan snarker with fantastic voice work. Being a thief, your goal is not actually to go through the map and slaughter all the enemies -- although you do have the option to do so, if you want -- but to tiptoe around and steal everything that isn't nailed down without anyone noticing. In order that you might do this without getting skewered by a guard, the environment is often quite dim. It behooves Garrett to stick to the darker bits, because the game keeps track of how much light is hitting him (or the volume it considers to be the player character, anyway; it's an FPS-like engine, and all you ever see of Garrett is an arm or two, when he wields various weapons), which in turn affects how well the guards can see him. The innovation of this is not to be underestimated -- Metal Gear Solid, which came out for Playstation the same year, works entirely on line-of-sight, and the generic mooks aren't nearly so bright about patrolling or alerting each other.
There are several ways to determine how much light is falling on a given part of the level geometry. The most computationally-expensive way -- brute force, more or less -- is called ray tracing. There's a bunch of objects, a light source, and a hell of a lot of math involved in drawing a jillion imaginary lines out from the light source and bouncing them through or off things to find out where the photons end up. (If you want to get technical about it, it's actually tracing photons backwards from an imaginary eye through an image plane to the light source. This is to prevent a lot of extraneous calculations for photons that turn out not to be visible to the camera in the end.) I remember back in the early-mid nineties, when the first (small, laborious) ray-traced renders started floating around what we thought of as the web. You whippersnappers with your Wiis and 360s and PS3s don't know how exciting it was to see a computer draw a crystal ball with stuff behind it. It was the teapotahedron of its time.
I'm not enough of a programmer to know exactly how the Dark Engine works, but it's probably backwards from the way you think. Figuring out how much light is falling on a spot in the geometry is essentially a form of collision detection, which is the nerd name for the part of the game framework that's in charge of figuring out whether you've bonked into an enemy or a wall or some other solid part of the level. Most people, I gather, if they've thought about it at all think that the game does this by working out the position of the player and the position of the other thing, and then, if they happen to have whacked into each other, specifically drawing out onto the screen the two things in a state of collision. They really don't. The easiest way to do this is to draw one thing, draw the other thing, and then go back and check to see if you have drawn any pixels of the second thing in the same spot as you've drawn pixels of the first thing. It's a bit more complex in 3D games, where things are also arrayed along a Z-axis (basically, the game checks the voxel render before it's output to the camera plane), but it's the same basic idea. It's been done this way since Pong.
The fact that the game doesn't actually know that you've run into Inky, Blinky, Pinky or Clyde until you've already done so is one of the reasons you can sometimes miraculously glitch through a corner of an enemy hitbox without taking damage (essentially, the player character's calculated motion is such that the time when player pixels and enemy pixels would be in the same place happens between frame draws, when there are no pixels to check), and part of the reason you get 'mercy invincibility', particularly in platformers. By the time the game draws both actors, performs the collision check, and starts the damage animation that lets the player know they've been hit, it's already several microseconds late -- if you didn't start blinking and go invulnerable for a bit, you'd have to basically be precognitive in order to move fast enough to avoid taking a second hit at the next frame draw. This is considered cheesy and patently unfair and tends to make your players throw the controller at the wall, and is avoided in good game design.
Light level detection is more or less the same thing, except instead of checking to see if one pixel is on top of another, you're checking to see what level of light is being applied to the render of a particular set of pixels. I'd need to pick the brains of a programmer to find out exactly what the Dark Engine considers to be the volume of the player character, but given where the Light Gem sits on your HUD in the first two games, it's entirely possible that that is literally what the game thinks of as Garrett, and that it's checking the color of pixels rendered on the camera-most face of the polyhedron in real time to find out how visible the titular thief is. It would also be a convenient way to implement the general rule that Garrett is always more visible when he has a weapon out, as the volume of the arms you see when he's got his sword, bow or nightstick out projects beyond where the gem is, and given how the light tends to pool, would usually bring them out of the deepest part of the shadows.
Thief 3, FYI, is built on an extensively-modified version of one of the Unreal engines instead, which is why it has a third-person view. (A bit disappointing, I have to say. For whatever reason, it's apparently really difficult to get the player model to do things like walk without looking like a chronic drunk -- the Garrett model looks all right when standing still, but tends to lack the grace I imagined while watching play for the first and second games. Ah, well.) Given the increase in processing power in the interim, and the fact that the engine wasn't custom-built for a sneakabout, the light-detection system in Deadly Shadows is probably entirely different than that of Dark Project and The Metal Age. I haven't a clue how UT2 handles environmental effects -- anybody want to enlighten me?
Comments
Post a Comment