By using this site, you agree to our Privacy Policy and our Terms of Use. Close
Tachikoma on 25 March 2015
Edit Thread
SvennoJ said:


Maybe I'm wrong yet most of the geometry, textures, models, all the stuff you need around each spawn point is the same every time. Loading that in 1 chunk from disk is more efficient, but yes indeed not optimal for a digital download version. You don't need to parse the spawn area every time, it's the same.
It's a trade off. I've worked mostly with gps navigation, maps of whole of europe, heavily compressed onto a 1 GB memory card with 1mb working memory. It's a balancing act but a couple smart caches and a bit of duplicated data where it counts go a long way towards a positive user experience.

Caching the area around the spawnpoint into memory would require a cache in active memory of about 2gb, thats a large portion of memory to "spend" on data that would become obsolete the moment the player switches area or progresses further, not to mention the process of duplicating this data to memory would impact overall performance and destroy the active memory area where predictive precaching is stored (there are no loading screens as you explore, only when warping from one area to the next).

GPS maps work in entirely different ways than games, you're working with a vector based map that streams in only one layer of detail at a time, as anyone who has used a gps device or google earth will know, gradually panning across a map delivers a generally smooth, seemless experience while jumping from one zoomed in portion to another causes a delay while the map area is parsed, that delay is the game equivolent of a loading screen.

I put it to you that duplicated data within a GPS device would use infinitely less storage space than duplicting the data stored in a spawn location for this game, the draw distance is insane, and thus beyond the intial high lod assets you would need virtually the entire citys low lod assets stored in memory too.

As I said the patch will likely reduce load times by adjusting the starting point with a less aggressive lod prefetch, resulting in more "beer eye" for the first 10 seconds and shorter overall times.

The engine as it is right now does already use memory storage for persistant data, which has a footprint of around 320mb, and stored the character data, statistics, and persistant world data, as well as the model data of fellow players that join during an active session, and the multiple forms of every weapon you possess.

While they will no doubt be able to find tune aspects of the streaming system beyond adjusting initial lod setup, the method you suggest would only really be feasible if there was only a disk version, and if ALL 8gb of memory for the system was available to games (which as we all know, it isn't).