The game files location....

Started by
4 comments, last by Zahlman 19 years, 2 months ago
Hey, all. When you make a game that has several 3d levels, each with models, ai, physics, lighting, vehicles, and all the other info, how do you store it. Since the data is large, do make my own format? I have no idea on how to make one of my own and have it openable. I heard the Irrlicht game engine uses .dll files to store their tutorial models, bitmaps and such. But I dont know on how to actually make a Dynamic-Link library. (hell, I dont even know what it is used for!) I would appreciate an answer soon, please.
Advertisement
Quote:Original post by DarkBrute
When you make a game that has several 3d levels, each with models, ai, physics, lighting, vehicles, and all the other info, how do you store it.
That's up to you. Most developers use some form of archive format to collect multiple bits of data in a single file. When starting out, however, the .DAT - basically a renamed .TXT file - is quite popular.

Quote:Since the data is large, do make my own format?
You don't have to. You can, if you want to, but you can also use the formats of others. You can store your data in .ZIP archives, too, and even rename them to make it less obvious what they are.

Quote:I heard the Irrlicht game engine uses .dll files to store their tutorial models, bitmaps and such.
Don't look to that as good design. Windows allows executable files to store some resources right within the binary, but that is typically only used when you have just a few resources. Storing large amounts of data within the binary is extremely efficient.

If the story is true, Irrlicht stored thosr resources within the .DLL specifically because they are tutorial data.
I haven't tried it, but I heard that PhysicsFS is great.
Rob Loach [Website] [Projects] [Contact]
I'm an oddball then. I wrote a C++ wrapper class for sqlite (www.sqlite.org) and enjoy the power of a sql database as my filesystem. The best part is that it's quite portable. Additionally, it simplifies/eliminates the need to develop/use a bunch of file-formats.

So far, it's fast. Especially for large volumes of data - as it isn't digging around in an archive and decompressing things. More importantly - it's dead simple to use. It also makes tool creation and asset management a BREEZE. My last use was a database to hold force-feedback effects in the game. Using a network fileshare - I can edit force effects and inject them into the database *while* it's being played. (To download the effects, I just added a hook to the engine that reloads sets of resources.)

Later on, when we publish expansions/updates/blah - just UPDATE some table rows. :-)
"This I Command" - Serpentor, Ruler of C.O.B.R.A
Quote:Original post by zarthrag
I'm an oddball then. I wrote a C++ wrapper class for sqlite (www.sqlite.org) and enjoy the power of a sql database as my filesystem. The best part is that it's quite portable. Additionally, it simplifies/eliminates the need to develop/use a bunch of file-formats.

So far, it's fast. Especially for large volumes of data - as it isn't digging around in an archive and decompressing things. More importantly - it's dead simple to use. It also makes tool creation and asset management a BREEZE. My last use was a database to hold force-feedback effects in the game. Using a network fileshare - I can edit force effects and inject them into the database *while* it's being played. (To download the effects, I just added a hook to the engine that reloads sets of resources.)

Later on, when we publish expansions/updates/blah - just UPDATE some table rows. :-)


That is very interesting. I think I have just decided on a radical change. Darn you for having such a good idea.

:P

Cheers,
Ryanmfw
If by any chance you're working in Python, check out the Pickle module. It roxors the big one one one one.

This topic is closed to new replies.

Advertisement