[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Library/Tool database
Of course I forgot something ;)
Paul's [PP: that's Paul Tiseo, LGDC webmaster] idea of the list of features:
We should establish a basic list of features that an SDK could carry
in the various categories we already have: general, 2D, 3D, sound, network,
etc. These would be features of interest to game developers. For example,
for 3D, we'd have: degrees of freedom, BSP, portals, dynamic lights,
shadows, etc. The features listed should be limited such taht answersare
yes/no or numbers, rather than text, to keep the search simple and for
consistency from listing to listing. For example, BSP (yes/no), degrees of
freedom (4/6), etc.
It would be a long list, to have *all* potential features, but we'd
database the info. Then, developers could get the SDK they need without
resorting to rummaging through SDKs that don't have the neccessary
features. Also, a comprehensive might be good for SDK developement. ("Hmm",
says ficticious developer for SDK1, "SDK2 has feature ZZ and we don't.
Maybe we should have it.")
The hard work would be to list at least all the major features for the
categories of SDKs. Then, we could get an initial mailing out to all the
knwon SDKs and add those that we find as we move along. One important thing
would be to get SDK developers to come to the LGDC and comne often.
I don't think it's feasible to really have a fixed feature set so that each
lib entry only has to have yes/no or a number or whatever for each. Feature
sets change rapidly (all the pime people invent new features) and they also
vary widely between the different types of libs - sound/2d gfx/3d gfx/...
So I'd say we *do* make a list of features, but an open one, so we can add
new ones any time. And the library entries just have one text field
"features" listing the ones the library really has, e.g.
"acceleration=partly, mipmapping=yes, degrees_of_freedom=6, curves=yes, ..."
Drive A: not responding...Formatting C: instead