I have been reading the thread on hash tables, and I am confused... Why bother with hash tables in a game for information? Why not use a database? With the advances in ADO and ADO+ and COM objects the speed should be close, so why dont we use databases in games, rather than hash tables/ look up tables? Of course you must understand this cquestion is coming from a Database programmer, who is only dabbling in the art of game creation, dont flame me too hard I jsut wnat to know what the disadavantges of using a .mdb file in a game would be........... to Code, or Not To Code

One reason may be this:

You read in all your crap from the database once, then you''re done. No more trips to the database! Just access your memory structure (in this case, a hash table).

It''s faster.

but in ADO you read in the database results in, and they are stored in a (vb is a collection , VC++ is a linked list) recordset which persists until you run another query. You can also use what is called a disconnected recordset to shut down the connection between you and the server ( file what ever). so you dont read it jsut once.... but that also depends because you can need access to different types of records at over and over, thusly executing many SQL statements which can be costly...

but also if you read in the entire table at the begining it would build the link list for you and you can query directly to that ( using ADO+) That would be extremely efficient. Writing the db might be another thing though... any other comments?????

why other than speed....? It seems to me that saved game files would have A. better security and B. easier to code format if they were saved to a database.... graphic look ups coudl be done only once a level during the load process....

to Code, or Not To Code

I think it really depends on the size of the data that you''re storing and the scale that you expect it to grow to.

As a programmer that started out in the game programming industry then moved to the database mining industry, this is my perspective on it (and as such, should only be taken as my opinion).

If the amount of data that you choose to store is going to be relatively small, and you don''t expect it to grow too much, then go ahead and use hash-tables. You have more control over how you look up the data, and assuming the form the data takes will be somewhat generic (i.e., just c-strings and ints, nothing else) will even exceed the speed of a database in some cases.

If, on the other hand, the amount of data you choose to store is somewhat large, and you expect it to grow a LOT when the game/product is released (think of MMORPG''s here) then you will want to use a database. It will save you a lot of stress in the long run, since anything you do will probably not help you to achieve speeds greater than what a well-designed database and some embedded SQL will get you. Plus, it will save you a lot of development time since fast and dependable utilities already exist for manipulating and searching databases.

(And just think of that situation that has been suggested: loading the entire database/hashtable and never going back to the database, just accessing your data structure. Though this is fine if your set of data is relatively small, and won''t change... in a large set of data this will just eat up memory, then to top it off, you have to consider what happens when this data changes. Larger online games ask for more than one server, and each must have up-to-the-second status on data. Having a centralized database will speed this part of the process up dramatically.)

As for the disadvantages of using a database, I really don''t see how there are any, except in the case where your data set is relatively small. In that case it''s merely a waste of resources. I think some developers may be somewhat turned off by using a database, because it''s perceived to be a "strictly-business" thing to some developers. Also, in its earlier days, databases were rather slow... so some people may not realize the great increase in speed databases have achieved as of late. I think this is changing, though, as more games go online and realize the benefit a database gives you when dealing with large sets of data (if designed well!)

On a side note, I can''t wait until I go back to developing games professionally, and not just in my spare time. But right now I know where the money is.

"Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are and what they ought to be."
        --William Hazlitt

The main reason someone may not want to use ADO is due to portability. COM is not available on many OS/platforms (UNIX has a COM bridge but thats about it as far as I know). Lets not forget current trends. Many PC developers have jumped on the bandwagon of having their games be portable to console machines. That limits the use of ADO right there.

While I agree that ADO is a powerful abstraction for data representations the actual storage of data in an external file brings up a few issues. Since ADO allows connection to an Excel spreadsheet, Access database, SQL Server, comma-delimited files etc you have to decide what the best format is.

Obviously you cannot choose SQL Server because most people do not have that and as far as I know there is no ODBC or OLEDB provider for MySQL.

Using an Excel spreadsheet or Access database could be viable options but anyone with Microsoft Office could go in an modify your data. You''d also have to make sure that users had the right provider for Access/Excel and hence would have to install MDAC 2.5. So far none of these issues are a really problem.

You must ask yourself a question though. Why do you need to use ADO? You said it yourself that you''d probably just use ADO to load a database into memory. If that is all you are going to be doing, why subject your program to the overhead of ADO?

If you are going to use ADO to do multiple lookups then lets talk about performance. Performance from ADO will never beat a straight proprietary database format built by you. ADO achieves it versatility by utilizing OLEDB providers. This level of indirection incurs a decent performance penalty when applied in terms of a game. I haven''t even mentioned the fact that ADO calls are blocking by nature. Sure, you can have an asynchronous Open() call but synchronizing that with the rest of your program is difficult.

Lets also talk about having to use ATL to at least effectively use ADO. Sure, you can use ADO via strict COM API calls but have you ever tried that? Not a very enjoyable experience. While ATL makes it easier it does add extra code and overhead to your project once again. Most game programmers do not use, or have experience with, COM/ATL.

Don''t get me wrong. I believe that using ADO for slower RTS games, or massive multiplayer online games has its merits. Unfortunately for most games ADO does not bring enough to the table to justify it.

Just my two cents.

- Dire Wolf
direwolf@digitalfiends.com

Dood I totally agree with Void* and Dire Wolf. You guys rock.

I think I mentioned ADO because its all I have ever used as a database programmer. I have never even contemplated writing my own format...

DOes anyone know where I could check out some Code or articles on that?????

I definately agree with Void* on the reason why people dont use databases. They were thought to be slow and business oriented only. For a long time they were. But now That I look at it, the game I am designing would benefit from a small amount of database usage.

I thank you guys for all yoru help and opinions! Thanks again!



to Code, or Not To Code

I must disagree here. Databases may have improved speed greatly in the years, but they are still VERY slow. In real-time games you can''t afford to wait for that 500ms database hit. When databases can be (and are) used is for MMORPG''s like void* said. However, this is because they have unique problem. Thousand of people need to access the same data at the same time. This is exactly what databases were designed for, and in that instance they will outperform straight file access greatly. Also, MMORPG''s have whole computers dedicated to the sole task of retrieving data from the database. Users won''t experience any slowdown because their computer isn''t the one accessing the database.

Also, there is the added complication of making sure that the end user can access the database. For example, your installation program must install/update DCOM (if needed) as well as MDAC. And this is just for window platforms, of course.

I use databases in my programs all the time at work, and I think they are great, but for simple end user games where only one person will be accessing the data, it is not only overkill, but it can even slow your game down.

- Houdini

cxi2: Sorry, don''t know your background very well, but are you versed in data structures? If not, you can check out STL: the standard implementation gives you vector, deque, list, map, and set; you can usually make your own kind of database using the right combo of those containers. Again, sorry if you already know this.

sweet, thanks stroffel, i did not know that. are those part of the c++ language? where can I find more info on those??

I dont knwo a whole lot about data structures....



to Code, or Not To Code

Yes, STL is C++. Check out the STL programmer's guide for more info on how to use it.

As for the databases: I agree with DireWolf. Databases are quite convenient, but they lack performance (although they're not as slow as Houdini thinks ). And I don't think that your data is very secure either: if you use a CSV or an MDB file, everybody can tinker with it (unless you change the file's extension ).

Dormeur

Edited by - dormeur on September 20, 2000 11:04:58 AM