Make the Game Dual-Boot/etc Friendly

[limith]

I like how some indie games are dual/triple/etc boot friendly and store save games in the installation location and do not require a re-installation from the separate booting OS in order to play. If it is possible, I would like PE to be able to run without having to re-run the entire installer which adds stuff to the registry so the .exe doesn't throw some error about the game not being installed.

Edited November 30, 2012 by limith

[AwesomeOcelot]

Not having to use the registry as a requirement (while still using it for convenience and OS integration) and keeping all paths configurable using ini files can save headaches down the road.

[anek]

What's the point? It would only work if you dual-boot multiple identical or very similar operating systems for which the installed files would be exactly the same (there's a reason applications have installers - they can install different things and install them in different ways for different systems, like say Windows XP vs. Windows 8 ). And even in the particular use-case of having a dual-boot setup with multiple quasi-identical systems, all your idea would save is a few minutes of time of performing a one-time installation.

 

I don't think that's worth making any compromises with potentially negative side-effects for...

 

store save games in the installation location

 

Storing save-games (or INI files or any other user-specific data, for that matter) in the application directory itself is a bad idea. It makes the application directory more messy, makes it more difficult to re-install the application, makes it more difficult to migrate the user-specific data to another PC or to make a backup of it, makes it impossible to use the same application installation from different user accounts without affecting each other, makes it impossible to maintain a proper filesystem security scheme, ...

 

It's the old-fashioned Windows way of doing things - Mac and Linux have moved away from this long ago, and Windows is now also slowly following (since Windows 7).

 

I think PE should follow the official Linux way of organizing application-related files, in order to keep things clean, neatly separated, and secure:

• The application is installed into a directory on the system drive (like "C:\Programs\<application>") to which only the Administrator has write access, but every user has read access. The installed files are never modified in any way when the application is used - the only scenario in which they change is if the Administrator installs a patch or new version or uninstalls it altogether.
  

• When the application is run from a user account from which it hasn't been run before, it automatically creates a set configuration files and a save-game folder, mod folder, etc., inside a directory to which this user account has exclusive read and write access (like "C:\Users\<username>\Application Data"). From then on it uses those files whenever it is run from this user account.
  In fact, under Linux those user-specific application files are further separated into two directories:
  
  • One for machine-specific settings, like INI files that specify the screen resolution, sound volume, ... - i.e. things which you will probably set to a different value for each PC/laptop/tablet on which you install the application.
    
  • One for all machine-independent data, like save-games, installed mods, INI files that specify game difficulty options, ... - i.e. things which you may want to sync between your PC and your laptop/tablet, so that you can continue playing on the train where you left off at home.
    

The advantages should be apparent.

Edited November 30, 2012 by anek

[limith]

What's the point? It would only work if you dual-boot multiple identical or very similar operating systems for which the installed files would be exactly the same (there's a reason applications have installers - they can install different things and install them in different ways for different systems, like say Windows XP vs. Windows 8 ). And even in the particular use-case of having a dual-boot setup with multiple quasi-identical systems, all your idea would save is a few minutes of time of performing a one-time installation.

 

I don't think that's worth making any compromises with potentially negative side-effects for...

 

store save games in the installation location

 

Storing save-games (or INI files or any other user-specific data, for that matter) in the application directory itself is a bad idea. It makes the application directory more messy, makes it more difficult to re-install the application, makes it more difficult to migrate the user-specific data to another PC or to make a backup of it, makes it impossible to use the same application installation from different user accounts without affecting each other, makes it impossible to maintain a proper filesystem security scheme, ...

 

It's the old-fashioned Windows way of doing things - Mac and Linux have moved away from this long ago, and Windows is now also slowly following (since Windows 7).

 

I think PE should follow the official Linux way of organizing application-related files, in order to keep things clean, neatly separated, and secure:

• The application is installed into a directory on the system drive (like "C:\Programs\<application>") to which only the Administrator has write access, but every user has read access. The installed files are never modified in any way when the application is used - the only scenario in which they change is if the Administrator installs a patch or new version or uninstalls it altogether.
  

