-
Notifications
You must be signed in to change notification settings - Fork 2
Technical decisions
vangogh is build around storing installers (programs that contain all game data and perform copying of game data and related dependencies on a local machine) from GOG. This is a deliberate decision as by itself vangogh can operate completely independently without any client. You can download an installer from vangogh, run it and have the game installed. In some cases this becomes quite unpractical - consider Cyberpunk 2077 that is 28 installer files and 11 more installer files for the Phantom Liberty DLC.
As a result - theo was built around this to provide convenience. Installing Cyberpunk with DLC will take a single command (or eventually a single click/tap). The fact that vangogh uses installers however implies certain behaviours that would be worth calling out:
-
theodoesn't implement support for every compression or packaging format and relies on installers doing their jobs. As a result there's no good way to report progress of the installation.theocan report download progress, validation progress, etc - but running an installer is an atomic operation. - installers need to be downloaded and present to work, which means that disk space requirements are doubled. You need space for the installer and installation. Installers are removed upon successful installation, but must be present while installation is in progress. This applies to both native and WINE installations. Using Cyberpunk 2077 as an example you'll need >300Gb for the installation (= 110Gb for the game itself, 40Gb for the DLC and at least the same amount for the resulting installation)
- updates are achieved by installing a new version on top of the old one (not as a partial updated data), which makes the disk space problem even worse (though keep in mind that the installer will overwrite existing files, so it'll still be double requirements, not much worse)
There are few alternatives to consider to solve this better, that might be implemented later:
- use application depots that GOG Galaxy uses and transition
vangoghto use those. Considerations:- Pros: this would solve both progress and double disk space requirements. This would also be aligned with Steam depots and solving this would allow vangogh to support DRM-free Steam games (and potentially more stores, e.g. Epic)
- Cons: this would defeat independent nature of installers. Potentially this con can be solved by providing server-side ability to package depots into installers on demand. This needs to be investigated further: how to package files into installers, how to handle dependencies, how to handle installer scripts, etc - potentially the way GOG Galaxy handles depots likely provides an answer to all those questions.
- unpack installers on the
vangoghserver on demand, adding a step in the installation process. Considerations:- Pros: this would allow to continue relying on installers as the primary stored artifacts
- Cons: this adds additional storage requirements on
vangoghserver, especially if unpacked installers are not discarded right away and are cached. This doesn't solve patching unless the previous version is also available (which by default is actually true today). In that case both versions would need to be unpacked and diffed to create a patch. In general - this doesn't solve the underlying issue of unpacking installers and just pushes it to the server. While certain things might be less of a problem, e.g. disk space - others will continue to be problematic, e.g. very long time to unpack large games with no good way to report progress.
- specifically for the patches - GOG provides them in certain cases, however the way they're implemented is not great and unless something changes radically that won't be a great solution:
- Pros: updates might be easier in terms of disk space requirements
- Cons: patches are not used in 100% of situations on GOG. Sometimes there's a patch. Sometimes there's an installer update. GOG also sometimes provides several patches from different versions to another version. Patches metadata is not very formal either - it's all part of the name, which would require heuristics to find the right patch for a given version to another version as well as determining which version is the latest. And of course that would only solve updates problem, but not the others.
At the moment the first option seems the most beneficial and might get investigated in the future. One of the two must happen to allow more confidence in that path:
- depots are implemented and validated as a viable option solving known limitations and preserving
vangoghindependence fromtheo(e.g. installers or archives are still available as an option somehow - either on demand or as optionally stored) -
vangoghindependence becomes lower priority than resolving those limitations and newer features (e.g. Steam DRM-free games) combined. In this casetheowill be required to download, install games fromvangogh.