Good Robot #29: Saves Go In the Save Place

By Shamus
on Nov 20, 2013
Filed under:
Good Robot

Players expect to be able to save their game. Which creates the question of, “Where do we store those saves?” Previously we’ve seen some surprisingly lively debates around the subject in the comments. I can’t find it now, but one person even went so far as to say that if a game doesn’t save in the /My Documents/ folder then the game is broken.

I can understand this. Microsoft created the /My Documents/ folder as a place for applications to store their crap. In an ideal world, someone wanting to back up their computer ought to be able to back up /My Documents/ and be reasonably certain they have everything. It’s supposed to be a general dumping ground for text documents, spreadsheets, game saves, configuration settings, power point presentations, email archives, web bookmarks, drawings, photographs, and whatever other data people create with their computers. It’s one location where users should be able to look and find ALL their files.

Unfortunately, /My Documents/ suffers from all the same problems that plague the Windows registry. Microsoft created “one system to rule them all”, and then made the implementation ambiguous. And it didn’t really do everything it needed to do. And it created security concerns. And then they changed how it worked from one version of Windows to the next.

For one thing, it’s not even called /My Documents/ these days. It’s /Users/. The location keeps changing. The internal structure keeps changing. The rules governing access keep changing. All of this creates problems for would-be game designers. Where do I put the user’s saves?

gr29_save2.jpg

I can dump them into the root of the current logged in user:

/Users/Bob