• When the application is run from a user account from which it hasn't been run before, it automatically creates a set configuration files and a save-game folder, mod folder, etc., inside a directory to which this user account has exclusive read and write access (like "C:\Users\<username>\Application Data"). From then on it uses those files whenever it is run from this user account.
  In fact, under Linux those user-specific application files are further separated into two directories:
  
  • One for machine-specific settings, like INI files that specify the screen resolution, sound volume, ... - i.e. things which you will probably set to a different value for each PC/laptop/tablet on which you install the application.
    
  • One for all machine-independent data, like save-games, installed mods, INI files that specify game difficulty options, ... - i.e. things which you may want to sync between your PC and your laptop/tablet, so that you can continue playing on the train where you left off at home.
    

The advantages should be apparent.

 

Hiding savegames in obscure locations which require changing folder options to show hidden files and going to C:/Users/<USER NAME>/AppData/ and then looking between Local/Romaing/LocalLow or a variety of other locations is bad and not an advantage at all. Keeping save games in the installation itself should be an option in the installation (Wesnoth and Recettear have this for example).

 

What you described isn't the "Linux way" of doing things, its the way of old fashioned annoying Windows games. A MINORITY of windows games support dual-booting/running the exe in any remotely portable way. Supporting Dual Booting is also good for portable gameplay, for example if PE was installed to an external harddrive, one could pull it off and play it on a variety of different computers (assuming same OS ofc). Quite a few programs that run or are distributed on Linux in fact do not have mandatory installers at all and are simple archives.

 

I don't understand what you mean by what's the point. There would still be an installer to unpack the game, all I am saying is to make it so that the game (the executable) once installed doesn't require me to re-install it on another OS just so the game installation is put into the registry. It's not insanely hard to put an .ini for pathing.

Edited December 1, 2012 by limith

[Bartimaeus]

I've always hated how some programs store settings/saves/other data somewhere in the (User)\ directory. Since firstly, I do not use the (User)\ folder for anything at all, and secondly, I have two partitions - one for games/files, one for Windows - when I reformat, that stuff always gets stinking deleted, because I assume that it's smart and is self-contained. Storing it in the game directory is infinitely preferable, (a la Baldur's Gate). In addition, I don't really care for having backups of the game's CDs on my hard-drive, and then having a backup of what the game directory should actually be after installing, (because when you reinstall, all the settings are messed up, patches aren't applied, etc.). So yeah, I agree with the OP on both points.

Edited December 2, 2012 by Bartimaeus

[Archmage Silver]

I like how some indie games are dual/triple/etc boot friendly and store save games in the installation location and do not require a re-installation from the separate booting OS in order to play. If it is possible, I would like PE to be able to run without having to re-run the entire installer which adds stuff to the registry so the .exe doesn't throw some error about the game not being installed.

This isn't some indie game, and that kind of support would just consume development resources unnecessarily.

[AwesomeOcelot]

I like how some indie games are dual/triple/etc boot friendly and store save games in the installation location and do not require a re-installation from the separate booting OS in order to play. If it is possible, I would like PE to be able to run without having to re-run the entire installer which adds stuff to the registry so the .exe doesn't throw some error about the game not being installed.

This isn't some indie game, and that kind of support would just consume development resources unnecessarily.

 

It wouldn't consume much development resources if they were using their own engine. I've got a few Unity games and it installs a bunch of stuff in the user folders and registry, so it's unlikely this feature would be possible on Windows.

[mstark]

Windows using C:/Users/<USER NAME>/AppData/ as the save game folder is a security measure, and not one that'll be easy to side step for the developers, I believe. Windows 8 (and to an extent 7, AFAIK) doesn't allow programs write permissions to the C:/Program Files folder as it's a huge security risk (creating some strange issues for playing old games like Baldur's Gate on it, since it can randomly migrate all the save files from the default save folder to AppData, breaking your save games, you will then have to move them back manually and give the game correct permissions with an Admin account).

 

While not friendly to the average user, since there's no clear information about where your files are stored, keeping the files separate from the installation folder is a huge benefit, as outlined by anek.

Edited December 3, 2012 by mstark

[anek]

Hiding savegames in obscure locations which require changing folder options to show hidden files and going to C:/Users/<USER NAME>/AppData/ and then looking between Local/Romaing/LocalLow or a variety of other locations is bad

 

