Jump to content
  • Advertisement
Sign in to follow this  
Iarus

Database suggestion

This topic is 4120 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, In my game, I have game object templates, like in Dungeon Siege (well I'm planning to!) and I thought that instead of creating a file system, I could store my templates in a database. I would store all my resources in there too. Is this a good idea? Do you have some suggestions of some good free database systems? My game is made in C#, and XNA(but that doesn't matter...) I'd like something that does not require to install a DB server on the client's computer, just the DB file. Kinda like access, but not access, because I don't really like it, and it's not free. I have VS2005 pro, I got it free from my university, and with it came MS SQL Server 2005, but I don't know how it works, and if it's any good for me.... Iarus

Share this post


Link to post
Share on other sites
Advertisement

What about just using XML, you will also have to remember that when using XNA and the Xbox360 you wont have accesss to normal database code but you will have access to XML.

You could also use the storage classes that ship with XNA.

Share this post


Link to post
Share on other sites
Just use the System.Data family of classes (DataSet, DataTable, DataView et. a.) They are intended as local, memory-based caches from DBMS systems. They don't really have a file format per se, though they can load and store from and to XML format and they are fully serializable.

I really doubt they'll ever be availible on the XBox so if you care about that, you'd be better off using the plain ol' XMLDocument class in your app. You could still use the DataSet family in your editor(s), though.

Share this post


Link to post
Share on other sites
If you are using XNA then use the XNA way of doing it. Take a look at Microsoft.Xna.Framework.Storage Namespace and it will do all you need to do. You can use it to serialize and deserialize your data objects in and out of the files as you need.

theTroll

Share this post


Link to post
Share on other sites
thanks for your quick answers.

yes I thought of using XML files, but files get big really quick with XML. Well big... it's relative, but the size of an XML document compared to the size of the actual data is big (if tag names and attribute names are large it's worst).

I've never worked with XML in C#, so I'm not really sure how it works, but lets say I want one template, and the file contains 100 templates. Do I have to completely parse the file to an XML tree, just to get one item? If yes, then I'll have to leave that tree in memory, cuz it'll be too costly to parse every time.
With a database, I would index the template name, and I would be able to get the data quicker.

