• Advertisement
Sign in to follow this  

Where do you save?

Recommended Posts

Hello dear readers!

I would like to know where you save on your games on what operating system and why.

In a perfect world, I dream from games saving their save-games in their own location (assuming they are not only a bare exe without folder). Nonetheless, since Windows Vista, Microsoft seems to dream of the C:\Users\User\Saved Games\, which is not used by any of my games at least.

Therefore, why do games on Windows even bother writing to anything but within the game's own folder? Are there any possible permission-problems in Windows?

Personally, I find the Documents-folder a bit odd, I really dislike when I see applications cluttering their content into this folder. Some games even put Screenshots in it, without putting them in a folder first. This bothers me a lot as it rejects even the slightest will of structure. Documents seemed to evolved into a "just smash your files here"-path for every application.

Now, when I look at Android, everything seems to be a bit stricter. As far as I know, every application is only allowed to access its very own assigned spot, is this right? Unless permissions is given.

I'm not so experienced with Linux, but I guess it replaces OS-calls with a simple ~ character, which will be converted to /home/user/. Though it seems to be polite to write to ~/.config/and keep everything clean. Assuming one adds a folder for their own game too.

Now, I totally lack MacOS experience or even iOS, I can't comment on that.

But generally spoken, what keeps games from simply writing save-files to the actual location of the game? Are writing permissions a problem on Windows? Even if these are a problem, why aren't games simply trying this as a first try and if that fails, just go to an established location (as %appdata% or documents)?

Is this just a simplicity way of dealing with this?

 

 

Share this post


Link to post
Share on other sites
Advertisement

Ah! But is it tasteless to simply attempt to save within a game's own location? Just try, if it fails, one can go with whatever is the trendiest approach, as AppData.

Because I feel like saving to a game's own folder is the most organised and user-friendliest approach, especially comparing to the scattering of save-files that is a phenomenon on Windows.

Share this post


Link to post
Share on other sites
The thing is on any modern version of Windows you will install to Program Files anyways, so saving next to your executable WILL fail. Why bother if you're going to just go back to AppData?

If you don't install to Program Files, and you can guarantee that your players probably won't try, you can save next to your binary.

Better than failing a save and having to fall back, you should proactively detect if your binary is in a privileged path, and just go straight for AppData if so.

Share this post


Link to post
Share on other sites

In Windows the special folder has been Application Data for two decades, introduced in Windows 98. The shortcut name since 2006 has been %APPDATA%.  Please don't hard-code paths, because they absolutely will change in the future. If you cannot use %APPDATA% then use the standard save dialog to find where the user wants to store their data.

In the Mac ecosystem /Library/Application Support/ or /Library/Preferences/ (with or without an initial ~) depending on what you are saving. Again, well established since 2001, and like above, if you cannot use those special locations ask the user where they want to store the data.

 

Share this post


Link to post
Share on other sites

Windows started from DOS, and was a single-user OS. At such a system, it makes sens to keep program and its data close to each other. Basically, a user had the entire disk without much restrictions.

