There''s hundreds of places to get info on graphics programming, AI, and other topics related to game developement. However, I haven''t found anything related to good data storage and retrieval methods. For simple games such things usually aren''t required. Unfortunately for me, my designs are anything but simple. So what are some common techniques used for this? I''m not talking about file formats for 3D models. I mean semi-large databases of information. I''ve got lots of IT experience, but throwing in a copy of SQL server with a computer game doesn''t seem like a viable solution.

How about the JET engine file format (.mdb) Access uses? Not a vast database tool. You can access it via SQL using ADO from within your C/C++ or VB program (since you didn''t specify a language). Not a perfect solution, I''ll grant you, but better than SQL Server

RM.





-=Kicking Butt and Writing Code=-

Data storage, as with many parts of game programming, is nowhere near being a ''solved problem'' to the same extent that things such as 3d graphics are. It tends to vary very specifically for each project.

If you want an SQL ''solution'', MySQL is probably small enough to distribute, but it has a 10mb runtime memory footprint. And relational databases aren''t really optimised for most game purposes.

The general way is just to use the language-provided filing functions, and write out the data in a specified order, and read it back in the same order. For anything more complex, you might need some sort of package file format. The Thief games (and System Shock 2, I believe) tended to just use zip files for much of the data. Some people like XML for saving and loading data, because parsers for it are publicly availably and the files can be easily checked for integrity and viewed in a web browser. A lot of developers also try and save a lot of data in simple key:value pairs, somewhat like a Windows .INI file. These are easy to parse (read the key, find the associated variable, read the value, store value in variable, repeat) and very easy to write. They are also trivial to check when something isn''t working right, and don''t get corrupted easily.

Aside from that, I don''t think I can give you much more info, sorry.