Re: Quake packaging [Re: Debian Games Team Policy]
On Fri, 27 May 2011 at 22:36:44 +0100, David Banks wrote:
> It seems from a rough survey that most engines are broadly command line
> compatible, at least far enough to get the game working consistently.
Great, then the quake-engine alternative/virtual package can be defined as
"is broadly command-line compatible with all the other Quake engines"
and you don't need a second layer of shell script.
> Side question: would you say the game should launch in fullscreen by
> default? Is it worth enforcing consistency on that?
I think first-person shooters should generally default to fullscreen, but I
don't think it's worth enforcing that - if Q1 is anything like Q3, if you
enforce it by setting cvars at the command line you'll remove users' ability
to set it in their autoexec.cfg, so overriding cvars with command-line options
should be reserved for "make it work" things like pointing to the right
location for the data.
> Should quakespasm still Provide 'quake-engine' for the moment, as
> quake-data produced by game-data-packager in unstable already contains*
> this virtual package?
IMO, Provides: quake-engine should mean "I provide the quake-engine
alternative" (so for the moment I wouldn't bother). That might mean changing
the output of game-data-packager, but we can do that - particularly if the
quake-data package contains all the necessary files to rebuild itself without
finding the CD again, like quake3-data does :-)
> In any case, I can't use the nexuiz package to run
> quake1 at this point, so I would say that is grounds to include
> darkplaces as a separate package.
One way to do that might be to have src:darkplaces build itself twice, for
darkplaces and nexuiz-engine packages, by patching the source at build time?
S
Reply to: