[Bug 185211] Review Request: prboom - GPL doom game engine

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: prboom - GPL doom game engine


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185211





------- Additional Comments From wart at kobold.org  2006-03-13 03:03 EST -------
(In reply to comment #2)
[...]

> MUST-FIX
> ========
> * Building gives a number of "integer <-> pointer of different size cast"
>   warnings these are _BAD_ on x86_64. I'll attach a patch fixing these.
>   One of these is a real bu, the others were ok.

Thanks for catching this.  It would be nice if there were a flag for gcc that
would treat these "integer <-> pointer" warnings as errors, esp. on x86_64.

> * %{_datadir}/prboom is not owned by the package
> * why the %dir %{_datadir}/games/doom ?

%{_datadir}/games/doom was supposed to be %{_datadir}/prboom.  My bad.  I've
uploaded a new .spec with this fix.

> About provide / req doom-game/-engine and Desktop files
> =======================================================
> I've been thinking about this and initially I came up with the following:
[...]
> But this is /becomes a mess so I suggest instead:
> -doom-engines provide dataname-engine for all datasets they support

I'm not too keen on this because it means that every time a new iwad becomes
available, the game engine package must be updated to signal that it can run it.
 The game engine package should not have to know about all of the possible
dataname packages that it can run.

> -doom-engines require enginename-data
> -doom-data provide enginename-data for all engines they are known to work
>  with
> -doom-data requires dataname-engine
> -doom-data packages include the .desktop file and icons, the .desktop
>  file invokes "dataname" wich is a wrappercript provided by the engine
>  with the correct cmdline arguments to use the relevant wad. If it is
possible>  that there are multiple providers of dataname-engine then the
alternatives
>  system will be used.

I'm starting to think that using the alternatives system for game engines might
be a little bit of overkill and introduce some unneeded complexity.  If the game
data was designed to work with a specific game engine, then the .desktop file
should reflect that.  If the game data can work with an alternate game engine,
then that's great, but the user will have to do so from the command line.

>  This way (desktop-file in data package) if people install multiple versions of
>  the data (free-doom, heretic-shareware,  doom-shareware) they get menu entries
>  for each.
> -datafiles packages are named as the game and will show up in comps for easy
>  user selection (the reqs will drag in an engine). so the free-doom data
>  package will be called just free-doom, doom-shareware-package will be called
>  doom19-shareware, etc.

+1

> I hope this makes sense and you think its a good idea :)

It seems that all of this complexity is being added (and I admit that I started
this messy discussion) only to support some level of indirection in the .desktop
file.  There are really only two simple requirements that I feel we must satisfy:

1) Each iwad has a usable .desktop entry so it can be run from the menu

2) Additional game engines can be installed to run the games

If we don't try to mix these requirements (don't allow alternate game engines in
the .desktop files) then it becomes much simpler and can be satisfied by a
subset of your suggestion.

Each game data package Requires: <enginname>, even if it is known to work with
others.  That game engine is hardcoded in the .desktop file and will be used
when the game is launched from the menu.  This ensures that users can 'yum
install <gamedata>' and end up with the data, game engine, and a usable .desktop
icon.

Game data Provides: <enginename>-data for each engine that it is known to work
with.  Each game engine Requires: <enginename>-data so that when the engine is
installed, it will pull in the data that can be played with the game.  However,
if the game data package Requires: a different enginename, then you might end up
with a situation where "yum install engine2" results in the installation of
engine2, game-data1, and engine1.  It's a little odd this way, but it does
ensure that both 'yum install enginename' and 'yum install dataname' still end
up with working .desktop icons.

Alternately, we can try to relax the "game engine requires game data" packaging
requirement for game engines like prboom that are designed to work with multiple
game data packages.  There are really two classes of game engines.  The first
class of game engine is very self-contained, such as 'tong'.  In this class of
game engine, the game data is just 'skin', such as images and sound.  The
purpose of splitting the game data from the game engine in this case is to
minimize the download size of package updates, not to provide alternate skins
for the game. While alternate skins could be made available, it is unlikely to
occur.  Such game engines should require game data in order to be played.

The second class of game engine are more 'game interpreters' like prboom, for
which the game data packages provide a new game experience with new game logic.
 For example, 'freedoom' is more than a cosmetic change from the shareware doom
game.  Such engines should not have to require game data files, since the data
files contain a large portion of the game logic.  In this case, the game data is
more than just skin, and it is expected that alternate game data packages will
be available.  They should only require that such data files exist and are
available through the packaging system.

I apologize if this sounds like rambling.  I'll try to clarify anything if I've
muddied it up too much.  :)


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.