> > Then maybe XML (yes, they are bloated) using XPath to query the > > information? Implementing a database engine just to load some stats > > looks for me like breaking a butterfly on a wheel. >
it's easy to have that impression, but sqlite is no oracle or mysql -- there is no client/server relationship whatsoever (unless you consider the shared lib the server, and the program linking against it to be the client??), so the database access code will be 100% contained within the wz binary. it's ultra light, and ridiculously fast for its requirements -- it runs very well even on embedded devices, and only works with one *.db file per database, thus we'd be talking about one extra file per mod just to store the stats (contrasted to several csv text files), and really suited perfectly well for games. well, i'll just shut up about that and point to < http://www.sqlite.org/different.html> and <http://www.sqlite.org/speed.html>. i definitely approve the idea of a switch, and actually, for the first time it's making me think of doing some serious stats modding (because of the obvious csv whiplash, and wzck buggery in some areas, i always just stuck to pie modelling in the past). i have a few recommendations: 1. we keep the database normalized: as described in < http://en.wikipedia.org/wiki/Database_normalization>, any databases we use should try to satisfy the 'third normal form'. if we just dumped the csv rows 1-for-1 into the database, then it's db abuse, and we might as well just stick with the csv values =) getting it normalized would involve such distinctions as: having a "splash damage" table separate from the weapons table -- if a corresponding row does not exist in the splash damage table, the weapon has no splash damage. otherwise, for each corresponding row, in the splash damage table, there would be "damage type", "damage", and "radius" fields, for example, allowing a weapon to have, for example, an incendiary effect to a range of 256, an intense inner explosion, and a moderate outer explosion (the csv files only support one explosive and one incendiary -- this would allow an arbitrary number). 2. built into wz binary, somewhere, we keep the sql table generation syntax for all the stats tables, and inside the mod, we keep dumps of the mod-specific stats within the mod as plain-text files -- these would contain update/insert/delete commands in raw sql. well have to decide whether we want to keep the compiled db inside of mods as well, but at the very least, this would make changes to the stats quite readable in svn.
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
