Has there been any contact with gog about supporting this upstream. Linux client is still under development iirc.
21 June 2016 at 21:27
Anonymous said...
I'm one of the maintainers of Debian's game-data-packager, and I'd be interested in adding Flatpak support to that (somehow, I haven't really worked out the structure yet). Want to join forces?
g-d-p started as a shell script to turn doom*.wad into a .deb each, and has grown into a Python 3 script able to turn various games' multi-file trees of proprietary data into .deb, RPM or Arch Linux packages. The primary focus is on games with Free engines, but we also support a few games with proprietary Linux binaries (Unreal, Quake 4, ETQW; also 95% of Unreal Tournament, but we abandoned that one when it became clear that it had unfixed network security vulnerabilities *and* bundled a sound library that no longer works with modern Linux).
Differences between g-d-p and your script:
* implementation language * uses packaged Free engines where possible (ioquake3, chocolate-doom, ScummVM etc.) - I'm not quite sure yet how that works in a Flatpak world: I could imagine ScummVM being a specialized runtime? * (mostly-)declarative data file per game, with hashes of known-good versions (you're very welcome to recycle these for your script of course) * understands (some) patches and tries to only package the latest version, which isn't so interesting for the monolithic installers from gog.com but makes a lot of sense for e.g. the Quake series
@MrMcQ2u: There hasn't been contact with GOG yet, but there are a couple of things we need to implement before it's a viable option for them, such as joystick/joypad support. Having it pre-installed in their target distributions might also be necessary...
@smvc: I don't see a lot of overlap between flatpak-games and game-data-packager. We only process installers from commercial games, where ScummVM, DOSBox are built into the package so that there's no configuration necessary on the user side. We don't support updating engines, and the fact that you have a list of supported games means we have different goals.
In the future, I would imagine game-data-packager automatically creating Flatpaks, rather than debs.
For some types of game data, engines that gnome-games will support such as ScummVM or NeoGeo ROMs, we might be able to avoid packaging the whole game, and just nab the "data" files.
As for the Unreal Tournament, you could now create a Flatpak with networking disabled :)
22 June 2016 at 10:17
[Image]
Early bird gets eaten by the Nyarlathotep
The more adventurous of you can use those (designed as embeddable) Lua scripts to transform your DRM-free GOG.com downloads into Flatpaks.
The long-term goal would obviously be for this not to be needed, and for online games stores to ship ".flatpak" files, with metadata so we know what things are in GNOME Software, which automatically picks up the right voice/subtitle language, and presents its extra music and documents in the respective GNOME applications.
But in the meanwhile, and for the sake of the games already out there, there's flatpak-games. Note that lua-archive is still fiddly.
Support for a few Humble Bundle formats (some formats already are), grab-all RPMs and Debs, and those old Loki games is also planned.
It's late here, I'll be off to do some testing I think :)
PS: Even though I have enough programs that would fail to create bundles in my personal collection to accept "game donations", I'm still looking for original copies of Loki games. Drop me a message if you can spare one!
"AAA game, indie game, card-board-box"
4 Comments -
Has there been any contact with gog about supporting this upstream. Linux client is still under development iirc.
21 June 2016 at 21:27
I'm one of the maintainers of Debian's game-data-packager, and I'd be interested in adding Flatpak support to that (somehow, I haven't really worked out the structure yet). Want to join forces?
g-d-p started as a shell script to turn doom*.wad into a .deb each, and has grown into a Python 3 script able to turn various games' multi-file trees of proprietary data into .deb, RPM or Arch Linux packages. The primary focus is on games with Free engines, but we also support a few games with proprietary Linux binaries (Unreal, Quake 4, ETQW; also 95% of Unreal Tournament, but we abandoned that one when it became clear that it had unfixed network security vulnerabilities *and* bundled a sound library that no longer works with modern Linux).
Differences between g-d-p and your script:
* implementation language
* uses packaged Free engines where possible (ioquake3, chocolate-doom, ScummVM etc.)
- I'm not quite sure yet how that works in a Flatpak world: I could imagine ScummVM
being a specialized runtime?
* (mostly-)declarative data file per game, with hashes of known-good versions
(you're very welcome to recycle these for your script of course)
* understands (some) patches and tries to only package the latest version, which isn't so interesting for the monolithic installers from gog.com but makes a lot of sense for e.g. the Quake series
21 June 2016 at 22:14
@MrMcQ2u: There hasn't been contact with GOG yet, but there are a couple of things we need to implement before it's a viable option for them, such as joystick/joypad support. Having it pre-installed in their target distributions might also be necessary...
22 June 2016 at 09:49
@smvc: I don't see a lot of overlap between flatpak-games and game-data-packager. We only process installers from commercial games, where ScummVM, DOSBox are built into the package so that there's no configuration necessary on the user side. We don't support updating engines, and the fact that you have a list of supported games means we have different goals.
In the future, I would imagine game-data-packager automatically creating Flatpaks, rather than debs.
For some types of game data, engines that gnome-games will support such as ScummVM or NeoGeo ROMs, we might be able to avoid packaging the whole game, and just nab the "data" files.
As for the Unreal Tournament, you could now create a Flatpak with networking disabled :)
22 June 2016 at 10:17