I've been looking around and it appears suggestions are only to store data to UserPrefs, or PersistentDataPath.

I intend to have map files streamed to the client on demand, and saved for reuse. UserPrefs seems inappropriate for large blobs. PersistentDataPath is per computer user, thus duplicating data and space usage. I believe Program Files has access restrictions too.

What are the current best practices for storing runtime data that meet the following criteria?

• Is shared across user accounts to avoid wasting disk space.
• Doesn't require elevated permissions.
• Doesn't annoy the user (such as data being placed in My Documents).
• Can be modified at any time.

I don't think placing game related files in My Documents/My Games/ annoys users, it's pretty much standard to put it there so why don't you do it? Each user can have it's own save games, skins and mods this way and it's easy accessible/mod-able.

However, for larger assets you do want to consider to share them amongst user accounts. I think you have two options:

• Users/Public/ isn't tied to a specific account and can be used for this.
• Store it locally like in a Data/Maps folder within your main game folder.

Apart from that, I think map data should in most cases not be all that large. Maps should just be a bunch of numbers like ID's and positions so unless it are huge dynamic worlds it won't really matter to have duplicates on rare occasions stored on the same HD.

• I would also thought inside mygame/Data/Maps etc. as your other content would likely be stored in the same location. (such as mygame/Data/Models) – lozzajp Oct 31 '16 at 12:02
• agreed, though assuming it won't annoy users is possibly not a good thing. I wouldn't classify myself as an unwitting, run-off-the-mill user, but it annoys me quite a lot. per default, your users folder is on your system drive. if you're trying to keep that clean, it gets on ones nerves if programs just bluntly dump downloaded files of arbitrary size there. You should also consider that the users folder will be synced in most AD environments ; that will mean syncing big downloaded files to the AD server. – Timothy Groote Oct 31 '16 at 12:30
• @TimothyGroote I agree, large files should not belong there. I have no experience with servers and synchronizing these folders however. It's always better to give the experience player options to choose from. – Madmenyo Oct 31 '16 at 12:38

I reccomend you use regular System.IO with the System.IO.Environment class. You can store to Local Appdata. The Environment class provides functions like the SpecialFolder enum or the GetFolderPath method to get the place to store data. This actually works pretty well as it gets the correct AppData folder for each operating system(on Windows it is Appdata/Local). You can then create your own folder in there for your game(if it doesn't already exist), You can store anything you need there: Settings, Levels, Scores, etc.

Upon much research, I've decided ProgramData is the best place. It's made for common data between users for a program (as opposed to the per-user AppData). I'll save per-user to AppData, and saves to %USER%/Saved Games.

I should have mentioned that these files aren't necessary to keep around, they're more of a cache. I shouldn't have mentioned 'My documents', as that's not shared between users at all anyway. I don't consider game data to be a document.

Unfortunately, it's a semi-protected directory where you can't modify a file that was created by another user.

Mono 2, which Unity uses, doesn't implement the appropriate classes for modifying permissions. I've had to resort to PInvoke/Native plugins.

I know the maps won't be large, but I'm not going to use that as an excuse for not doing things properly. Users/Public just seems like abuse.

Edit: You could do it without permissions, using a cyclic system. User1 saves to "A.txt", if the file needs changing, and User2 logs in next, User2 saves to "B.txt". When User1 logs back in, "A.txt" could be deleted, etc.