"C:/Users/<USER NAME>/AppData/" is not fundamentally more hidden then "C:/Programs/". Both are places that newbies will not dare to browse by themselves (they tend to stick with "Desktop" and "My Documents/Pictures"), and hence users have to be told about the folder's location in the manual if they are looking for save games and INI files.

 

And once a user knows where to find them, there's not really a difference. If you need to access the save-game folder often (which shouldn't be the case), you can create a Desktop shortcut or something.

 

The fact is that these are the paths which Microsoft has chosen for these purposes, if you don't like them complain there or switch to another operating system that has chosen more accessible paths. I for one don't think they're that bad.

 

What you described isn't the "Linux way" of doing things, its the way of old fashioned annoying Windows games.

 

Uhm, no, the opposite. Old fashioned Windows games write lots of stuff into their application directory, so if you've had it installed for a long time and played and tweaked it often / installed some mods / etc., it was not uncommon to reach a point where the installation was screwed up beyond recognition and in order to fix it one would have to throw it all out and re-install the game from scratch.

 

Keeping the program directory immutable, means you never have to re-install it. Worst case scenario, you'd have to delete the user-specific INI and mod directory in "C:/Users/<USER NAME>/AppData/" to return to the post-installation state.

 

In addition, I don't really care for having backups of the game's CDs on my hard-drive, and then having a backup of what the game directory should actually be after installing

 

But this is exactly what the proper Linux-like separation of files would avoid!

If save games and settings and mods and everything is written directly into the installation directory, you'll have to backup this whole directory (many GB) in addition to the original installer (also some GB).

 

If the files are separated like I described, you only need to backup either the original installer or the installation in "C:/Programs/" (which never changes after installation), plus the user-specific files in "C:/Users/<USER NAME>/AppData/" (likely only a few MB).

 

There would still be an installer to unpack the game, all I am saying is to make it so that the game (the executable) once installed doesn't require me to re-install it on another OS just so the game installation is put into the registry. It's not insanely hard to put an .ini for pathing.

 

But you're assuming that just unpacking is all the PE installer will do, so the resulting installation would be identical for every windows version. I'm not so sure this is a valid assumption. Windows XP and Windows 8 are very different systems, the Obsidian developers may not want to limit themselves to the lowest common denominator. The installer could unpack different executables for each of them, or at least set different registry options depending on the system. Moving registry options into INI files would not change this.

 

Keeping save games in the installation itself should be an option in the installation (Wesnoth and Recettear have this for example).

 

It could be an option. I still think that your particular use-case (dual-boot installation sharing) is not mainstream enough to warrant any special attention, but it could be useful for portable USB stick installations.

However, it should only be implemented if it doesn't require any considerable development effort, and it should definitely not be the default for normal installations.

[anek]

While not friendly to the average user, since there's no clear information about where your files are stored

 

It's only confusing because users coming from older Windows versions are not used to it, and some programs have already switched to this scheme while others haven't yet.

 

In Windows 8 and beyond, it seems this will be the standard (and possibly only supported) way how it's done though, so future Windows users will learn to look for user-specific application data in "C:/Users/<USER NAME>/AppData/" from the start, so it will not be confusing to them. To them, "C:/Programs" will seem mysterious and something to be never touched.

[AwesomeOcelot]

While not friendly to the average user, since there's no clear information about where your files are stored

 

It's only confusing because users coming from older Windows versions are not used to it, and some programs have already switched to this scheme while others haven't yet.

 

In Windows 8 and beyond, it seems this will be the standard (and possibly only supported) way how it's done though, so future Windows users will learn to look for user-specific application data in "C:/Users/<USER NAME>/AppData/" from the start, so it will not be confusing to them. To them, "C:/Programs" will seem mysterious and something to be never touched.

 

This was the case with 2000 and XP. Vista/7 added an extra layer of Roaming/Local/LocalLow. It is a bit of a mess and a complete pain in the arse to do anything with, it's very much like how linux distributions do things with there /home/[username]/.settings directory. Also use %appdata% to navigate to the [C/D/F/G]:\Users\[username]\AppData\Roaming or [C/D/F/G]:\Documents and Settings\[username]\Application Data. As long as they allow me to change the directories used if I need to with an ini file located where the game exe is located I'm good.

[anek]

This was the case with 2000 and XP.

 

