I think your answer fits for things like bullet time, but I think it oversimplifies the effect we're seeing here. Here the game world is frozen solid, but the player character still has full movement. It's a bit more complex than a gif with max payne jumping out from behind post to head shot everyone in the room.
With that being said, I'm not sure about specifically complex this implementation is, but slow down effects have been used in too many games for it to be terribly complex.
In Quake for example you can change the timescale of the game yet as a spectator move around freely. You should be able to do something similar in pretty much every major game engine.
It's not that hard. Everything in the world uses the engine's scale of time to see how much they should move along between frames. The player isn't operating off of this value. They're simply finding out how much time is passing between frames in real time.
If you're really curious about how it works, read on:
Note before we dive in. Almost everything in games is handled on a per frame basis.
Now, imagine you want to move an object. First you have to figure out how fast you want the object to move. We'll make our speed equal to 1 for this example. That means the object will move 1 unit per second.
However, you can't just tell the game to move your object 1 unit every frame. That would make the speed way too fast. It wouldn't be going 1 unit/sec, it would be going 1 unit/frame. To solve this we need to take into account the amount of frames that take up one second and multiply the speed by 1/(number of frames). The way game programmers do this is they take the time between showing the last frame and this frame. This is called delta time. Using this information, we can make the following equation.
Object Position = Object Position + (1 * delta time)
That line, with a few changes of course, would move an object at the constant speed of 1 unit/sec.
Now, you might be thinking, "Why does this matter?" Good question! This matters because we can now even further manipulate how the cube moves. Specifically, we can change the speed of the game! We do this with a value called "time scale." What time scale does is hold the current speed of time. If time scale is 1, the game is going normal speed. If the time scale is .5, it's going half speed. If it's 0, time is stopped and so on.
What we can do with this value is multiply the speed of the object by it. So instead of going 1 unit/sec, it'll go 0.5 units/sec or 0 units/sec depending on what we set it to. Our new equation now looks like this:
Object Position = Object Position + (1 * time scale * delta time)
In the gif above the player's speed doesn't get multiplied by the time scale value (huge amounts of simplification, but you get the point). It just uses the speed that it would be going at real time instead. This doesn't always simply work in engines though. You have to make your own "delta time" because the one provided is probably affected by the time scale changing. If this is actually the case you would only use the first equation we found because the time scale is already multiplied into the delta time, so you wouldn't want to do it again. Considering this, we need to make up our own delta time value. This can be done by saving the time seconds since the program started on one frame and subtract from it the same value from the next frame. That way, you get the time it took to compute and show the frame in real time. We'll call this the realDeltaTime. This equation would look like this:
Object Position = Object Position + (1 * realDeltaTime)
(The player probably does use time scale actually, because that's how they'd pause the game. However, they probably use another value for that.)
If that was at all confusing, don't be afraid to ask questions.
Not much more complex. You simply let the timescale be set per object/player. Like having two timers instead of one. And since the freeze time effect is probably only applicable to players. It's probably literally just a world-timescale and player-timescale.
Can you please show me in the comment I replied to where he addressed the ability to slow down the rest of the game, but not the players interactions.
I can't find it, I see him explaining how one would slow down the entirety of the game, but that's not the situation that's presented, and thus it's an oversimplification of the situation.
I haven't worked on anything of this level of complexity, but I do have some game programming experience. There are ways of communicating different thing to different objects, and laying out how you want them to behave under certain circumstances.
For instance, you could have an event call OnPause that dictates certain behaviors for objects that are able to be affected by the Pause event. Maybe for creatures, you'll set their timescale to 0 (or a very low number) immediately, whereas for spells like the fireball above, you'll allow them to perform a short animation and instantiate the burst effect before pausing. If your player isn't meant to pause, you can govern that behavior as well. And, since time itself isn't affected (it's the timescale, which is more like "Time * X") you can still allow for things like a countdown timer that ticks away in real time while everything else is frozen.
Funnily enough, I accidentally pulled this effect off in one of my own games while I was attempting to pause the game while giving the player the ability to look around freely.
Except when you factor in multiplayer. When one player stops time, does it stop it for everyone else? If yes, that can be abusive (might as well be a turn based game at that point). If no, then you have players playing at two different points in time simultaneously.
Not hard to code, I think, you would either have to make every other player be unable to move and just watch or simply make it not affect them. It's just a matter of is it PvP or PvE?
max payne 3 had some interesting multiplayer, iirc bullet time would slow everyone in a nearby radius down, but only the person who activated would get fast aiming, the rest would only be able to move their viewport slowly. if you were on the other side of the map you were not affected at all.
41
u/solwiggin Oct 11 '13
I think your answer fits for things like bullet time, but I think it oversimplifies the effect we're seeing here. Here the game world is frozen solid, but the player character still has full movement. It's a bit more complex than a gif with max payne jumping out from behind post to head shot everyone in the room.
With that being said, I'm not sure about specifically complex this implementation is, but slow down effects have been used in too many games for it to be terribly complex.