Where should my programs be storing saved games? I had them going to the {user}/Application Data/ directory on XP. On 7, it seems to get redirected to {user}/AppData/Roaming/ . I have a directory called {user}/Saved Games/ on my computer, and I'm wondering if I'm supposed to use that.

In any case, I would be creating the subdirectory {company name}/{game name}/ within the directory I mentioned. And the {user} part comes from the user.home System property.

What about Windows Vista? I've never actually used it, but I suspect it would use the same folder as Windows 7.

I can differentiate between OS's using the os.name System property. I believe the three relevant options are: windows xp, windows vista, and windows 7 (I'm not sure about the case, but I always convert the resulting String to lowercase before checking it anyways).

Can you just use System.getProperty("user.home") or does that not work on Windows 7? It seems like they just change Application Data to AppData, so why not save it there? As long as it remains consistent per user, there's no problem.

System.getProperty("user.home") gives me C:\Users\Steven, and I just have to add \AppData\Roaming\ to get the right directory. Somehow, even if I add \Application Data\, it still windws up in \AppData\Roaming\.

I'm going to use the Saved Games directory. I assume that's what it's for, and that's where Purble Place (a game that comes with Windows) stores its saved games.

System.getProperty("user.home") gives me C:\Users\Steven, and I just have to add \AppData\Roaming\ to get the right directory. Somehow, even if I add \Application Data\, it still windws up in \AppData\Roaming\.

Isn't that the compatibility layer? I think Vista and Win7 do some magic under the hood so that older apps written with XP in mind and are hardcoded to write into /ApplicationData/ end up writing into the correct place.

Isn't that the compatibility layer? I think Vista and Win7 do some magic under the hood so that older apps written with XP in mind and are hardcoded to write into /ApplicationData/ end up writing into the correct place.

I guess so. I don't know and don't really know how to find out.

It seems rather arbitrary to change the folder from "ApplicationData" to "AppData" and then redirect "ApplicationData" to "AppData\Roaming". In fact, I think it's pretty stupid, but Microsoft didn't ask for my opinion.

In any case, I'm going to write to the "Saved Games" folder until I find out that's wrong.

I think the Roaming bit, probably defines what gets copied across on your roaming profile, using a windows network. Most of the main players are saving data in here, including some of my pre-Vista legacy applications. I also have the Saved Games Directory (not hidden unlike AppData).

Writing to the "Saved Games" folder might not work too well on non-English versions of Windows. It might be better to go with appdata or the documents folder.

I suppose you can get at the "Saved Games" folder using native code if you think it's worth it.

http://en.wikipedia.org/wiki/Special_Folders seems to indicate that non-English versions have different names for all the folders. It says something about this in the header above the table of special folders. It doesn't explicitly say that all the folders have different names, but it seems like it would.

http://en.wikipedia.org/wiki/Special_Folders seems to indicate that non-English versions have different names for all the folders. It says something about this in the header above the table of special folders. It doesn't explicitly say that all the folders have different names, but it seems like it would.

correct: never use hard-coded paths because well-known paths change from one version of the operating system to another and they are internationalized as well; moreover, on Windows Vista and 7 well-known paths can be redirected to other directories.when doing Win32 programming you should use the proper API functions to retrieve the actual paths, in Java you can use system properties such as "user.home"; you can also use environment variables hard-coded in your paths, but this wouldn't be system-portable (environment variable names are different on Linux, for instance).

The documents folder would be my choice for settings and savegames. -Not because I like that solution, but it seems to be the de-facto standard. At least every game I've ever installed seems to have thrown its stuff in there. Personally I would prefer to have savegames in a subfolder of the game such as c:\games\MyGame\savegames, so the ideal solution as far as I'm concerned is to give the user an option to choose where stuff goes.

The documents folder would be my choice for settings and savegames. -Not because I like that solution, but it seems to be the de-facto standard. At least every game I've ever installed seems to have thrown its stuff in there. Personally I would prefer to have savegames in a subfolder of the game such as c:\games\MyGame\savegames, so the ideal solution as far as I'm concerned is to give the user an option to choose where stuff goes.

At least on Mac it makes more sense a lot of the time to put save games in user/Library/Application Support/ so that the user doesn't have to see that stuff. I personally get very annoyed when games put stuff in my Documents directory (or any app), because I use that as, well, my documents directory. Folders like Work, Games, Code Projects, etc. go in there. I hate it when it becomes populated by tens of folders for things I have no desire to ever go in. 99% of the time you only want to access a save game from within the application, and because of that it makes the most sense to keep it hidden unless the user asks for it.

And if they ask for it, you should either make it easy to find (put it in an expected place) or make it revealable from within the game. I am not a fan of people using "." directories for saves, because then I can't back up save files or delete data I no longer need.

I agree it's annoying, and I too would prefer to have it more out of the way. But to me it's even more annoying to have stuff scattered across appdata/local, appdata/roaming, my home directory, my documents folder, documents/my games and god knows where else. At that point I find it more convenient to have any one location where I can find the savegames and settings or whatever else I need to back up or mess with. With appdata being hidden, subdivided and less used (by games) I feel documents is a better choice.

The documents folder isn't what I would have chosen as a dump location for games had it been my choice. But it wasn't, and for whatever reason most games seem to have appropriated the documents folder for their own use. It may be a suboptimal solution, but it seems best to go with what is currently common practice as default. -Though it would be nice if Sun would give us an easy way to get at the windows "known folders".

I'm not sure what you mean by "." directories.

But anyway, what is common practice regarding settings and savegames on Mac and Linux? And how do you get at those folders? Is user/Library/Application Support/ what you get with System.getenv("APPDATA") for instance?

It's not possible to create folders in My Documents and related folders on windows from Java. Doesn't matter that much for save games. But is annoying if you create an application where you want the user decide where to put his files. Feel like the the Carol Beer character on Little Britain.

It's not possible to create folders in My Documents and related folders on windows from Java. Doesn't matter that much for save games. But is annoying if you create an application where you want the user decide where to put his files. Feel like the the Carol Beer character on Little Britain.

...computer says no!

Strange, I've never had any problems creating folders there in Java. Then again, I'm always running my programs as an administrator. Maybe I should try running them as a guest.

Wow, I wasn't aware of that bug. But I just tested to be sure and it appears that you actually can write to My Documents, it's just that File.canWrite() returns false. So your app could just (rightly) assume it can write there and write its save file.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org