The corresponding folder was available, but the proper separation of files was not enforced in any way and thus not done consistently by different programs (and not at all by many older programs).

 

Vista/7 added an extra layer of Roaming/Local/LocalLow.

 

There is a good reason behind this, see my first post in this thread.

Not the separate LocalLow folder, that's just lazy design not to mention bad naming. But the Local vs. Roaming distinction, that is indeed sensible.

 

It is a bit of a mess and a complete pain in the arse to do anything with, it's very much like how linux distributions do things with there /home/[username]/.settings directory.

 

Yes, and on Linux it's not a pain in the arse at all. The reason is that the principle itself, of separating the files like this, is neither obscure nor complicated to learn/understand. It's logical and practical.

 

It's just that Windows Explorer (and the "open/save file" dialog on Windows) makes it unnecessarily difficult to access those locations. The starting location for file browsing on Windows is, depending on how you browse, either Desktop, or My Documents, or that "Documents library" thing that adds another virtual layer on top of the folder structure. From none of those starting points is there a really quick way to get to C:\Users\<USER NAME>\AppData\, plus as someone has mentioned some version of Windows have these files hidden by default and require you to change folder options to see them (although, I think, that is also true for the contents of C:\Programs\).

 

On Linux, the starting point for file browsing is /home/<USER NAME>/, and the folders for user-specific application data are right there inside that folder (e.g. /home/<USER NAME>/.config/, and /home/<USER NAME>/.local/). Their names start with a dot, thus most Linux file managers will hide them by default, but make it easy (like 2 clicks) to switch between showing and hiding them. Getting to things like save-games and INI files is quite convenient this way.

 

The usability limitations of Windows Explorer should not be mistaken for disadvantages of the general principle of separating application data in this way.

And Microsoft happens to have chosen C:\Users\<USER NAME>\AppData\ as the location to be used for separating out user-specific application data, so app developers should simply use this location. I've seen some Windows games do the separation, but put the user-specific files like save-games in My Documents\<GAME NAME>\ instead, so users would find them more easily. I think this is a bad idea. If it's too difficult to get to the location that Microsoft has chosen for those files, that should be fixed in Windows Explorer itself.

 

In the meantime, Windows users can manually create a pair of shortcuts in the Start Menu (or Desktop or Documents folder or wherever is convenient), e.g. in the case of Vista/7:

My Application Data ---> C:\Users\<USER NAME>\AppData\Roaming

My Application Data (machine-specific) ---> C:\Users\<USER NAME>\AppData\Local

[SGray]

In the meantime, Windows users can manually create a pair of shortcuts in the Start Menu (or Desktop or Documents folder or wherever is convenient), e.g. in the case of Vista/7:

My Application Data ---> C:\Users\<USER NAME>\AppData\Roaming

My Application Data (machine-specific) ---> C:\Users\<USER NAME>\AppData\Local

All described above concept is good, reasoned architecture-wise and so on. But first thing: in Windows it's still inconvenient to have game files split and more so - part of them on system drive. Generally dislike many games intent to write something on system drive (unregarding installation folder) even if it's totally unnecessary (sometimes - lazy programming, left default "c:\<target dir>" path instead of relative references, sometimes - relying on system paths). Specifically that thing caused many annoying bugs in older games, btw.

Next thing - what if I wish to install the game on flash drive and transfer it with all my progress between say PC and notebook? How many actions should I perform to achieve this if game files are split? (even considering writing batch or bash script - you had to run it before plugging out the drive)

 

The best decision imo - proposed above clearly named config file in game directory with all paths editable. And doubt that there would be much external libs that are unavoidable required to be deployed on system drive (for Windows installation).

The sole three reasons I see for a game to enforce tangling with system drive, constant absolute paths or to use registry are:

1. Re-use of that files by other programs (totally not our case)

2. DRM protection (not our case also)

3. Ease of patching. That thing is reasonable enough, but if there are plenty of patches intended - some patcher launched from game dir could be created. If there is smaller amount of patches - it isn't much of a hassle to ask the user for game installation dir. So it's not a must too.

 

 

Uhm, no, the opposite. Old fashioned Windows games write lots of stuff into their application directory, so if you've had it installed for a long time and played and tweaked it often / installed some mods / etc., it was not uncommon to reach a point where the installation was screwed up beyond recognition and in order to fix it one would have to throw it all out and re-install the game from scratch.

 

