Other than Dropbox, what out there has been especially useful for storing and sharing game content like images during development (similar feature set to Dropbox like working offline, automatic syncing and support for windows/osx)?

We are looking into hosting our own SharePoint server but it seems to be really focused on documents... Maybe Box.net would work?


For code, we are using Git.

To be more precise, I was looking for an easy, automatic way for content produced by artists/audio engineers to be available to everyone. Features like approvals of assets don't hurt either. Following the answer linked by Tetrad, Alienbrain looked pretty interesting but..is way out of our budget (may be something to invest in in the future).

What ended up doing...

We were going to go with Box.net but downloading the sync apps for desktop use required us to wait to be contacted by them for some reason. We did not have much time to wait so we ended up going with Dropbox Teams. Box.net has a nice feature set but we never really felt held back without them.

Thanks for the help :).


1 Answer 1


It depends on the nature of the content:

  • Is it an asset that is loaded by the game, like a model or a texture? You want a version control system.
  • Is it some form of data not loaded directly by the game, but used to build data directly loaded by the game, such as a localisation spreadsheet? You want a version control system.
  • Is it a document outlining the game design, some feature detail, or a technical process or procedure? You want a version control system.
  • Is it a file that can be rebuilt from something that's already in version control, such as executables and linker objects? You probably don't want a version control system (*).
  • Is it a file that you want to share with a coworker temporarily, such as a code change or an updated asset, that you don't want permanently in the game, but they need in order to continue their work? You don't want a version control system. (^)

(^) There are a few options in this case:

  • You mentioned Dropbox, which is great when you're collaborating with teams over any distance, but limits you to 2GB. This should be fine for temporary use, given that all your other data should be in version control; however, if you need more space there's now a (paid) Dropbox for Teams option.

  • If you don't want to pay for the cost of a bigger Dropbox plan, but only need to occasionally share large files, then using one of the dozens of file sharing sites (like RapidShare) might be an option.

  • Hosting an FTP server may also be viable for you.

  • If you're working on the same LAN (or you can set up a VPN), then both Windows and Mac can create network shares that are writeable by one another, without size restrictions. It's common to create a read/write share named Dropbox, and use that for exchanging files. It's also common to name machines after their users; i.e. to send a file to John Doe, I can open the share \\JOHNDOE\Dropbox and place the file there.

  • Special mention for Git if you're sharing code: you can create a separate branch with your code changes, and push to your main repository. Other people can then grab your changes, without disrupting your master branch. (In these cases, it's common to place your branch in a directory with your name, i.e. johndoe/bugfix.)

(*) Occasionally, you'll want to commit/store executables and symbol files somewhere in order to debug issues with older builds, without needing to rebuild the game. This is commonly the case when dealing with crash dumps.

  • 1
    \$\begingroup\$ to summarise: anything related to the product that is not generated by other things related to the project goes into version control. \$\endgroup\$
    – jwenting
    Nov 30, 2011 at 12:25
  • \$\begingroup\$ De-facto answer, though it can be more complicated than it seem. "like working offline" <-- this means hg/git/some other DVCS, unless svn can be regarded as "working offline". However, the OP's main concern is images, DVCSes as I know don't deal with binaries really well, in that case he may need SVN. \$\endgroup\$
    – kizzx2
    Nov 30, 2011 at 13:48
  • \$\begingroup\$ svn works well with infrequent submits/updates, as long as there's a good division of labour (else the number of merge conflicts can get out of hand, as with any such system). \$\endgroup\$
    – jwenting
    Dec 1, 2011 at 10:04
  • \$\begingroup\$ Would you store all the textures and models in source control, even if they add up to gigabytes? (I've never worked on a project with that amount of non-source-code data, so I wonder how people do this) \$\endgroup\$
    – RomanSt
    Dec 1, 2011 at 21:30
  • 1
    \$\begingroup\$ @romkyns: Yes, I'd definitely store it all in a VCS. At some point, you'll regret not having it. In regard to managing very large repositories: it's a pain, but it can be mitigated by placing data in separate repositories. Our current project at work has an "art-source" repository (100+ GB) and an "intermediate" repository (~20 GB). The artists commit their texture/model sources into art-source, but then export them into intermediate for consumption by the game (or build system). Only the artists need the full art-source repo; everyone else just needs intermediate. \$\endgroup\$ Dec 2, 2011 at 11:28

You must log in to answer this question.

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