Unix is a multi-user system from the ground up. There is "system stuff" in /usr where all programs are stored (you don't want a 100 copies of a program, one for every user). Each user has a home directory, typically /home/user at a Linux system. At such a system, you don't want to keep data and program next to each other, as it will be a mess (imagine 100 users sharing one directory for Foo files associated with program Foo).

Also, there are security concerns, I may not want that other users know what I make at the system. With a $HOME directory for every user (~ is a little trick of bash, it's not an OS primitive), that problem is solved. I also want to rely on existence of some program X, that should not be hackable by another user, as it would enable him to get my data. Users thus don't have write access to system areas.

Note that ~/.config is actually part of the XDG standard, an attempt to structure where programs store their data.

 

Windows has shifted from the DOS idea to the multi-user idea, but it has a lot of legacy, so it's a bit more messy than you'd like.

 

I don't know about Apple machines at all, other than its current machines run a unix kernel, but the file system give to the user is not typical unix-y.

Share this post


Link to post
Share on other sites

Windows has shifted from the DOS idea to the multi-user idea, but it has a lot of legacy, so it's a bit more messy than you'd like.


Not entirely true; modern versions of Windows actually have absolutely no DOS heritage whatsoever and were designed as multi-user from the ground up too.  DOS-based Windows was killed in 2001.

Now, it's also the case that modern versions of Windows have some compatibility fixes/kludges (delete as appropriate) that behave as if they had a DOS heritage, but that shouldn't be confused with actually having a DOS heritage.

On modern Windows you save to the user's profile, with %appdata% being recommended, because:

  • Windows is a multi-user OS; saving to the program's directory may overwrite another user's saves.
  • Windows is built with robust ACL-based security and the user may not have write access to the program's directory.

Share this post


Link to post
Share on other sites

What is it about %APPDATA% that is better than C:\Users\User\Saved Games?

I'm aware that FOLDERID_SavedGames is only supported on Windows Vista and up, but we can still retreat to %APPDATA% on Windows XP. The issue I have with %APPDATA%, it is literally "hidden" for the not-so-technically-versed-player, making the whole "find the savegame-files" quite a bit more stressful.

On the other hand, C:\Users\User\Saved Games isn't used at all and probably less known than %APPDATA% for the average player. But I find the overall folder-architecture of %APPDATA% a bit more demanding for the average player.

Also, C:\Users\User\Saved Games supports multiple user.

On another note, saving the game within the game-folder should not really be a problem for multiple users either. Because usually the game will display multiple save-files on the "continue-menu", if another user just overrides your savegame, well that sounds more of a personal than a software problem.

Better than failing a save and having to fall back, you should proactively detect if your binary is in a privileged path, and just go straight for AppData if so.

Is program files the only privileged path? I think there is no OS-call to check this but just matching the file-path against a fixed term?

Share this post


Link to post
Share on other sites

I'd argue that the difference between %APPDATA% and FOLDERID_SavedGames is personal preference. Some people might want saved games to persist outside of the application data, others may not. A proper backup strategy will need to be saving both locations anyway.

As for the multiple user problem, you're just thinking about this wrong. Not only is Windows supposed to to isolate one user's data from another for privacy purposes, it's meant to reduce or prevent writes to executable directories for security reasons, and it's meant to segregate executables from configuration and from user documents. Saying that all this is for individual users to worry about is what we used to do back in the 90s and it wasn't sufficient. It took Windows a long time to learn the lessons that Unix had known for years, but let's not forget them.

Share this post


Link to post
Share on other sites

Hm, I still don't see the problem with writing savefiles to the exe location. What exact security reasons? If two users decide to share a game, that is their decision, right?

E.g. what is the problem with a high amount of writes to a executable directory?

I know a lot of people, that keep complaining about games putting files everywhere but the executable location, while quite some (non-installer) games simply put it inside the executable location.

Edited by Angelic Ice

Share this post


Link to post
Share on other sites

What is it about %APPDATA% that is better than C:\Users\User\Saved Games?


The biggest is that the location is designed to be adjustable to fit best on the system. Also %APPDATA% is one of many ways to access the specially-configured Application Data folder, it has been around for about two decades as they have tried different shortcuts.

Anyway, C:\Users\... MIGHT be that path, and on many systems it is. It also MIGHT be on another drive, perhaps D: or E:. It MIGHT be under another directory name. The "users" portion gets translated, so it MIGHT be C:\Utenti\, or C:\Usuarios\, or similar. It MIGHT be under C:\Documents and Settings\User\... or some other path. The value is adjustable and the user user MIGHT have customized it to be in a completely different location for their own reasons.

Even further, for users on a domain (think school networks) data can be stored in a "roaming profile" that moves from machine to machine automatically. The Application Data folder moves between machines automatically, but C:\Users\... does not. In roaming profiles that specific path may not exist at all.

Microsoft has been telling people to use the Application Data folder for two decades. It works with all their technologies, works with localization, works with accessibility, works with advanced features like roaming users. They built it to be used, and increasingly game developers are FINALLY starting to use it. That is where the data is supposed to go on Windows machines. Documents go in the documents folder, so if you are storing documents put them there. But application data that generally is not user adjustable goes to the Application Data folder.

Share this post


Link to post
Share on other sites

Hm, I still don't see the problem with writing savefiles to the exe location. What exact security reasons? If two users decide to share a game, that is their decision, right?

E.g. what is the problem with a high amount of writes to a executable directory?

I know a lot of people, that keep complaining about games putting files everywhere but the executable location, while quite some (non-installer) games simply put it inside the executable location.

 

  1. Who said "two users decide to share a game"? What if you just have it installed on a shared PC, and 2 users happen to run the same program without coordinating with each other? Why should user 2 be able to overwrite user 1's games? Or even play from them? Not every computer is a home PC with carefully coordinated access to all the software.
  2. Who said "high amount of writes"? Any write to an executable directory potentially changes what that executable can do. That's a security risk. More commonly this comes in the form of a virus, but it could also come in the form of a malicious user altering or replacing the executable, so that other users unwittingly run it.

Yes, the way saved games are stored on Windows is annoying. But these restrictions exist for very good reasons.

Share this post


Link to post
Share on other sites

Reply to frob:

Oh, misunderstanding and my mistake, I wrote C:\Users\User\Saved Games because I know no other shortcut for it but FOLDERID_SavedGames. And that is probably more programming related, while %APPDATA% works via search etc. too.

I totally am convinced that absolute paths are not advisable for this, simply for every reason you mentioned.

FOLDERID_SavedGames isn't secure? As far as I know, if the path does not exist (somebody deleted it), Windows creates it either way. If the user changed the configuration (to whatever drive), it should point to that as well, right?

Hm, yes, I witnessed this too, more and more application using Application data. Some still clutter my documents folder, though, haha. So I should give up on FOLDERID_SavedGames? I really wonder why nobody uses it, as it seems to be natively made for that, haha.

Reply to Kylotan:

I still do not understand the issue. If they use the same user-account, well, then they will have no benefit from either way, since it will use the same user-path in %APPDATA%.

If they use two different user-accounts, the game is probably installed on either user's paths, or am I overseeing something? So, if it is installed on user A's account, user B won't even see the game? Unless user B can, I would see no advantage. If user B can see user A's game, that is the point where could I see reason to actually not save within the executable.

Nobody said "high amounts", but "reduce" sounded like reducing it to a lower amount of writes not completely forbidding writes, haha.

Edited by Angelic Ice

Share this post


Link to post
Share on other sites

There isn't a separate copy of Program Files for each user. That's why these other data directories exist; so that the same program can have different configurations for different users. Shared data and config can go in %PROGRAMDATA%. Per-user data and config should go in %APPDATA%, unless a more specific folderID exists. And user-created documents would be in My Documents, again, unless a more specific folderID exists for that. Although given Frob's caveats about whether some of these other folders are actually as useful as folders inside Appdata, I wouldn't know what to recommend. It looks like a horrific mess to me, but still better than it used to be when programs could write wherever they like.

Share this post


Link to post
Share on other sites

This isn't formal documentation, and it relates to the difference between %APPDATA% and My Documents (the main point remains relevant), but it's a decent overview and a good read: https://blogs.msdn.microsoft.com/oldnewthing/20050701-09/?p=35133

 What’s the difference between My Documents and Application Data?

The most important difference between My Documents and Application Data is that My Documents is where users store their files, whereas Application Data is where programs store their files.

In other words, if you put something in CSIDL_MYDOCUMENTS (My Documents), you should expect the user to be renaming it, moving it, deleting it, emailing it to their friends, all the sorts of things users do with their files. Therefore, files that go there should be things that users will recognize as "their stuff". Documents they've created, music they've downloaded, that sort of thing.

On the other hand, if you put something in CSIDL_APPDATA, (Application Data), the user is less likely to be messing with it. This is where you put your program's supporting data that isn't really something you want the user messing with, but which should still be associated with the user. High score tables, program settings, customizations, spell check exceptions...

There is another directory called CSIDL_LOCAL_APPDATA (Local Settings\Application Data) which acts like CSIDL_APPDATA, except that it does not get copied if the user profile roams. (The "Local Settings" branch is not copied as part of the roaming user profile.) Think of it as a per-user-per-machine storage location. Caches and similar non-essential data should be kept here, especially if they are large. Other examples of non-roaming per-user data are your %TEMP% and Temporary Internet Files directories.

 

I guess a rule of thumb might be: "can my program break if the user messes with this file?" - if the answer is "yes" it goes in %APPDATA%.

Share this post


Link to post
Share on other sites

Hm, I still don't see the problem with writing savefiles to the exe location. What exact security reasons

If the user can write savegame files to the same directory as the EXE, then the user can write a DLL to that directory too... If there's two versions of a DLL - one in C:/Windows and one in the same directory as the EXE, the latter will be loaded, which is a common way of getting programs to execute your own custom code.
Now one user can place a trojan horse DLL in the game's directory and wait for another user to play the game. As soon as they do, they run the trojan horse code under their own account, granting it's author full control over all their private files.

That may not be an issue on many home computers, but it's an issue in general, and the security model is made for the general case.

Share this post


Link to post
Share on other sites

The others have pretty much said it all, but I'll just add one thing.

Be careful of using (or when implementing) the AppData or SavedGames folder as a fallback, if the user doesn't have the necessary rights to write to the executable directory (if the EXE is in ProgramFiles, and the user doesn't run the program as an administrator).

If the user runs the game as admin, then their save will go into the EXE folder (again, probably ProgramFiles), but if they later run it without admin rights, then you must ensure that your game still loads the correct save, otherwise it may just look in the fallback folder (AppData or SavedGames), and will not find it.

 

I only wanted to post this, because I've had this happen to me in a couple games (whose titles I can't recall right now).

Edited by __SKYe

Share this post


Link to post
Share on other sites

Ah! But is it tasteless to simply attempt to save within a game's own location? Just try, if it fails, one can go with whatever is the trendiest approach, as AppData.

Because I feel like saving to a game's own folder is the most organised and user-friendliest approach, especially comparing to the scattering of save-files that is a phenomenon on Windows.

 

It stops being user friendly if you are using multiple accounts. I feel that for games this is almost no issue but it's nice to have separate saves for each account. With the document folder on Windows this is easy to achieve. Same goes for mods, I love when games allow me to mod in the account folders, this way I can create another account profile for specific mods. On the other hand, for popular modable games there will be mod managers rather sooner then later.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement