Re: Library/Tool database

[Steve Baker <sjbaker1@airmail.net>]

Christian Reiniger wrote:
> 
> Ok, here's a collection of the ideas concerning the library/tool database,
> plus some new things by me.
> 
> (I'm sending this to both the LGDC and PenguinPlay lists as it affects both
> projects about equally.)


I'm going to play devils' advocate here...

 
> (1) The things we have to store in the database:
> 
> ID number
> Name
> Current version
> Current version's release notes
> Date of last update
> Classification
> Homepage
> Download location [what about mirrors?]
> Short description
> Library author's comment [?]
> Supported platforms (Hw/OS combinations) [incl. comments (port status
>   etc)]
> Underlying libraries [incl. comments] User comments
> Feature list [see below]
> Links to games using it [?? Link to happypenguin ??]

Is this really worth all that effort?

Seems to me like a one line description plus a URL is all you need...and
we already have that in a dozen places.

If people are at all interested in a toolkit, let them visit the
homepage
and there they'll find all the authoritative data.

Why waste all that effort collecting, maintaining, updating a database
that
it seems to me people are only likely to visit once in a blue moon?

> (2) How the data is collected
> 
> * The library authors provide us with most of the data, both the initial
> set and successive updates when new library releases come out. Somehow in a
> happypenguin- or freshmeat-like way.

As a library author/maintainer, I have enough work just keeping and
maintaining my code and documentation - without being handed the
responsability
to keep up other people's databases.

People use sites like this one to initially find a suitable library.
Your
description simply needs to provide enough approximate information to
help people cull the list from 100 libraries down to a manageable dozen
or so. Then they need to visit the homepages for the individual packages
to get detailed information.

This isn't something one does every day - just at the start of a new
project.

Information about updates and new revisions can be found from the
mailing
list of the toolkit itself - or from existing sources like Freshmeat
(which has reported every revision of my library without me even telling
them because they have a web robot that visits my site regularly and
sees when it changes).

That's all you need.

All this other activity is just a waste of effort.  Worse still (and I
have personal experience of this) is that these grand summary sites get
bad information in them - there have been no end of occasions where I
have found sites that were completely incorrect in describing my package
and I've had to go and correct them.

There is much less chance of errors if you keep it simple and let the
user visit the true home page.  Cut out the middleman!

> * Users of the libraries are encouraged to post comments, descriptions of
> their experiences etc. If possible via some web form or automatic mail
> processing system, so that we just have to look at it from time to time to
> remove the troll entries.

This is somewhat useful - since it's a source of unbiased information
about SDK's from their users.  However, Linux Games Tome maintains such
a database - and despite over 100 users and 200 subscribers to the
mailing
list - just ONE comment on my PLIB library has ever been recorded.

The Game tome catalogs some 14 SDK's - only three are rated at all -
and they all scored 5/5. This gives you zero information about those
SDK's.

The Games on that site *do* get rated - but the ratings are a waste of
space.
My Tux_AQFH game hase a solid 5/5 rating - that's as good as Quake.
There
is no *way* my game is even close to the quality of Quake.  It's barely
even playable yet!

The problem is that people don't vote for all the games - just the ones
they really liked or which really stank. They don't vote on the basis
(specifically) of how good it is NOW, how good it would be if it were
completed, how good an implementation it is, how good a concept it is...
all that stuff.

The same will happen with SDK's people will only vote for an SDK they
used - so you never get a level playing field.

So, it *might* be possible to make this work - but a real simple "select
a rating out of 10 and leave some comments" site ain't gonna cut it I'm
afraid.
 
> * Group 2 of us (working on PenguinPlay grounds) performs specific tests on
> (some of) the libs, e.g. trying to use as many of them in a single game to
> see if any conflicts arise, taking a critical look on their compilation and
> installation behavior or using them in weird configurations.
> I don't know exactly how we'll do this - perhaps with some "Game Library of
> the Month" thing similar to the "Game Project of the Month" ??

You have time to do this!?!

That's a MAJOR undertaking.

Also, personal biases and preferences would be impossible to avoid
unless you have SEVERAL people testing each package.

I happen to like interfaces that are heavily object-oriented - but if
the reviewer of my SDK prefers a procedural style, or an autogenerated
code from a glitzy GUI tool....well, I may end up with a terrible
review.

Checking for multiple SDK's in a single game is OK for testing (say)
a sound library against a graphics library to be sure that they don't
conflict - but that's a combinatorial nightmare (there must be
a dozen sound drivers and a dozen graphics libs - someones' going to
write 144 separate programs to test all those?

Also, what about libraries that are not DESIGNED to work with other
libraries because they purport to provide a full solution. Would you
downgrade (say) the Quake graphics engine because it only works when
tightly integrated with it's own sound engine?  Tight integration
between modules might be a blessing or a curse.

There is simply no way to acquire all that information - and even
if you did write all 144 programs, who the heck will ever CARE about
the results?  If I were starting a new game development, I'd probably
just pick a graphics library that I like and a sound library that I
like and test them against each other myself.

SDK's are hugely a matter of personal preference...that's why there
are so many of them. Almost everyone who approaches the problem
decides that it's simply easier to write a new SDK than to put up
with percieved limitations of someone elses.

I'm sorry - but I just don't think this is at all productive.

I think we have enough SDK's - we need people to write good games.
Quit talking about it, preparing to do it, thinking about how to
build a web site to tell other people to prepare to think about
doing it.

Just do it!  Write great games.  Everything you need to do that
is here -- a dozen times over.

Linux *desperately* needs *good* games.  The whole future of the
OS depends on it.  If I see another Tetris clone I'll scream.
There are 64 tetris clones for Linux.

It's not even that hard to do.

My kid had a great strategy game idea last night. After about
20 hours of work, it's nearly finished.  It has GUI, sound,
3D graphics, joystick support, etc, etc, etc.  The only code
I had to write was stuff that you couldn't possibly abstract
into a game library.  I could probably have used any of a dozen
SDK's and gotten much the same results.

--
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)