• Announcements

    • Spaff

      These Forums are closing!   10/04/2019

      After more than a decade of serving this community well, these forums have finally run their course and it's time to close them down. That doesn't mean we want to close the doors on our community, quite the opposite!
      Our discord server grows ever busier by the day, and we encourage all Double Fine fans to meet us over there www.discord.gg/doublefine In a short time these forums will become a read only archive and will remain that way until they become needed again.
      You never know, it might happen.  There is... a prophecy. Thank you all for being part of these forums, and remember that the fun is definitely not over - so please join us on Discord! Love ya, Spaff, Tim, Info Cow, and all of Double Fine.
Sign in to follow this  
soeb

[Feedback] Save game and configuration file location

Recommended Posts

I'd just like to suggest you do not save inside the install path. It's an ugly thing to do on all operating systems, although in this case, I'm only asking from the Linux perspective (but do use %APPDATA% and AppSupport on the other two).

On Linux, you should use $XDG_DATA_HOME for saves and $XDG_CONFIG_HOME for configuration files. Even just using data would be better. Some of the past ports that were done by Edward Rudd (The Cave, Stacking, Costume Quest, Brütal Legend) use $XDG_DATA_HOME/doublefine/ as the path, so I would suggest retaining that as a company directory is already used for 4 of your games. The exact implementation of how this should work is outlined in the XDG basedir spec, and also to a degree in a similar post from me on the DF-9 forums.

As for why you should do this, besides following established standards and practices, well - using XDG paths allows one to easily transfer all data between system installation, as well as back it up without much thought.

If the concern is cross-platform Steam cloud through using autocloud, then please still reconsider using normal paths on systems. Autocloud should not be used for modern games, and one should instead rely on the API for saves.

Share this post


Link to post
Share on other sites

I too hope this will get fixed - and hopefully before the public release, to minimize impact of changing save directories. There really is no excuse to not follow the xdg-basedir spec for new applications.

As for why you should do this, besides following established standards and practices, well - using XDG paths allows one to easily transfer all data between system installation, as well as back it up without much thought.

Another reason is that this would allow to have a shared location (/opt, /usr/local, ...) for the game data on multi-user systems when the DRM-free version will be released while still having per-user save files. And if someone really *does* want the save files under the install directory, they can still create a wrapper script and adjust $XDG_DATA_HOME.

Btw, on Windows there is a standard directory for save files since Vista: FOLDERID_SavedGames

Share this post


Link to post
Share on other sites

I support this. I think it's been mentioned elsewhere, but, assuming Windows, this will cause issues if the user has Steam installed in C:\Program Files[ (x86)], has UAC enabled, and does not run Steam as an administrator.

Even if the location doesn't interfere with the writability of the program directory, another user account could play, delete, or otherwise interfere with a player's game saves.

Share this post


Link to post
Share on other sites

Welp, time to post what I've posted in the other thread:

Since it is a cross-platform application, it would be difficult to somehow make it "universally" use a user's private directory (such as Windows' "My Documents" or "My Games") for such data. It would need to do it on Windows, Linux and Mac OS, not to mention programming separately what it should do on other platforms it is being developed for.

Share this post


Link to post
Share on other sites
Welp, time to post what I've posted in the other thread:
Since it is a cross-platform application, it would be difficult to somehow make it "universally" use a user's private directory (such as Windows' "My Documents" or "My Games") for such data. It would need to do it on Windows, Linux and Mac OS, not to mention programming separately what it should do on other platforms it is being developed for.

I was going to link you here!

It's actually quite trivial to generate the output path and abstract the actual write functionality based on the OS. The game runs on Windows, OS X, and Linux, so we can assume the latter portion is already implemented.

For the former task, generating the output path, it's as simple as expanding a given environment variable:

- Windows uses %AppData% for any user-specific application data. It also offers "%UserProfile%\Game Saves" specifically for games, which was added in Vista

- OS X uses $HOME

