Sv: Re: Library/Tool database

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>----------  Mail forwarded (Author is Steve Baker)...  ----------
>Subject: Re: Library/Tool database
>Date: Wed, 15 Sep 1999 16:18:29 -0500
>From: Steve Baker <sjbaker1@airmail.net>
>
So, the author doesn't see this?

>Seems to me like a one line description plus a URL is all you need...and
>we already have that in a dozen places.
>
As you say, if we did just a one line description, then we already have that
in a dozen places, and there wouldn't be much of a point.

>If people are at all interested in a toolkit, let them visit the
>homepage and there they'll find all the authoritative data.
>
Yes. They will find all the data. ALL the data. Too much data. I find it
impossible to get an impression that is anything more than an extreme
abstraction from briefly looking over a libs homepage. Of course, if I have
an hour or a half, I'll be able to get a pretty detailed picture. It still
won't be insanely objective, and I probably won't know what the "feel" of
the lib is. I'll only know the abstract picture the designers of that lib
has in their own head of their lib, plus perhaps a very rudimentary
knowledge about the design paradigm and interface of the lib.

You rarely see a homepage for a lib saying "go to this lib instead for most
uses, as its simply better and more tigthly coded". That kind of thing
simply isn't the porpuse of a libs homepage. A libs homepage is supposed to
tell the strong sides of a lib, updates and documentation, plus perhaps a
little on what it doesn't do so well, but it isn't meant to show
inferiorities in the lib itself. There's nothing wrong with that, that's the
way things should be.

This means that there is a significant amount of data, that is vital, that
the lib's homepage does not provide the visitor with. We plan to provide
this information.

>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?
>
I think developers will be very interested in a site suchs as this. It will
very quickly give them the knowledge of how the environment is changing (and
it is, in some small way, every day), what the future seem to be bringing
and what it doesn't seem like it will bring. It will give them the knowledge
of what everyone else is doing, from *their* perspective, and it will very
likely give them hints as to what they could be doing, and how.

This site will bring a much needed opaqueness to the library scene, that is
sadly missing rigth now. It will bring this opaqueness to people in a
fraction of the time it would otherwise take them to get it.

And don't forget the lib developers themselves. I imagine they would be
doubly interested in a site suchs as this.

>> (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.
>
Usually, I imagine sending us the list of changes when a new version comes
out will be sufficient. We should be able to pick out the relevant stuff.

>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.
>
A site suchs as this will allow people to stay on top what is happening with
many, many libs. I don't see why developers wouldn't want to take suchs a
oppertunity, and browse the site daily. If a news item about a specific lib
interests them, they can go to the page for that lib (on our site), and very
quickly get a pretty diversed picture of the lib. That's not possible from
any other site currently.

>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.
>
If you already have a diversed picture of all or most of the libs out there,
then yes. I suspect most people don't. *I* certainly don't.

>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.
>
That would them be either because of neglect or bad organization in the
site.

>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!
>
We are not middlemen, in the sense that we don't plan to simply replicate
data on the homepage of each lib. We add to and enrich the information.
Standardise and compare it. Give second, third, fourth and fifth opinions.
Make it easy for people to find all libs that resemble this lib.

Where we plan to go is beyound simple summary, but to a real, valuable,
usable, fast, comprehensive and user friendly unique site. That's atleast
the way I have understod it.

>> * 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.
>
Now, my memory might be completely off (wouldn't be the first time), but it
tells me that Linux Game Tome isn't directed especially  at developers, but
gamers. That would explain the situation. Besides, having a 100 users
doesn't mean having a 100 serious users. If I do a Tetris with you lib
(sorry if that's not something I could do with your lib, I don't have an
easy way to find out, so I didn't know (ok, perhaps I'm just lazy, but bare
with me :) ), am I an user? Not that I'm trying to put you or you PLIB down,
but I don't think your example is very informative.

Anyway, even if alot of people don't use the feature, those who do will make
it usefull to the extent they do, regardles.

>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!
>
I'm utterly opposed to ratings, especially of this kind.

>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.
>
I think the kind of feedback is very much related to how you ask for it,
what your sites' "feel" is (serious/funky/be cool/peace to earth...), and,
of course, what kind of people your site attract. Its "just" a question of
attraction the rigth people and ask in the rigth way with the rigth kind of
site. I don't think that's impossible. Besides, we ourselves would be users
of quite a substantial amount of the libs, so there you have the first X
serious comments (where X is the amount of people we have doing this, which
is unknown right now).

>> * 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!?!
>
Well, not in the way you propose.

>That's a MAJOR undertaking.
>
Well, yes, but not as major as you make it out to be.

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

>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.
>
Then he's a bad reviewer. A good reviewer *would* offer his personal
opinion, but throw in the fact of his personal bias and say that OOP is
tightly integrated in the design of the SDK, and therefore, if that's what a
reader wants, then it migth very well be a good to check it out.

He would probably also say that if a reader want a procedural, top-down
design, then they should stay clear of your lib, which is 100% good advice
for suchs a reader.

>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?
>
No. That would be silly... You merely have to encapsulate the different
components of ONE program, then implement each component once for each lib
you want to test.

You can then test all libs against each other without the kind of effort you
portray, by simply plugging each lib into the game in turn and see if it
works with all the other libs.

>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.
>
Why would we? We'd simply tell the facts as they are: The Quake graphics
engine doesn't work with other sound engines than the Quake sound engine.
We'd then probably also say something about how that wasn't so bad because
it allowed for some optimizations, and the simple fact that the Quake engine
and the Quake sound engine is a pretty good solution, would probably also do
alot to improve our positive feelings about this engine.

In the end, its up to the reader to make up his own mind. That should be the
aim of any well-written article, nomatter the kind (perhaps with the
exception of articles for novices, which has to keep things simple).

>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.
>
I can think of atleast one quite large group of people who would be almost
ecstatic to have these kinds of test: the lib developers. It will enable
them to make their libs better, and therefore benefit all: lib developers,
game developers and gamers. They can all get and/or produce a better product
as a result.

Seeing how good a library is at cooperating with other libraries is
certainly an important part of getting a just reasonably detailed picture of
a lib. This is certainly information that is vital, but not very accesable,
if at all accessable.

>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.
>
The question is wheter this is a problem with the libs that exist, or if it
simple is a result of people not being able to find what they are looking
for? I think a site suchs as this will help to reduce fragmentation of
effort and promote inter-lib cooperation.

>I think we have enough SDK's - we need people to write good games.
>
I couldn't agree more with you. That's why I think this site is suchs a good
idea.

>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.
>
This site will tell people how to do it. If people don't know how, they will
either never start, or fail. Nobody gets anything out of that.

>Just do it!  Write great games.  Everything you need to do that
>is here -- a dozen times over.
>
It is my understanding that you are a library developer?

>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.
>
Tetris is a great way to be introduced to programming. I don't think its
something alot of talented people waste their time on, though. If they don't
have a very good reason.

>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.
>
Hmm... It seems to me that the requirements for a game it takes only one man
20 hours to create is pretty limited. Besides, you seem to be a very
informated individual in this regard, so it is not that surprising that you
shoud know how to do things somewhat quicker than many other people,
especially if you used the same lib you yourself are developing...

--

I want to thank you for taking the time to write this. If every new project
being started up had a guy suchs as you around to make people see the weak
spots in their vision, I suspect not nearly as many projects would fail as
is the case today (the last think I heard was that only 1 in 20 projects
succeed).