Quake 4
Quake 4 was the first shooter I ever worked on. I did some level scripting, some mission work, and some combat encounters. But looking back on it, two things stand out.
The first was the Data Processing beam puzzle, coded in Quake C. The player needed to rotate L-shaped joints to redirect a beam of light toward a target. We shipped with a 1-node puzzle and an 8-node puzzle, but we had talked about much larger versions. It would have been easy to implement because of how I set it up.
Basically each node kept track of its own state, and whenever it rotated, it would update its own state and then recursively update every other node in the puzzle.
There’s a video of it here:
The other was the Strogg Flyer behavior on the Tram level.
Strogg Flyers were enemies that moved along splines. But the splines only took care of the flight path. In order to make them bank as the path curved, we had to script that movement separately. Usually this was done by eyeballing it. After x seconds, rotate y amount, then rotate back after z seconds. It was annoying to make a change, run the game, no-clip to the right spot, hit the trigger, and then make another tiny adjustment.
But in the tram level, essentially a rail shooter, we couldn’t even do that. If you no-clipped away from the tram, you couldn’t get on it again. The only way to hit the triggers was to sit there and wait multiple minutes until the tram got there.
If I just had some data from the spline about the tightness of the curve, I could automate it. Sadly, our tools didn’t expose that information.
So instead, I placed an invisible mover on each spline, and started it on its path a second before the flier. Then I could just compare the forward vectors of the invisible mover and the flier. The greater the angle, the more it needed to bank. It worked beautifully.
Until it didn’t.
Sometime after I left the project, code rot came for the flyers. I don’t know what happened or when, but after the game launched, I found out that none of the flyers in the tram level banked at all.
There was also that time that I was in the Planet Quake Picture of the Day, because six was an utterly incomprehensible number of women to have on one project.
Wolfenstein
I have no screenshots or video of my work on Wolfenstein. The game that was in development for the 3-ish years of my involvement bears little resemblance to what actually shipped.
I worked in both C++ and a proprietary scripting language on combat encounters, NPC behavior, a cut boss fight, and cut features that I absolutely cannot talk about.
Singularity
I was only involved in the early prototype phase for Singularity, so I’m limited in what I can say about my work on it.
I can say that I did some interesting camera work, context-sensitive actions, and some weapon prototypes, all exclusively in C++. This was also my first exposure to Unreal Engine.
Prey 2 (Cancelled Game)
I was brought onto Prey 2 on a short term contract to help with some mission work, using a proprietary scripting language.
I take my NDAs seriously and can’t talk details, but if someone else does the leak, the genie can’t go back in the bottle. This video doesn’t contain any the missions I worked on, but will give you an idea of what that work might have been like.
The only other thing I’ll say is that even years later, I am still profoundly sad that this game got cancelled. That studio and that team deserved better.