this post was submitted on 13 Nov 2023
115 points (86.6% liked)
Games
32724 readers
2462 users here now
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Weekly Threads:
Rules:
-
Submissions have to be related to games
-
No bigotry or harassment, be civil
-
No excessive self-promotion
-
Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
-
Mark Spoilers and NSFW
-
No linking to piracy
More information about the community rules can be found here.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
yeah this can only work if implemented by the devs. The only reason this can be done for some older emulated games is that there is only a megabyte or two needed to capture the state of the entire system. Not several gigabytes.
I was under the assumption the collections that utilize this system do it by just saving the inputs and timestamps and simulate them as such rather than understanding the entire whole state. I'm not sure how it works with non-seeded elements
I do agree with you about the dev focus. It would be way more complex even though if feasible if you can simulate without it graphically but you I can't imagine it just being a system similar to recording or achievements
that only really works with deterministic systems though. You could do that with a 6502 or simple systems because you could perfectly predict what the state of the system would be in just by replaying inputs. everything up to predicting all cache misses.
consider a badly written game on a modern console (remember that save states should work for any game) in which physics is tied to framerate. Follow the chain... framerate depends on system speed... which, indirectly depends on the ambient temperature (a console running in a hot climate would throttle earlier than one running in an air conditioned cool room). And because modern systems execute more than one process, it also depends on what else is running (were you downloading a game in the background, slowing down the game ever so slightly?) or unpredictable things such as interrupts on certain system timers. And the list goes on and on. Even if the game didn't have physics depending on framerate, differing deltaTime on each frame means different floating point rounding errors happen, which could accumulate over time.
So in this case, replaying inputs does not get you the exact state. you were in. there are just too many variables.
No game should save gigabytes. Even megabytes can be too much. If the game is very linear a save could mean a single number. Even if it has character cosmetic customization and a convoluted plot with lots of choices it's still usually in the kilobyte range. The larger saves (overall) would be sports games like rally racing where the game needs to be able to provide a thorough replay of every race.
system state is not the same as a save file. System state is the cpu registers, the process' entire memory space (because you don't know what the game might do at any point) gpu context, etc.
edit: example: the save file for older games was measured in bytes. System state is much larger han that. It contains everything not just what the developer decided to allow you to save.
My BG3 saves are massive. Not at the PC but very much in the Gigabytes