Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Let me make the case that it's definitely not just nostalgia - or, at least, that Quake style movement didn't fade away because of any objective, rational process.
One of the exasperating consequences of the rise of game engines has been that you have games shipping that have more and more of their game design inherited from their game engines.
On some level this makes sense - games are just massively complicated, and so if you already have working, tested code, it's often quite tempting to just go with what already works (and not spend time really internalizing how working things work) and then focus on figuring out the particular things you are adding from that baseline.
As just such an example, when I was working on Activision's Soldier of Fortune, we largely inherited Quake 2's movement code, and most of it was left untouched by the time we shipped. At some point, midway through development, inspired by Thief, I stayed late one night with a co-worker, and I added in leaning around corners to the player controls. I don't remember the particulars of that process, but (obviously) I had to make tons of aesthetic choices while doing that, because I was writing it from scratch. But the base movement we could inherit.
If you go back and look at first person games from the late 90's, their aesthetic choices about basic player movement are all different in subtle ways. That makes sense, because most studios were writing their own bespoke engines at the time, and there was vastly less code sharing. So people were writing code because there was no particular alternative, and so they were making tons and tons of aesthetics choices whether they wanted to or not. Lots of those choices weren't always great, but they were often particular.
It's clear at this point that lots and lots of FPS games just inherit Unreal Engines movement. Not because it's great, but because it comes with Unreal and it's a default. To me, there's something very specific about the way friction works with player movement in Unreal that feels very ... sticky? ... compared to Quake Engine games. Players come to a stop when input is released in a way that feels like being in glue - again, at least to me. There's more subtle gliding around in Quake. As far as I can tell, the difference rarely effects game play in most games. But it does change how it feels aesthetically to play moment by moment.
Anyway, this topic feels intensely path dependent to me. Unreal's movement is the default because Unreal is the default engine (in a lot of contexts), but it didn't become the default because of anything specific about its player movement code. Those aesthetic decisions were just along for the ride, so to speak. Or at least, that's my sense.
Interestingly, I found a github project a while ago that tried to reverse engineer Quake / Source's movement and put it into Unreal Engine 4. No idea how successful the project is, but I suspect it might be an interesting resource for seeing what's different between the two: https://github.com/ProjectBorealis/PBCharacterMovement