Bug#811133: game-data-packager: z_code.py produces packages which only support the engine installed at build-time

[Alexandre Detiste]

> Dear Maintainer,
> 
> z_code.py looks at whichever engine is available at build-time and
> hard-codes that into the resulting .desktop file. Ideally the package
> should use the zcode-interpreter alternative, although that isn't
> supported by all packages Z-Machine emulators currently, and doesn't
> work well with X- v. terminal-based interpreters.
> 
> Regards,
> 
> Stephen

Hi,

I also thik z_code module is not optimal the way it's implemented.

It would be better to have an updatable runtime shipped in
a game-data-packager .deb or a runtime-only spun-out deb
than to have z_code generate a 2-line shell script that can't be
updated without requesting user to recreate the .deb with GDP.

We then would always use entry['Terminal'] = 'false'
and have our runtime launch an xterm / konsole / ... 
if the engine needs it (which means it's not gargoyle-free)

The .desktop file would call our runtime with a --gui
option telling it the console / xterm is needed.

Otherwise (=when called from the command-line),
the runtime would launch the game in the current tty.

We could have symlinks like

/usr/games/zork1 -> /usr	/game/zgame

and zgame would know which game to run from it's arg[0].

Alexandre



I've played around something similar for DOSbox.
(and Skyroads in DOSbox works lovely on a ARM Chromebook, so even
if this was originaly i86 code, this can now be considered "all" data !)

http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/game_data_packager/games/dosbox.py

With the second half in 'runtime':
http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/runtime /dosgame.py