Also I'm using XNA, but I don't have an XBox360 and I don't plan of buying one anytime soon, so I don't care much about that platform, well not for now anyways. So the "it's not gonna work on an XBox360", "it's not supported by the 360",.... is not a really good argument for me. (not saying that those argument are not valid, they are good, but I'm not developing for that platform)

I'll look again into XML and I'll see what System.Data and Microsoft.Xna.Framework.Storage can do for me. I'm stubborn so I'm still thinking about database...

Share this post


Link to post
Share on other sites
The trick is not to do any of the work yourself. That is where serialization comes in. One you mark the stuff you want serialized and make the code to open, read, save and close the files, then you are pretty much done. The way I do it, is make a base class for all the classes you are going to serialize. In that class have the read, write functions. After that derive all serializable classes from that one. You will be able to read the data in on the fly and not really have anything else to worry about.

Things to remember. For a large game you don't want to load all the data in at once, so you have to have a way to break up the data so that you can load in the data you need.

For exmple say you are making a landscape and need to load in data as the person moves across it. You break up the landscape into a grid, 100 x 100 or whatever fits your needs. Each grid is a class, that has a name (also will be it's filename), also had all of the other object classes that will make up that one bit of landscape (trees, rocks, ground verticies, ect). Also in the class are the names of the 4 grids that surround it. So if you move north, and you need to load the next grid, then you just ask the current grid who is north of you? You then load that grid and continue. Now you do preimtive loading by loading things that are further out then you can see, that way the person never has to wait for it to load.

theTroll

Share this post


Link to post
Share on other sites
XNA's storage facilities really only include access to plain old streams. Its purpose it to virtualize the HDDs on PCs and XBox360s and doesn't provide much in the way of services beyond that - you can get a stream to read or write.

In order to easily serialize an object graph with XML, you have to attach a bunch of special attributes to the object's fields. I don't know much more about it than that - its all black magic to me.

But your objects don't comprise a complex graph - it sounds like its just a list of homogeneous objects. The easiest way to load/store something like that is to keep them in a System.Collections.Generic.Dictionary, keyed with some sort of identifier (an enum, strings, whatever). That will give you fast access to the individual objects. And if you put the Serializable attribute on your template class, the Dictionary can go to and from disk with a simple BinaryFormatter.

You can whip up a quick editor that will operate directly on this same Dictionary, using a DataGridView. There are a number of ways to bolt your collection into one of these.

There's really no reason to get into using DataTables unless you want conditional filtering for some reason - you get that for free with the associated DataView class. A "database" is good at storing arbitrary collections of values. Your collections of values arn't arbitrary - they are expressed in the template class's definition.

Still, if you are detemined, the DataTables are really easy to use and have excellent performance.

Share this post


Link to post
Share on other sites
Quote:
Original post by Iarus
Hi,

In my game, I have game object templates, like in Dungeon Siege (well I'm planning to!) and I thought that instead of creating a file system, I could store my templates in a database. I would store all my resources in there too.

Is this a good idea? Do you have some suggestions of some good free database systems?[...]



This is very close to what I came looking for.
I'm working on a couple different projects. Both have large amounts of static, shared information. They both of course have objects which also need to be saved btwn sessions. I'm working in C++ for one and Java in the other. I could switch the C++ project to Java, but I've got really cruicial work done in the Java project already, so I wouldn't want to switch it to C++. Maybe after I have completed it.
Originally I was going to make static classes for the reference material and just Serializable [Objects] for the others. But recently I was thinking about how the index features of databases could make it easier to get the data I'm looking for. Especially on the C++ project--the static data is basically tables upon tables for game stats and such, cross-referenced on 2 d100 numbers, etc.

Would your advice be different than what you gave the OP?

Share this post


Link to post
Share on other sites
Item 1 - The data MODEL is key. Spend most your time thinking and designing your DATA ... and your classes around that data. If you design data in a relational maner more than an OO maner, that's no problem ... design your data the way you like. Don't worry about storage - all relational models can be stored in and RDBMS, a flat-file db, a binary file, XML, etc. All .NET OO data models can be persisted to a serialized binary file, a serialized XML format, a custom written relational db, etc ... The model and the storage medium are largely orthoganal.

Item 2 - The classes through which you access your data should not expose any details about the underlying storage mechanism to the user who just want to get and set values, except perhaps an interface to refresh the data or commit changes. A Template object can a a custom class "Template", or an instance of a typed data set "TemplateDataRow" ... but either way it doesn't need to know how its written or read.

Item 3 - Seperate your data persistence code, from your data persistence interface. In other words, while the program may need to say WHEN to load or update a value, or when to write it to disk, it shouldn't care that on 1 app that happens to be an XML file, on another a highly optimized binary format, on another serialized datatables, and on another just a strait database call. If you look closely you can see that the DataAdapter's Fill and Update are really the same as a streams Load and Save.

Share this post


Link to post
Share on other sites
let me see if I understood what you said....
Quote:
Original post by Xai
Item 1 - The data MODEL is key. Spend most your time thinking and designing your DATA ... and your classes around that data. If you design data in a relational maner more than an OO maner, that's no problem ... design your data the way you like. Don't worry about storage - all relational models can be stored in and RDBMS, a flat-file db, a binary file, XML, etc. All .NET OO data models can be persisted to a serialized binary file, a serialized XML format, a custom written relational db, etc ... The model and the storage medium are largely orthoganal.

who cares how it's stored, if it's well-designed it won't matter much.
Quote:
Item 2 - The classes through which you access your data should not expose any details about the underlying storage mechanism to the user who just want to get and set values, except perhaps an interface to refresh the data or commit changes. A Template object can a a custom class "Template", or an instance of a typed data set "TemplateDataRow" ... but either way it doesn't need to know how its written or read.

encapsulation, yeah gotcha
Quote:
Item 3 - Seperate your data persistence code, from your data persistence interface. In other words, while the program may need to say WHEN to load or update a value, or when to write it to disk, it shouldn't care that on 1 app that happens to be an XML file, on another a highly optimized binary format, on another serialized datatables, and on another just a strait database call. If you look closely you can see that the DataAdapter's Fill and Update are really the same as a streams Load and Save.

more encapsulation? not sure..."data persistence code/interface" is a bit more formal than I usually address things; I probably know what you're talking about but didn't catch it for sure.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!