The funny/sad detail is that the 80s (at the latest) already solved the problem. Have a look as XDR and Sun RPC. It has both strongly typed APIs and versioning built in. You would have to come up with your authentication mechanism for applications e.g. have them send a cookie file (descriptor).
Any fixed sized bitstring has an obvious natural ordering, but since they're allocated randomly they lack the density and locality of sequential allocation.
The idea is to duplicate assets so loading a "level" is just sequential reading from the file system. It's required on optical media and can be very useful on spinning disks too. On SSDs it's insane. The logic should've been the other way around. Do a speed test on start an offer to "optimise for spinning media" if the performance metrics look like it would help.
If the game was ~20GB instead of ~150GB almost no player with the required CPU+GPU+RAM combination would be forced to put it on a HDD instead of a SSD.
This idea of one continuous block per level dates back to the PS1 days.
Hard drives are much, much faster than optical media - on the order of 80 seeks per second and 300 MB/s sequential versus, like, 4 seeks per second and 60 MB/s sequential (for DVD-ROM).
You still want to load sequential blocks as much as possible, but you can afford to have a few. (Assuming a traditional engine design, no megatextures etc) you probably want to load each texture from a separate file, but you can certainly afford to load a block of grass textures, a block of snow textures, etc. Also throughput is 1000x higher than a PS1 (300 kB/s) so you can presumably afford to skip parts of your sequential runs.
In theory they gave the flag state a perfectly valid casus belli, but the flag state isn't in a position to take on the US navy. It would be funny if the flag states or the owners tried to seize US owned property in some involved jurisdiction as compensation.
reply