Screenshot

I really just hacked this together today after work, so yeah... it's simplistic, mostly untested and really, really ugly.

But I just thought I'd post it anyway, for no particular reason. It works for me, that's about as much as I can tell you about the quality. I'll try to clean up the code a bit after work tomorrow so I can post it on GitHub.

The logic behind it is really quite simple: This little app scans the registry for installed GOG games.
You can launch them from here, but that's not the interesting part:
If a savepath is specified by the game (which is the case for roughly one out of four GOG games), you can (after specifying a common sync folder inside your Dropbox, GoogleDrive, Box or whatever folder) move the savegame-folder to your common sync folder with a single click, replacing the original folder with a SymLink. (You can also move everything back with one more click). Dropbox (or whatever) will then sync your savegames. Repeat the procedure on any other machine and you've got a working cloud-sync setup.

The applications needs admin access because Symlinks can't be created by users. Windows 8.1 was tested, 8 should work and 7 might.

THERE'S ABSOLUTELY NO WARRANTY. TRY AT YOUR OWN RISK.
http://www.tapper-ware.net/data/devel/applications/GOGCloudSync/GOGCloud.zip

I'll post the code and more info tomorrow. It's not glamorous, but it works.

If this is alpha I wonder what features will be added to beta. Maybe save sharing in the forums? :) Release 1.0 should be galaxy compatible ;)

Take note GOG and hire him for Galaxy!

nice job but I'll pass. cloud saving means you need to have access to internet to be able to access your saves (unless it local.copies), and does anyone really realise trusting your data with a third party is that safe? ( yes i know its game data but still)..don't understand why people blindly go cloud......

Just in case your physical computer blows up... :P

GOG is looking for sub-contractors, so hansschmucker might consider emailing them.

not if it is done properly, i.e. it syncs the file save locations to the cloud.

The files are still on your local HD.. the program just moves them around to a location that is managed by a service like Dropbox, which then has to perform the actual syncing.

About Galaxy...I really would have done this ages ago, but I always thought "why bother, Galaxy is just around the corner anyway", but after seeing how limited the test was it seems that another way to sync might still be useful for some time.

But in any case, this is a program for personal use. which means I can get away with a lot of dirty hacks, subpar code quality, insecure behavior and limited compatibility, as well as relying on a third-party service to do the actual sync. Developing it into something that you want to distribute commercially would really take quite a bit of effort.

Update 1 (just a quick fix during my lunch break... you can thank RemoteDesktop for that):
Change game scanning so that it doesn't crash if no game is found in the new GOG registry branch.

Just to get it out of the way: Source is now online at
https://github.com/hansschmucker/GOGCloudSync
and license has been changed to AGPL 3.0

+1 for sharing this and especially the source. Would love to take a look and maybe contribute, I really don't have the time for it. But I think there are quite some developers here that might be interested in turning this into something bigger.

I've got some spare time tonight, so I'll be doing a UI for merge-conflicts next. Everything else is up for grabs. My personal wishlist so far consists of

* Better sync-conflict management (right now it just fails silently, except for a return code).
* Syncing between cloud-location and directories that cannot be symlinked .
* Timer-based syncing for these
* Keeping track when an application launches/closes to determine sync time for these cases.
* Database for games that don't have a savegame-location defined by GOG.
* Filter-based copying for savegames that are not in dedicated directories.

This should be merged into GOG Galaxy!

Comes in handy when your disk drive explodes

It probably shouldn't, since the code quality is really low, but since I'm starting to get to the interesting stuff, it might provide a few pointers.

For example:
How should sync-settings themselves be synchronized? If somebody enables sync on one end, should the other clients assume the same setting? Or should sync-settings remain local, so a user can have (for example) two syncing and one non-syncing client?

If sync-settings are stored locally, is it better to store them in a portable fashion or in a central location?

That kind of stuff needs to be figured out. So far I'm thinking local sync settings in the application directory. While this makes correct interaction with UAC impossible, it IS a lot more transparent to the user than some registry setting.