Where do you save?

Started by
17 comments, last by menyo 6 years, 10 months ago

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?

Advertisement
There's a lot of historical accident at work here.

In the Olden Times (think Windows 3.1 era) you put a game into some folder, and saves went right next to it. Easy.

Then Windows 95 happened and introduced Program Files. Apps and games were meant to install into Program Files.

Then security awareness happened and writing unfiltered binary data to Program Files without an Administrator account was forbidden.

There were a few "standard" solutions on Windows for a while, including using Documents, but over time things settled on AppData.


For a contemporary game, I'd say do the recommended thing. Put your game's saves and other "internal" data in AppData. Prompt or allow configuration for where to stash screenshots and other "external" data.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

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.

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.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

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.

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.

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.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

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?

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.

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.

This topic is closed to new replies.

Advertisement