Re: [Algorithms] Data base choices
Brought to you by:
vexxed72
From: Jamie F. <ja...@qu...> - 2007-04-04 10:26:47
|
Mat Noguchi (BUNGIE) wrote: > Ahh. I'm still a bit confused as to why different types of links would make it hard to view your data as a giant relation. A link is essentially a directed dependency, right? A link is a directed dependency, yes. You certainly could think of the data in terms of a database schema, I'm just not sure it's helpful (at least to me). Each class would have its own table, and the overall structure of the thing would just be madly complicated. Jamie > MSN > -----Original Message----- > From: gda...@li... [mailto:gda...@li...] On Behalf Of Jamie Fowlston > Sent: Tuesday, April 03, 2007 11:10 AM > To: Game Development Algorithms > Subject: Re: [Algorithms] Data base choices > > Mat Noguchi (BUNGIE) wrote: >> Why do different types of objects need to store links differently? > > Scope ambiguity, there :) Please read as "(the links between objects > come in various different forms) and (each class of object is > different)". Different types of object do not need to store links > differently; we do have several types of link. > > Jamie > >> MSN >> -----Original Message----- >> From: gda...@li... [mailto:gda...@li...] On Behalf Of Jamie Fowlston >> Sent: Tuesday, April 03, 2007 10:16 AM >> To: Game Development Algorithms >> Subject: Re: [Algorithms] Data base choices >> >> Jon Watte wrote: >>> Joris Mans wrote: >>>>> 3) you can't run reports on serialization >>>>> >>>> What do you mean by that? >>>> >>>> >>> How many Green Tree Giants are there in that level? >>> What textures does the Reticulated Blob entity use, across the game? >>> If you sum up all the polygon counts of all the mesh instances in all >>> the levels, how much do you get? >> We can run reports such as those on top of our serialized objects, but >> from reading further down it sounds like we're very much agreed... >> >>>> The disadvantage of not using a serialization system is that you have to >>>> write save/load code for every class/struct you want to store. >>>> >>> With serialization, you also have to write code for every class/struct >>> you want to store. >>> >>> However, I would like to posit that I don't want to store classes and >>> structs; I want to store higher-level constructs, such as "entities" and >>> such. Once you have a meta-data system (such as you get from a rich >>> composable data model), serializing vs saving vs database transforming >>> becomes adapters/strategies on top of the same subsystem. At that point, >>> I've found that thinking of game data as a database schema, rather than >>> as a sequence of shapeless blobs, helps with structure and management. >> Objects serialize themselves into our databases, which put higher level >> structure on the whole thing, so we've got very much what you describe. >> I can't say I've ever found thinking of it as a database schema very >> helpful, because the links between objects come in various different >> forms and each class of object is different, but I can definitely see >> where you're coming from. Certainly our databases are a far cry from the >> "near-random streams of data which you'd better hope work OK when they >> hit the game code or you're hosed" which I've worked with on some game >> projects. >> >> Jamie |