By using this site, you agree to our Privacy Policy and our Terms of Use. Close
SvennoJ said:
Wyrdness said:

So show us these so called worlds you've created on those hardware that is comparable to the games now then because you've gone round in circles only to end up admitting that it stops when you run out of disk space basically highlighting my point to begin with, the bathtub analogy to simplify it. The is a reason developers aren't doing as you say no matter what hardware comes out after all you've been using the solution since 2000 yet no one in the industry is using it on these large scale open worlds. 

No s* specs don't mean much on their own that's the whole point architecture is how the hardware is set up to function. Skyrim uses a different engine today implementing fixes modders created. 

I developed TomTom Navigator back in the early 2000s in a small team, mostly responsible for map storage (TeleAtlas map data) and rendering, route planning, instruction generation and gps map matching. After which I moved on to dynamic storage of map changes (and exchange through the cloud, which we just called a server back then) and dynamic obstructions (traffic jams, closures).

Really it's not hard to see persistence in games is very possible large scale, Minecraft has been doing it for decades and wasn't the first. You don't need much data to store changes, at most 22 bytes for X,Y,Z plus orientation and item ID. In case of Ultrahand contraptions it would be X,Y,Z and orientation for the center point of the object then a binary tree storing the attached items with relative coordinates, orientation and item ID. (Which is easily compressed to use up even less data)

If just storing displaced items, at 22 bytes per item, that's already over 47 thousand items per megabyte before compression. Using a quad tree to efficiently store, retrieve and edit these items doesn't add a lot of overhead. It's just an efficient indexing system to find things quickly based on world position.
The challenging part was calculating routes across Europe within the small memory limit of the device while everything else keeps running. Thus wrote my own memory manager and garbage collection routines to cull dead ends from memory and efficiently reuse that memory. A combination of single linked lists and using fixed size memory blocks that could be exchanged between different parts of the program based on demand.

We had the entire road network, every address, street names, built up areas (buildings), rivers and other land use geographical features, point of interest, stored in less than 2Gb with efficient retrieval back in 2005. Zoom-able from entire Europe/NA down to street level.

I must say it was pretty cool to see the good old TeleAtlas (now TomTom owned) map data back in FS2020 as that uses Bing which uses TomTom maps. Ironically I never use gps navigation myself anymore, I'm so tuned to maps I take a few looks at Google maps when I have to go somewhere and just drive there :) I don't even have smart phone, kinda stepped away from technology. Never make your hobby your work kinda thing.

Anyway to me it's clear, TotK 'sacrificed' persistence over interactivity / physical interactions. Some, maybe most people would prefer that. To me it's just more TwitTok moments as I'm more of a builder expecting things to stay after I build them. With better hardware, it could have done both. Hence the Switch feels dated.

That is not even comparable to what game developers deal with like mate seriously, we're talking huge dynamic worlds that are generating interactions all the way down to physics interacting with tonnes of objects here.