> Le mardi 1 septembre 2015, 22:50:57 Markus Koschany a écrit :
Soo,
Id' like to wrap this up.
*) I'd keep the current "technical" page mostly as-is; as this is quite
usefull as development dashboard (I'll add the TODO games too).
Screenshots & long description would be dead weight here.
As it would be quite deceiptfull for user not tracking git version to see there that $game is supported;
but to realise that this game/version isn't support by their
outdated package; I'll add a link to a frozen-in-time & reproducible version at
file:///usr/share/doc/game-data-packager/list.html
the disclaimer at the top would be quite different:
- This is an automaticaly generated list of games supported by the upcoming release.
+ $wording "dpkg-parsechangelog --show-field version" on "dpkg-parsechangelog --show-field date",
+ list, for upcoming release please see http://pkg-games.alioth.debian.org/game-data/
*) As separate "marketing" page will be built, in the visual likes of
http://blends.debian.org/games/tasks/finest .
Instead of listing every single game as in the "technical" page,
games would be grouped by franchise of similare games:
- doom, doom2, final-doom, compet_n together;
but not with doom3 & doom3 bfg as they are something else
- zork games together , explaining the evolution from text games to visual ones
.... with one screenshot per game & list of engines used in the description.
This needs some new "franchise:" hint in G-D-P .yaml files. (trivial)
The description-per-franchise shared by several games
would be stored somewhere-else. The long descriptions
of one-of-a-kind games (Tyrian, ROTT) would go in the indivual
.yaml; and added to the generated .deb's too.
> > This feel like a big regression:
>
> I think the implementation details are up to you.
I've got a bad gut feeling about this.
> I could also imagine to use debconf, to ask the user a couple of questions
> and drop root privileges where appropriate. The point was that a customized
> metapackage could combine features of g-d-p with normal Debian packages,
> that are already available in the archive. It is simply another high
> level layer and
>
> apt install games-scummvm
>
> is probably easier to remember for users than a dozen g-d-p commands.
*) I don't think it's really a problem if users must endure some minor
incovenience to get non-free software running on their system;
and I prefer having separate packages that does what is says on the tin like
"geoip-database-contrib" that having a package called
"games-scummvm" that unexpectedly starts
downloading 1GB of demos/free'd full games (Dreamweb) when installed;
even when user already have the full version of these games somewhere;
but they had to specify the path by hand.
If common RaspBian users are willing to go to these step-by-step instructions guides:
http://www.instructables.com/id/PIrate-The-Secret-of-Raspberry-Island/?ALLSTEPS
http://www.codingepiphany.com/2013/06/23/running-gog-com-scummvm-games-on-raspberry-pi/
they'd find awesome if they are told that they can buy the game on their
Windows PC and run G-D-P & lgogdownloader in-host on their Raspberry
with a single command & without having to mess around with
locating files in C:\someting and moving those around with USB sticks
& editing scummvm configuration files.
> > apt-cache search <somegame> will also list game-data-packager ;
> > maybe it's more a documentation problem than a technical one.
>
> Yes, it is both a documentation and usability problem. I think a simple
> GUI would be helpful for g-d-p too.
I was thinking of starting with something a bit lame, that'd look like a 10 years-old
xcdroast with a big terminal widget.
Then I found this...[1]
[1] https://lists.debian.org/debian-devel-games/2013/05/msg00041.html
I guess it's the way to go instead of holding it back forever.
> The question is whether you want to promote the contrib games
> aspect of Debian in general (free engines but non-free data)
> or just a tool like g-d-p.
I'd prefer users using Debian-provided scummvm than
using some scummvm.exe in Wine; this way the engine
continues to get regularly updated and they get a better
overall exeperience. I want to promote the contrib games
aspects and g-d-p is a mean to achieve that goal.
> If it is just g-d-p, I would invest the time in a good man page, examples
> and a GUI and forget about the rest.
I'm not good at writing documentation; the man page can certainly be improved.
> I think it is more interesting to write documentation, articles and
> guides about the bigger picture.
Yes... but I've read this [2], and I think the "Apparently we haven't found this consensus yet." is still valid;
for me a free engine without free-data is useless in main & should go to contrib
(that includes residualvm, maybe rbdoom3bfg...)
[2] https://lists.debian.org/debian-devel-games/2014/02/msg00086.html
If we can at least come up with a basic description of the situation
that includes what is considered common knoweledge on d-d-games
and everyone agrees on that'll be a good start !
Regards,
Alexandre DetisteAttachment:
signature.asc
Description: This is a digitally signed message part.