Question Can end users specify where to save games' data?

This freeware Unity Engine game, for example, saves its Windows data at:

1. %USERPROFILE%\AppData\LocalLow\Turbo Chimp
2. %USERPROFILE%\Documents\Turbo Chimp
3. The registry key HKCU\SOFTWARE\Turbo Chimp

I realize at they very least the first of which is a default. But for the game's end users are there any general Unity command line parameters that might allow specifying different paths (e.g. thegame.exe -save_path=c:\games) or allow to use a file like thegame.ini to specify where to save?

This would allow a portable way to play the game.

 

It depends how the game has been coded. Most games just use: https://docs.unity3d.com/ScriptReference/Application-persistentDataPath.html

If a game hasn't been coded to be portable, then no. Not say you can't mod a game to make it possible, but this is a dev forum and not a modding forum.

 

Since this game is a freeware, you can install it and see its files. Obviously it's not just your link because of 2).
Anyway, this game is just an example. I don't want to mod it, but just to know if Unity allows end users to tweak games' paths in general.

For comparison, Adventure Game Studio allows it regardless of what the game developers coded (one just has to get a file called acwin.exe from AGS' own website, put it in the game's folder and use it to customize paths, even if the game itself included no such options).

 

The reason Application.persistentDataPath exists isn't because Unity sets any specific rules, it's because various different supported platforms often set security rules on what is writable by each process, and Unity made it easy to comply with all of them with the least effort.

 

Please see my comparison to AGS. The game developers can do what they want, and yet AGS lets the end users decide what they want too.

 

Okay and? What's your point?

Unity isn't just a game engine. There's plenty of use cases were the concept of a 'save game' is irrelevant to the application being made. So Unity is a generic, generally non-specific toolset, and specific features like a save game is something the developer is expected to implement themselves. That includes where and how it's written to disk.

 

So I'll ask differently, since the posters here know Unity better than anyone, and probably know Windows too, is there a general way in Windows to intervene in what Windows sends to Unity in let's say Application-persistentDataPath?

 

No, you should ask the developer of the game to allow you to change that directory. The most you can do is to replace the path with a junction in Windows, but the game will still think it's writing into the original path.

 

Kind of. You can hook into an application's binary and override the functions to alter its behaviour, but the way to do this is a very advanced programming topic. Microsoft Research actually has a package they developed to help do this called Detours.

https://github.com/microsoft/Detours

Alternatively, if developing this is not something you're interested in, there are tools for bundling an application into a portable form complete with virtual file systems and registries.

https://en.wikipedia.org/wiki/Portable_application_creators

Here's an example of one of them that even shows how to do it for Unity applications.

https://www.boxedapp.com/
https://www.boxedapp.com/boxedapppacker/usecases/pack_unity_app_into_single_exe.html

 

If it used something an environmental variable like %AppData% you could have just started the game with a simple script of:

set AppData=c:\games

game.exe

In this case there are no environmental variables (except I guess %USERPROFILE% as the root of the required folders), but still I wonder if there's something similar to this script.

Note creators like PortableApps don't attempt tricks like this. They just stay in the background, wait till the app is exited and then clean up its mess. And prior to opening the app, they copy its data into the relevant folders. So overall lots of copying and deleting except using a bypass script like above.

 

They're able to do that because they're the author of the app. Tools like the ones I mentioned earlier allow anyone to make an app portable.

Edit: Thinking on it a bit more I would actually consider the method you describe to be much more of a trick as the one that companies like BoxedApp use (ie virtual file system that is stored in memory that BoxedApp modifies the app to use) means the app never touches the real file system and therefore never runs the risk of contamination.

Essentially the technology is identical in nature to that of a virtual machine and in fact one of the example products in that Wikipedia article is from a company that specializes in virtual machines. It's much more expensive too which doesn't surprise me in the slightest seeing who made it.

https://www.vmware.com/products/thinapp.html

I wouldn't consider anything that has to access the file system or registry to be a truly portable app. Best case even if it works flawlessly it's still leaving behind remnants of the app. For example Windows doesn't erase the contents of a file when told to delete it. It just removes it from the file table. All of that data is still there.