Ideally, you'd want to use a version control system, like Subversion, etc, so that you can always get the latest version of every asset from a central repository (if your HDD fails, then having to re-piece-together the game by going through your email history is never fun), and so you can also easily go back in time to older versions ("hey the game is crashing now, I'll try undoing your changes from 9am today...").

In a small, distributed team, this can be a pain to set up though... You need a central server somewhere, and someone needs to back it up and administer it.

Using something like Dropbox is a lot easier in these situations because they take care of the hosting issues. The downside is that you lose fidelity in change management -- every change is automatically 'committed' to the server, without a log message, and regardless of whether it's a WIP or a usable change. Dropbox's versioning / undo / blame abilities are also a lot worse than a real VCS like Subversion, and may not even exist if you're using free Dropbox.

If it's just art your sharing, a dropbox of Google Drive will be sufficient. If you're sharing code or working on a project on a program together (like Unity), then you need a version control system. I learned this the hard way.

But again, if it's just art, a well organize cloud drive should be fine. Good luck!

Ideally, you'd want to use a version control system, like Subversion, etc, so that you can always get the latest version of every asset from a central repository (if your HDD fails, then having to re-piece-together the game by going through your email history is never fun), and so you can also easily go back in time to older versions ("hey the game is crashing now, I'll try undoing your changes from 9am today...").

In a small, distributed team, this can be a pain to set up though... You need a central server somewhere, and someone needs to back it up and administer it.

Using something like Dropbox is a lot easier in these situations because they take care of the hosting issues. The downside is that you lose fidelity in change management -- every change is automatically 'committed' to the server, without a log message, and regardless of whether it's a WIP or a usable change. Dropbox's versioning / undo / blame abilities are also a lot worse than a real VCS like Subversion, and may not even exist if you're using free Dropbox.

It's good for coding but I disagree you should set up such system for art. Art is art, it rarely "breaks" and you often have just one person working on one asset be it a texture, model, sound etc.

I disagree almost to the point of downvoting this, but since you're offering earnest advice, and the topic is somewhat a matter of opinion, I'll just rebut instead.

In a simple game, sure, art might not often break things, but there's certainly the potential for breakage and more-complex games run into it not infrequently -- As one example, say a graphics programmer tweaks a shader in such a way that the texture that it used to sample for information no longer contains the correct information. You can't argue that this is a broken code, because the code functions as expected -- the art is simply out of date. Other times, an artist might "check in" some changes to an asset that aren't what the designer wanted -- its a bad idea to simply rely on the hope that the artist has kept a backup of the old version. In larger teams its also not always true that the same artist always works on the same asset -- its unlikely you'll have two different artists working on the same piece at the same time, but many artists might touch the same piece all during development.

These kinds of problems are what a version control system handles -- Art should be versioned alongside the code (what if you need to back out some code changes and all your "new" art is incompatible?), sometimes changes need to be undone, people need to be able to collaborate. On top of that, an adequately backed-up version control repository--preferably on a redundant volume (say, mirrored RAID)--offers great piece-of-mind.

Now, the one difference, IMHO, between code and art in a version control system is that I believe code assets are best-served with a truly distributed model (typical GIT-like, or mercurial-like workflows), and art assets are better-served by the more-traditional centralized model (check-out/check-in model, more like Subversion). The main reason is the size of the raw art assets, and the fact that you don't need all of the art to do your job in the way that programmers need all the code to do theirs -- for small projects, this probably isn't a practical concern, but still the history of the art repo can become very large -- perhaps too large for someone working remotely over a slow connection.

There are workflow advantages to version control too -- You can always afford to be experimental and even recklessly so, safe in the knowledge that you can't break anything beyond repair.

If you're a small team, drop-box works for you, and a complete lack of file versioning doesn't scare you, fine. Do what works for you. As a programmer these days I don't undertake any non-throw-away project without version control, even if I'm the only one working on it. I would strongly recommend against even a single artist working without version control, but I can see an argument that it might be unnecessary if you can square yourself with the potential for human error (no or infrequent back-ups) or minor catastrophies (drive failture or an artist who just disappears). Working with two or more coders or two or more artists without version control is just asking for trouble, though, and borders on heresy.

an adequately backed-up version control repository--preferably on a redundant volume (say, mirrored RAID)
someone working remotely over a slow connection

I think it's funny you switch back and forth between a serious big scale project and small and poorly arranged setup depending on what suits your point. If you have things like mirrored RAID doing backups you most likely have an adequate internet connection and build your team based on relevant requirements.

Projects come in all shapes and sizes, so do budgets and infrastructure. Private hosted GIT/Subversion accounts are a $10/mo commodity -- I can host either or both for no extra charge through my $9.99/mo webhosting package that I'm already paying for. I fully acknowledge and explicitly say that Dropbox is an option for small teams if they can live without capital-V version control. My argument is that proper version control isn't that much more difficult to grok, and its benefits begin to outweigh the simplicity of something like Dropbox pretty quickly once you have more than one person working on the art assets. No, you don't necessarily need to retain every version of an art file whenever an artist decides to recolor something, but Dropbox will do that by default too.

You spend some time knocking how some of the problems are because of workflow, but branches solve those problems and allow everyone to keep working at their own pace. I agree the code and art teams need to coordinate, dropbox doesn't change that, and to the extent possible the code should be robust about art being out-of-date. But that doesn't mean the repository of art-history needs to be sub-standard. I'd rather have the capability and not use it, than to lock myself out of it ahead of time. Things like atomic checkin are really nice, and AFAIK Dropbox can't guarantee atomic checkins of a package of changes, or even package a bunch of files together at all. Branches and tags are also pretty useful.

If you're a small team, drop-box works for you, and a complete lack of file versioning doesn't scare you, fine.
...
As a programmer these days I don't undertake any non-throw-away project without version control, even if I'm the only one working on it.

Dropbox/Google Drive don't "completely lack" file versioning... see above...

It keeps old versions around, probably with a date-time stamp of some kind -- you might be able to correlate the two independent systems, but its error-prone. This isn't capital-V Versioning, Dropbox has no notion of what art asset file in its history matches up to what version of your source-code assets.

Hi,

Usually email is good enough, but if the file is gigantic, such as a huge map for your game, then uploading to your website FTP or to something like Sourceforge would be the way to go. Your team can get at it that way.

Clinton