- Linux, as mentioned earlier in this thread, uses $XDG_CONFIG_HOME, and if an environment variable isn't available, ~ can be used as shorthand for the root of the current user's home directory (So ~/doublefine/brokenage, for example)

Share this post


Link to post
Share on other sites
Since it is a cross-platform application, it would be difficult to somehow make it "universally" use a user's private directory (such as Windows' "My Documents" or "My Games") for such data. It would need to do it on Windows, Linux and Mac OS, not to mention programming separately what it should do on other platforms it is being developed for.

Such is the nature of cross-platform development. Selecting the correct per-platform save directory isn't difficult at all though, especially compared to other porting tasks.

For the former task, generating the output path, it's as simple as expanding a given environment variable:

- Windows uses %AppData% for any user-specific application data. It also offers "%UserProfile%\Game Saves" specifically for games, which was added in Vista

"%UserProfile%\Game Saves" (well, "%USERPROFILE%\Saved Games" actually) is the default for FOLDERID_SavedGames. But as that can be changed, relying on the default would be worse than not using the directory at all. The correct way is to use the SHGetKnownFolderPath() function.

- OS X uses $HOME

Again, there are OS-provided APIs that should be used, namely NSApplicationSupportDirectory. I don't really know all that much about OS X though so I'm not sure if the Application Support directory location can be changed in practice.

- Linux, as mentioned earlier in this thread, uses $XDG_CONFIG_HOME, and if an environment variable isn't available, ~ can be used as shorthand for the root of the current user's home directory (So ~/doublefine/brokenage, for example)

Actually, the XDG Base Directory Specification is quite clear on what to do when the $XDG_* variables are not defined - and they aren't defined most of the time. Also, as soeb mentioned, $XDG_DATA_HOME is a better catch-all directory than $XDG_CONFIG_HOME, which should only be used for configuration files.

As Broken Age already uses SDL2, DF could simply use SDL_GetPrefPath() to get the save directory. While this function isn't perfect, it neatly abstracts all the OS-specific goo. Specifically, using "doublefine" as the org parameter would put the Broken Age saves next to those for most other DF games - at least on Linux.

Share this post


Link to post
Share on other sites
I support this. I think it's been mentioned elsewhere, but, assuming Windows, this will cause issues if the user has Steam installed in C:\Program Files[ (x86)], has UAC enabled, and does not run Steam as an administrator.

Even if the location doesn't interfere with the writability of the program directory, another user account could play, delete, or otherwise interfere with a player's game saves.

Strangely this isn't the case. I am all of the above, and the save files seem to work fine. Very strange.

I'm baffled and amazed they're not using %APPDATA% or %UserProfile%\Game Saves on Windows, though. (THE CAVE did, as do most modern games, as they should.) It's my understanding that it goes against the fundamentals of the operating system, established a long time ago, to put save files into the Program Files/ dir -- I wonder if they had to write some sort of hack to it to work with UAC enabled??

Maybe DFOliver or DFAnna can explain the decision?

Share this post


Link to post
Share on other sites

The progression is saved in the installation folder, because of cross-platform Steam cloud save support. Since we are too short staffed to use the Steam API directly, this is unfortunately the only way to support this feature.

Share this post


Link to post
Share on other sites
The progression is saved in the installation folder, because of cross-platform Steam cloud save support. Since we are too short staffed to use the Steam API directly, this is unfortunately the only way to support this feature.

Is this something that will eventually be corrected, or are we stuck with it for the life of the game?

Share this post


Link to post
Share on other sites
The progression is saved in the installation folder, because of cross-platform Steam cloud save support. Since we are too short staffed to use the Steam API directly, this is unfortunately the only way to support this feature.

Is this something that will eventually be corrected, or are we stuck with it for the life of the game?

Never say never, but unfortunately it's not in the list of things that will change anytime soon.

Share this post


Link to post
Share on other sites
Sign in to follow this