Standardizing various games packaging things across distros

Hans de Goede hdegoede at redhat.com
Fri May 6 06:42:44 PDT 2011


Hi,

On 05/06/2011 02:03 PM, Bas Wijnen wrote:
> Just replying to my own post with a new idea I got from myself. :-)
>
>> Your approach ... really comes down to including a tiny static library in the
>> source, and has all the problems that come with it.
> ...
>> [M]y approach is similar to using an external shared library, with all the
>> benefits that come with it.
>
> We can also use a real shared library[1]. This has several benefits and
> one major drawback:
>
> Benefits:
> - No special code is required at the start of the game.
> - Other functionality is easier to add, such as using a highscore server
> (locally or on the net).
> - Highscore parsing code is taken out of the game to a central place,
> which allows us to really close the security hole of badly written games
> (as far as high score files are concerned).
>
> Drawback:
> - The current code that has already been written by the Fedora people is
> not usable, and must be replaced by calls into the library. In fact,
> this may mean significant rewriting work for each game.
>
> The benefits are nice, but the drawback is huge. I would like to agree
> the following about games with a central highscore file:
> - New games and games for which this is initially implemented should be
> written to use the shared library.
> - Games which already use their own system should be patched using the
> method Fedory uses.
> - It is considered an improvement, but not a priority, to patch games to
> use the shared library instead of their own handling, and thus to move
> from the sgid-safe patch to the shared library patch.
>

I like +1

> I've updated the wiki page on freedesktop.org about upstream to talk
> about this: http://www.freedesktop.org/wiki/Games/Upstream
> Please feel free to change it.

Ooh you've actually started a wiki page +1 for that too :)

> The library interface I am proposing there is:
> * Get the current list of highscores.
> * Register a callback to be notified of changes to a list of highscores.
> * Unregister the callback.
> * Free the list.
> * Send a new score, which is potentially a highscore. Returns: position
> in the high score list.

Did you check if we're not re-inventing the wheel here? IOW if there not
already is some generic highscore sharing server + client-lib somewhere
already ?

Regards,

Hans


More information about the Games mailing list