I opened the collection of links, which is quite good if a bit old. But then I had a subconscious mental itch, and thought, wait... where had I heard the name mrelusive before? That sounds _really_ familiar.
And then I remembered - oh, right, mrelusive, JP-what's-his-name. I've read a huge amount of his code. When I was working on Quake4 as a game programmer and technical designer, he was writing a truly prodigious amount of code in Doom 3 that we kept getting in code updates that I was downstream of.
And he was obviously a terrifically smart guy, that was clear.
But I had cut my teeth on Carmack's style of game code while working in earlier engines. Carmack's style of game code did, and still does, heavily resonate with my personal sensibilities as a game maker. I'm not sure if that particular style of code was influenced by id's time working with Objective-C and NeXTStep in their earlier editors, but I've long suspected it might have been - writing this comment reminds me I'd been meaning to explore that history.
Anyway, idTech4's actual game (non-rendering) code was much less influenced by Carmack, and was written in a distinctly MFC-style of C++, with a giant, brittle, scope-bleeding inheritance hierarchy. And my experience with it was pretty vexed compared to earlier engines. I ultimately left the team for a bunch of different reasons a while before Quake4 shipped, and it's the AAA game I had the least impact on by a wide margin.
I was thinking about all this as I was poking over the website, toying with the idea of writing something longer about the general topics. Might make a good HN comment, I thought...
But then I noticed that everything on his site was frozen in amber sometime around 2015... which made me uneasy. And sure enough, J.M.P. van Waveren died of cancer back in 2017 at age 39. He was a month younger than me.
I didn't really know him except through his code and forwards from other team members who were interacting with id more directly at the time. But what an incredible loss.
Just wanna say that I loved Soldier of Fortune. Lots of FPSs around that time felt really like and plastic-y. SoF was one of the few that made shooting a gun feel satisfying and visceral (and I’m not even talking about the gore, I played the censored version).
Thanks! That's really cool to hear, 20+ years later.
I actually did all the effects work on the weapons (muzzleflashes, smoke, explosions, bullet holes and surface sprays, and all the extensions to Quake2's particle systems to make that content possible) and all the single player weapons system game balancing, as a matter of fact. Both the sound design and animation / modelling on the weapons went through a number of iterations to get them really over-the-top and delightfully powerful / ridiculous, too - I was lucky to work closely with a great sound designer and a really talented animator on that.
Well, as I say, I'd been meaning to look into this in more detail because it's something I'd been long curious about. But I don't think I have time right now to dig into it.
Really enjoyed this comment--thanks for sharing. Game development really sounds like such a different beast from standard line-of-business programming. Always enjoy hearing stories about it and reading books about it (Masters of Doom comes to mind).
Thanks! I've been thinking a lot recently about maybe getting some of my own stories down. The late 90's were a really fascinating time to be in games.
And I loved Masters of Doom, too, although it was weird reading it and occasionally seeing people I knew show up in it, briefly.
You should write them down. I would love to read them, and I'm positive many others would, too. The 90s gaming scene is incredibly fascinating to read about, especially as it started to shift from the cowboy ethic to the corporate ethic (both have their pros and cons). I think I speak for a lot of us when I say we'd love to hear what you have to share.
I ... hmm. My memory is really, really dusty on that.
I remember I had a handful of conversations with Bryan Dube during development about Q4 deathmatch. He was a super sharp game programmer / technical designer who had done a ton of the work on Soldier of Fortune 2 deathmatch previously, and had worked on the Urban Terror mod for Quake 3 before that. And he was much more focused on multiplayer than I was.
We talked a lot about weapons (as I had done most of the code side work on weapons in Soldier of Fortune), but I'm now remembering him being really keen at the time on adding more high skill play to Q4 deathmatch. We all loved rocket jumping, and I remember him really wanting to add other kinds of high skill movement.
So that much I definitely remember. More than that and my memory is kind of fuzzy. To be honest, lots of team members loved deathmatch and Quake, and all of us were of course talking about gameplay possibilities all the time, so it's possible the idea originated somewhere else on the team.
Ah, yeah. If you go through the code there, Bryan had to change that file in quite a few places to implement crouch sliding.
Nick Maggoire is an animator. Super nice guy. No inside voice at all. I shared an office with him for a while :) I haven't kept up with him, but after Q4 he left for Valve where he's been ever since, it seems.
That comment strongly suggests to me that Nick did the animations for players crouch sliding. Or, that's my hunch anyway.
And he died in 2017 :(
"Carmack paid tribute to him with the comment that he was "the best developer I ever worked with, my right hand, and a good friend. It was an honor.""
I like how there's a whole book on quaternions. I've never understood them and I'm convinced every definition I've read was written by someone who also didn't understand them. I might try to find a copy if I ever dabble in 3d again
Edit: To clarify, I understand the need for quaternions (to avoid gimbal lock), just not how to use them manually. Euler angles are simple enough, I can change whichever axis by some degrees or radians. But with quaternions I never understood what was going on under the hood
One thing to know about quaternions is that you do not need to understand them in order to know how to use them, much as you do not need to understand how an automatic transmission works in order to drive a car. The knowledge of how to use them is completely separable from the knowledge of why they work, and if you concentrate on the former, and don't worry about the latter, much progress can be made.
Edit to add: When I say "you don't need to understand how they work to use them", I mean, you can literally implement all the math to multiply, conjugate, scale and invert quaternions from basic math operators and floating point numbers in C, and use those operations to rotate 3d objects around in your program successfully, all without having any idea why they work. I know this, because I have done it.
The basis for my understanding how to use quaternions, and how to build the basic operations on them comes from this site, which is quite concise and dense, but contains the necessary information if you can beat your head against it persistently: http://www.tutis.ca/Rotate/7quaternions.htm
Instead of representing a rotation by roll, pitch, and yaw... you represent rotations by a 4x4 matrix. As this is a 3-dimension problem being represented in a 4-dimensional matrix, you have some weirdness to the math (IE: you need an additional constraint) but otherwise things get easier.
---------
"Why is it easier?" Because roll / pitch / yaw systems have Gimbal Lock.
That's... pretty much all you need to know as far as I'm concerned. Its a different system of representing rotations for reasons that the "classic" system messes up in.
------------
The math for quaternions is hard, but... who uses math these days? Just go into Blender, click the Quaternion button, and click the up/down buttons on the Quaternion matrix to see how the different values rotate the object.
Once you practice both "classic" (pitch/yaw/roll) vs "quaternions" for... I dunno... 10 minutes? It becomes blatantly obvious that quaternions are easier to use. Its not even close. And I'm not sure if anyone has to implement the math of them anymore in any circumstances, so its just a matter of practicing them inside a 3d modeling program to see how to use it.
After you've learned how to use quaternions, then you go back and learn the math behind it. If you care to. Or don't, its not like you need to know what the matrix represents exactly...
---------
EDIT: Consider animation. If you've got an object that's rotating from (roll: 90-degrees, pitch: 90-degrees, yaw: 0-degrees), into (roll: 0-degrees, pitch: 180-degrees, yaw: 90-degrees), and you change this by going...
(90, 90, 0)
(89, 91, 1)
(88, 92, 2)
...
(2, 178, 88)
(1, 179, 89)
(0, 180, 90)
Did the object rotate and "look" correct in all frames?
Now do the same with the 4x4 matrix quaternion. This is all just a simple click in Blender + animation keyframes. Does the object look better?
Weird crap happens in the roll/pitch/yaw form. Weird in ways that's difficult to describe in words, but easy as crap to see in 30-seconds of Blender. So just pull out a 3d modeling program and look at the damn thing, its really obvious.
A quaternion is not a 4x4 transformation matrix. In game development context, it usually refers to a structure consisting of 4 floats and is always assumed to be normalized.
We used quaternions in our engine back in 2005-2008. Compared to matrix multiplications, multiplying quaternions was cheaper so we could save a few instructions here and there. But I never used them since.
One reason being, I suppose, processors are now much more superscalar-friendly so a matrix multiplication doesn't take much more time than a quaternion multiplication does. And with matrices, you get the whole package: not only rotations, but translations, scalings, and even projections, - all in one go. So you have simpler code, simpler data structures, and you don't lose performance so... why bother?
I didn't even include quaternions in my book. Well, not that I didn't want to. We had a whole discussion with the publisher about whether we should keep the whole chapter (complex numbers, conformal transformations, non-commutative 3D rotations, and quaternions) and I lost.
> I've never understood them and I'm convinced every definition I've read was written by someone who also didn't understand them
This seems about correct. The book in the list also seems to fall into that category.
Quaternions are actually really simple and pretty once you understand them. The idea is that you specify and axis and an angle. The axis alone gives you a 180° rotation. 1 is the identity and gives you no rotation. If you interpolate between those on a circle (cos/sin) you can get any rotation around that axis.
One may wonder why one needs the sandwich product to rotate a vector when simple multiplication is enough for complex numbers. The reason is that in 2D there is only one plane of rotation and all vectors lie in it. In higher dimensions vectors can be decomposed into a part that lies in the plane of rotation and a part that's orthogonal to it (parallel to the axis in 3D) that is untouched by the rotation. With the sandwich product the quaternions cancel out for the orthogonal part but combine for the part in the plane. This also makes it obvious you have to take half the angle.
Finding the quaternion that rotates between two vectors is also easy. You just multiply them, then take the square root to get the half-angle. Taking the square-root is extremely simple: assuming your quaternion is normalized, you just add 1 and renormalize! Obviously this doesn't work if that quaternion is -1 (can't normalize 0), but it makes sense geometrically: a 360° rotation (-1) is the same around any axis so no axis can be recovered, but for its square root (180°) you have to pick one. It's just not well defined.
Of course all of the above can be shown with a few lines of algebra, and with geometric algebra the whole thing becomes even cooler.
Whilst a lot of those books are old, some are covering subjects like Quaternions that have been well understood for hundreds of years if not much longer. They're not necessarily lacking in value. There's a lot there that's pretty evergreen.
Sounds like they're the gamedev equivalent of a Monad? Which I only vaguely understand as a result of a poster on this forum's "Everyone explains it wrong" style post. Hoping you get a similar response with this.
Basic concept, 1 dimensional form: you want to represent a direction in a 2D plane. You can use one number, a heading angle, but at some point you reach a full circle and the number has to wrap. This creates annoying special cases. So another approach is to use a 2D vector, a point on a circle. Those are usually normalized so that x^2 + y^2 = 1. No angle is "special". You can average and filter such vectors without problems, for example. This is called a homogeneous representation, because it behaves the same everywhere in its space.
Now upgrade to 2D - latitude and longitude. Near the poles, small positional changes cause huge latitude changes, and computation error increases. This is a serious problem in navigational systems. So it's common to represent latitude and longitude inside of GPS systems as a 3-component vector, a point on a sphere, in what's called "Earth-centered, earth fixed" form. Now you can average or difference measurements without special cases. (Yeah, WGS-84 to compensate for planet not being a perfect sphere, etc.)
Now upgrade to 3D orientation. That's a quaternion. It's a point on a 4-dimensional hypersphere. This can be mapped to a 3D vector pointing in space and a roll around that vector, or to pitch-roll-yaw, etc. As above, a quaternion is a unit vector. It's hard to visualize this, so just shut up and calculate.
I am going to be the HN pedant here, and for that I apologize.
Quaternions don't specifically need to be unit vectors or points on a 4-D hypersphere. They are any number with 3 imaginary parts and 1 real part. Being a unit operator is a property of a rotation (this holds true even if you aren't using quaternions or if you extend to n-dimensional rotations), not a property of quaternions.
In the context of game development, "quaternion" almost always refers to a normalized one that represents a rotation. Many engines aren't even capable of representing anything else with their quaternion types and enforce this automatically.
That's probably because pretty much all uses of quaternions in games are for rotations, which involve normalized vectors. As a mathematical concept, quatetnions are far broader and more applicable than just rotations. This is a generic mathematical concept, not something specific to graphics.
Wow, I had never seen this explanation before. That makes so much sense! Now I finally understand why we always normalize the quaternions and why that is a sensible operation...
My (poor) understanding of quaternions is they are like a vector with a rotation angle around the axis of the vector. This is probably incorrect on many levels. But it was a simple enough explanation that it made sense to my brain why this would work better than simple SRT transform parameters for avoiding gimbal lock. It's been several years since I needed to deal with 3D transformations of any sort, so I'm a bit rusty on all this.
Ultimately, the “canonical” representation of rotation state is still axis-angles, thanks to Euler’s rotation theorem (any combo of rotation results in just one rotation around some final axis)
(normalized) Quaternions are just the intermediate representation of axis-angles, they describe the component-wise algebra of combining axis-angle rotations [Euler-Rodrigues formula](https://en.wikipedia.org/wiki/Euler–Rodrigues_formula)
Game engines just leaves them as quaternions for performance reasons.
The [ Re , Im ] form is convenient for manipulating by coordinates, but the “final” succinct representation is still “angle”, because the component-wise form has more degrees of freedom than necessary.
(lw,lx,ly,lz)*(rw,rx,ry,rz) = (w,x,y,z)
where
w = ww-xx-yy-zz
x = wx+xw+yz-zy
y = wy+yw+zx-xz
z = wz+zw+xy-yx
where
ww,wx,wy,wz = lw*rw,lw*rx,lw*ry,lw*rz
xw,xx,xy,xz = lx*rw,lx*rx,lx*ry,lx*rz
yw,yx,yy,yz = ly*rw,ly*rx,ly*ry,ly*rz
zw,zx,zy,zz = lz*rw,lz*rx,lz*ry,lz*rz
There's an alternate concept for rotations called a rotor that is just as capable as the quaternion concept but does not require reasoning in higher dimensions: http://marctenbosch.com/quaternions/
Also want to add +1 for A Theory of Fun by Raph Koster. It's a very lightweight read with pictures, yet still changed the way I think about what is fun, and learning in general.
I assume, given the headings there, it talks about Model/View/Controller as the way to organise a game (and an application as a whole)?
If you’re interested in how to put a game together, MVC is an obvious model to follow.
For those who don’t understand what I mean, you firstly worry about data and have a way to represent that. That data only been the “actors” state and position in the game. Nothing graphics related. Nothing to do with how they interact. This is the “model”.
You then have completely separate code that can move those actors around by changing the values in the model. This will include state changes like collisions. No graphics involved.
You then have separate code that draws the actors in the model based on their state.
It isn’t obvious to many but this allows you to concentrate on the various areas that need coding. It also allows you to, say, easily change parts of the code as needs be.
It took awhile, but I finally found all of the books in the 'Game Development Essentials' series by Jeannie Novak (https://www.jeannie.com/gde)
• Game Development Essentials: An Introduction (3rd Edition)
• Game Interface Design (2nd Edition
• Mobile Game Development
• Game Industry Career Guide
• Game QA & Testing
• Game Audio Development
• Game Level Design
• Online Game Development
• Gameplay Mechanics
• Game Simulation Development
• Game Artificial Intelligence
• Game Project Management
• Game Story & Character Development
It took awhile, but I finally found all of the books in the 'Game Development Essentials' series by Jeannie Novak
• Game Development Essentials: An Introduction (3rd Edition)
• Game Interface Design (2nd Edition
• Mobile Game Development
• Game Industry Career Guide
• Game QA & Testing
• Game Audio Development
• Game Level Design
• Online Game Development
• Gameplay Mechanics
• Game Simulation Development
• Game Artificial Intelligence
• Game Project Management
• Game Story & Character Development
Amazingly, this thread was posted on what would have been Jan Paul's birthday.
Care was taken to ensure his website would remain active, and it's heart-warming to see that people are still finding it useful.
Johannes Marinus Paulus van Waveren was absolutely brilliant and the kind of person who left a lasting impression on those who knew him. He is sorely missed.
Does anyone know if the books in this list cover "gameplay systems"? I am 9 months into my game dev job after 7 years of experience at SaaS, and I looked a lot for examples of how to design something like a buff/debuff system or passives and came up short. Would appreciate some literature in this space because I feel like so many games have them that I don't want to re-invent the wheel each time.
I opened the collection of links, which is quite good if a bit old. But then I had a subconscious mental itch, and thought, wait... where had I heard the name mrelusive before? That sounds _really_ familiar.
And then I remembered - oh, right, mrelusive, JP-what's-his-name. I've read a huge amount of his code. When I was working on Quake4 as a game programmer and technical designer, he was writing a truly prodigious amount of code in Doom 3 that we kept getting in code updates that I was downstream of.
And he was obviously a terrifically smart guy, that was clear.
But I had cut my teeth on Carmack's style of game code while working in earlier engines. Carmack's style of game code did, and still does, heavily resonate with my personal sensibilities as a game maker. I'm not sure if that particular style of code was influenced by id's time working with Objective-C and NeXTStep in their earlier editors, but I've long suspected it might have been - writing this comment reminds me I'd been meaning to explore that history.
Anyway, idTech4's actual game (non-rendering) code was much less influenced by Carmack, and was written in a distinctly MFC-style of C++, with a giant, brittle, scope-bleeding inheritance hierarchy. And my experience with it was pretty vexed compared to earlier engines. I ultimately left the team for a bunch of different reasons a while before Quake4 shipped, and it's the AAA game I had the least impact on by a wide margin.
I was thinking about all this as I was poking over the website, toying with the idea of writing something longer about the general topics. Might make a good HN comment, I thought...
But then I noticed that everything on his site was frozen in amber sometime around 2015... which made me uneasy. And sure enough, J.M.P. van Waveren died of cancer back in 2017 at age 39. He was a month younger than me.
I didn't really know him except through his code and forwards from other team members who were interacting with id more directly at the time. But what an incredible loss.