How do games like Prince of Persia manipulate time? | Bitwise
Вставка
- Опубліковано 9 чер 2024
- Manipulating time at will is in my opinion one of the most interesting and powerful feeling game mechanics.
Games like Prince of Persia, Braid, Qauntum League and even Overwatch employ time manipulation mechanics. But how does it work? How do games manipulate time? How can you rewind the entire world, speed it up and slow it down?
In this video I will go in-depth into the inner workings of Time Manipulation in games.
Timestamps
0:00 Intro
1:05 Update loops and time steps
4:30 Global time rewinding
8:24 Local time rewinding
13:12 Optimizations
15:15 Conclusion
My patreon: / digidigger
You can listen to our podcast at:
/ @publicvoidupdate
open.spotify.com/show/7ak1IV8...
podcasts.google.com/feed/aHR0...
or wherever you listen to podcasts
Music in in outro:
Besus y Abrazor - Rolemusic: freemusicarchive.org/music/Ro... available under a Creative Commons Attribution license creativecommons.org/licenses/... - Ігри
That's very insightful, the "zipping" method in the OG prince of persia trilogy abuses the limitation of the method. Where your character's movement/action is only stored for a maximum number of 20-ish action. If you do more actions than the maximum in a short amount of time and you start rewinding, the games would start glitching and teleports you forward, allowing you to past through locked doors or skipping a large gap.
in GTA Vice City speedruns they use the replays to change stuff since the replays are not only videos but made in engine and some properties can be transferred from the replay to the current position/time. I forgot how it actually works but it looks pretty wild
6:40 ok I just realized something really clever with TOTK's rewind. So when you rewind you see a ghost of the object at regular intervals. I think this is one of those hard save points that isnt interpolated. I dont think its *every single one* but that is extremely clever to use the position they know it was at, that they are going to place it back at, and make a ghost of that point.
I'm surprised the video didn't mention TotK. Perfect implementation.
I also thought of TOTK, but because in one of the puzzles I had a cube move touching side to side with the wall and going around a 90 deg. corner. This, as I understand now after this video, made the game tilt the cube unintentionally with an almost but not perfect interpolation of 'saved frames'
a lot of info in this video here is wrong
i worked on a student project called chrono disfunglement so we rebuild braid time rewind in 3d
you dont store key frame data only, you store key frame data and then you store the difference of each frame. the reason behind storing the difference instead of the key frame is due to reduced bit space required to store it. for e.g. if your data is an integer the difference in key frame 1 and key frame 2 is usually way smaller than a integer, that's how you store less data. think of it as a lossless video file compression, the concept is the same
there are key topics that isnt touched too, for e.g. how do you handle particles system cause those require randomisation. one way is to use graph since graph is continuous but a long enough graph (that doesn't repeat itself) would look random to a user
you don't use delta time either since that causes driff, you need to use fixed update, to speed up or slow down you just call it more or less times in a period
go watch the vid made by braid creator, all the info to build a time rewind game is there
I cannot explain how hard the Belgian techno anthem Pump Up The Jam joke you inserted here landed with me. Just a huge roaring reception over here.
I watched Cunk On Earth last week, and today for some reason I've been pestering my wife with that joke all day. Explaining it, showing it to her, playing the song. And to so abruptly find it here in the midst of a great technical explanation was just perfect. 10/10.
There is also FixedUpdate() which fixes an issue on really fast computers, where deltaTime can be so small it introduces large rounding artifacts. Its also called in line with physics updates. This means if you update physics in Update(), it could happen that partial state is displayed on screen.
You can also improve performance by using looped linked lists for the object data, just make sure everything is pre-initialised when you start a scene etc so that if a rewind happens straight away it just rewinds to it's start position, no need to check if you're out of list bounds because you just loop back to start/end seemlessly
Also known as circular buffers. Better to use fixed-size arrays though than linked lists for both memory and performance gains.
@@PapoochCZ Depends on use case, in this case yeah, fixed size is better for time manipulation, however I would not store positions but rather the amount of time's worth recorded, velocity, rotation & increment amounts to add (so for example object->velocity += time_point->velocity,
object->inc_velocity += time_point->inc_velocity, loop object->velocity += object->inc_velocity until next time point). Yes it would take more memory but it would also allow storing more time's worth of data for less than the equiv in positions etc
You have inspired me to make a low poly, open source, time manipulation game!
I've had my own thoughts about reversing time, where instead of saving everything that happened in the past, you make use of the laws of physics being reversible, so you basically just need to invert the velocity of every point mass, and in theory everything should play out in reverse.
When writing this as a game, things break down pretty quickly because things usually aren't actual point masses, and the game physics probably don't match real physics and therefore may not be reversible, so you would need to basically custom-write the physics for how things behave when they're reversed.
But I think if you do manage to do something like that, it behaves quite differently from what's described in this video. First of all, there would be no passive performance drain from constantly saving all the data from every object, so this could scale very differently. Then, what I think is the main difference, is that it would be possible for a currently reversed object to behave differently from what it did originally, for example when another object that it would "reversely interact" with isn't there to have the interaction with. Just that mechanic probably would be pretty interesting to build a puzzle game around.
I adore your channel, you helped me out a lot!
As someone who published a time travelling game on console, this video evokes very painful memories. 😂
I've always wondered this for a long time after playing the Prince of Persia series but not being educated in game development I never really knew where to look for answers!!
that was a nice video! Your explanation and edit made it easier to understand!
Man, i love your videos so much. All your videos are awesome congratulations
This is an excellent explanation of this mechanic!
Thank you for recommending Braid. That was my first Indie Game i've played back then and i really loved the mechanics there ❤
Convergence: A League of Legend Story is a must play when it comes to time manipulation. A metroidvania where all the time you can rewind time, use various time powers to fight and traverse. It's awesome.
This video came up at the perfect time, as I've recently been thinking about how one would implement time travel into a multiplayer game.
Though, I was wondering whether it would be possible to include player perception into it as well. (Player 1 stops time, but player 2 sees only the other teleport.)
I only theorise as I am not a game dev, but I think the trick would be in sending both players out of sync data from the game server.
Timebenders was exactly that, a time traveling multiplayer game. What I can say is: do not make this, it's a pain to program and you will question why you ever got into game dev in the first place :')
Conceptually you need to think about what happens from the perspective of the other player when one player stops time locally. I think your interpretation would make sense, except for what happens with the other players. If one player freezes time around them, then everybody else would not be able to move. If that player then moves somewhere else and resumes time, from the perspective of everybody else that player would indeed "teleport".
If it's more of a "local" time freeze then I suppose only players within its radius would perceive it as a teleport. Everybody else would just see that player walking around normally I suppose. It's kinda hard to wrap your head around, but this is what would make sense to me at least.
Wait what?
oh yeah!
Comeback Time
You know Glen's "how it was made series"? It's essentially not actually teaching you how the mechanics work. This is where the hard efforts of DigiDigger comes in and truly teaches you the useful information.
very nice and deep
thanks
PUMP UP THE JAM, PUMP IT UP WHILE YOUR FEET ARE STOMPIN
That game of yours looks fun as hell
As a guy that like to develop games sometimes, these concepts are really cool to learn :). When I play a game with a really cool mechanic my developer brain always wonder how they did it. Hey, would be cool if you explain how Noita can do physics for essentially every pixel of the game without burning our computers.
Good idea! That's actually something I want to dive into as well: putting it on the list :)
AKA Framerate Independence
came in the right time
been wondering about that since playing tears of the kingdom
If you are a videogame designer, or want to be one, this channel is one of the few that teach theory in a professional way without need to know much technical stuff. Other channels I suggest you are GameHut and Coding Secrets (same guy, but slightly different content).
you broke me at 4:55
You can also guess the current velocity of the object by looking at its position and its position at the next frame, same thing for the rotation velocity.
(not the previous one since you could've gotten a new force added at the current frame which impacted the next frame)
Interesting thing about time rewinding in Sands of Time and other games from first ubisoft trilogy, is that it stores not frames, but fixed amount of animations. It is 12 or 20, I don't remember correctly. Current ANY% speedrunning strat is "zipping": quickly make more animations then this buffer can contain, and when, rewinding time, the player model will be launched with direction and velocity of the last animation, because the engine does not know what to do because there are no more animations to play.
I guess it was made for performance reasons also: you don't need to store the entire timeline of all entities if all your moving entities are player and enemies, you just remember animation start frames and direction and then play animations in backwards.
Amazing video! I have a question though. In the game timebenders, if players agreed to not kill eachother and just continue moving around, wouldn't saving all those frame information cause the game to crash or did you limit the amount of time players can rewind?
The visualisation used in this video heavily implies a ring buffer. And most games with time reversal limit the time you can reverse.
13:50 So a span, very interesting
To keep in mind!
I was half expecting this to be a video about a clever use of the Command Pattern, but it never came up. I'm wondering if you considered it during your research but settled on the methods in the video?
I wonder if you can improve performances by only storing key frames, like a change of direction ? Because if you think of it, you can always rewind a free fall path by only storing the end and the start of the path.
It makes me want to make another game prototype that will never come into a real game...
If you can let the engine figure everything out, the only key frames would be the initial state/environment, player inputs, and perhaps the RNG output. Trackmania kind of does this with their replay files.
@@lovalmidas oh ok that's pretty crazy at this point ! Like you really need the engine to make the exact same operations every time
Great explanation
You haven’t seen the video yet
Conceptually, reversing time in classical mechanics is simply reversing the direction of every velocity. Couldn't then you reverse time in the game by recording all external events (like keypresses and every other interaction that isn't the direct result of the physics engine) and reversing all velocities (linear velocity, angular velocity, animations, etc)? You would then play the external events in reverse order at the appropiate time to essentially reenact the past. This could have problems with rounding errors and lead to divergences to what actually happened but I reckon they wouldn't be that big if the reversing is kept to a "small" duration.
Basically, if you can get you physics engine to work deterministically, you could reverse time quite easily with little memory requirements.
In fact, maybe both methods can be combined to make sure that the "reenacments" don't diverge too much by periodically (buy not too often) resetting the state of the objects to what the recorded state says it should be at that point in the rewind.
More than the physics engine has to be deterministic. Games often involve destroying and creating objects, so you will need maintain a record from the past so you can 'reverse' their deletion. If there were random number generators used (and they don't usually work in the reverse direction), you need to work around it. You'll also need to reverse AI states, which might be complicated if you are using anything other than a history table.
The super minimalistic idea would come in the form of a word document with undo function. The undo function itself contains memory of what was changed, and sometimes it is easier to keep one record of a 3MB image and have the undo function reference it, than have various undo steps keep a copy of it each time it is transformed.
@@lovalmidas yes, all those external "interactions" to the physics engine would need to be recorded.
Great video! One suggestion from a non-native speaker though: please lower the volume of background music. It really distracts from your voice and makes understanding you way harder than it needs to be. Except for that, everything was really easy to understand!
I did the smashmouth tabs thing and I need a doctor.
12:21 Could you make some kind of if statement and "isGoingInReverse" bool that you would negate when locally going backwards on each individual object, so that you'd only GLOBALLY record object movement if objects isGoingInReverse=false?
Aka, to only record local movement in global movement if the local movement ISNT going in rerverse somehow?
Great videos btw, I'm learning a lot here! Thank you ;D
Thanks Cunk!
Knowledge.
WHOOOOOO LET'S GOO
TheStellarJay would have probably really liked that game if it ever got released.
Christmas in July, what a pleasant surprise.
Time and space are productions of the mind imposed on reality to structure it.
Do you know about Achron? The RTS game that you can time travel in multiplayer
How do you produce your videos and make visual representations?
It's ironic that the podcast plug has a bad audio quality filter over it.
Sooo, if i had 2 different variables for a delta time, could an object move at a different velocity from the world? Like, lets day we freeze the worlds delta time, but the player still has the normal delta time, would the player still br able to move while the world is stopped? If so, could we have something like the Flashs perspective? If we make the worlds delta time really slow, and the player moves, we record it but play the recording speeding the worlds delta time and the players so the ratio is still the same but the worlds delta time is the same as the original ome from the player, would the player move super fast, while retaimimg their own sense of time?
Honestly i have so many questions now, and i could even list some more that i thought off, but it would be boring to everyone lol
Ps: sorry for bad english, not my native language
Typically, you would store one additional deltaTime for a local override, and a boolean switch to indicate whether the object should use its own local deltaTime.
This recreates the Bullet Time and the SuperHot core mechanics, where the player moves with his own deltaTime (kept fairly constant to not disorient the player), while the rest of the world moves with the global deltaTime (tied to the player's movement for SuperHot).
In the world's perspective, it will seem like the player is moving really fast, assuming the engine is able to handle the speedup and still make accurate physics calculations.
Hehe I've also used this method before
5:05 lmao
Dissapointed at the lack of foldyflaps and moonman.
"How would it rate the current state of the west capitalist market economy" was the most hopeful thing I've heard in quite a while...!
Return of The KIIIINNNGGGG
Cringe
Time.timeScale = 0.5f;
Wait other people know about Quantum League? WAIT WAIT WAI-
I wonder how ToTK's Recall ability works. It's incredibly janky and a bit overpowered, but still very fun. Of course, it only acts on one object at a time, but you can run it on just about any physics object...
You actually called it. It's linked to physics. Probably storing every physics frame locally in a memory efficient way (I'd assume a local, maxed local buffer of sorts). The hard part here likely being that there are so many scenes that you want to make sure the object graph tree is superbly managed or it'll end up glitching hard.