Wyrdness said:
It's not true but then you proceed to say it's an architecture problem which is what I said? Okay... You don't seem to follow what's being said it's not about save file size it's about the actual saved playthrough itself becoming unplayable because it eats up too many resources because of permanent changes it has to track. So again the is no hardware that will ever deliver this in a seamless huge open world like TOTK because this concept has a dead end flaw that the is no way around the can only ever really be limited or partial permanence. Go watch TOTK videos before you claim you can't build complex machines I've linked one recently in the Zelda thread. |
If the ps3 had 2 x 512MB split memory instead of 2 x 256MB it would not have been a problem. Therefore a hardware limitation. Arguing about architecture is irrelevant as that's part of the hardware design.
And Skyrim became unplayable on ps3 because it had to track too many changes, the change log in memory got too big. Plus an ancient engine with lousy garbage cleanup. The game did remain playable, but only after turning off all auto save features and restarting the game every 15 minutes. Either some memory leak or broken garbage cleanup routines, as load the same save file from a fresh start and it worked again (for a while) FS2020 had the same problem initially, the clean-up routines to store cache lagged behind the fetch routines causing the game to use more and more memory. I clocked it at using 51GB ram before it finally crashed, already running horribly maxing out the page file.
You can throw more RAM at it, or optimize the engine. But first you need enough RAM and storage to actually keep track of everything. With enough storage you can track everything in a huge seamless open world. Either in the cloud, in ram or on disk. I've worked on that myself in GPS navigation with maps of entire Europe and US with user changes and updates anywhere, share-able online. Basically a dynamic map stored as a multi level quad tree with bit flags to indicate where changes are, with a hash table to lookup the actual changes in an efficient way. You can build onto it yourself (but mostly used for temporary closures, direction changes, speed traps, traffic jams etc etc) And that ran on piss poor hardware nearly 20 years ago with little ram. Streaming data back and forth to disk, fetching what's relevant. Surely a game can do that as well...
Dynamic machines, sure, they will only be active in a bubble around the player, just like any other moving parts like NPCs. The enemies don't patrol on the other side of the map either. That's the whole point of storage, go out of range, freeze and store until back in range. Minecraft does that as well. I don't expect to make a harvester that keeps running on the other side of the map. That's left to MMO style games that run in the cloud. (Although there are plenty ways to simplify stuff in case of harvesters or machines that appear to keep on going by logging the output. Games are deterministic by nature, everything can be turned back into an equation when the user is absent)