(For this discussion, Let’s assume the current user is “Bob” and the game we’re making is called “Foo”

Or perhaps:

/Users/Bob/My Documents

Or maybe:

/Users/Bob/AppData

Or one of these.

/Users/Bob/Saved Games/
/Users/Bob/Saved Games/Foo
/Users/Bob/Foo
/Users/Bob/AppData/Foo
/Users/Bob/My Documents/Foo
/Users/Bob/My Documents/my games/Foo

I can find examples of most of these on my computer, by the way. And this is to say nothing of non-English versions of Windows where SOME of the above will be replaced with localized values, thus multiplying the number of possible permutations. What a mess.

For the record, the game in the misspelled folder is Dead Space.
For the record, the game in the misspelled folder is Dead Space.

But maybe I shouldn’t put it in Bob’s directory. Maybe the saves ought to go someplace public so that all users can access the same saves?

/Users/Public/Public Documents/[all the permutations from above]

In my current version of Windows 7, some of the directories are hidden by default, so when the user goes searching for “batman” or “minecraft” to back up specific games, they won’t find the files they need, even if they’re lucky enough to be looking in the right place and using the correct search terms.

Even if I do the homework and figure out what Microsoft really expects me to do, and even if the docs are clear, is it really going to offer me a reliable, predictable, sensible place to put these files? Will it be backwards compatible? What if the directory doesn’t exist because the user “cleaned up” this mess? Will my program have permission to create the needed directories? The odd thing about user permissions in Windows is that they pretty much ONLY apply to the /Users/ area and a couple of system folders. I could fill all hard drives with thousands of folders and the OS would never raise an eyebrow. From my perspective, /Users/ is the most dangerous place to save data because it’s the ONLY place where some unforeseen edge-case configuration might cause the game to crash or be unable to save, thus creating maddening support problems for ME. I could save files literally anywhere else with no risk.

This creates a testing nightmare for anyone. Maybe Windows Vista Home Edition has some fussy difference that needs to be accounted for. Maybe I’d need a completely different solution for Windows XP.

Bah, Windows XP is ancient. You shouldn’t support people that can’t be bothered to upgrade.

You make it sound like I’m punishing THEM for not upgrading, but that’s no what’s going on. I’m the one being punished. XP still has a respectable market share and I’d be giving up a lot of potential sales by refusing to support those people. By cutting off XP users I’m hurting myself and rewarding Microsoft for their half-assery. (By creating additional pressure for the user to upgrade.) I’m giving up sales so I can be a shill for the idiots who created the problem in the first place. That’s messed up.

Worse, all of this extra work, worry, testing, and support, applies only to Microsoft-based systems. It’s work that doesn’t need to be done for (say) Mac or Linux. (Assuming a developer is planning on developing for those platforms.)

The path of least resistance is to just ignore all of these Microsoft shenanigans. Just create a save game folder wherever the program is currently running. This way the game will work the same way on all platforms, I’ll always have read/write permission, and we don’t have to worry about littering the user’s documents directory with abandoned files when the game is uninstalled. It’s neat, it’s clean, it’s easy, and it’s self-contained.

The diamond shape on the right side is for debugging. It shows me the position of a spawn point where a story node or robot COULD have spawned

Looking at the /Users/ directory on my computer, it looks like a lot of indies have come to the same conclusion. I have a lot of indie games installed, and precious few of them appear in /Users/. That space is overwhelmingly dominated by AAA titles, and I’m willing to bet that indies are just saving the game under the current working directory.

Maybe “current working directory” needs some explanation?

The CWD is where THIS program is running. If you base everything off the CWD, then you never need to know about or care what drive you’re on.

If the game is installed to:

C:/Games/Foo

Then that will be the CWD when the game is run. If I create a “save” folder without telling the OS specifically where to put it, then it will end up in the CWD like so:

C:/Games/Foo/save

If the user moves the game to (say)

D:/Games/Indie/Shooters/Foo

…then the game won’t suffer or get confused. In fact, the game won’t even know that the move took place. Saves will appear in:

D:/Games/Indie/Shooters/Foo/save

and everything will be fine.

So that’s what I’ve been doing. Cutting corners and cursing Microsoft. I strongly suspect that it’s no accident that the more you try to be cross-platform, the more of a pain in the ass it is to support Microsoft.

EDIT: As someone pointed out below, with my current setup if the game is installed to /Program Files/ then the user would need to run as administrator in order to save the game. That won’t do.

Screw this. I’ll just hard-code the game to save everything to

C:/butts/

That should make everyone happy.

Enjoyed this post? Please share!


is a programmer, an author, and nearly a composer. He works on this site full time. If you’d like to support him, you can do so via Patreon or PayPal.

A Hundred!A Hundred!2020202012There are more than 291 comments. But less than 293

From the Archives:

  1. Cybron says:

    I don’t think I own a single game that saves to the My Documents folder. Checking, that’s not quite true (got a couple old AAA titles in there), but the vast majority of them just save to working directory. It seems like the sanest solution to me, even if it can be a little more difficult for the end user.

    What really annoys me is games like Minecraft that save in some foreign appdata location that I have to go hunting through hidden folders for.

    • ET says:

      Yeah, I think that’s what Shamoose alluded to.
      Applications in Windows 7 onwards are supposed to use /Users/Bob Smith/appdata/ to store stuff for themselves for the Bob Smith user.
      It’s actually kind of sane, similar to Linux’ /usr/bob-smith/.myapplicationname/
      And then I guess /users/Bob Smith/My Documents/ is the default location to store Bob’s files?

      • Peter H. Coffin says:

        On POSIX systems, $HOME/.appdir shorthands to ~/.appdir no matter where the convention is; /usr/bobsmith, /home/bobsmith, whatever. (Do modern Windows support that at least? They’ve been making Serious Progress in becoming POSIX-compatible, if not necessarily compliant.)

        • Steev says:

          There is an %appdata% shortcut that is supposed to go directly to where the app data is supposed to go.

          Though I’ve never used it in code, so I don’t know if it would compile properly and work once executed.

          • mystran says:

            For code you should use SHGetFolderPath with CSIDL_APPDATA to get the folder. Same for most other system folders. I think there might have been some other way as well, but as far as I know the above works on pretty much any old windows. In fact you should probably use SHGetFolderPath to find the user profile (eg c:\users\foo) as well.

    • Zukhramm says:

      How lucky you are, I wish that was the case for me.

      I’ve said it before, but again: As long as Microsoft seminar blissfully unaware that people sometimes use multiple drives or partitions, putting things in the user folder is evil and should not be done.

      • DIN aDN says:

        … Is it rude to ask why you’ve written ‘remains’ as an anagram? Because I’m genuinely interested in knowing the answer.

      • bickerdyke says:

        Not exactly. MS is *partly* aware of that and lets you move at least some of the user folders (like “My Documents” or “Saved Games”) to other drives.

        And then, in addition, we have that idiotic software that ignore even those moveable folders and hardcode a path on the C drive!! (Hate to say it, but Shamus, I’m looking in your direction!)

        • Shamus says:

          (Hate to say it, but Shamus, I’m looking in your direction!)

          Whut?

          What “software” of mine are you using? Are you talking about the open-source projects I GAVE AWAY? That’s on you, man. If my projects are too “idiotic” for you then feel free to mess with the source yourself. Those projects were SPECIFICALLY about messing with graphics, and everything else was slapdash.

          Good grief.

          • Thearpox says:

            “Screw this. I’ll just hard-code the game to save everything to

            C:/butts/”

            This may have been a joke, but I don’t blame anyone for taking it seriously.

            • Thearpox says:

              Forgot this quote: “And then, in addition, we have that idiotic software that ignore even those moveable folders and hardcode a path on the C drive!! (Hate to say it, but Shamus, I’m looking in your direction!)”

              And now bold the “hardcore” part in my previous post.
              Sorry for double-posting.

  2. Zagzag says:

    The vast majority of games I own, in fact all of them I currently have installed (which isn’t too many as it’s not been too long since I last nuked my OS) save in the my “documents/my games” directory, or in their own directory. The main problem with the latter in my opinion is that I only tend to back up my “users” folder, so I lose saves for any of my indie games unless I remember to back them up individually.

  3. Daemian Lucifer says:

    I cant really remember when the decision was made to store anything in my documents.I hate it.I loved when back in the day you specified installation one path,and everything related to that game went there*.Why the need to spread everything everywhere on my hard drive,I have no clue.Fine,so maybe some people like storing all their saves in my documents,let them change the save directory,not force me to store everything there even if I dont want to.

    *Unless you deliberately specified another path for saves.Which is another peeve of mine:Why is there no longer an option to change the save file?Jerks!

    So Shamoose,please store everything into …/Foo,and Ill love you for it.

    • Zukhramm says:

      Actually when I specify I want to install things on D that means what I really want is for all program to fill up my C-drive anyway. I especially want to fill up my OS drive quickly if it’s a small SSD.

      • bickerdyke says:

        But that’s the fault of win and that whole “Drive” concept. On *nix, you still can have your root on a small SSD, but have SUBDIRECTORIES stored on other devices.

        • Zukhramm says:

          Well, but developers choosing to go along with it are also at fault, no one’s forcing them to.

        • eroen says:

          There may have been regressions since then, but last I used windows it also supported mounting filesystems on arbitrary folders in the tree. (Not that this as powerful as you might expect, mounting happened too late to be used for user folders. Come to think if it, that reminds me of having /usr on a separate filesystem with recent versions of ‘enterpricey’ linux distros.)

  4. Dave B. says:

    Like you, I agree with the idea of saving to My Documents, but as you pointed out, a lot (a majority?) of games don’t do that. I’d consider it far more reasonable to put saves in the CWD than somewhere like Users/Bob/Appdata.

    Of course, you could make the location user-configurable, but I’m starting to feel like that’s the litany of arm-chair designers who can’t make up their minds. It’s not always appropriate (plus it’s more work for you.)

    • Paul Spooner says:

      My suggestion, save in the LWD and put a shortcut in the appropriate My Documents folder (if you can). Heck, put one in EVERY appropriate My Documents folder if you like!

      • Winfield says:

        The problem with this is that:

        A) He still has to figure out which My Documents to save to
        B) If a user drags that shortcut to a USB drive, they only get the shortcut. Unless they’re very alert and pretty computer savvy, most users who back up their savegames and restore their computers will find their savegames gone.

        The second problem can be solved by performing a “junction,” which is the Windows way for a file or folder to exist in two places at once. However, creating a junction requires administrative capabilities, which Microsoft is doing their best to expunge as a day-to-day tool (and with good reason.)

        • Paul Spooner says:

          A) Can be handled on install, just put shortcuts everywhere, or allow the user the choose or something.
          B) Unfortunately seems be the case no matter what method is used.

          I agree it’s not the ideal situation, but as Shamus has pointed out, an ideal situation requires both a common standard and good platform support, neither of which are likely.

          • Winfield says:

            Except then everyone would, completely justifiably, be angry that the game thinks so highly of itself that it’s added itself everywhere.

            He’s much better off just saving to the game directory.

        • Rick says:

          I’ve seen users do this and not stop to wonder how so many AAA games fit on a single floppy disc. And they even still worked!

          Until you put the disc in another computer or after you’ve formatted that one… Then the magic stops.

  5. Smejki says:

    Or you can primarily use CWD save AND create a copy of it somewhere in My Documents (you gotta choose some place, there is no right answer, as you mentioned). Then you just check for consistency and use either of the saves or inform the user about conflict if there is some in Steam Cloud saves conflict-y way.

    • ET says:

      Put a soft-link from one folder to the other!
      Then you don’t even need to check for consistency between the save files, since they’re the same files.
      But honestly, the more “correct” way of doing that, would probably be to have the files located in /users/bob/foo/ since then they’d be able to copy their saves easily in Windows.
      In Linux, the file-copy utility has an option (I assume; I could be totally wrong) to follow the links and make an actual copy of the files, if you decide to back up your saves.

      But yeah, Sham-wow’s solution is probably the correct one.
      I mean, what percentage of gamers actually back up their saves and don’t know how to search their hard drive for the files?
      I assume that the people backing up their saves are at least computer literate enough to press CTRL-F. :)

      • Smejki says:

        The joke is you can never pressume people have some skills and traits unless they are a requirement for action you are talking about. I’ve seen people not knowing how to rename file, not knowing what a (logical or physical) drive is after 10yrs of using computer. And they were players. How did they manage to do so?! Mysteries.
        You can only pressume they… know alphabet, can turn on PC (either way), held a mouse or touched a screen at least once, can press buttonz, can write and read (which is not the same as properly understading written word), can eat, drink, .

      • Toastgoblin says:

        I’d probably prefer an option to specify save location if it isn’t CWD by default, since bits of program going in random files is a pain. In either case, what I would strongly recommend to Shamus is having a fairly obvious way to find out immediately what the save location is. Y’know, Game Settings > Where are my saves??? or some other straightforward option. I’ve spent far too long looking for saves and data that are in arbitrary folders with arbitrary names, and have exactly zero identifying features to let you identify them as the right files when you do see them. For that reason I’d also suggest calling the files something like “Good Robot Save 00001.sav” and putting that information in the manual too!

    • Rick says:

      Cloud saves are great, I used to use them on my Xbox. All good until you end up on a really unreliable internet connection and have to waste ages moving them all back to being local.

      Great when they work though.

  6. Blue Painted says:

    I’d say you *should* use the My Documents structure but rather than make any unnecessary assumptions about where that structure is located just ask Windows … SHGetFolderPath() … which works all the way back to Windows 2000 and still works on Windows 8.1

    And (a certain large software company please note) *DON’T* just get the value once and then try to use it forever … it’s a reasonably quick call to make and the user is likely to be in real-world space when saving/loading … and what if I started using your software weeks ago and I’ve had my HOME folder remapped in the meantime? Eh? How about that …! (end of grump :-)

    • Richard says:

      Current Working Directory is actually the worst place you could put the files in any OS from Windows XP SP2 onwards or Linux/Mac from the beginning.

      You shouldn’t use CWD for Linux or Mac either, because in most cases the user cannot write to them without sudo – this is where Windows very recently ‘caught up’.

      Just to make life more fun, in the case of Mac, it might actually be impossible for anything at all to write to the CWD.
      – One of the recommended ways to install software on a Mac is a “dmg” file, which is a disk image that gets mounted read-only on run.
      So the CWD is a virtual read-only drive…

      The right way to do it is to put the files in the user’s “Home” directory.
      However, you absolutely must not assume the path is anything in particular – not even what it was last time the software started.

      The call above (both .NET and C++ versions are available) is the way to find it on Windows, and if you’re using a cross-platform toolkit, the “find Home” is usually done for you on all supported OS.

  7. Ian says:

    “Portable” apps are good. It’s even a selling point to a certain kind of person (i.e. those who understand the concept of “folder” or “directory” (a surprisingly low percentage if my support calls are anything to go by)).

    Otherwise, if it’s Windows, and you don’t mind .NET – you can use this. The advantage is it’s backwards compatible with earlier Windows versions. The disadvantage is it’s not exactly portable to (e.g.) Linux. There is a WIN32 API equivalent, but let’s not go there :).

    • Winfield says:

      You’re aware this is a C++ project, right? Why would he shy away from a Win32 API call if he had to integrate .NET to avoid it?

      If you’re a troll, that was actually a master play. Damn.

      • Richard says:

        Or just use the C++ call that does exactly the same thing.

        Most of .NET is just a wrapper for the actual Windows API.

      • Ian says:

        I was aware of that, yes. Hence the note about portability.

        Also … it ain’t hard to write an interop wrapper for any .NET stuff – make it a library (static or dynamic) and you’ve got a platform-dependent module. Just replace with similar for other platforms – hopefully keeping the main codebase stable.

        Or do the same with SHGetFolderPath of course. Wherever your comfort zone is. But remember that using .NET instead of Win32 APIs is much more likely to be forward compatible. Case in point: SHGetFolderPath has already been deprecated.

  8. Aquarion says:

    Since Vista, there’s been a seperate “Saved Games” system folder (Folder ID is FOLDERID_SavedGames) , which is installed at the home level. On my setup I’ve got that dropboxed and stuff. on XP there’s a “My Saved Games” folder which appears to do the same thing, but I don’t think it’s a system folder.

    Putting it in My Documents isn’t ideal, and I know I was slightly surprised when my My Documents folder suddenly hit a gig because Sims 2 decided that’s where it needed everything to be, but for all AppData is the official place to store user data, I find putting anything the user is expected to back up there to be pessimal.

  9. newdarkcloud says:

    A lot of the games I own on PC just place save files in the CWD. I don’t see a problem with this, honestly. It makes things a lot easier and makes it fairly easy to find those saves.

    There’s honestly no point imo in ever using the My Documents folder. If you desperately need to backup the save, just remember to copy it into the My Documents folder or where ever else you want it to be.

    • Rick says:

      CWD is fine until you end up hunting through lots of “//save” type paths where you don’t really care about the publishers, you just want to know where GameX is located. Sure you can follow the shortcut or search, but that makes it cumbersome for large libraries of games.

  10. Just Passing Through says:

    I wouldn’t mind My Documents if so many companies didn’t insist on hiding the game folders in another folder named after them. Two or three years from now I am not going to remember that GenericGames published Foo, nor will I care.

    • ET says:

      It’s also fairly obnoxious in an industry with a long history of Company X going bankrupt, or being bought out, or changing their name, or merging with company Y and now both names get changed, or…

  11. Wulfgar says:

    Just keep them in game folder. I hate when games are creating folders in God-knows-where. Its especially frustrating when i want game to be on disk other than C:
    Europa Universalis 4 made me sad when i discovered that it took more than 20gb for save games on my small c: drive

    • Raygereio says:

      Europa Universalis 4 made me sad when i discovered that it took more than 20gb for save games on my small c: drive

      Wait. 20 gigs? That’s insane. How many indvidual save games were that?

      • Cerapa says:

        Quite a lot.

        I have the exact same problem. I tend to create a new save whenever I save(which is quite often), and I’ve had to clean out my saves folder quite often because C is running out of space. I once ran into a problem where the game would crash if I tried to save, and while looking for a solution noticed that my C drive was completely filled up.

        • Sleeping Dragon says:

          See also the first Witcher, there is actually a playemade utility for tracking down and cleaning up all the saves.

          On top of that a lot of people use SSD drives as their system drives nowadays because of the speed advantage, we can discuss if it’s really an issue but still, some games keep overwriting stuff pretty frequently and can have pretty hefty saves. Like Minecraft, which I was able to free from the appdata grasp and have it stay on my gaming drive after a little googling and file editing.

    • ET says:

      I’m lucky enough to not have played many games where the save games were the large files.
      Usually, it’s the pre-rendered cutscenes* which end up doubling the size a game takes up on my computer. :|

      * The which would have looked better with the in-game engine, thank you very much!

    • Richard says:

      You are aware that you can move My Documents (and User Home) anywhere you like?

      The trouble with doing that is of course the programs which don’t actually use the real Windows API to determine the location, and either hard-code or read a random Registry key that they guessed contained it.

      That’s why I consider programs that don’t use the actual Windows call to be fundamentally broken.

      • Kelmomas says:

        I have a small 40GB SSD, so I just symlink any bulky user folder into the program’s own folder on D: (Link Shell Extension makes that a matter of a couple of clicks, too). Works well, but not exactly an average user solution.

    • Kelmomas says:

      I’m assuming you’ve since figured out how to move those saves, but in case you haven’t: Paradox game saves are plaintext, which compresses remarkably well.

      You can cut down to around 40% their original size simply by enabling Windows compression on the save folder. (In my experience this doesn’t even slow down loading/saving to any meaningful degree.) If you need to save *more* room, compress all the older saves with 7-Zip to bring them down to 10% or so.

  12. At some point I got frustrated with having to work out where games got installed, so now I just install everything into a “Programs” folder in My Documents. Under the game’s name too, none of this “sort by publisher” nonsense.

    That way, as long as the developer saves games locally, I don’t have to look very far. Some still put their saves somewhere else, but at least the ones I own put it somewhere in Users and I don’t have to go trawling through the whole of the main drive.

    • ET says:

      I started deleting the developer’s name years ago, although it’s under /Program Files/
      The worst was…the late 90s? Early aughts?
      Whenever it was, about half the games I played flipped a coin to decide if it was the developer or the publisher’s name.
      The other half flipped a coin to see if it was ./Developer/Publisher/ or /Publisher/Developer/
      …yeah. :|

  13. Factoid says:

    In fairness to microsoft, they’ve tried to fix this problem in Windows 7 and 8. It’s theoretically supposed to be abstracted away from both the users and the developers to get around the security problems. If you point to \users\bob\my games\foo or \users\bob\my documents\ it should just handle the rest in terms of security and folder structures.

    I think \users\username\my games\ is the prefered location, but it really doesn’t matter most of the time.

    And I don’t get why a user would be cursing a designer for NOT putting a save in My Documents. I always look first at the game directory for a saves folder. If one does not exist, I just go ask google, because as you point out it can exist in one of any hundred places with in the user directory tree.

    • Nick-B says:

      You are partially correct in that the “standard” should be “C:\Users\Bob\Documents\My Games”. The My Games sub directory was created to separate out the gaming related files from the rest of the “other categories” that “my documents” could hold.

      As for the change in path names since XP, Shamus, it can all be explained fairly well:
      See, after Windows XP, they realized that spaces in paths could still be a potential problem (for some programs being made badly), so they simplified it all into a path that had no spaces in it. If you look at my earlier path above “C:\Users\Bob\Documents\My Games”, you notice that up until the root of documents, there isn’t a single space. Heck, even though in Windows Explorer it is labeled “My Documents” it is really called “Documents”.

      To help legacy programs that still hard code their save path for files to “C:\Documents and Settings\Bob”, in Windows 7 (and I think maybe Vista?) Microsoft implemented a… kind of shortcut. I think they called it hard link? If you work really hard at it, you can get explorer to show the folder “Documents and Settings” in the root of the C drive, but it doesn’t actually exist. It’s just a link to the users folder, which replaced it. Same with Documents and My Documents, there are two copies, one of which is a link to the other.

      So, really, not much has changed, other than the names of folders, but Microsoft has still left in legacy support for older styles of documents-path hard-coding for bad programs. But, really, shouldn’t you just be calling Windows and asking for the current user and saving in %CURRENT_USER%\documents ?

      Hell, save the old fashioned way, and newer windows versions will support it by default. The LAST thing we should be doing is “Well, NOBODY follows the standard, so I sure as hell won’t.” That only encourages everyone else to not follow it as well. Please, for a gamer, use Documents for save games.

      • Bryan says:

        > shouldn’t you just be calling Windows and asking for the current user and saving in %CURRENT_USER%\documents ?

        This is kinda funny after what you said about following the standard.

        Because, see, that’s not the standard either. Because some people’s documents directory is not in \users\username; see below. You should call SHGetFolderPath(hwndOwner=NULL, nFolder=CSIDL_PERSONAL, hToken=NULL, dwFlags=SHGFP_TYPE_CURRENT) and append whatever you need to append, to that, if you want to work all the way back to XP.

        And yes, the flags are important; see http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181%28v=vs.85%29.aspx for why. Users can change where certain special folders go; SHGFP_TYPE_CURRENT tells the API to return the current value, not the default.

        Of course, this isn’t anywhere near portable. In Linux, what tends to be common is picking the game name, and doing a (python-style) os.path.join(getenv(“HOME”), “.” + gamename, “saves”). I’ve also seen recent (Unity-engine) games doing os.path.join(getenv(“HOME”), “.config”, “unity3d”, vendorname, gamename, “saves”), but this has a bunch of the same issues as random subfolders of CSIDL_PERSONAL on windows. No idea about Macs.

        (But actually… crap. If XDG_CONFIG_HOME is set, then use it instead of (getenv(“HOME”), “.config”), in order to follow the freedesktop API. But I’d skip that entirely, and do XDG_DATA_HOME instead, now that I read the actual freedesktop page… looks like unity does it wrong. Fun.)

        • Nick-B says:

          Yeah, after posting it, I’d looked farther down and seen posts about the SHGetFolderPath function. Here, I thought using the keywords was standard, so I just referred to that. If I actually got to program for Windows, I would certainly look into and find the windows call for retrieving the folder path for the user’s document location as you stated.

          Hopefully most of whatever else I said stands though. And yeah, I don’t even want to think about Linux.

  14. Tychoxi says:

    Once again, an article I agree fully on! There should have been a Videogame Council back in, like, 1999 where they all agreed a standard savegames location!

    For what it’s worth, I totally agree that the best course of action for your project is creating a “saves” directory wherever the game’s installed/running from. I especially like it in “small” games, where you can just copy the whole directory and make it portable along your savegames. Having everything related to the game in one single place is useful for ease of use. The only problem I see with this is that you’d have to explain users NOT to install the game in certain directories that are Windows protected?

    As you and others, I consider “My Documents” is a nice concept but it can be a hassle. This is especially annoying too:

    /Users/Bob/Saved Games/
    /Users/Bob/Saved Games/Foo
    /Users/Bob/Foo
    /Users/Bob/AppData/Foo
    /Users/Bob/My Documents/Foo
    /Users/Bob/My Documents/my games/Foo

    • Nick-B says:

      Here’s my opinion:
      /Users/Bob/Saved Games/
      No. Never save files to the root of a folder shared with others. That will only cause problems when every program saves their save file as SAVE01.SAV

      /Users/Bob/Saved Games/Foo
      No. Not even MS seems to care about supporting Saved Games as a folder. Checking, only 2 AAA and 2 indies use it currently (out of hundreds installed)

      /Users/Bob/Foo
      No. Do not sully the root of my user directory with game folders.

      /Users/Bob/AppData/Foo
      No. Appdata are for Apps, not games.

      /Users/Bob/My Documents/Foo
      No. We’re getting closer. This is where things used to be, but since you can have a “my music” and “my pictures” folders, the root of this isn’t the place either

      /Users/Bob/My Documents/my games/Foo
      Yes. Personally, I wish this was labeled “my gamesaves” or something, as this implies it’s full of actual games, but I’ll take what I can get. Here we can be sure that only game-related files will be placed, and not crowd out other folders that have other purposes. (I’m looking for music, why do I have to scroll past game company save folders to find the MUSIC folder?)

      • Canthros says:

        Out of curiosity: what makes a game not an app? “Application” is just a synonym for “program” in my world.

        • Richard says:

          AppData is intended for cache (Local), settings (Roaming) and other ‘hidden’ files that are probably specific to the user or the user/machine pairing but shouldn’t be exposed to the user for whatever reason.
          (Maybe they’ll break something horribly if they edit the file.)

          It’s also a very good place for user-installed “mods”, because each user can put the mods they use in there without also modding their kids games – perhaps they don’t want to use the “MoreSplatter” mod.

          At work we’ve now started using that for the “.ini” files that contain the program settings, in order to avoid the Registry and make the config files portable across the different supported OS platforms.

          Also, technically you are supposed to use a GUID as the folder name for things in AppData to prevent name collisions. You are also supposed to remove it when uninstalled!

    • James Schend says:

      Vista added a standard location, ages ago. (Ok, not in 1999, but.) The problem is game devs still aren’t using it.

  15. bickerdyke says:

    For that purpose, screw portability and ask the operating system! That’s what it is for!

    For linux, that means assuming ~ as base and go on with ~/.GoodRobot as I don’t know of another place where you’re supposed to write your AppData.

    For Win, as someone already mentioned, use SHGetFolder to find out where the USER wants to have his saved games. And you can even find that out without bugging the user. If he moved his saved Games Folder, the OS would know that.

    AppData would be possible, but second choice as you already figured out, backing the Documents folder up (Whatever it is called) should be enough. AppDate is a place for stuff that would be nice to be backed up, but the user shouldn’t see, and can’t simply be copied to another machine by putting it on a USB stick.

    To backup a Linux System you simply backup /etc, /home, and /var. everything else can be rebuild by the installer and packet management. That’s so convinient and makes Linux backups fit on a DVD.

    Dirty tricks like you suggested (current directory? are you effing SERIOUS??! that could be anyware.) force me to backup the complete Harddisk, including all the large ressource files that I don’t need to backup as they are on the game CD in my shelf. Or can be downloaded again from steam.

    • Chris says:

      I agree completely. Speaking as a network admin, saving to CWD is madness. Sure, if the user has administrative privileges it’ll work, but it will break for any and all limited users. Shamus’s notion that file security only applies to the Users folder is flatly wrong.

      • Winfield says:

        I suspect he’s simplifying for the technically mixed audience here. There were some shortcuts in his explanations of the Windows side too (I think – I haven’t Windowsed seriously since 2008 and I’m rusty) and he’s got a lot of readers who don’t program but like to follow along.

    • Neko says:

      For Linux, making a dot-dir in the user’s home directory is still acceptable more or less but it does introduce a lot of unwanted clutter. Happily, there is a FreeDesktop.org standard that has existed for a while that addresses this, and defines a bunch of environment variables you can check to get a suitable location for files of various types.

      In Shamus’s case, he might want to make his directory as $XDG_DATA_DIR/GoodRobot/, where $XDG_DATA_DIR defaults to $HOME/.local/share/ if not set. Config files generally end up in ~/.config, cached data in ~/.cache, and so on – but you should check the environment variable rather than hard-coding their names.

      I think Microsoft sets an APPDATA environment variable, but I’m not certain how portable across versions it is.

      • James says:

        Yes, this. These things are documented, even on Windows. Don’t store your save games in My Documents, that folder is for my documents. All applications, including games, should be saving/writing to %APPDATA%. For generic non-user-specific application data there is C:\ProgramData\ in newer versions of Windows. There are system calls for getting these directories.

        On GNU/Linux, follow the FreeDesktop standard. I can always spot a crappy Windows developer porting to GNU/Linux by the visible directory sitting in the root of my home directory. I’m looking at you Race The Sun.

        • James Schend says:

          That’s not true. Windows has a named folder specifically for save games, and it defaults to Documents/My Games (in English/US at least).

          Of course the entire point of being a named folder is that the user can rename or move it where ever they like, so it doesn’t have to be in Documents if the user doesn’t want it there.

  16. swenson says:

    Wait. Are you telling me that there are people in the world who want their game saves in My Documents? Why would you ever want that? It’s so messy! What do I care where my saves are? I don’t deal with them. That’s the game’s business. I frankly prefer for them to be in C:\Program Files\Good Robot\saves: easy to find if I need them, out of sight otherwise. Why would I want them somewhere else?

    I mean, My Documents is for documents–spreadsheets, text documents, presentations, books, etc. A save file is not a document.

    • James Schend says:

      There’s a Windows “named folder” for game saves. If you don’t want it in Documents, you can move it to where ever you want. The whole point of using “named folders” is so the user or system administrator can move them to whatever folder/disk/network they want and all their software still works.

      Unfortunately, since most game devs are … let’s be generous and say “not very good at building software”, 90% of them won’t respect your choice.

      • swenson says:

        See, now if more people used that, I would be a lot more okay with it. I just am really against save files being anywhere remotely where I will see them on a daily basis. It would be exceptionally rare that I actually need to do anything directly with a save file, I almost always open it through the game itself, so I have no need or desire to have them clutter up the things that I do use!

      • Steve C says:

        I’m never going to move saved games and not the game. If I decide to back up my saved games I will only want to back up those saves, not all of them. Named folders causes everything to fail on move, not everything to work.

        If a program is self contained in one folder and never touches named folders, system folders or any other folder on the machine then I can easily copy/paste that folder to any other machine and it will work.

    • Anorak says:

      Unfortunately that falls apart on a multi user system.

      Program Files should not holder user data, nor should /usr/local/

      If several people use the computer to play the game, with their own OS login, then they’d see each other’s saves unless you implemented a User Profile system in the game itself.

      And why do that, when you could let the OS do it for you?

    • bickerdyke says:

      That’s a bit naive. If you “don’t deal” with save games during a backup, they’ll be lost at the next OS reinstall.

      • Alexander The 1st says:

        Finish all the games that currently run on your computer, then let them get lost and start again on the next OS reinstall.

        If the game is good enough, you shouldn’t have an issue with playing through it again, and if the game isn’t good enough for another run…then just don’t play it.

    • I like it when mmos save things to My Documents, because it makes it easy to find screencaps for my blog and the files aren’t very big (in my experience anyway). Single-player games, I prefer elsewhere, because I backup My Documents much more frequently than I do game saves and don’t want the bloat.

  17. Isaac says:

    The problem with saving in the current directory, particularly if it’s in Program Files, is that ever since Vista the User Account Control restricts what can write to Program Files. You can’t write to the current working directory because to do so you’ll at least need to run as Administrator and possibly modify the permissions further. This is one of the big compatibility issues when running software developed for XP and earlier on newer versions of Windows. There’s a built-in redirect for 32-bit apps in certain circumstances.

    Personally, I’m fond of the common Linux convention of /home /usr /bin /var and so on. It’s not perfect, but everyone follows the conventions a lot more closely than in Windows-land and it’s really easy to figure out what to backup.

    • MrPyro says:

      While UAC is new to Vista, the idea that users do not always have access to folders under Program Files (or the main Windows folder, or any number of other folders outside the Documents folders) has been in place since the NT days. It’s actually a security feature, so that standard (non-administrative users) can’t make changes to the system that will affect other users; important when you actually want a security model worth a damn.

      The issue with Shamus’s setup here is that on a computer with multiple login accounts (such as a house with children who have their own login, which presumably won’t have admin rights), the limited accounts will not be able to save their games.

      Shamus could have the installer create the saves folder and specifically modify the privileges to be universally write-able; then all you need to worry about is the users over-writing each other’s save games.

    • Gaz says:

      I was just going to say this – the method Shamus decided to use will fail if the programme is installed in program files (the standard for steam :)) and not executed in Admin mode.

  18. HeroOfHyla says:

    I hate hate hate when games save in My Documents because I have very limited space on my c: drive, and I install all my games on my e: drive. If a game doesn’t let me choose where I’m going to install it, I just don’t install it.

    Ideally, all games would just come in zipped folders that I could extract anywhere and not deal with install wizards.

    • Hitchmeister says:

      You can redirect “My Documents” to exist on a drive other than C:. I’m not saying it’s simple. Microsoft goes out of their way to make sure no non-default configuration is simple, but it can be done.

      • James Schend says:

        Right-click Documents, click “Location” tab, type in/find a new path, hit Ok.

        How much simpler could it be?!

        • Doesn’t always work like that.
          I did this on my computer earlier last year – but it didn’t redirect entirely.
          So I spent a few hours messing around with the system variables, then made a mistake and had to restore to a previous point.
          I then redirected in the same way as you suggested and it appeared to have worked correctly.
          But then the next time I logged in, all the folders had duplicated themselves, the desktop had disappeared and files were being written to both drives.
          Another system restore.
          Finally, I just changed the environment variables around.
          Tada!
          How much simpler could it be?!

  19. Just create a save game folder wherever the program is currently running. – NO! This is the worst possible solution, and here’s why: CWD is not the folder where the game is installed!

    This is a surprisingly common misconception, but CWD really has nothing at all to do with where the files for the program are. It’s just common for Windows to set CWD to that, but 3rd party launchers or user himself may run it from anywhere. You cannot rely on CWD alone. At the very least, you must perform a check that CWD contains the game’s executable or some other file that unique identifies that this is the right folder.

    That said, using CWD is doubly bad, because the user may not have write access to that folder. Not everyone will be admin. This is why e.g. Google Chrome installs itself into %APPDATA% instead of %PROGRAMFILES%. You cannot rely on the user having write access to anywhere but their own %USERPROFILE% subfolders.

    As for localization, you don’t need to care. Use the %VARS% and let Windows expand them as needed.

    • Shamus says:

      If CWD isn’t the game folder, then the game won’t run at all. If some 3rd party launcher tries to launch the game without switching to the game dir, then the game has NO WAY of knowing where to look for the textures, sounds, etc.

      Take the exe out of any game directory and try to run it someplace else. It won’t work.

      While you are correct that a game wouldn’t run under the given scenario, it’s clearly an incorrect way to launch programs. (At least on Windows.) I imagine most games would fail to run under these conditions.

      • ScrubNinja says:

        You’re conflating two different ideas. Current working directory is not the same as the location of the executable.

        Think of it in DOS terms. I might run these two commands:
        CD \games
        mygame\start.exe

        CWD is \games, but the executable is in \games\mygame. The executable should not be paying attention to CWD. It should look for its resources relative to its own location on disk. That’s the only thing that makes sense.

        • Shamus says:

          No, I understand the distinction. What I’m saying is that your first example is an improper way to launch a modern windows app and I would never expect it to work. As a test, I just tried to launch Crusader Kings 2 this way and it crashed on startup. I expect you can do this with any game that needs data files and you’ll get the same result. If CWD isn’t set to the exe dir at startup then the application has no way of knowing where to look for its files.

          • James Schend says:

            It’s one of those distinctions that’s *technically* correct but practically not much use.

            Yes, technically, the CMD isn’t the same as the program’s directory. Even I, Mr. Super Fussy About File Locations, don’t think this is a real issue to solve.

            Practically, you plop a shortcut somewhere (in the Start menu/screen, Steam, Desktop, whatever) and that’s the only supported way to launch the app anyway. If the user does something else and the app doesn’t work, that’s on them.

            • Paul Spooner says:

              Perhaps I don’t understand what you’re talking about. You or “Tino Didriksen” or “ScrubNinja”. It sounds like you are objecting on some esoteric grounds which have no bearing with how “normal people” use software. The way I read it, your terminological quibbles are the only thing here that is “practically not much use.”

              For all practical purposes, anyone who knows the distinction between the CWD and executable file path also knows how to solve problems arising from such a distinction.

              The main thing that makes me think that all three of you are more interested in lexical quibbles and OS arcana than solving problems is that not one of you has offered an alternate term. “You say CWD, but what you really mean is File path” could at least be interpreted as helpful.

              It appears you are basically saying “The normal way of thinking about this which works for every-day people is improper.” Plus all three of you basically ended your suggestions with the equivalent of “If normal users can’t figure this out, tough on them.”

              All three of you have said (with various phrasing) “There is only one correct way to do this… my way!” Therefore, on behalf of everyone here who tries (very hard at times) to keep politics and religion (which is apparently how you view these topics) out of the discussions:

              We are not the least interested in a holy war. If that is what you have to offer, please take it elsewhere.

          • …improper way to launch a modern windows app and I would never expect it to work.” – I would, especially for a cross-platform app since the problem must be solved for the other platforms anyway. It’s only Windows that defaults to setting CWD to where the executable is – other platforms will set CWD to anywhere.

            I highly recommend figuring out where the current executable is (can usually inspect argv[0] for this) and search for data files relative to that location – use CWD only as a last resort.

            Unfortunately, without a library to abstract out that detail, finding the current executable location in a cross-platform manner is stupidly complex to have working in 100% of cases. Windows has a simple enough function to call, but on Linux you need to inspect /proc and/or argv[0], and I have no idea about OS X … I let Qt handle it for me.

            • Peter H. Coffin says:

              Windows has a function call, and linux, well… the shell and perl both manage to figure it out reliably, and it’s always available as positional parameter 0 ($0).

              [18:22:45] $ cat ~/bin/test.sh
              #!/bin/sh

              echo “Positional Parm 0: $0”;
              echo “dirname parm 0: $(dirname $0)”;
              echo “Current Working Dir: $PWD”;
              hellsop /home/hellsop/src
              [18:26:23] $ echo $PATH
              /home/hellsop/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.
              hellsop /home/hellsop/src
              [18:26:29] $ test.sh
              Positional Parm 0: /home/hellsop/bin/test.sh
              dirname parm 0: /home/hellsop/bin
              Current Working Dir: /home/hellsop/src

              And there’s often sufficient reason for starting applications by shell scripts anyway, that it could be thrust into an environmental variable and that way become available to the application.

              • Bryan says:

                Note that unity tries to readlink(“/proc/self/exe”) to figure out this location. Which fails hilariously when /proc/self/exe isn’t actually the executable, because I launched it by manually specifying a different dynamic linker (so the exe symlink is the linker, not the program executable), because my main libc is too old to run unity-built binaries, but the libc that I installed in /opt somewhere is a lot newer. (Because unity builds against a too-old libc, and embeds the version check in the code.)

                It’s just not possible to run a different-version libc and dynamic linker, so you have to either /opt/glibc-2.15/lib/ld-linux.so.2 /path/to/32bit/game/executable, or edit /path/to/32bit/game/executable so that its PT_INTERP section points at /opt/glibc-2.15/lib/ld-linux.so.2 instead of the unity-provided /lib/ld-linux.so.2.

                (Granted, the latter *is* the standard SysV ABI location for the linker. So unity is doing the right thing there. It’s just that that linker won’t work with unity games on my system because it’s too old…)

                ANYWAY.

                A shorter version of this post: You can also sometimes look at where /proc/self/exe points, on Linux, if you need to know where the binary is.

                But the binary is likely in /usr/bin or /usr/local/bin, which users don’t have write access to, so using this to find the savegame location is … yeah, not a particularly good idea.

          • kdansky says:

            That’s not how CWD works. CWD is a global per-process variable, which makes it risky at the very least (any library that you use can change it without your permission). What you want to do is find your executable path with GetModuleFileName(), put that string into a CPath-container and figure out your local paths relative from there. Then you’re always relying on the exe itself, and not on any links or user folders.

            Savegames belong in a subfolder around here, which is the documents-folder.
            ::SHGetFolderPath(nullptr,CSIDL_PERSONAL,nullptr,SHGFP_TYPE_CURRENT,filepath.GetBuffer(_MAX_PATH));

            Arguably you can put them into the common folder, but then why would two users want shared save-games? That’s pretty much not the point of it.

            And for the love of all that is holy don’t write to the application’s folder. Generally people install stuff in their %PROGRAM_FILES%-folder, which doesn’t have write permission without admin access for anyone not using an XP (and XP is on the way out).

            • Richard says:

              I actually deliberately use CWD to locate necessary data like modules and plugins, because I can set that to a different location than the executable during debugging.

              The executable gets saved in %project_build__dir%, but gets run in %project_data_distribution_dir% during development so I can easily control the distribution while working on it.

              Although now I come to think of it, that’s actually a security risk and I shouldn’t do it.

              I probably won’t change though.

              • Simon Buchan says:

                You could just pass it as a parameter or environment variable, every sane debugger supports customizing them. Or, you know, just hard code it in your debug builds if you’re super lazy.

    • James Schend says:

      Ugggh there’s so much bad advice floating out there it’s no wonder so many programs get this wrong.

      Don’t use %% vars to get the paths. They’re woefully incomplete and basically only exist for compatibility with DOS scripts from 1994. Use the SHGetKnownFolderPath() API call, it’s the one and *only* correct and complete way to retrieve these paths.

      • You’re right, SHGetKnownFolderPath() is the only correct way for code to do it, but that requires at minimum Vista. For WinXP support, it’s SHGetFolderPath().

        The reason I didn’t think about %VARS% is what I use them very often – plopping %APPDATA% in the file explorer address bar is still the fastest way to navigate to your AppData folder.

        • For per user settings (or saves) that is correct, SHGetFolderPath() on Windows 5.x and SHGetKnownFolderPath() on Windows 6.x

          For SHGetFolderPath() use CSIDL_APPDATA
          and for SHGetKnownFolderPath() use FOLDERID_RoamingAppData

          And if you want to be able to install the game without requiring elevated privileges, but instead do per user installs then.

          for SHGetFolderPath() use CSIDL_LOCAL_APPDATA and make sure to create a sub folder called “Programs” and create the application folder in that, this is needed as the Programs folder do not really exist pre-Vista.

          and for SHGetKnownFolderPath() use FOLDERID_UserProgramFiles

          One of my own software have been doing the above things for years, and it is also more or less a recommended practice by MicroSoft.

          Installing stuff to the “Program Files” folder only makes sense if you are an admin and you are installing something for multiple users and you wish to control the updating of it.

          And if you wish to have shared save games and make them “public” then,
          CSIDL_COMMON_APPDATA and FOLDERID_ProgramData are the ones you should use.

          My Documents (retrieved using CSIDL_PERSONAL and FOLDERID_Documents ) should only be used for things like “Save As…” dialogs, where the user explicitly saves, defaulting the Save As location to the My Documents folder is a nice thing to do.

          So the tools to do it right is right there, just not that obvious for most folks sadly (took me a few years to learn my mistakes and do it the “right” way).
          The OS will with all the stuff mentioned above make sure it points to the correct locations, and allow the user (or admin) to move/reassign folders as they see fit.

    • X2Eliah says:

      STOP INSTALLING GAMES IN PROGRAM FILES.

      Forgodssakes. Stop suggesting it as the default, stop assuming it’s the only place games go, stop treating it as the preferred destination. STOP.

      • ET says:

        I can understand your frustration, but where else would the installer know to set as a default?
        I assume there’s an OS function call, which returns either ../program files/ or ../program files (x86)/ based on what type of executable you’ve compiled.
        The OS wouldn’t know by default, so I assume it’s something like windowsPleaseFindDefaultX86Directory() and windowsPleaseFindDefaultX86-64Directory().

        • Richard says:

          Yes, there are both WinAPI calls and Environment Variables that define the location of the ProgramFiles folder.

          The Environment Variable is “not recommended for new designs”, but is still there

          – Also, ProgramFiles doesn’t have to be in C:\, or even a local drive, it could be anywhere and (in theory) have any name.

          Not something you would want to change post OS install though, given how many programs (especially uninstallers) put hard-coded paths into the Registry during installation or first run.

        • Daemian Lucifer says:

          Ive seen a handful of games that specifically look for “Games” and installs there,even if “Games” is on a different drive.That always pleasantly surprises me,because its so rare.

      • Cuthalion says:

        It seems odd to me that Program Files is, in fact, a bad place in which to put Programs and their Files.

  20. James Schend says:

    There’s an API function, SHGetKnownFolderPath(), to find “Named Folders” (that means folders programs are allowed to save files in, such as: Documents, Pictures, etc.) The list of “Named Folders” is here: http://msdn.microsoft.com/en-us/library/dd378457.aspx Low and behold, there’s already one for saved games: FOLDERID_SavedGames

    As a Windows developer, you *must* use SHGetKnownFolderPath() (or something else that calls it) to find where to save your files. If you do anything else, your program is buggy and is not guaranteed to work in future versions of Windows.

    Saving in the CWD is ludicrous because it’s read-only in the most common case (user running program while UAC is engaged.) You really want your *video game* to require elevation to save a little file? That’s crazytalk.

    “But what if the gamer doesn’t want the saved games in their My Documents folder?” Then they should moves the “Named Folder” to where they do want it. That’s exactly *why* you use an API call to retrieve it instead of putting the folder name in a constant somewhere. There’s no guarantee My Documents for your user is in the same path it is for you. (In fact, it’s practically guaranteed it’s *not*, especially if the user speaks a different language than you.)

    There is literally no other correct way to do it other than the one Microsoft provided. If you hate Microsoft so much that you’re willing to sabotage your application to spite their rules, you’re just making all of your users (who now have to deal with your buggy program) suffer.

    (And BTW, saying “well other games do X” doesn’t convince me, since 90% of games are buggy in this instance. Popular != right. Hell, even tons of non-game software gets this wrong– Java being the hugest pain in my ass at the moment.

    • James Schend says:

      Oh and BTW, while I’m lecturing, if you do decide to user AppData for game saves (which IMO is acceptable if you don’t expect users to want to move save files around), please learn the difference between Local AppData and Roaming AppData. Firefox got that wrong for *years*, making their browser useless for any network with roaming profiles.

      For a save file, you’d want to use Roaming (the file should move with the user.) If you store any kind of cache or files that can be regenerated, they should go in Local (the file stays on the computer and does not roam with the user.)

    • Shamus says:

      “Saving in the CWD is ludicrous because it’s read-only in the most common case (user running program while UAC is engaged.)”

      I did not know this. Interestingly, all of my testers must run as admin, since none of them have reported trouble with saves.

      Also, this is pretty enraging. The entire program is 100% free of OS-specific calls. I can load images, get fonts, talk to the graphics hardware, and process user input without having to use a single Microsoft-specific call.

      And now when it’s time to do something dead simple I have to break all of that and clutter up the code with stupid conditional compile-time clutter. Boo.

      • James Schend says:

        There’s two possibilities:

        1) Your testers are all running as Admin (in which case, you badly need to test the default Windows configuration for each version of Windows you support)

        or 2) Depending on how you packaged your app, Windows might be “saving your ass” and doing a virtual direct redirect to a virtual folder for your saves.

        Number 2 takes a bit of explanation: for applications that show absolutely no sign that they’re aware of any Windows Vista features (including UAC), Windows will silently redirect attempts to write to “Program Files” to a fake “Program Files” folder in the user’s AppData folder. This is one of those occasions where Windows “fixes” a common application bug with a bit of code in the OS.

        But it’s always, *always*, been a bug for an non-installer application to write files to the “Program Files” folder. It’s a popular and commonly-seen bug, but it’s still a bug. Non-administrative users aren’t brand new in Windows Vista, they’ve always been around and your program would simply be broken in XP or 2000 because those OSes don’t do the virtual folder redirect to save you from your own bug.

        • sheer_falacy says:

          I’m willing to bet it’s 2) in the case of his game. I’ve certainly run into that before with a number of games. It’s annoying to look up that path when I want to transfer the saves. I bet if a number of those people tried to find their saves they’d have a hard time because of it.

          You certainly shouldn’t expect to be able to write to the program install path, because that’s not really secure.

          So just write to Documents/GoodRobot, or Documents/Saved Games/Goodrobot, or something along those lines. Tons of games save to Documents/ or Documents/. And, as people have said, don’t hardcode the path to it – use the windows API, or at a bare minimum the environment variable.

        • Alan says:

          I’m guessing a third possibility:

          3) Shamus is handing around zips of the program, and his testers just unzip it and run it in place.

          That’s my guess. It certainly works, and it makes a lot of sense during testing. But it’s decidedly non-Windowsy. And as you say, if he eventually ships an installer of some sort that installs into Program Files, it’s either going to break, or the installer is going to be doing the wrong thing by Windows standards.

        • coandco says:

          Speaking as one of said testers, I put all of my games into C:\Games, from long habit and a desire not to have to dig through the incredible mess that is Program Files whenever I want to launch a game manually. And yes, Shamus is distributing Good Robot as a .zip file.

          • Richard says:

            Well, that’s why it’s working at the moment then.

            When you created the C:\Games folder as a normal user, it will have been given your user permissions.

            By default, that will mean you have full control and members of the Administrator group have full control, but ‘limited’ users can only read/modify/execute.

            So if you log on as a different ‘limited’ user, you’ll probably find it silently dies.

          • James Schend says:

            That only works if you have a single user on the computer. The instant you add a second user, he won’t be able to run any of the games without hitting huge permissions problems.

            And if Shamus is planning to eventually create an installer, he should do it ASAP– installers are surprisingly difficult to get correct and if you wait until the last minute, you risk having to delay release because you can’t get the installer working correctly.

            • Richard says:

              Definitely start on the installer ASAP.

              For my first ‘public’ project I waited too long before starting on the installer as I’d genuinely thought “How hard can it be?”.

              And I was wrong, it took quite a while to find a good installer pack and get it configured in a decent way.

              For Windows, NSIS is by far the best ‘free as in freedom and beer’ option, and as it’s totally self-contained.

              It makes smaller installers than MSI-based ones as well, which surprised me.

      • James Schend says:

        When in Rome. If you’re going to build an app to run in Windows, you have to follow Windows’ rules. When in Rome.

        The reason Windows is so popular, BTW, is because of features like this. Windows is used by so many people *because* system administrators can easily redirect folders to different paths– network shares– something which is unreasonably difficult and buggy in other OSes.

        (And BTW, OS X probably has similar rules– you should ask someone about that. It certainly did in the Classic era. It’s only Linux that’s the “wild west” where anything goes.)

        • somebodys_kid says:

          A lot of weird Windows quirks are starting to make sense now.
          Are those annoying compile-time conditional statements the only way to do correct cross platform development then?

          • James Schend says:

            Well, if you’re coding “to the metal” in C or C++ like Shamus is doing, then yes. As far as I know. POSIX file functions don’t cover Windows.

            At some point, Shamus (or a library he’s using) already has some kind of conditional compilation because the function for opening a GUI window in Windows isn’t the same as in X11 (Linux) or OS X. So I don’t see why he suddenly sees it as an issue now, frankly… I guess because it’s in a library and he doesn’t “see” it in the code?

            If you’re using something like MonoGame, Unity, Unreal Engine, etc. then the environment will do it for you automatically. That’s just one of a million reasons I’d never recommend writing a game in C or C++, it’s just headache central.

            • Mephane says:

              Please tell me how to use *any* Windows-related functionality in C++ without going to “the metal”. Pointer in, pointer out, pointer inout, oh, who has to allocate this buffer? Now it’s me, now it’s you! This here requires just a fixed buffer, this here requires to call the same function with specific parameters set to 0 in order to get an estimate about the maximum required buffer size (you will still have to check afterwards if all that was used). Hope you did not dare to have a class member function with concise names like “DeleteFile”, look at me, look at your class, look at me, look at your class, I’m on a horse and your member function is now DeleteFileW.

              As someone developing for Windows myself, I can say the Windows API is madness. Boilerplate, petal to the metal, get out the flamethrower and juggle your bare pointers madness (or use evil tricks like &myvector[0] to have a std::vector and still be able to pass a raw pointer to a Windows API function).

              • Alan says:

                &myvector[0] is explicitly blessed by the C++ standards, specifically for situations like that. So I’m hesitant to call it a “trick”. I’ll leave judging it “evil” or not up to the individual. :-)

                • lethal_guitar says:

                  It’s mightily useful whenever you need to interface with a C library. I really wouldn’t call it a “hack” – it’s a necessity if you want both nice and clean C++ and use low level C APIs.

                  C++ 11 introduced the data() member functions for this, which makes it look much better.

              • James Schend says:

                Right; that’s why I don’t recommend coding in C++ for *any* type of application.

                C#’s API/library is much more sane than Windows’, much much easier to use and you can still link in C++ DLLs if you need the performance. And it’s portable, as long as you stay within what’s supported by the Mono project.

                The real point I’m making is: don’t code in C++ at all. C++ is a lousy language. Windows’ C/C++ API is a lousy API.

                • Actually pure C is not bad at all. It’s when you start adding COM and interfaces and sub-classing and Managed code that things get messy fast if not careful.
                  I’ve been doing Win32 API coding for years using C like calls to the OS.
                  The issue with the Win32 (aka Win64 API if you make x64 exes) is that it’s getting long in the tooth, way to much backwards compatibility, and too many cooks in the the kitchen. Sometimes stuff is added to an existing API instead of making a new, so that means they can’t phase out the old function.

                  And MicroSoft has said in the past that as long as programs that are frequently used still uses a old API function then they will not remove it.

                  MicroSoft did try to phase out old code, but people got really upset when their VisualStudio/Express 2012 (i think) compiles failed to run on anything older than Widows XP with Service Pack 3.

                  I do not envy the API gang at MicroSoft, they are caught between a rock and a hard place, damned if you do and damned if your not. No wonder everyone are drooling over clouding so much, you send the new code each time the user starts the application, and in a pinch a text editor (like notepad) could be used to fix a bug.

                  The Metro apps was a good idea but not well executed, they should have focus on making them desktop apps instead of Modern UI apps. To me a HTML5+CSS+JS dekstop app is a wet dream, no more compiling, scaling and flexible UI etc. But at the current pace that dream is still 2-3 years away (Windows 10 or 11?).

                  As to the .Net/C# api. That API actually is on top of the Win32 API (Windows itself is the Win32 API), the advantage .net stuff have, is that it’s way never, so What is presented to the coder makes more sense. I assure you if the Win32 API guys got to redesign the naming and parameters and stuff for the Win32 API today it would look way different.

                  In my own software I had the luxury of redoing a lot of stuff and behavior from scratch, MicroSoft can’t do that with Windows, users are used to shit just working, even if it is more than 10 years old. Heck, a properly written program that was written for Windows 95 (18 years ago) will still work fine on Windows 8.1 good luck saying the same about a Mac or Linux (pre-compiled) program on the latest release of those OS platforms.
                  Only the web itself (at least websites correctly made) can compare with that.

                  But I have to admit, I wish MicroSoft would be a bit rougher.
                  For example. they could have turned Windows 7 into their Legacy OS to handle anything made for the WIn32 API, and then make a new v2 of the Win32 API which would not be directly backwards compatible with Windows 7.

                  MicroSoft did a leap when moving from the Windows 9x core to the Windows NT core, at some point they will need to leap from the Windows NT core to the Windows something core, but with a larger leap that breaks compatibility with the majority of software out there.

                  What I’m saying is that I agree and disagree with you.
                  The .net/#/mono stuff is awesome, but there the burden on working with the API stuff is shifted to somebody else, and you as a programmer are now dependent on somebody else to fix things for you, while with C (or any other un-managed language) the Win32 is under your control and you can easily code in stuff to handle any issues your self.

                  APIs are awesome if they hardly ever need to evolve, start evolving and those APIs get stale pretty darn fast, regardless of the language. The code that is the easiest to maintain is the code that one does need to write or change at all, and such code does not really exist.

                  • Simon Buchan says:

                    Microsoft did make a “clean slate” API that doesn’t care about back-compatibility: WinRT, that runs all those Metro, I mean Modern, I mean Immersive apps that everyone hates :). Of course, since it’s not compatible with all those old desktop apps, nobody cares about it, and “Microsoft are such idiots! I don’t want to use this shitty interface!” Which is fair enough, since it’s *not* as good as desktop (though not nearly as bad as everybody seems to think it is, that seems to be more of a “it’s different! I hate it!”). The real question is: is that not as good *yet*? Either desktops are largely going away in favor of tablets and small touch-laptops, in which case Microsoft has dug itself out of a hole and has experience building applications for the small screen, or it isn’t, and they have dug themselves out of a hole and have replaced the entire windows API with fresh clean *good* APIs over a period of several releases (and thus not getting into an XP/Vista situation where they don’t ship for 6+ years). Windows 9 will be interesting, since it should show which way they’re heading with WinRT.

        • Steve C says:

          Windows has rules like this specifically to make it more difficult to move files around. It’s part of tying in your userbase and increasing switching costs. It’s a business decision more than it’s a programming one.

          • Alan says:

            Seriously?

            The core ideas aren’t some Microsoft invention. They date back to the 70s, to Unix. Unix built them (and in many cases probably nicked the ideas from other places). Unix created/stole them because actual experience showed them to be useful. Anyone administrating a large corporate system is thankful for the support. If you want to be able to install software your kids can use, but remain confident they can’t break the software, nor infect it with a virus, these are the tools you want. This was a great step forward in ending Microsoft’s history of being wildly insecure.

            I have no idea how this makes moving files around harder: you want your software back, reinstall it however you did in the first place. You want to move your personal data, it should all be in one place (On modern Windows, typically C:\Users\USERNAME, but it can be changed). It means you can move to a new system relatively easily and keep all of your personal data. Heck, it makes it easy to take all of your personal data and move it to Mac OS X or Linux.

            • Steve C says:

              Reinstalling it isn’t moving it- it’s reinstalling it. That’s the problem. I’m specifically avoiding a reinstall.

              Copying a program that can fit on a DVD takes seconds. Installing a 4Gig program takes minutes. Case in point- Windows. I have an image of the hard drive windows is on. I can reinstall windows in about 2hrs plus a handful more hours over the next month re-tweaking it the way I like. OR I can use the backup image I keep and be done in about 2mins. A program that decided to spread itself across my OS drive and the drive I wanted means I cannot do the same thing. Also it means that when I use that image for windows that I’m going to break some of my other programs if my backup wasn’t recent.

              Most importantly if I’m reinstalling it there’s a reason and likely that reason is I want to remove all traces and start fresh in order to solve a problem. If reinstalling keeps ANY of my previous settings then it didn’t uninstall correctly. When I uninstall something I want all traces of it gone including from the registry. Output of the software that can stand alone (for example documents) should not be deleted but everything else (like saved games) should go. It took me hours to properly remove adobe acrobat off my mom’s computer. Any software that does something like that is pure crap.

              Moving software means I want to keep my customized settings. I do not want to remove all traces in that case. I do want to keep my saves and access it elsewhere. I can’t do that with confidence because an installation can throw files everywhere. Some random game has no business putting files into windows/system32 but so many of them do. THAT is not secure.

              Microsoft ended nothing. It is wildly insecure. If it was secure I’d be able to lock down the drive my OS is on and no legitimate program would want to touch the OS drive.

      • Blue Painted says:

        You pretty much have to when you get to OS specific stuff like where files have to go … the *IX world thinks ~/ means “base” but Windows doesn’t (I think OSX does too, but it’s basically IX anyway) but the good news …

        … it’s really easy to package up this stuff in one place, stick a big label on it saying “cross platform crud inside” and then leave it alone. Call it once for “the base of my save file structure”, maybe via a config file so users can change to suit themselves, and you’re done.

      • Anachronist says:

        The CWD is never read only if you let the user install the game to wherever they want. If you’re trying to be free of Windows cruft, then you can also be free of the Windows Installer, and allow the game to be unzipped into any directory the user chooses.

        See also my comment below. I never use “My Documents” if I can help it.

        • X2Eliah says:

          I’ve yet to see an installer that doesn’t allow the user to *choose* where to install. E.g. outside of program files, thus not having any of the UAC nonsense.

        • James Schend says:

          If you gave me a .zip file like that, I’d still put it in “Program Files”, and you’d still have permissions problems.

          I put all my program files in “Program Files”.

          So your assertion that you’d NEVER have permission problems is incorrect. The fact is, NT is a multi-user OS and you have to follow its rules to create working software.

      • ET says:

        Well, you can segregate the OS-specific stuff pretty well.
        Save-game code could probably go into something like save-games.c and maybe have one smaller file like save-games-os-specific.c.
        I know it’s do-able, but I haven’t written anything touching OS-specific code in a while, so I don’t know how difficult.

      • Richard says:

        You’re using the SDL toolkit, right?

        http://wiki.libsdl.org/SDL_GetPrefPath?highlight=%28\bCategoryFilesystem\b%29|%28CategoryEnum%29|%28CategoryStruct%29

        Like most cross-platform toolkits, it’s got a way to find the user-folders. Use that!

      • Mistwraithe says:

        Bah. Everyone else beat me to it. I know: Last post!!

        Being OS agnostic will only get you so far. At some point you actually need your software to run on an OS and at that point the correct behaviour is defined by the OS. If you are on Windows and you want to save data you use SHGetKnownFolderPath (or SHGetFolderPath on older Windows). If you do anything else then your program is by definition non-standard and also almost guaranteed to not work properly on some machines and for some users.

        I have done very little development for other OSes but I’m sure they have similar standards. An OS without standards would just be chaos (which in fact is part of the reason Windows was so chaotic for so long, the standards weren’t enforced very well for a long time).

      • bickerdyke says:

        While it’s definitly nice to keep your software free from OS-Specific stuff, there are exactly two points where you HAVE to be OS specific.

        No 1 is when you’re accessing hardware. Graphic card, input devices, printers, that kind of stuff. You get around that as you’ve delegated that to a bunch of libraries, from stdlib to OpenGL and SDL.

        No 2 is a bit more difficult, because that’s the behaviour to the outside world: The user. And you again have a big bonus here as games may bring their own, non-standard, user interface. Most people I know don’t liek using Java developed software, as they tend to feel “unnatural” compared to their other software. yes, they’re the same on all platforms, but that just means they’re NOT sticking to the OS user interface guidelines on Win AND Linux.

        To sum this up: The user expects all his software to work neatly together. And it’s the OS duty to take care of that, and that’s why you want to play nicely with the OS when it comes to file storage, launching, backups, automatic updates(ever noticed how your KDE Dock is NOT clogged by tons of app specific update tools because the packet manager handles updates for all programs?)

        The OS is not your enemy. The OS is there to help you and take care of getting right all that small stuff, even if “right” is OS dependant. Trying to be OS independent here in the end means doing it wrong on all platforms.

      • Neil Roy says:

        The installation program can be OS specific and choose an installation folder, the game itself can save in the same folder as the game, leaving it up to the user to choose a good place for it. Or don’t bother with Linux support, tell them to use WINE. ;)

    • Anachronist says:

      This is wrong in so many ways I lost count. If you are trying to write portable code without platform dependencies, you have to lose the mindset of needing the Windows installer, registry, and any OS-specific APIs. CWD works just fine, or a subdirectory thereunder, and has always worked just fine on every version of Windows (I believe CWD must be known as an ANSI standard), for any program installed from a zip file into a directory of the user’s choice.

      • Abnaxis says:

        This. This right here.

        The first thing that came to mind after reading the post was “why do you need an installer?” Good Robot doesn’t need the registry. It doesn’t need the API. Just pack the game in a zip and let users unpack it wherever they want, a-la Frayed Knights (There are other games that roll this way, but I know Shamus has FK).

        I’m surprised the suggestion took this long to pop up.

        • James Schend says:

          For one extremely important reason, you can’t put it on Steam, Desura or GOG without an installer. (Well. Maybe GOG.) You can’t port it to Xbox 360 without an installer.

        • I guess one could also simply ask the user the first time as to where they want save games (and possibly screenshots) to be saved. A default path could be pre-filled in the requester even.

          I haven’t made a game myself (yet), but I would probably save to app data roaming folder for the user, and instead provide a export/import savegame feature which would default to My Documents but let the user choose the path to be anywhere.

          I cant recall any triple A or quad A (*hurl*) games that have done that yet. I guess backup to the cloud is the closest you can get today. Mind you that import/export of save games did exist in games a couple decades ago.

          • bickerdyke says:

            Why?

            That’s what the operating system is for. It already gave the user a chance to say where he wants his savegames, it knows how to seperate savegames between users, knows how to back up save games (and not the game ressource files that can be reinstalled easily)

            While OS independant programming is nice, but if that has you re-implementing Os features, it’s usually a fail.

            • “While OS independant programming is nice, but if that has you re-implementing Os features,”
              There is a OS feature for backing up your save games to another folder or a USB stick or external HD? (and for “that” game only and not everything in else?)

              Also, depending on the game (or even software in general), being able to export maybe to some portable XML format is nice.
              Mass Effect games let you import a save but I can’t recall being able to export a save.

              “%USERPROFILE%\Saved Games” (FOLDERID_SavedGames) is nice but sadly very few games support it, maybe because it’s Vista+, if it had existed on (or been backported to) XP then I’m sure most would use it.

              I guess the game could create the Saved Games folder on XP if it did not exist. But how would the user know it’s there?

              I don’t have a console, but I seem to recall that at least the PS3 let you back up saved games.

              So unless you know to go to the Saved Games folder (this goes for Vista+ too) you do not know not is there/how to get it. You could write it in the manual, but who read those right?!

              Now if I click the start button, I see my latest used programs, I see Pictures and Music and Games on the right side of the menu, so I click on Games.
              I see a list of games, but no mention of savegames.
              I right click a game, no mention of savegames.
              There is also no buttons or any indications anywhere of something that would let me “Backup my savegames”
              Or even delete specific savegames, or let me see the size of the savegames.

              Also note that you would either have to quit the game or Alt Tab (and not all games or systems are so happy when that happens) to go to the Saved Games folder.
              What is so bad about adding a import/export feature (maybe even with compression and error checking added).
              There are middleware for trees and UIs so why not middleware for savegame management as well?
              There are still games that have a limited amount of save slots for trying out loud, that’s not technological progress.

              I known I’m ranting “a tad” here, but savegame import/export is darn easy to add to a game. I don’t own a PS3 so I don’t know if the PS3 OS (or the PS4 or XBox One) has a save game manager of any sort.

              And, even if it was a PC port of a console game, a lot of times a Launcher is used, savegame management could easily be added to that.
              And I highly doubt MicroSoft will add any save game management at least not for Windows 9, and probably not Windows 10 either.
              Sure you have steam, but not all games use steam.
              (does steam allow import/export of save games?)

      • Alan says:

        You’re also losing the mindset of behaving like a native package. It will confuse and/or irritate some of your users. It’s not a big deal for testing or for a small distribution, but in paid software it looks decidedly amateurish. This sort of special casing and inconsistency is a part of why console fans mock PC gamers.

    • DrMcCoy says:

      How about using SHGetFolderPath() instead? SHGetKnownFolderPath() isn’t available in MinGW.

      I guess GetEnvironmentVariable(“APPDATA”, foobar, sizeof(foobar)) is deprecated as well?

      • SHGetKnownFolderPath is probably the non-deprecated way, the old API calls for paths are deprecated.
        And as to MinGW Etc. Just add the missing includes ad it should work.
        Also, opening library then checking if the function exist, and only then actually using it is the correct way. This is what MiccroSoft suggest, check for features/functionality instead of relying on OS version etc.
        This is the same mentality as web design and javascript etc. You check for functionality first,

        I do that for all my coding. I still rely on some 3rd party libraries that may make a few assumptions, but I’m trying to avoid those when possible.

        • DrMcCoy says:

          Well, no. Just adding the includes /won’t/ work.
          I don’t actually have a Windows installed. I’m cross-compiling with MinGW on GNU/Linux, producing Windows binaries

          • Ah! I’ve begun poking around MinGW (or is it MinGW64, damn all the forking going on these days) and MSVC, it’s not easy to try and get rid of all dependencies. If it’s isn’t a dependency on MSVCRTxx dlls it is a dependance on MSVCRT.dll (which one really should not use as it’s a internal OS library) and this is a huge pain in the ass. I think I read that there is an effort to make a lib so that MinGW can be fully dependency free (so tat any dependencies are cause only by the programmer instead).

  21. Thearpox says:

    I’m a but late to the discussion, but at the installation, would it be possible for it to ASK ME where it’s save games would go, and offer several prime options? With brief explanations?

    Or at least TELL ME WHERE THE SAVEGAMES ARE GOING during the installation.

    I’m not yelling at you Shamus, but it’s gotten to the point where no matter what game I’m playing, AAA or flash, I always go online to and find a forum thread where somebody asks that. Even before opening My Computer. Maybe have it say savefiles location on the Load Game Menu, if not during the install?

    • “at least TELL ME WHERE THE SAVEGAMES ARE GOING during the installation”
      Dude I couldn’t agree more. Let me say that I’ve Googled more than once “where does xxxxx save the games?” over the years.

      • Blue Painted says:

        Then how about having Good Robot tell the user where the save games are … and when needed? So the menu bits that deal with save games might look like …

        * Load a game
        * Save a game
        * Tell me where my save games are

        …? After all, Good Robot probably knows.

        • Oh shit. I just got imagery of of MicroSoft buying “Good Robot” for use as a helpful mascot for the OS that pops up and helps you when (why is the internet looking at me like that?)

          And for anyone that caught my reference, you have my condolences.

  22. Anachronist says:

    I never use “My Documents” (or whatever it’s called these days) for anything where it’s possible to avoid using My Documents.

    For one thing, it isn’t portable, like the current working directory, or a selector to let the user choose a save location. As far as I can tell from reading this series, Shamus is trying hard to keep Windows cruft out of this application.

    For another thing, “My Documents” is always on the C drive, and can’t be redefined. The C partition is my system partition. Ideally, I want only the OS stuff and installed applications to be there. If the hard drive partition crashes or becomes irreparably corrupted (this has happened to me more than once), I absolutely do not want any of my own data on the C drive. Everything goes into my “work” partition, as much as possible. If disaster strikes the system partition, I’ll get a new hard disk, reinstall the OS and applications, and I still have my data safely somewhere else.

    Some programs insist on using “My Documents” and don’t let me change the location; for those, I have to back up my data periodically. PITA.

    • AyeGill says:

      It’s actually possible to move your “my documents” folder to another partition. I, too, once thought as you did, but it turns out I was wrong:

      Right-click My Documents. Select properties. Select the “Location” tab. Select a new location for your documents. And you’re done.

      I agree that this should really be configurable during installation, though.

    • MichaelG says:

      Or try this:

      http://lifehacker.com/5467758/move-the-users-directory-in-windows-7

      Worked fine for me during installation of a new system.

    • James Schend says:

      If you don’t like My Documents where it is, just move it.

      The entire point of programs using an API call to find My Documents (and other named folders) is so the user can move them all over the place and the programs still work. That’s one of the things that makes Windows *better* than competing OSes, where you can’t (practically speaking) move those folders and still have working software.

      • *nod* it’s just a shame they did not backport the Vista/Win7/Win8.x known folder stuff and a few other API things (that they could relatively speaking do without too much work).

        While I do not mind having pre-vista and post-vista code paths (since I do feature checking anyway and it’s thus easy to plonk in a If branch there), knowing that say XP SP4 (if it existed) would have the same psaths/certain APIs as Vista and later. (and a update to Vista with Win7 and Win8 known folders, there is at least one path that was added in Win7 that would be nice to ave in Vista as well)

        Why backport? Well, if XP support it then folks would be more likely to use Win7 features for example as they’d only have to code it once.
        If MicroSoft managed to do this then we’d see quicker migration from XP to Win7 (and now Win8.1)

      • Anachronist says:

        Any API you use for Windows should also be available for any other OS; that is, it should be part of the standard library of the language you’re using. If you want to write portable code, not Windows-specific code, you can’t be using Windows APIs.

        The fact that Windows has its own API doesn’t make the OS “better” than others. Unix had a standard user $HOME environment variable, accessible from any language, for over 20 years before Windows came along, and no API is needed. One could argue that this feature makes Unix “better” than competing OSes.

        If you’re not using an OS-specific API, the fallback is to reference the current working directory. While it might make good security sense for “C:\Program Files\GoodRobots\” to be non-writeable by the application, it strikes me as forcing subdirectories under that also to be unwriteable as a needless restriction. One could ask the user upon first run where to store saved games, suggesting a known writeable path like a folder in TEMP.

        • There is only one cross platform standard “API”, it’s called POSIX.
          I can’t recall hearing savegames being mentioned there though.

          I guess you could look at the HOME environment variable though.
          But there is no definition of what folders should exist (under POSIX)
          so any “Save Games” (or would it be “save games” Linux is case sensitive after all) or “Pictures” or “Screenshots” etc. would be undefined.

          At least on Vista+ a POSIX “SAVEGAMES” environment variable could be mapped to the Saved Games folder (but what about on XP?)

          Also note that XP, Vista, 7, 8, 8.1 are not a POSIX compatible OS.
          I think there is a “POSIX on Windows” thingy out there but that is intended for Windows Server as far as I can recall.

          I guess the closest to a standard one can currently get is Steam, but not everybody uses that, and it’s also a proprietary standard/system, and non-steam games can not use it. (Steam developers prove me wrong, can a non-steam game use steam for savegame storage/backup?)

        • Richard says:

          That’s completely wrong.

          There is no cross-platform way to read user input.

          There is no cross-platform way to draw graphics to a screen.

          Heck, there’s really no cross-platform way to store and access any non-volatile data!
          (Compare Windows, Android and iOS)

          All the interactions your software has with everything outside itself are mediated by the operating system (or equivalent), and you have to obey the rules of that OS and use its APIs.

          And no, these APIs are neither compatible nor identical across operating systems.
          There may be a ‘lowest-common-denominator’ of functionality across the OS you wish to support, but the interfaces are going to be different.

          A truly cross-platform application follows the rules and conventions of its host OS – because that means all the users get the behaviour they expect.

          Put an iOS-styled app on Windows or Linux and the users won’t like it.

  23. Hal says:

    How difficult would it be to let the user define where the saves go? That is, during installation (or perhaps in a setting panel in-game) the user defines the directory where the games are saved. You could have it default to whatever (CWD, Bob’s documents, etc.), but the user can change that path if desired.

  24. MichaelG says:

    This kind of thing is why I backup all of “Documents and Settings”. That gets me tons of crud, including browser caches, but it’s just too complicated to figure out where the real “data” is. And it would be after a disk crash when you are reinstalling from backups that you discover you’ve missed something.

    It would be nice if all the read-only stuff (like program binaries) were in one place, and all the read-write stuff (like save files and program options) were in another.

    But it would also be nice if programs didn’t merrily run around the system placing files wherever they felt like it. For security if nothing else, we need to restrict where programs can access. This business of “you ran the installer, so I can do whatever I want to your system” should really end.

    I’d also like to be able to delete a program and all its files with one simple command, not rely on a buggy install/uninstall script for something I downloaded just to try.

    • Domochevsky says:

      Weeell… there is a solution for you for that particular problem. (And something I’d wish a OS was entirely build around.) :)

      • Well, if MicroSoft had added a app manager where you could select and delete data that belong to the app then thee user could easily clean stuff up.

        For example a software I make uses a GUID (UUID) for it’s install folder name, it’s settings folder name, and it’s registry install/unistall key.
        It would be dead easy to add some thingy to the control panel to uninstall and then optionally clean up any stuff left behind. (the user might just want the saved settings, and MicroSoft recommend that settings are not deleted on uninstall to avoid user data loss, i.e. only delete what the user want deleted).

        • Richard says:

          They sort-of did, in the MSI concept.

          Trouble is, very few people actually use it (heck, I don’t), and at the end of the day, it really is going to be down to the application developer/packager to decide what should and should not survive an uninstall.

          You can’t just erase every file the application created, because user data like documents, spreadsheets etc almost certainly should survive.

          – Perhaps you’re going to install competing but compatible software instead. After all, in a perfect world, that would always be an option.

  25. Mephane says:

    I just want to say, as someone who has so far been using a translated version of Windows (German): localized directory names are the work of the devil.

    • Sleeping Dragon says:

      This, if English is not always your default language things get even more excellent. some developers, in particular large studios that localize their AAA games, also translate the names of directories, at least in Polish. So on top of getting all the developer directories and such in your Documents location you will also get things like some of your games saving to “My Games” while other save to “Moje Gry” and similar parallels between more than one language.

  26. Incunabulum says:

    Saved games, and as much of the other games stuff as possible, should go into that game’s directory.

    I don’t want to go looking through multiple folders to find a savegame and I want to be able to easily delete the game and all its associated cruft when I’m done with it.

    Right now I have 17 games in my /mydocuments folder, several of those games were deleted but the uninstaller wasn’t set up to remove those directories. On top of that, I have *another* 10 inside /mydocuments/mygames.

  27. X2Eliah says:

    Just gonna throw this in:

    I have an SSD as an OS disk. It’s small-sized, it doesn’t like frequent small file writes, so I keep all games (and similar programs with propensity to poop a lot of tiny filewrites into it) on a different harddrive.

    I HATE GAMES THAT POOP THEIR SAVES IN C:/. *HATE* them. I TOLD the game the use X:/Y/Z/Gameplace, so PLEASE FOR GODSSAKES, game developers, TAKE NOTE what I just told the game, and actually USE THAT LOCATION, not something godawfully random that makes no sense and satisfies nobody.
    If a user installs their game in C:/Program Files, then that’s ther responsibilty, and on their head to run it in admin mode.

    My question is, WHY did the user install it in Program Files? Because that’s the default option? If so, then WHY did YOU as the dev, the maker of the installer, put Program Files as the default path, if you *know* full well that it causes issues?

    This sounds mean, and I’m sorry about that. But the core message is valid – YOU are the developer, and it is up to YOU to a) listen to the player during installation, (using install path), & b) Not throw curveballs to the player during installation (automatically suggesting progfiles).

    • X2Eliah says:

      Oh, yeah, before anyone says: Steam allows choosing install destinations now (origin does that too), and I have neither of them anywhere near C:/.

    • ET says:

      I’m curious to know how old your SSD is.
      I read a good article, where a guy did the math, and worked out, that for a reasonably sized modern SSD*, you’d basically have to max out the bandwidth of your SATA cable, for several months straight non-stop, to kill an SSD, if it has even remotely competent load-leveling.
      (Actually, it might have been years.
      If it wasn’t, it sure as sugar will be now; SSDs are still on Moore’s law.)
      This was back around 2010, I think.
      It’s kind of nice, that load-leveling firmware, and some improvements in the max number of rewrite cycles, has basically made the fear of thrashing an SSD or thumb-stick obsolete.*
      So…the whole “safely remove” thing…basically needs to be replaced with the OS just writing everything instantly, as if these were normal disks.

      * Actually, it was calculated for a thumb-stick, but it’s all based on the basically the same flash and load-leveling tech underneath, as far as I know.

    • Alan says:

      Developers make it the default because it’s where Microsoft tells you to put it. They’re doing the right thing. Software should, by default, be installed into Program Files[1]. Software should only write to Program Files during install, uninstall, and updates, and should request Administrator access to do so. Any other data a program needs should, by default, be written somewhere in Users\Username\AppData or Users\Username\My Documents[2]. When a program does this, there are no issues.

      When done correctly a lot of things Just Work: It’s harder for a virus to infect your software (because the virus needs Administrator access and you’ll be asked for permission; doubly useful for a child’s account which will entirely lack Administrator access). The uninstaller won’t blow away your data. You can relatively easily find and backup your data. A user can easily ask all future software to be installed to a different drive. A user can easily move their data to a different drive, or even make it available on a network share. A user can just click the “Express Install” in the installer and get reasonable defaults. Multiple users will get their own data files (a child can’t save over your game), while sharing the same game install (which can easily be 30 GB these days, which is non-trivial on an SSD).

      Windows permissions are a clusterfuck because developers have been ignoring standards from 1997. 16 years is enough time to get up to date. The bad old ways continue to work because Microsoft is committed to keeping antique software working, not because developers should keep using them.

      I’m sympathetic to just writing data into the current working directory. As a developer it’s incredibly convenient. But it’s actively user hostile. The work to do the right thing really isn’t that hard and will improve life for everyone. And for the unusual cases where someone has a good reason to store their saves or install their games somewhere else, I entirely support making it an option.

      [1] Or more accurately, whatever SHGetFolderPath(0, CSIDL_PROGRAM_FILES,…) returns.

      [2] SHGetFolderPath again, with CSIDL_APPDATA or CSIDL_MYDOCUMENTS, respectively.

      • MichaelG says:

        So if I have side files like graphics models, textures, etc. do they go with Program Files, or into AppData?

        • James Schend says:

          Program Files – those files belong to the program, not to the user.

          AppData is for data that belongs to the user. Each user gets their own (initially blank) AppData.

          Remember, one computer can have 30,000 users or zero users. If roaming profiles are enabled, one user can exist on 30,000 computers. In Windows, it’s important to keep track of what belongs to the program, and what belongs to the user.

          • Steve C says:

            The program belongs to the user. The files the program needs to operate belong to the user. I run programs on an infinite number of computers because I use everything off a portable USB drive. I don’t want my cruft left on that computer when I’m done.

          • Alexander The 1st says:

            And what if I want a user to be able to replace graphic models/textures/etc.? Or mods?

            Then all of a sudden, they need write access, wouldn’t they?

            • Alan says:

              If the user wants to make it available to all users on the system, yes. In which case they should be using Administrator access, since they’re doing something that will impact other users.

              If the goal is for a user to be able to install mods just for themselves, it should stay out of Program Files. A well behaved program should support this. And sure enough, Firefox (and I believe most web browsers) support adding mods without needing access to the install directory.

        • guy says:

          Up to the designer. If it’s supposed to be easily modifiable, it goes in AppData. If it’s not, it goes in Program Files. Program Files is explicitly intended to be hard to modify.

      • That is all and good as for the SHOULD part, but that only applies to All Users installs (Program Files).
        A lot of the time, Per User installs are desired.

        I’ve lost count of the times I’ve installed a program, had a elevation prompt appear, fine, then after install there is no start menu icon to be found. Why? Because that got put on the admin account, not my normal user account.

        Even after all these years, Windows programmers still can’t figure out admin vs non-admin users. I assume Linux programmers had that shit figured out like years ago (as Linux had “UAC” since almost day one).

      • X2Eliah says:

        See, this is nice and all, but it completely ignores one very key premise:

        – *I* own my computer. *I* want to dictate where stuff installs. And anything ‘C:/’ or ‘windows-default’ is *nowhere* in that list.

        – No, seriously. I will accept that for default users with default installs who like their system drives bloated and messed up, aye, use whatever. But don’t force your basic should-be’s if I’m NOT using the basic install principles.

        That’s the big issue here, tbh. I will concede setting defaults to progfiles, appdata, whatever (even though it still manages to be a problem for many games, but whatever). I will not concede anything being pooped in a location I explicitly did NOT select/allow for the game. If I put it in X:/Y/Z/foofpoo, then that’s the disk area I allow the game, and that’s what I want to be respected – without any appfiles, progfiles, userfolders or whatever. I’m not supersmart about Windows’ internal stuff, so I don’t know if there is a real way to limit a program, explicitly, to a single folder/area (e.g. something like executable properties->disc access->allow read/write to: [list directories]). There probably isn’t such a mechanic. So I use the next best thing, which is specifying the install location. And so far, very very many developers – indie and AAA – are completely ignoring this compact and pooping their game data into places I don’t want and never told them it was OK to do.

        tl;dr: Defaults – okay, I concede that. Custom install location – please, *in this case*, stick to that dir and that dir only.

      • Steve C says:

        I find what you suggest to be actively user hostile. I (a user) want everything necessary to run that program in one place. The only time I want a program to ask for admin access is for changes to the OS, not to the program itself.

        • Alan says:

          When I said user hostile, I meant “for the overwhelming majority of users.” You, I, and pretty much anyone with an opinion on the matter, are terrible reference points.

    • Enno says:

      You may want to move your user profile folder someplace else, then. Maybe create a junction point from c:\Users\JohnDoe to D:\JohnDoe, if that is where you want to store your own data. The install directory for the game should say nothing about where the saves are going. Saves belong in your user profile, where they are included in your backup.

  28. Matt K says:

    Honestly, this issues is why I’ve embraced Steam as a platform. I had computer issues last year and had to reinstall the OS. For my non-steam games this meant trying to find where the saves were (btw, no one seems to us /user/saved games). However most of my Steam games used Steam Cloud so even if I missed some, for those games all I had to do was reinstall them (and I did lose a bunch of saves).

    • Sleeping Dragon says:

      Except for days when Steam cloud decides it would rather not work or that it wants to bring back some obscure savefile you created last week, a feat of necromancy that apparently requires the bloody sacrifice of all your current savefiles for a given game. Now to be perfectly honest I have generally been disabling cloudsaves since I only use this one PC but I know this was something of an issue at least in Defense Grid community and even more so with Dungeons of Dredmor.

  29. Nick Pitino says:

    For what it’s worth being a non-programmer myself, I like it when saves are in the same folder as the game as that makes it easy to find them for backups. It’s also the place I kind of logically expect them to be and is where I check first.

    PS:

    Regarding twitter: What is wrong with hunting and butchering your own meat?

    • Shamus says:

      Hunting and butchering your own meat is a fine and useful skill if you do it because you enjoy it. But if you just want a hamburger, then it’s a ridiculously time consuming way of solving the problem.

      • AyeGill says:

        On the other hand, you’re a lot more likely to be without a computer(example: you leave the house without a sufficiently advanced cell phone) than you are to be in a situation where hunting and butchering a wild animal is faster than going to a grocery store and buying some ground beef.

        • guy says:

          On the third hand, if you need to do long division without a computer/calculator, you are probably in space.

        • Alexander The 1st says:

          If you’re leaving the house without a sufficiently advanced cell phone or other device capable of performing division via user-input and you need to do long division, long division is probably not the biggest problem you have (See guy’s comment about being in space).

          On the third and/or fourth hand, if you have a cell phone that isn’t able to perform division via user-input and it *still works*, it’s probably a Nokia – so you can probably solve a lot of the problems involved, including hunting and butchering wild animals for food. :p

          • Cuthalion says:

            My horrifying, but durable little Nokia brick supports long division via user-input into a built-in calculator app that doesn’t clearly tell you which buttons do what.

            It can also hunt and butcher wild animals for food, yes.

    • postinternetsyndrome says:

      The same as with all meat consumption, I’d say. But I don’t think that’s what he meant…

    • John says:

      I have definitely used games in the past (original Diablo I think, maybe others) where the games were just saved in the game’s folder (under C:). When I uninstalled the program it removed everything except for the game folder, save game folder and the saved game files. Then years later when I reinstalled the game the saved files were in exactly the right place and I could start where I left off. When uninstalling I think I may have been givien a message telling me that not all folders have been removed and I should delete them myself if I want to.

      John.

      • Veylon says:

        The “right” way where data is stored in the User directory – be it “Saved Games”, “AppData”, or “Documents” is intended to preserve this kind of functionality. The raw content of programs can come and go, but your portion that’s unique to you should be in your folder and be preserved.

  30. WWWebb says:

    I thought this is what installers were for. The installer suggests/asks where the user wants things and then writes to a config file (or registry entry if Windows-only) that keeps track of where everything is.

    A good installer can set read/write permissions at install time for whatever directory it’s creating so you don’t have to worry about Admin rights and user permissions or whatever.

  31. ET says:

    Even reading through these comments is giving me a headache;
    I can only imagine how bad it is to actually know and remember all of this stuff.

    Is there any library which would abstract away all of this, in an OS-independent, cross-platform way?
    And respect user permissions, if they exist?
    And…?
    Like, just give the programmer some generic functions to do things like:
    – get the directory for your game’s write-safe area, for the current user? (put saves here by default)
    – like the above, but for all users? (put config data here y default, like hardware settings)
    – …
    Does this exist?

    • James Schend says:

      Yeah of course, tons and tons of libraries abstract these kind of details away.

      The biggest hurdle is making programmers aware that features like “roaming profiles”, “limited user accounts”, “multiple users on one computer”, etc. even exist in the first place.

      Shockingly, I’ve found that computer programmers frequently have huge gaping holes in their knowledge of the OS they spend all their time running and developing software for.

      • krellen says:

        IT and programming are two different subjects. For the most part, programmers don’t need to know how the OS works and stores things (as there are libraries and APIs to provide any required variables), and system administrators don’t really need to know how to write a program (unless you consider scripting to be programming). Now, there exists a need for cross-discipline people – some has to write those libraries and APIs – but that need exists mostly on the backend, closer to the OS itself. Microsoft needs those people, but EA shouldn’t.

        Unfortunately, we’ve been making computers simpler for users to use at an increasing rate, especially in the last twenty years or so, so the vast majority of people don’t actually realise how complicated they really are. “Computers” isn’t really a single, compact subject, anymore than say “literature” or “science” are. Studying one part of “computing” should not require a mastery of all parts of “computing”, but many of us still seem to expect it to.

    • Richard says:

      Yep.

      Qt does – QDesktopServices::storageLocation (v3/4) or QStandardPaths (v5)
      SDL does – SDL_GetPrefPath (at least from 2.0.1, anyway)
      Wx does – wxStandardPaths

      I would expect that every a cross-platform toolkit contains a method to do this.

      The problem is of course getting the programmer to actually use it.

  32. Adam says:

    I’m no programmer (happy English major, thank you very much) but it seems to me like there’s no real benefit to saving your game saves to /Users as opposed to a folder directly related to the game’s dedicated folder. Why are people so adamant that they should use the documents folder, anyway?

    • James Schend says:

      Because a single computer can be used by more than one person.

      So you install your program, and both Bob and Phil want to play it. Bob plays and makes a save, and now Phil plays and… Phil has the same save as Bob? No, that’s not right…

      Game saves obviously belong to the user, not to the computer. So you need to put them in some per-user directory– it doesn’t have to be Documents necessarily.

      • Endymion says:

        What if Bob keeps his game installed on a flash drive and plays on multiple computers? In that case any absolute location solution is an absolute nightmare.

    • In the old days, programs went in “Program Files” and everything else went in “My Documents” and yes some programmers even hard coded the Program Files path, which was real fun if windows was on the D: drive instead (I actually had that for a while many years ago), Windows itself was fine, but almost any other software broke.

      And before we got the Roaming App Data folder the registry was used for settings and stuff like that.

      As there was no UAC/elevation stuff back then, if things weren’t saved in My Documents then they where saved in the program’s own folder if it had one that is, some programs just liked to burp files all over windows folder.

      And uninstalling delete files, problem was that sometimes the installer/uninstaller would just assume it was the only program in the world so it would overwrite system files, or shared files, and when uninstalled it would delete them, thereby breaking pretty much anything else.

      Those where the old wild west days.
      Now we’re in the post Wall Street crack era, things are overly complicated or too obscure,
      and somebody is getting screwed and somebody is getting rich,
      and you are certainly not the one getting rich.

  33. hemebond says:

    I’m pretty sure that explanation of the current working directory is wrong. The working directory does not necessarily contain the application.

    If I’m in C:\Games and I run C:\Windows\testapp.exe, my current working directory is still C:\Games.

    Same on GNU/Linux. If you use “echo `pwd`” in a bash script:

    user@computer:/$ /home/user/test.sh
    /

    • Bloodsquirrel says:

      You’re confusing the working directory of your command prompt with the working directory of the program.

      If the program asks Windows what its working directory is, Windows will tell it C:\Windows\. The entire point of this function is so that the program can find files relative to its own location.

      Command line scripts don’t follow the same rules since they’re expected to behave as if a user was entering them into a command prompt. They’re being read from a file and processed by whatever program (such as a command prompt) rather than running a process of their own.

      • WJS says:

        Not at all true. Open the properties of a shortcut. See that “Start In” entry? That sets where the shortcut runs from. Change that and you change CWD, no command prompts involved. (This will probably break the program unless it’s very simple, but it will run at least briefly)

  34. Mintskittle says:

    I see only one way to solve this. Have Good Robot put its saves in another games directory.

  35. safetydan says:

    I strongly suspect the easiest thing to do is either use SDL 2 so you can use the SDL_GetPrefPath function. Or maybe look at its source code and do the same thing. The “right” way on Windows is using SHGetKnownFolderPath and get FOLDERID_SavedGames but that doesn’t work on XP. Linux is even worse in that respect as there’s no standard.

  36. Skye says:

    I have a crazy plan.

    First time the user tries to save, ask them where they want to save it. Give them a default that makes sense. (Probably where the program is, or in My Documents. One of those.) But let them pick. Write yourself a little .txt file that the program reads to figure out what the user said when it needs it again.

    Not sure if this is impossible for some technical reason. I’m a college level programmer (so, beneath Shamus, but above the bulk of humanity) and this is what I make my programs do whenever they need to save something.

    • Sam says:

      It’s a neat idea, but what happens when I move the save file (like if I’m freeing up HDD space)?

      • Bloodsquirrel says:

        The same thing that would happen if you moved the save file for any other game?

        • Skye says:

          Exactly. If a game saves the game, and you manually move the save file without telling the game where it is, the game can’t find your file. That’s an acceptable breakage. Presumably, you have a similar setup with loading (where it defaults to the last game you saved, and you can redirect it to open any file with the right extension) and rely on the user to remember where they put everything if they want their saves spread through multiple folders.

          From a design standpoint, it should follow the user model quite well- the most well known applications (Word, excel, notepad, etc) operate like this, and most users have figured it out by now. For users who don’t understand it, they hopefully won’t mess with it, and the saves will live where you defaulted them.

          This doesn’t stop the determinedly foolhardy user, who changes the save location every time and tries to open an excel doc that they changed the extension on. (I have had a user do that. They though that was how you created tables in html.) On the other hand, there’s a limit to how much foolproofing you can actually do. I can’t help thinking a lot of modern save systems were designed to be this foolproof, much to the annoyance of everyone else. Whether Shamus think his users are that unsophisticated is up to him.

  37. guy says:

    “The path of least resistance is to just ignore all of these Microsoft shenanigans. Just create a save game folder wherever the program is currently running. This way the game will work the same way on all platforms, I’ll always have read/write permission”

    Uh, no, actually, you won’t. My desktop is pretty fussy about writing to Program Files when saving and when a game saves there I need to explicitly designate it as being run by an administrator in order for it to work.

  38. Alan says:

    156+ strongly opinionated comments on file locations? These are clearly my people.

  39. ateius says:

    You put the user’s saves in the same place they installed the game, because they’re game-related data and the user doesn’t want to go on a scavenger hunt through C:\Windows\Users\User Data\Local\Documents\Games\My Games\Electronic Arts\EA\EA Games\Good Robot\hamburgers\local\45937459\saves every time they’re looking for a savegame.

    I installed the game to E:\Good Robot, so the saves should be in E:\Good Robot\Saves. Period, full stop, end of story.

    And don’t even get me started about games that spew config files and user profiles and whatnot all over the directories instead of keeping them in the install folder …

  40. Dev Null says:

    I often find myself thinking of comments halfway through one of your posts, but usually I force myself to read the whole thing before commenting. Glad I did today, because the halfway-point comment was going to be:

    “Just put it in C:\foo; 95% of people will never notice, and the other 5% will hate you no matter what you do – they might as well hate you for doing something that’s actually awful.”

    And then I read the edit…

  41. Ithilanor says:

    I don’t have an opinion to add to the crowd; I’m just amused that of all things, it’s a post on save file locations that gets 200+ comments. That’s more posts than anything in this series except part 17, and that post was explicitly looking for feedback. I’d be interested to see which posts, from the long history of this blog, have the most comments.
    *passes the popcorn*

    • Paul Spooner says:

      That would be the infamous “religion” post… a-right-a-here: http://www.shamusyoung.com/twentysidedtale/?p=12768
      As of now, 1034 comments.

      It wasn’t the start of the policy, but the moderation hassles highlight why religion and politics are not discussed in the comments. Interestingly enough, a significant fraction of programmers consider file-structure conventions a religious dispute, and wish to convince everyone to adopt their point of view, thus making it political as well. I’d guess that’s why there are so many responses here.

      • Ithilanor says:

        I figured that would lead the pack; what I would like to see is a list of the top 20 most commented-upon posts. Linux vs. Windows has 255; none of the Postcards from Linux posts break 200, which surprises me given the fervor OS usage seems to inspire. (That’s probably contributing to some of this post’s discussion, incidentally)

        • Paul Spooner says:

          I’d be surprised if any in the top 20 had less than 350 comments. The AutoBlography drew quite a few, and IIRC 200 comments isn’t all that rare.

          It would be easy if I had access to the database! As it is, I’m thinking about writing a Python bot to extract the data from the “monthly summary” pages. If someone else has a better idea, or wants to beat me to it, I’d be glad to just play with the data.

          • Shamus says:

            I’d be willing to go after the answer if someone can help me with the syntax. I know enough SQL to do “select [stuff] from [table] where [condition]” on my own, but I get lost when doing queries within queries, which I think you need to do here.

            The tables are such:

            https://codex.wordpress.org/Database_Description

            • Fidicor says:

              I think this should work (I don’t have a mysql database to play with at work, so I couldn’t test it though):


              select Psts.post_name,Psts.post_title, Cmmnts.ncmnts, datediff(Cmmnts.maxdate,Cmmnts.mindate) as CommentingDuration
              from wp_posts Psts inner join (
              select comment_post_ID, count(distinct comment_ID) as ncmnts,max(comment_date) as maxdate, min(comment_date) as mindate from wp_comments
              group by comment_post_ID
              ) Cmmnts
              on Psts.ID=Cmmnts.comment_post_ID
              //where ncmnts >= 200
              order by ncmnts desc
              limit 25

            • Alan says:

              I’ve tested this on my own WordPress install. The output fields are: Title, number of comments, the ID for the post, and a link to the post. It’s sorted from most comments to least and only shows the 20 posts with the most comments. Mess with the LIMIT to have more or less.

              SELECT * FROM (SELECT post_title, COUNT(*) AS num_comments, comment_post_ID, CONCAT(‘http://www.shamusyoung.com/twentysidedtale/?p=’,CONVERT(comment_post_ID, CHAR)) FROM wp_comments, wp_posts WHERE comment_approved=’1′ AND ID=comment_post_ID GROUP BY comment_post_ID ORDER BY comment_post_ID) subquery ORDER BY num_comments DESC LIMIT 20;

              Same thing, formatted to be a bit less awful:

              SELECT * FROM (
              SELECT
              post_title,
              COUNT(*) AS num_comments,
              comment_post_ID,
              CONCAT(‘http://www.shamusyoung.com/twentysidedtale/?p=’,CONVERT(comment_post_ID, CHAR))
              FROM wp_comments, wp_posts
              WHERE comment_approved=’1′ AND ID=comment_post_ID
              GROUP BY comment_post_ID
              ORDER BY comment_post_ID
              ) subquery
              ORDER BY num_comments DESC
              LIMIT 20;

  42. Enno says:

    As you already pointed out, saves don’t belong in Program Files, because you need Administrator rights to save anything in there. This is also why configuration data (those awful .ini files) doesn’t belong there, but in %APPDATA%. Incidentally, all those folders that have different names on different versions of Windows have environment variables to access them, and you should use them.

    Additionally, nobody backs up their Program Files directory, so you don’t want to store things there anyway. A normal user backup contains the user’s Documents (C:\User\Shamus\Documents) and their Application Data (C:\User\Shamus\AppData). You want your saves to be in a backup, so those two are good locations to consider.

    You should definitely not ask the user. The average user doesn’t know what the file system is, and should not have to. They want to play a game, dagnabbit! Even if they do, though, they know even less about what a good location is, and they are going to be mad if their save was not part of the backup when they reinstall.

    The real question we need to ask ourselves is, is a Save Game “Application Data”, or is it a “Document”? I suppose that the answer has to do with what you want the behavior to be if a user has a profile on a domain, and logs in to two different computers – should their somain profile contain the saves, so they can play the game on one computer, and then continue playing that save on the second one later? I suspect that is what the Roaming folder does (where %APPDATA% points by default), and because the answer to my question is “Yes”, the save should go in there, not in My Documents.

    Looking forward to playing your game. Why aren’t you on Kickstarter yet?

    • TMTVL says:

      Kickstarter doesn’t allow PayPal, I don’t know about the internal policies, but I think IndieGoGo might be a better bet.

      Feel free to call me out if I’m wrong, I’m actually curious.

  43. Eric says:

    Don’t forget the other problem: if you have the game installed on a different drive, and the user has limited space on the C: drive (like with an SSD), should you still install the game to the Users folder?

    I find it exceptionally annoying when a game clogs my Users folder with gigs of save data, considering my SSD only has 100ish GB to go around and limited read/write cycles are still a potential concern.

  44. Endymion says:

    This reminds me of an interesting thing I ran into awhile ago when I wanted to start playing Dominions 3 multiplayer via e-mail. Since it requires me to grab save files and move them around every turn I needed to know where the game saved. Turns out that the game saves in its working folder unless it is in program files where it can’t. In that case it does indeed save the game fine, but no one seems to have even the slightest clue as to where. So I quickly decided the easiest thing to do was to just move the entire game’s installation over to its own folder so it would save in the sane location.

    Personally I hate saving to My Documents though. That whole thing is a mess and when I want to do a major reinstall I want to be able to just reformat the drive I use for my OS and only my OS, and then only have to do a few tweaks afterwards. I don’t want anything valuable on my C drive, because I expect that I could on a whim reformat the whole thing any day.

  45. kdansky says:

    I want to add that fiddling about with save-game paths is a waste of time to begin with. It’s needless micro-management for the OCD-afflicted. If I really need to find my save-games (what for?), then I can look the path up online, or search my disk for it (the inbuilt search tools are really quite good, and then there is FindEverything which is just ridiculously powerful). If I want to move my savegames, then I’m already an advanced user, and “mklink /J” is super easy to use.

  46. Zak McKracken says:

    Oh dear, long comment thread… I wanted to remark that I’m in favour of using the the %appdata/goodrobot/ folder. That’s where most software is putting their user-specific stuff (and for multiple users on one machine, they shouldn’t be able to overwrite each other’s saves…)
    This is also the closest you’ll get to putting it in /home/[username]/.goodrobot/ on Linux.

    I can’t comment on how hard it is to figure this out but … well you’d need OS-specific code in any case since on Linux the user’s usually not allowed to write in the game’s directory, thus the savegame must be in userland. Figuring out where that is is platform specific. In Linux it’s just an environment variable, on windows … well, here’s hoping that you’ll find a solution.

    At least for the language problem, I don’t think it’s a problem. Entering “c:\Users\” in the explorer adress line will send me to c:\Benutzer” on my machine, and “program files” is automatically redirected to “Programme”. Lots of English, non-tanslated software states “c:\program files\*” as installation path and appears in c:\Programme\ on the hard drive. — I think Windows (including XP) simply puts hidden hardlinks in place and that’s it.
    Otherwise there’d be a huge problem for non-English Windows installations.

  47. Chargone says:

    Paradox has conditioned me to never, Ever put a game in program files. Their grand strategy stuff is all about the mods, but if the games were in program files, trying to run any mod simply crashed the game.

    I don’t know the details, but it was a horrendous pain in the arse and a result of a change from xp to vista.

    Steam games: the path naming confuses me, but so far as i can tell… everything is nicely arranged in a game friendly manner which is also user friendly (or would be if i interacted with it often enough to remember it) from the user’s pov: find steam folder. Every single game running on steam puts it’s files in the correct, standardized place within the steam folder.
    This probably splits between my documents and program files abd has it’s own issues and…

    Ya know, with how much of a pain in the arse all this is, I’m quite glad everyone in my house has their own computers (no non-admin users), we’ve long since given up trying to use the LAN for anything but cable to the modem (under XP the damn thing just worked, for everything. Before, we had to do crazy stuff with the server every time we wanted a kan game, it seemed. After, a game may or may not find other computers. File teansfers aee such a pain in the arse that Flash Drives and manual actions are more viable for any function.) And I’ve given up on backing things up entirely. Games can be reinstalled and saves aren’t That important (the rare significant document gets stuck on a flashdrive or something immediately)

    i lost my point.

    Basically, if possible, let me install the game somewhere other than program files and keep it’s save files in a /savedata (or whatever) folder within. If it’ll fit and run on a smallish flash drive then the entire permissions issue becomes moot. Either multiple copies for multiple users is doable (include a note somewhere relevant about the issue with permissions vs saves if in program files) or the user can treat the flash drive like a cartridge (saving everyone many headaches.)

    If that’s somehow non-viable, and jumping through windows’s stupid hoops is unavoidable, find the official ‘correct’ way to do it for minimum bugs and maximum compatability life, then put the entire decision tree outside the user’s eye, mind, and reach…

    Different users being able to see each others Game Saves is utterly irrelivant unless they’re arsehats or small children who shouldn’t have unsupervised access to the machine anyway. Why is that even an issue?

    Doesn’t windows (and *nix, and every console ever to have a harddrive) have it’s own absolutely standardised save/load … thingy? Like microsoft office and every older game which Didn’t try to do weird things used for saving and loading? Is it not possible to call That and then say ‘if the user puts the file somewhere silly that, and the consiquences, are their problem’? Maybe put a ‘help’ type question mark button next to the save and load buttons which explains the relevant issues for those who care or have problems.

    I’ll admit, i know nothing about programing. I know just enough about using (mostly windows) computers that every non-expert older than me I’ve ever met assumes i know a lot because i can Usually sit down in front of a new (not excessively technical) program, spend a few minutes fiddling with it, then tell them how to do the vast majority of what they want to with it, and how to use it without breaking anything. (Which is not the same thing as knowing all the ins and outs and avandced tricks and the like to it.)… this is just me being good at figuring stuff out though. I’m no expert, and no programmer, and can only comment from experiance.

  48. RichVR says:

    I want my games to save in the same place that I install them. Thus, my 2 TB E: drive. E:/Games/Foo/Saves.

    If they insist that they save on my smaller C: SSD then they are broken. My SSD is for my OS and only my OS.

  49. Steve C says:

    I want Good Robot to run off my portable USB flash drive. I want to be able to stick it into a computer I’ve never had access to before and know it will work. I want this of all programs from now until the end of time.

    • Chargone says:

      This is pretty much the entire reason consoles exist. (Or at least got anywhere)

      They do that.

      Well… supposedly.
      Some high-ranking dingbats seem to think things like the ability to get spammed with what everyone else is doing, or duplicate the Entire Point of the device it’s using as a VDU is more important.

  50. Ian H says:

    I for one think we should all embrace the new C:/butts/ standard proposed here.

    Whatever Shamus decides I hope he posts explaining what his final setup is.

  51. Alan says:

    This discussion has lead to some ideas stewing in my head.

    Microsoft Word, Adobe Photoshop, and piles of other applications don’t (generally) create their own interface for managing saving and loading. They rely on the operating system provided interfaces. So everyone’s files go where they want. On Windows and Linux, it will default to a My Documents or similar directory; I suspect Mac OS X does something similar. I can accept the default, organize it into sub-folders, or stick the files just about anywhere I like. Using the operating system’s native file manager, I can delete files, copy files, and move files. By double-clicking on a file, the associated program will automatically start and open that file.

    Games (generally) take this powerful structure and say, “Fuck it, I know better.” They roll their own everything. I can’t necessarily manage my saves directly. I usually have little to no control over where the files are saved. Double clicking on a save won’t (generally) launch the game and load that save. Often I can’t even specify a name for my save, so I can’t mark as save as “Key Point-pick New Vegas faction.” Everything is crazy. This can have some benefits, but it takes a lot of control away. Since the game developer is rolling everything from scratch, every litle feature, like selecting where to put my save, is additional complexity, additional chances for bugs, additional possibilities to get reviews complaining about how it is to use.

    Now, there are applications that take the same route as games. Music management software springs to mind, especially iTunes. And I know a number of people who loathe iTunes because they lose control of how their music files is organized.

    Maybe games should start using the standard loading and saving interfaces. A developer can set the icons to be screenshots easily enough on Windows and I believe it’s not too hard on Linux and Mac OS X. The timestamp can be the timestamp. The remaining information, save number, chapter/location, can go in the filename. Now, I can delete old saves with a non-crap interface. (I have spent so much time fighting Bethesda’s file interfaces.) I can load an old save and the game simultaneously. I can give useful filenames to important saves. And I can put my files wherever I like! The developer gets all of the benefits of a powerful, heavily debugged interface that is familiar to most users.

    On the down side, this is certainly more complexity for the user. For people who don’t keep a lot of saves, it may be annoying to be bothered with the relatively complex file selection interface. (On the up side, “just hit OK” will be the right answer for most people.) The other challenge is that presenting the standard file chooser interface may not work well in a full-screen 3d-accelerated game. My knowlege is rusty, but last I knew the standard Windows controls didn’t play well with full-screen 3d accelerated applications.

  52. Ranneko says:

    God no, Saves are user data, they should go in the user’s home folder (ideally all in the same kind of place, but there is too much history and changing standards to keep that).

    The user directory is:
    1) Always writeable by the user
    2) Easily backed up

    I am pretty sure most of my games do this, I have hundreds of games installed and even freaking Zombie Shooter knows to save to somewhere in my user folder.

    Sure, the Blackwell games have their saves in User\myUser\Saved Games and Zombie Shooter places them in User\myUser\Documents and minecraft hides them in \User\Appdata\Roaming\.minecraft

    Windows has a variety of environment variables to ensure that you are consistent even if the user has set non-standard locations for these things:
    http://best-windows.vlaurie.com/environment-variables.html
    http://technet.microsoft.com/en-us/library/dd560744%28v=WS.10%29.aspx

    The same concept applies for OSX and Linux. User data goes in the user directory unless there are good reasons for overriding (which should generally be initiated by the user).

    This has an added bonus of allowing multiple users to have their own saves AND settings with a single install of the game. Especially good if you like inverted and other people who play games on your computer don’t.

  53. D-Frame says:

    I just hate it when games put their stuff anywhere other than into their own directories, so my vote is pro-CWD.

  54. Asimech says:

    Is it possible, without being a huge hassle, to check if the game folder is in Program Files (or that the user just doesn’t have the rights to access the CWD) to then put save files in users\Bob\savegames\
    and if it’s not then in CWD?

    Alternatively default the save location as C:\games\ or something and give an error if they try to install to Program Files.

    On Linux/Mac always putting save files into home directory might be the safest bet. ~/.foo-gamedata/ or whatever.

  55. Ardis Meade says:

    Shamus
    Shame
    Sha-moose
    Bubala
    Come schmooze me. Now, we love what you been doing on Good Robot and we are fully committed to giving everything you need to make this game all it could be. However, Black Friday is in two days and we need this on the shelves. So, wrap it up. We ship tomorrow.
    Aren’t you glad you’re an indie?

  56. JAmes says:

    Store it as a blob of encoded data in the Registry.

    • Roxor says:

      Please don’t. System Protocol One does that, and it makes it virtually impossible to back up your saved game. I lost my last one because I forgot it did that and I thought I was backing up everything when I made copies of C:\Users and D:\Games and didn’t remember it used the registry for saved games.

      Seriously, what kind of idiot programmer do you have to be to put saved games somewhere that inconvenient? The average Joe doesn’t know how to use Regedit, and every time I do use it, I’m a nervous wreck about double-checking I’m changing the right values and desperately hoping I don’t break something and have to reinstall Windows again.

  57. Neil Roy says:

    In my own game, I have it default to being installed in the user directory. This has an environment variable %USERPROFILE% which works under all Windows since XP. I install the game by default into that directory in a subdirectory for the game. This is in the installation program script and the user can then change where it is installed if they wish. I used to save my game settings and saved games etc into %APPDATA% which is also the same under all Windows since XP, but that is a hidden folder. I got tired of trying to explain where this was as well as other issues.

    I finally settled on having the game install by deafult into the %USERPROFILE% folder, and save all settings and such into the same folder that the game is in. This was the game can be installed onto a USB thumbdrive and carried with you, plugged into any computer and played. To date I have had zero complaints about this set up. I have a note in the documentation and troubleshooting text I provide with my game to make sure you install it into a folder that the game can write in. the C: drive itself is okay, so has the %USERPROFILE%, so those are the recommended locations and most people will stick with the default. I could care less where Microsoft wants it put. As far as I am concerned, My Documents sounds like a location for… well.. DOCUMENTS! You know, text files, PDFs etc… makes zero sense to put save games in them.

    I wouldn’t stress over the one in a million chance someone will have some screwy setup. If they do, they can re-install into a folder where the game CAN write, this is something that is done at install time by the installation program. Works for me anyhow.

    • Neil Roy says:

      OH! There is one additional problem with making your game portable. If you want a Linux version, where the game is installed and can save games DOES matter much more. A reason why my game is still Windows only. ;)

      • Neil Roy says:

        Oh yes, if you’re planning on selling this, I’m not sure how much $$$ you plan to make off of Linux users who like to get everything for free and like to have the source code for most things they download. Maybe this has changed and there is a market, but there is a reason you don’t see many commercial games available for Linux.

  58. WJS says:

    For the love of god, why would anyone ever assume that you must have write access to where you’re running from? You only need rx to run, and this is the case on Windows, Linux and Mac.

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *

*
*

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>