1
\$\begingroup\$

I've been thinking a lot about the best way to store and load assets in your filesystem. By this I mean where in the file system to store them, and how to retrieve them when loading etc., as opposed to how their stored when the program is actually running. I would imagine that this would be a fairly common question, but I can't seem to find it anywhere else, perhaps because I'm not asking it properly.

So far, I have found two strategies, and I would like to know what other ones there are.

  1. Storing the assets in an absolute path on the system. You may have to get the users home directory if the user doesn't need to be an admit/root to install the game, and other OS dependant stuff would probably need to be done to ensure that the path is actually valid, but it seems like this could work well.

  2. Get the game's location on the system, and assume that assets can be found in an adjacent directory. I don't think there is any OS independent way to do this, but it does seem feasible. This might be nice as it doesn't require the user to install the game, making it all around more portable, but it does seem like it would destroy an OS paradigm where specific portions of the game when in a certain place in the os (say /usr/games, and the executable would go in a different directory).

Both of these ways do seem a bit clunky, so are there any other ways to get the location of your assets? Otherwise, which is used more in games you've worked on? Thank you.

\$\endgroup\$
4
  • 3
    \$\begingroup\$ I replaced 'path-finding' with 'filesystem' since the latter generally refers to things like A* and such. \$\endgroup\$
    – user1430
    Commented Jul 5, 2011 at 16:57
  • 2
    \$\begingroup\$ Also you say "in memory" but "as opposed to how they are stored when the program is running," which is contradictory. I assume you're asking about how the assets should be stored on the disk? That's what it sounds like from your bullet points. \$\endgroup\$
    – user1430
    Commented Jul 5, 2011 at 16:59
  • 1
    \$\begingroup\$ Erm, yes, I'll fix that, I suppose that most people think of RAM, cache, or other forms of primary memory when they think of memory, rather than secondary memory. \$\endgroup\$
    – Leif Andersen
    Commented Jul 5, 2011 at 17:03
  • 2
    \$\begingroup\$ Check out gamedev.stackexchange.com/questions/2309/… too. \$\endgroup\$
    – PrettyPrincessKitty FS
    Commented Jul 5, 2011 at 17:31

2 Answers 2

Reset to default
8
\$\begingroup\$

You're over-engineering this =)

Windows games have two different storage areas:

The first is for static data with the installed program and these files are almost always referenced relative to the application itself, or defined in a file (XML usually) that the program loads when it starts up so there are no hard-coded references. Using the Windows Registry to store paths has fallen out of favor.

The second is for user data like saved games, and there is a standard API for working with that directory. On recent Windows the standard security setting stops a user from saving data to the program area, which is why this is done. On Linux, which I am no expert, I'd assume this directory would be a convention to use /usr/games or something in the /usr directory space.

\$\endgroup\$
2
  • 3
    \$\begingroup\$ On Linux (generally) your executable goes in /usr/bin, and the rest of your files have specific locations according to how they're used. There are generally two axes of differentiation: user-specific or user-independent, and static or dynamic. \$\endgroup\$
    – Keeblebrox
    Commented Jul 5, 2011 at 19:37
  • 1
    \$\begingroup\$ Using the Windows Registry for a lot of things is still falling out of favour, especially for portable applications. One of the things that I really like about portable software is that settings and related data are stored in simple text files that can easily be modified manually if something goes wrong; on the flip side, with the Windows Registry, little bits and pieces of settings and other similar information tend to get scattered all over the place. \$\endgroup\$
    – Randolf Richardson
    Commented Jul 5, 2011 at 21:19
1
\$\begingroup\$

I think that the most elegant form is to abstract the filesystem and to do it operating system independent. This abstraction is responsible of determine the operating system that is running the game and get the real path of the game executable. Then all your code that accesses to resource paths are always relative to the directory that you want. For example, separate always the directories with / ( unix, window, osx ) the operating system doesn't matter because the wrapper abstract this.

Normally the resources are grouped, because if you are in main menu, you only wants to load the resources in main menu. Then the wrapper can have the hability to generate groups, and maybe to search inside this by name. ( this approach doesn't use paths, once the groups has been created ).

The boost file system library here is a form to facilitate the creation of the filesystem wrapper.

\$\endgroup\$
3
  • \$\begingroup\$ Although Boost is a good example of a library aimed at this type of functionality, I'm very displeased with it because of the reckless disregard the developers seem to have for backward compatibility (AlphaMail is a WebMail application that depends on an older version of Boost, and is not compatible with a slightly newer version because the API changed too drastically). \$\endgroup\$
    – Randolf Richardson
    Commented Jul 5, 2011 at 21:22
  • \$\begingroup\$ Boost library is intended to provide very quality solutions to some problems. Some of them are standarized in new versions of C++. The problem is, like you say, the backward compatibility, that is most easily achieved by stable libraries that doesn't change. \$\endgroup\$
    – momboco
    Commented Jul 5, 2011 at 21:57
  • \$\begingroup\$ APIs can change in ways that don't eliminate backward compatibility. The beauty of a library like Boost being open source, however, is that someone who needs the backward compatibility can take the portions they need and re-implement them in their own libraries in order to protect themselves from unexpected changes where the user has a newer version pre-installed. Of course, this defeats one of the main purposes of code libraries, but unstable APIs certainly don't discourage this. \$\endgroup\$
    – Randolf Richardson
    Commented Jul 6, 2011 at 1:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .