Dead Rising 3 Gets Massive 13GB Update
- Thread starter Alex Co
- Start date
Recommended Videos
the answer to that is bad file storage. they probably went the easy way and stored the data in large archives. like "textures.dat holding ALL textures in the game in one file, which actually has 10.000 files inside, but hard drives treat it liek one file and thus less likely to get things fragmented. however they probably encoded the archive in such a way that you cant replace part of it without reprocessing whole archive (part of why modding some games were hard). so they thought its easier to jut redownload whole archive even if it changes only part of it, hence the large sized download. we see this a lot in the MMOs and their archived packages. expansion comes out, heres a 5 gb download that wont actually icnrease the size of the game.Sanunes said:
Basically this is good idea when you plan to never update the game as it usually causes less trouble for people that dont know how hard drives work and get it fragmented (as NTFS actually looks if it can fit whole file without fragmenting when writing, which causes less fragmentation when using the drive, and FAT 32 doesnt (but really noone uses FAT anymore))
I think really big files are, in general, more likely to get fragmented. However, I suppose that if you had an archive file that you wrote directly over, without resizing it at all, future updates shouldn't make fragmentation worse. But then you are implementing a kind of file system in the file itself, which is a bit strange. It would be a development effort with few gains and added restrictions that I doubt studios would subject themselves to.Strazdas said:
FAT32 is a very dated file system, but it does seem to get used in basically all USB flash drives. It doesn't support files over 4GB (as indicated by the 32 in the name). It is possible to manually split larger files up before copying them over, but that's not really something you want to do with any frequency.
OT:
A 13 GB update really doesn't seem like something that should be common. Proper patches should only include the data that actually changes. So unless they changed a significant amount of the assets for the game, this really shouldn't be so big. Even if they are using large archives, patching systems can work on a binary level (most effective if the patch is applied on an uncompressed level, of course).
Granted, it could turn out to be a common occurrence if Microsoft only provides them one method to patch, and it's an inefficient one.
Will you be able to do other things while it downloads? And can you turn of the machine during a download and continue on a later moment?
One big file is more likely to get fragmented than 1 small file. however 1 big file versus 10.000 small files is less fragmented as those 10.000 files would be written all over the drive. And since NTFS looks for "large enough" space to fit the file if possible it is more likely that at worst that big file will be in 5 fragments instead of 10.000 files in 100 fragments. That makes readability easier and since you need to read hundreds of those files each time your loading something - working with it faster.ntfwc said:
i do not know how hard of easy it is to develop for that, only that most games i know used that and that games that didnt and are inconstant developement also started moving towards packages like these (for example world of tanks). It is obviuosly popular with game developers.
I have a flash drive with FAT32 as well, however that is also getting outdated. all the flash drives i see now are going full NTFS, so FAT32 is pretty much obsolete with exception of older devices like my MP3 player that still uses a 2gb FAT32 card.
I agree that this is how it SHOULD work. however sometimes archives are built in a way that you would need to "Rebuild" them to make this work (for example how if you mod San Andreas and forget to press rebuilding of the data file the game will be full of bugs). and sometimes doing a "mysteriuos rebuilding" on a machine that takes a lot of time with large archives (takes around 2 minutes for ~2GB files i done it with, no idea how much 13 gb will take) may cause anger with users. Especially considering that nowadays some people may even download the whole thing faster than that. I do agree that updating the archives would be what should be done but does the average user even know what that is?
I don't doubt that packaging resources is popular. I was referring to designing an archive format where you could update the archive file in place without changing its size, in order to avoid possible fragmentation from reallocation. Since individual objects would likely change size in updates, you would have to handle allocation and deallocation within the archive yourself, so you would be implementing a type of file system. It would be an interesting challenge.Strazdas said:
I think that was the plan in the first place, but it's still kind of stupid (of them). Especially when you're trying to make this the center of a living room experience.StubbornGiant said: