How the hell does the recall mechanic work in TOTK? Essentially, the mechanic allows any physics object within the world to play its previous few seconds of movement in reverse. I've seen a lot of people calling this a massive feat, is it true?
How the hell does the recall mechanic work in TOTK?
Its neat, but not that complicated.
1.) Object hasn't moved do nothing
2.) Object has moved but not within the time limit do nothing
3.) Object has moved. Object stores the last position it was at rest or when it made a change in direction. When using recall check the timestamps and go back to latest one that is within range. Then treat movements like a transaction record and replay them backwards. Movement generally is just a position and a vector.
This is along the lines of what I was thinking as well. The solution is really as easy as just storing a ton of positional information, but it seems like something that would really bog down performance on something as limited as the Switch. It seems like there really is no limit on how long something has to wait until it cannot be affected by the ability.
Well they probably cheat somewhat and have some of these things have predefined backward paths. You probably only need to dynamically store recalls for objects interacts with by the player or a dynamic entity like a mob.
>storing a ton of positional information, but it seems like something that would really bog down performance on something as limited as the Switch
Not that much I think, storing the position of objects over time is only:
3 floating values (X, Y, Z position, let's say in 4 bytes precision) * frames/seconds (let's say 30) * maximum recall (let's say 1 minute) = 21KB per object
Even if there's 1000 recorded objects in the world, that's just ~20MB of RAM, and I'm pretty sure you can just do interpolation and not store 1 position per frame but rather every 4 frames for example, which would result in 5MB of data
A single texture is heavier than that
Oh wait, there's the rotation too
Well, roughly double the final value, it's still not that much.
>frames/sec mattering for a physics simulation
ask me how I know you're not a game dev
i mean you can replace it with tickrate, even then it'd probably only be 60 ticks/sec, wouldn't it?
I was thinking about that as well and I think the answer lies in how it works. When you use recall, the game is frozen. That is an effect but it also explains how it can be optimized. The game probably doesn't save position and motion vector for items that are not streamed in. And at most you may only have maybe 50 items or so within range and you could save position/motion vector data for that with no problem. You can also optimize by not storing position data every frame.
Also should mention that there is probably a thread going through and wiping old data stored in the object or the object has a finite buffer that overrides old data position and vector data after it gets filled.
arent all of these fixed movement objects? like a plank flowing down a fixed path on the river or a mechanical piece moving clockwise
No it can be done on objects manipulated by the player. That's what really boggles my mind about it.
what if you move 10 objects and do it on the first one you moved? theres probably a small limit
Congratulations on that revolutionary time rewind mechanic Nintendo
2007 game here
>found the snoy
Like clockwork.
>2007 PC slav game
>must be sony fans shilling this
This is LULZ, retard, I'm a PC gamer just like most people here
Lol, Entropy Center had this before Zelda.
>when Nintendo does it it’s a feat
Goyslop worshippers.
Wrong board
Didn't Braid do this or am i misremembering
pretty much, main difference being that there wasn't per-object rewind. it was per-object exclusion from rewind.
I've developed on "Split" on the steam... it's shit cuz of publisher....
anyway this game has same mechanic, you can rewind time, we've also added possibility to spawn a holographic clone that repeats what action you took back in time.
Idea is simple: every SAMPLE_TIME change if RECORDED_PROPERTIES changed their values:
true -> make a snapshot of those values
false -> ignore
When going back we just linearly interpolate between snapshots.
If there is constant movement of something that we face enclose in 0%-100% state, we just record the "progress" value every snapshot.
This is how we managed to take small resources when recording complex transformation in space.
BONUS: When holographic clone is created, we just don't delete data that was recorded and rewind(ed?), we just cut them of the list and give it to the holographic puppet controller.
It just werks ¯_(ツ)_/¯
Next time, post it in the stupid questions thread.
>I've seen a lot of people calling this a massive feat, is it true?
lol no
>I've seen a lot of people calling this a massive feat, is it true?
There's not that many game world objects that it applies to at a time, so it doesn't really need all that much storage. Suppose it can keep the state of 50 things going back 1000 frames, that's still quite doable in a bit over 3MB (assuming a object ID, a 3-vec for position, a 3-vec for primary axis orientation, and two more doubles for orientation, which is totally overkill, and maybe another word for the object's state). It's really not that much storage, either in memory or in the game's save state.
Linked list or some kind of buffer of vectors representing the objects velocity each physics frame. Iterate backwards and apply the velocity * -1 to the object. This works for all traits of the object including rotation, on/off status, whatever.
It's probably more complex in reality but that would be the first step I would take.
Honestly it seems similar in functionality to a program's "undo" functionality.
Can't believe retards are fawning over a rehash that took half a decade with garry's mod/nuts and bolts grafted onto it. Nintendoids are a joke.