Keeping the program directory immutable, means you never have to re-install it. Worst case scenario, you'd have to delete the user-specific INI and mod directory in "C:/Users/<USER NAME>/AppData/" to return to the post-installation state.

...

If save games and settings and mods and everything is written directly into the installation directory, you'll have to backup this whole directory (many GB) in addition to the original installer (also some GB).

Wha?? Ever heard about sub-directories in relative paths? No one asked about dumping everything in root folder. Replace "C:/Users/<USER NAME>/AppData/" with "<game dir>/", and add user-specific folders if you wish. Everything else is absolutely similar. Mods, saves, settings - everything.

 

 

[teknoman2]

that's strange... im using windows 7 since it's launch and i had no problem with any game that saves in it's own folder (such as BG) and all new games use the "My Documents" folder to keep config and save files. i never had to search in hidden folders for hidden files to find my saves.

unless i missundertand what you guys are talking about, i dont see the issue here. unless you log into your pc as non admin user, for witch i cant really see the reason besides it being not your pc

[AwesomeOcelot]

unless you log into your pc as non admin user, for witch i cant really see the reason besides it being not your pc

 

It's way more secure if you don't log in as an admin unless you need to, OSX and Linux distros work this way, Windows has been moving in this direction, making it possible to do this without the pain of earlier versions.

[Waywocket]

Requests like the OP's are poison, and the fools that make them poisonous.

 

Any developer making a game which stores its saves - or an application that stores its settings - in the installation directory deserves to be publicly shot.

 

That is all.

 

I hope you understand the effort it took me to be this astoundingly polite; the rage this thread has induced in me makes me want to go out and eat some puppies.

[Luridis]

Applications attempting to write user specific data outside of user directories in Windows 7 fires UAC as intended. Believe me, I deal with hapless software vendors who do this sort of crap on a regular basis and it's not fun when you're trying synchronize deployment to 6,000 machines. Application vendors are supposed to expand user environment strings to store application and user data so that if something changes in a future update the action is seamless to the application.

 

Examples:

 

%APPDATA% is "C:\Documents and Settings\%USERNAME%\Application Data" on Windows XP

%APPDATA% is "C:\Users\%USERNAME%\AppData\Roaming" on Windows 7/8

 

If the vendor had hard coded the absolute path into the MSI table then the application would likely fail to install or run properly on WIndows 7.

 

This behavior is not unique to Microsoft operating systems. This is part of POSIX compliance and most *nix systems store information via relative path as well. That's why they have a dozens of symbolic links and the convoluted Filesystem Hierarchy Standard.

 

The developers don't need to cater installation to you your client, that is your job. There are tools available, might I suggest SyncToy 2.1 and/or using a virtual disk:

 

[SGray]

Applications attempting to write user specific data outside of user directories in Windows 7 fires UAC as intended. Believe me,

You have pretty strange statements here. Creating and writing files anywhere except writing to drive roots, touching system directories like "Program Files", or overwriting files belonging to other users - does not require administrative privileges, neither triggers UAC.

Your impressions could appear from dumping everything to "Program Files", but then you're doing it wrong.

 

it's not fun when you're trying synchronize deployment to 6,000 machines.

"There are tools available, might I suggest PowerShell remoting and/or using a virtual disk."

 

If the vendor had hard coded the absolute path into the MSI table

Yep, agreed, absolutely "no" to this.

 

Filesystem Hierarchy Standard

The bad thing Windows has NO such strictly defined thing considering user apps. Add to that poor architecture support for such concept. And, when so - the most convenient way to store apps and their configs could differ.

 

store information via relative path as well

Relative to what? Plea there - is for being able to choose between paths relative to game installation directory and relative to OS installation disk/variables (which in my case is reserved for persistent system apps). 10 minutes worth of coding: check if there is game dir in "Users" available, if not - check for same dir in game installation folder, if neither - ask where to create. Single check per game launch, defining directory with which the game is working further.

 

A little bit dissimilar, considering user profiles: first check for "Users\<user>\GameConfigDir" second one is for "GameDir\GameConfigDir\<user>". And that's all.

 

 

 

I hope you understand

