   How to store game information?
  I'm creating my own formats at the moment and I was thinking about how to store everything. I have some thought on this: (It's going to be a singleplayer & multiplayer RPG)- Store every mesh, position, texture, bounding volume, etc in one huge file but have the terrain plus its textures in another.- The same idea but all textures in another huge file (perhaps all textures together as one huge texture or load them as separate textures.I'd prefer a small amount of huge files instead of a huge amount of small files.What are the pros and cons of the methods?   
  Have you considered using a package file such as zip?This means you can put everything in a single huge file, but still treat it internally as lots of small files.   ;  Be careful when you say "everything." That can lead to you not really getting across what you mean.For instance, it wouldn't really make sense to store all the meshes in a single file, even within a single level, unless the meshes that are stored were part of the actual level geometry (even then, depending on how you do things, there are exceptions).What would be good is if you thought about how you want to load things. You want to load a character model, right?So, we're loading a character called "Billy." Billy needs mesh geometry. So that's one thing to load. He also needs some textures on the geometry so he looks like Billy, and not some ghost. Also, he would probably need some animation data. Depending on whether you do vertex animation, or skeletal animation, you would generally store the animation data in the mesh, or perhaps a separate animation file.So, that's generally how you load things. But, since we want to see Billy, and we have some files: Billy.model (possibly containing multiple meshes), Billy.texture and BillyNewspaperRoute.animation, we really don't want to have to constantly specify those 3 all the time (although we could do it easily enough).What you might think about is combining all the files that Billy needs to come alive into a single archive or one "huge file." The archive doesn't need to be compressed (although again, it quite easily could be).So, what have we learned? Don't get caught by thinking that you need to group assets by their type. It makes more sense (to me, at least) to group them by purpose. That way, even though your engine is loading several different asset types, you just need to specify that you want Billy.archive and it will load everything you need to see Billy in all his splendor, riding on a bike (you will want a different archive for the bike model, textures, animations, shaders, etc), delivering newspapers.Also, use as small textures as possible, it's generally more efficient for the graphics card. Somebody correct me if I'm wrong, but if you need part of a texture, then the whole thing is loaded onto the graphics card, and large textures cause larger load times when transferring data to the graphics card, when then means the time it takes to render Billy increases.Edit: Whoops, I guess I didn't really completely answer your question:Quote:Original post by HannesnisulaWhat are the pros and cons of the methods?To be honest, I can't really think of any pros about storing so much together like that. I mean, it will also come down to how you organise your assets for loading onto the GPU for rendering. But everything else can be messed with and changes, and is just a way for your engine to keep track of things.So if I wanted to load Billy, why should I have to load one massive file of meshes, and then another massive file of textures? That's two massive files which are taking up memory when all I want to do is see Billy riding his bike.   ;  I looked in my WoW and Warhammer Online folders and I noticed they have some huge files with everything stored in them. Is it possible to somehow quickly locate the information I need to load from a huge file and skip the rest? Like making the file able to be treated as a folder or something like that?   ;  Most file formats contain enough "organizational" data to make it easy to skip to a relevant "section". For example, binary files are often composed of a series of "chunks", where each chunk begins with (or has near the beginning) a value indicating the total length in bytes of the chunk. If you identify the chunk (from some kind of signature, also near the beginning) as one that you don't care about, you can check the length and just skip past the whole chunk.That's the general technique. For specifics, you need to know the format you're working with. If it's your own format, that's easy (assuming you've designed it intelligently). If it's someone else's, you'll have to look it up, or failing that, figure it out by reverse engineering (note: this may be prohibited by software licenses).   ;  Yeah, that's basically what I was thinking of. Well, thanks for the vindication :P   ;Quote:Original post by HannesnisulaI'm creating my own formats at the moment and I was thinking about how to store everything. I have some thought on this: (It's going to be a singleplayer & multiplayer RPG)- Store every mesh, position, texture, bounding volume, etc in one huge file but have the terrain plus its textures in another.- The same idea but all textures in another huge file (perhaps all textures together as one huge texture or load them as separate textures.I'd prefer a small amount of huge files instead of a huge amount of small files.What are the pros and cons of the methods?the answer to this question will be found in how you intend to load your data, than how you want to write it out :)basically, do you intend on streaming your terrain/mesh data? do you load things in a per-area block?packing your data into runtime-ready formats is always a good thing, but your loading access pattern will determine what format you need.