4 ms·

The good thing about these limits is that they are all arbitrary and enforced on the server-side in the app store and related infrastructure. If it turns out th

by pilif 11y ago

The good thing about these limits is that they are all arbitrary and enforced on the server-side in the app store and related infrastructure. If it turns out that the limits are too stringent, then lifting them is simple. However, if it turns out that this works out in Apple's favor, then this provides a huge benefit for users as their devices will last much longer than they do now. I can see how the initial reaction of game developers is to think "this can't work. I can't do this", but I also have a feeling that with time solutions will present themselves and apple might also weaken the limits a bit where needed. The article is quoting Binding of Isaac: Rebirth as something that can't possibly happen on AppleTV due to this and I honestly doubt that. At no point in time are all assets visible on screen (heck - novice players will require a long time before they see anything but the first two levels - the game is hard) I'm convinced that the assets could be split into multiple chunks and delivered as needed. Then over time, as so far iOS does never expunge downloaded assets until the system is under memory pressure, the game would remain installed in full as long as people actually use it (BoI:R is way smaller than the 20GB total limit right now). Is all of this different from what we're used to? Sure. Does it make some classes of games completely impossible? I don't think so. It'll just take some getting used to, but the limitations actually enforce better architecture design, so they might even be a very good thing overall.

ascagnel_ 11y ago
It also makes me think of game levels designed for the 6th generation of consoles (PlayStation 2, GameCube, and Xbox). Since the consoles had limited memory, they'd have a permanent resident set of memory, and then individual levels would be lumped together into a package file and streamed from the disc on-demand. Lumping them all together meant that they were in the relative location on the disc, so reducing the drive head seek times. As long as the game wasn't pushing up against the size limit of the disc, assets would be repeated to avoid additional seeks (no point in seeking to the sound effect file, seeking to the music file, seeking to the model file, etc. when loading a level). The difference here is that those lumped-together levels live in the cloud and can be cached to system storage ahead of time (although faster players or those with slow network connections may need to wait for chunks to cache).

by pilif 11y ago

ascagnel_ 11y ago

It also makes me think of game levels designed for the 6th generation of consoles (PlayStation 2, GameCube, and Xbox). Since the consoles had limited memory, they'd have a permanent resident set of memory, and then individual levels would be lumped together into a package file and streamed from the disc on-demand. Lumping them all together meant that they were in the relative location on the disc, so reducing the drive head seek times. As long as the game wasn't pushing up against the size limit of the disc, assets would be repeated to avoid additional seeks (no point in seeking to the sound effect file, seeking to the music file, seeking to the model file, etc. when loading a level). The difference here is that those lumped-together levels live in the cloud and can be cached to system storage ahead of time (although faster players or those with slow network connections may need to wait for chunks to cache).