Nope. Try to explain yourself without flaming. If you can.

 

Edited December 29, 2012 by SGray

[Luridis]

You have pretty strange statements here. Creating and writing files anywhere except writing to drive roots, touching system directories like "Program Files", or overwriting files belonging to other users - does not require administrative privileges, neither triggers UAC.

Your impressions could appear from dumping everything to "Program Files", but then you're doing it wrong.

 

That depends on your UAC settings as well as 3rd party security software. There's also defined access scopes within the registry. I've had more than enough application vendors come back and say, "Oh our app needs access to this or that directory, run it as administrator." Poor design... Additionally, putting things outside your user directory typically doesn't give other users access rights to it unless placed in "shared documents".

 

"There are tools available, might I suggest PowerShell remoting and/or using a virtual disk."

 

I'm well aware of the "tools available". I'm pretty familiar with MSI tables, VBScript, PowerShell, Python, C#, and a host of vendor scripting languages used by enterprise desktop management suites; of which I am myself a Sr. Administrator. That does not change the fact that application vendors do not follow platform guidelines and create absolutely wicked problems that *I* must sort out with one of those tools. Try dealing with services that need to be run in user space, "What do you mean the server must be logged in for it to run?" Or, applications that want to open FTP and update their program directories at run-time and don't bother to update the application shortcuts with command line options that changed in the newest version.

 

The bad thing Windows has NO such strictly defined thing considering user apps. Add to that poor architecture support for such concept. And, when so - the most convenient way to store apps and their configs could differ.

 

I didn't say Windows was any better, but the FHS is about as confusing as they come when trying to explain, "No not that bin, the other bin, and check the home directory as well."

 

Relative to what? Plea there - is for being able to choose between paths relative to game installation directory and relative to OS installation disk/variables (which in my case is reserved for persistent system apps). 10 minutes worth of coding: check if there is game dir in "Users" available, if not - check for same dir in game installation folder, if neither - ask where to create. Single check per game launch, defining directory with which the game is working further.

 

You agree with me on not hard-coding file paths in the MSI table and then not agree with the use of a relative path? Relative, as in using environment variables, not as in relative to working directory, if that's what you think I meant.

 

i.e. I meant...

 

This: %CommonProgramFiles%\AppName\SharedStuff

 

Not This: ..\Common Files\AppName\SharedStuff

Edited January 4, 2013 by Luridis

[Luridis]

BTW: My apologies to the OP... I see he meant a self-contained application directory that doesn't reference the registry, etc. What I thought he was asking for at first was multi-OS compatibility in the same directory which would be insane amounts of work. That said, I'm not sure if it's possible anyway if they lean on any run-time libraries outside of Unity itself.

[SGray]

I'm well aware of the "tools available".

I meant that suggesting to use a virtual disk is not-so-good suggestion ) Using side apps to manage game files is not much better, and totally not the best decision if that need could be avoided by design. And I've faced plenty of apps poorly designed for server use too, but PE is a game, and user-pc design is less restrictive.

 

This: %CommonProgramFiles%\AppName\SharedStuff

I meant either choice between quoted upper and "<gamedir>\SharedStuff", or ability to change variable name that path is using in some config file.

*Doubt that OP had in mind any OS other than different installations of Windows, tho. (If he is referring to .exe and registry.) And OS independent, non VM relying (like java) app is pretty unlikely - too much work, indeed.

[moridin84]

Putting the settings in the application directory is a bad idea, for the reasons explained.

 

I don't really see a problem with putting save games and such in the MyDocuments/<GameName> directory though. Plenty of games do this, including Starcraft II, The Witcher, Just Cause 2.

 

I think it makes sense to put files you want the user to access in the MyDocuments directory and stuff you don't in the AppData directory.

[SGray]

Putting the settings in the application directory is a bad idea

Can't fully agree with that, but even if so: if smth like in my previous post is implemented - how often would you want to change an inner setting of where to put other settings, saves, etc? If you don't care about that / convenient with MyDocuments - never. So it lays there as a simple static game file.

But. If you by any case (like stated in the OP or dozen others) want to change those paths - they are available to edit as simple plain text, without need to dig in game files or modify binaries. That approach helped greatly with running older games and is quite convenient to use, if those paths are available for edit.