Rewinding is technically possible, and there are games that incorporate rewinding into the game, like Braid or Prince of Persia: Sands of Time. Probably some newer ones. However, that only works if the game developer conforms to a lot of constraints. I don’t think that it will ever be a standard feature on all video games.

• Not all functions are “reversible”; you can’t just run everything “backwards” easily on a general-purpose computer. One specific operation that is famously not-easily-reversible – and that we are so confident that this is not easily reversible that we make a lot of computer security rely on it – is multiplying two prime numbers together. So you’d have to impose dramatic constraints on how games can be written to provide the ability to just say “start running the game in reverse”. (Related trivia: the question of whether the real world can theoretically be run in reverse if you could look perfectly at everything in the universe for just one moment, the arrow of time, is, as I understand it, something of an open question in physics.)

• One tactic for “rewinding” is to basically store checkpoints periodically and then retain enough information, like the player’s inputs, such that one can basically “fast forward” from a checkpoint. If you can “fast forward” cheaply enough in terms of CPU time, then rewinding to a checkpoint, and then fast-forwarding to a given point, once for each frame, looks like you’re running in reverse. This is basically how modern movie codecs work today: you have keyframes that are basically a “checkpoint” of a frame that are stored, maybe every few seconds or so. Then you have information necessary to compute the next frame from the existing one. So when you seek backwards in a movie, internally what a movie player is likely doing is seeking backwards to the keyframe prior to the time where you’re trying to seek to, then playing forward. That “seek back to a checkpoint, then play forward” is a lot more technically-easy to do than to require a game to truly be reversible, since in many games, it’s possible to store a fairly-small amount of information to record the game world at that point in time – and “play forward”. But many games also can’t store their entire world in a small amount of space, and for some, it’s hard to perform saves cheaply-enough in terms of CPU time – constantly and frequently-enough, maybe every couple seconds. If you can’t reduce the game state to a very small amount of information, then you are only going to be able to rewind so far. Implementing this is, today a requirement of a number of multiplayer games – nearly all multiplayer game engines basically rely on each computer involved being able to deterministically generate the same world state on each participating computer. One technique to reduce apparent latency to other players is to do client-side prediction, predict what the other user is going to do, like continuing to walk in the same direction that they’re walking, and then render each frame as if they had done that. Sometimes, that prediction is incorrect, and in those cases, they’re going to need to be able to re-generate the world state; what they do is constantly internally checkpoint and then roll world state forward by replaying inputs when they actually learn what that other player was doing. So some games and game engines already basically implement the internal functionality required for this sort of approach, at least over a limited period of time. But it requires the developers to constrain what they do throughout the game to some degree.