Re: Suggestion for a new game
-----Original Message-----
From: Bruno Kleinert <fuddl@tauware.de>
To: debian-devel-games@lists.debian.org
Subject: Re: Suggestion for a new game
Date: Tue, 14 Jun 2011 11:40:09 +0200
Am Dienstag, den 14.06.2011, 10:34 +0800 schrieb Paul Wise:
> On Tue, Jun 14, 2011 at 3:18 AM, Jesse Smith wrote:
>
> > I'm pretty "live and let live" with the artwork
>
> Ok. If you have a lot of artwork or models etc, please consider
> splitting them up into separate source packages. For an example of
> such splitting done in Debian for one particular game, take a look
> here:
>
> http://packages.debian.org/search?suite=sid&keywords=openarena
>
> Watch out for duplicate files, you can save a lot of space by running
> fdupes over your artwork repository.
>
> Please note DFSG item 2 when dealing with the artwork. It is quite
> rare for the game development community to think about it
> significantly. Some guidelines:
>
> Don't put generated files in your version control repository. If they
> take a long time to render it might be appropriate to add them to the
> release tarballs though. Make sure everything can be rendered/built
> with DFSG-free tools and that one of the make targets
> clean/distclean/maintainer-clean removes any generated files, so that
> Debian can ensure that the building/rendering still works.
>
> Render text at build time or preferably at runtime (enables i18n). Use
> the system fonts. If you choose a specific font then use fontconfig to
> find it rather than bundling it with your project. If you create your
> own special font, please distribute it in source form (for example
> FontForge text format) and ensure that it can be built using free
> tools. When you enable i18n your chosen font probably won't have all
> the required characters so your text rendering system should be
> prepared to fall back on other fonts on the system.
>
> Pre-rendered images of layered raster images are not source code.
> Instead include the multi-layer raster images (Gimp/Photoshop/etc)
>
> Pre-rendered images of vector image files are not source code. Instead
> include the SVG or similar and render the images at build time or
> runtime.
>
> Pre-rendered images of 3D models are not source code. Instead include
> the models, textures etc and render the images at build time or
> runtime.
>
> Pre-encoded compressed video files are not source code. Instead
> include the models, textures etc and render them at build time or
> runtime.
>
> Pre-encoded compressed audio files are not source code. Instead
> include the tracker projects, the csound programs or whatever you used
> to generate the audio. Please ensure that it is possible to
> automatically generate the in-game audio using DFSG-free tools. With
> audio, try to keep original recordings around and apply any effects at
> build time to a copy so that the effects are easily tweakable or the
> recording easily replaceable with the same effects applied.
@pabs: Nice summary, I'd suggest to put these guidelines into the Debian
wiki if isn't already there.
@Jesse: If you find these suggestions quite picky please keep in mind
that they make packaging much easier for *EVERY* free operating system
distribution (*BSD, fedora, openSuSE, etc.), this is *NOT* limited to
Debian! ... I just wanted to add this remark ;)
Greetings - Fuddl
I agree with the general idea of breaking the data and source into two
separate packages. I've done this with a few other games to make
packaging easier. Right now though I'm a bit hesitant to do this, for a
few reasons:
1. No distributions are packaging OpenSSN yet, so users have to download
and build/install the program from source. It's much easier to do this
with one package.
2. At the moment, both source and data files are in regular flux.
Splitting the packages makes sense if they can be upgraded
independently, but right now changes are happening quickly in both.
3. The total tarball is still quite small (under 5MB).
What I'd like to do is keep everything in one package for the next
couple of releases while development is going fast and both data and
source are in flux. Then, once things become more stable, split it into
source and data packages.
Does this seem reasonable from the Debian side of things? My other
alternative right now would be to offer three packages (source, data and
combined). This would make packaging easier for the distros and still
give users one big tarball to build manually. It's a bit more work, but
I'm willing to give it a try to get OpenSSN packaged.
- Jesse
Reply to: