# Is there a cross-platform special directory I can use for game save files?

I'm developing with LWJGL and Java on a Windows 7 laptop. I've successfully set up saving to the %appdata%\gamename\saves\ or long form c:\users\user\appdata\roaming\gamename\saves\ folder by using File dir = new File(System.getenv("APPDATA") + "\\gamename\\saves\\");.

I have hobbyist level experience with Linux, and zero experience with OSX. My game will be fully cross platform.

Is System.getenv("APPDATA"); cross platform? If so, where does it point to on Linux or OSX? Is there a best practices alternative that I should use?

I'm using this code on my game right now:

System.getProperty("user.home");


Simple and efficient.

It's a user dependent directory, which is perfectly fine for storing save files. I'm using it to download and store assets, though.

There is no such directory; %APPDATA% is Windows-specific. You'll have to abstract it yourself: create your own GetSaveGameDirectory function that returns an appropriate path on whatever operating system you're running on. You can typically make this determination at compile time with preprocessor checks against the appropriate macros in C (and it's ilk). I'm not entirely sure of the best way to do so in Java.

On Windows, an %APPDATA% subdirectory for your company or game is appropriate. On the Mac, ~/Library/Application Support/Your Game is common although Apple's guidelines recommend against storing "user data" there (it should go to the ~/Documents directory) -- it depends primarily on whether or not you prompt the user to select a directory).

On general *nix systems you'll probably find less standardization -- perhaps a hidden directory within ~, such as ~/.yourgame? Certainly this is the common practice for configuration files. An actual *nix user will probably need to chime in on whether or not this an appropriate game save location.

For the best results, do not hardcode the path to the directory based on the English string, but use the OS API to access the directory. This will help ensure your game runs properly on non-English version of the OS. For example, on Windows, use SHGetKnownFolderPath or an equivalent wrapper, if possible.

• Worth mentioning that new in the latest version of OS X, Apple has made the ~/Library directory invisible, so most users won't be able to find files inside there any more. So it's now doubly-important to put save files outside that hierarchy! Jan 28 '12 at 9:14
• Yes, ~/.gamename is the expected behavior (and how it's always done, see Minecraft, Warzone2100 and any other game). If you still want to have the save in another location you can create a link via that directory. On general *nix systems you'll probably find less standardization...actually, I feel the exact opposite (if we talk Linux, BSD and Unix...not sure about MacOS). Except for some awful-closed-source games which do not honor the directory structure, I always find my configuration files and game saves in ~/.name. Jan 30 '12 at 8:08
• @Bobby For Mac, dotfiles/dotfolders work fine (we still have .bash_profile, .emacs.d, .vimrc, etc.), but if you're specifically targeting mac, then please put your data in ~/Library/Application Support/Your Game like Josh suggested. This retains the whole "backup your home folder to back up all you should need" concept from *nix, but doesn't clutter up ~/ with bunches of dotfiles. While ~Library is a hidden folder now, if users really want to get at their saves, they can open Terminal. Or you can have an "export save file" button, which seems nicer. Not sure how I feel about Documents. Sep 8 '12 at 4:14

On Linux, the only standardized path would be the XDG_DATA_HOME and XDG_CONFIG_HOME directories. Use the environmental variables with those names if they exist, otherwise default to $HOME/.local/share/<appname>/ for user-data (saves, progress, player profile) and $HOME/.config/<appname>/ for configuration. Deleting the latter directory should in theory not affect user provided data other than resetting everything to default settings. You have also got XDG_CACHE_DIR ($HOME/.cache/<appname>) for non-essential/temporary files. Dumping everything in $HOME/.<appname> just clutters up the user’s home folder, and they might not appreciate that. It is a mostly deprecated practice with the new Free Desktop standardization initiative.

Windows:

• %UserProfile%\Documents\Saved Games\GAMENAME\

Linux:

• ~/Saved Games/GAMENAME/

OSX:

• ~/Documents/Saved Games/GAMENAME/

As Josh mentioned, don't hardcode paths - use the OS API to use the correct path:-)

• I'm not hardcoding paths. I'm appending "\gamename\saves\" to %appdata% in windows. I actually have a problem with storing saves in documents folders - even though its a commonly done thing. Saves are not documents, You cant/shouldnt edit them in word processor. You cant reorganize them without breaking their respective games/apps. Nothing should ever dump anything in a Documents folder. It annoys hell out of me. They clutter an otherwise well organised place to store important files and documents pertaining to my business. End rant. :-p
– Suds
Jan 28 '12 at 13:10
• Sorry to overflow -- but on windows, thats exactly what the %appdata% folder is for; storing application data. I don't have enough experience with other OSes to know the correct locations with them, but surely there's an equivalent?
– Suds
Jan 28 '12 at 13:14
• I'm not sure I like the idea to poolute myHome-Folder with yet another visible folder. I'd rather go for ~/.gamename, because that's the behavior I'd expect. Jan 28 '12 at 18:06
• On Windows it needs to go to a folder that will survive folder redirection and roaming profiles. Jan 29 '12 at 1:54

I think the best out of all places to place game data would be your game's installation folder, IE:

    %Install%/Saves/


Where %install% would be something like C:\programfiles\yourgame\ or ~/apps/yourgame/

• -1, on most platforms the game would be installed in a place the user is not allowed to write to. Jan 28 '12 at 18:07
• The game will have privileges to write to it. Jan 28 '12 at 18:16
• No, it will not. And even if you should stop using that OS, because the privileges are terribly flawed. Jan 28 '12 at 20:38
• Additional -1 because it's not robust in multi-user environments. What if two different people use the same computer and want to play the game? Really, this is a problem that has been solved in the previous century - it goes into the user's profile, end of argument. Raising objections to that, or alternative solutions, is a waste of time and energy. Jan 29 '12 at 1:49
• It's not about flaming, it's about best practice. This does not work on nearly all platforms (works on default Windows XP, not sure about Windows Vista or Windows 7, surely does not work on any Unix as long as the game isn't installed in the Home-Directoy, which it shouldn't be). It works for me, uh, that's great, but it doesn't work for the rest of the world. Jan 30 '12 at 9:07