TIGSource Forums

I'm a newb indie developer, but have plenty of software engineering experience. I was wondering what wisdom was out there in terms of cheap/free online collaboration tools for over-the-internet game dev? I've started using DropBox, which seems great and you get 2.5 GB for free - that seems pretty good for sync'ing art assets, and also for hosting builds. What do folks use for version control hosting? GIT seems pretty cool, but GitHub is free only for open source projects (which can be cool..but we don't all want to go open source).

I don't know how github's pricing works, bitbucket (github-alike) will allow you to host a closed-source/private project with up to 5 participants with a free account.

Also I believe (?) you can set up your own git or mercurial server with just a web server.

git/mercurial will potentially start to cause frustrations if you keep very large art assets in them. svn will not have that problem but will be harder to set up.

GIT and Dropbox are a fine combination.

And the point of GIT is to not worry about needing a central server. Just push/pull from eachothers computers as needed.

For Snapshot we use:

- Mercurial and BitBucket. Completely free for a private repo.

- Dropbox for some assets. Only for people who we don't give source access, other than that assets go right into Mercurial/BitBucket. We also use the public dropbox folder occasionally to share screen shots.

- Google Docs for any type of documents that fit there.

- Skype. You can create persistent chat rooms, so next time someone logs in they see all the messages they missed. We have one of these with everyone involved with Snapshot in it, so we are constantly talking. In addition we schedule actual voice meetings every monday and thursday, and any additional times it seems appropriate. You can also share your screen with people, although this only works with 1 on 1 calls apparently.

The first half of development was all done under the same roof, and the second half has all been done remotely. I think working remotely hasn't been all that bad for Snapshot, especially with all of these tools we've been using...   and they're all free!  :)

-Dave

Great, I'll start using BitBucket. I know you can pull from each other directly, but it's nice to have an always-on server since my laptop isn't always on.

It looks like some folks like Merc/GIT for art, but just not for huge art assets? Do they do binary-diffs at all, or will they blow up your repo sizes after many changes?

Does committing art/audio assets to source control benefit you? Does it make sense to do it?

• Chances are you don't need that level of revision granularity for your art/audio.
• Why bother the artists with needing to learn a source control system?

Just put it in Drop Box, and keep a few dated revisions if you need them.

Yes. One of the best things about version control is being able to revert back in time to a previous build. If you can revert back the build of your game, but not the assets for that build, then it's almost pointless.

I think final game assets should always be tracked in version control, along with any builds of the game you make. We have a automatic build process that creates a new release build of Snapshot, checks it into the source control, and then adds a label at the current revision. This way, we can go back to previous labels and have the build and resources for that build.

The real question is should checking in the raw art assets benefit you? Things like PSDs, etc. Personally, I'd say yes to this as well. You never know when an artist is going to stomp over some art accidentally, maybe they named a file incorrectly, or maybe they saved at the wrong time. It sucks losing work no matter who you are.

From what I've seen distributed revision control systems like GIT or Mercurial don't handle these too well. Most big game studios I know of use Perforce, which works well for things like this. Unfortunately it costs a ton of money, but it's free for two users.

I agree with the author above. I personally commit, at the very least, everything necessary for a build. As for the art's source files (PSDs, AIs, and so on), I don't, but you certainly could (but then again, as of yet, I'm yet to work with anyone else).

If that can help :

I have a mercurial repository for my project. I don't have assets yet, but I'm planning to do the following.

I'll setup another mercurial repository. Mercurial 2.0 was recently released and provide an "available by default" (you still need to activate it for your repo) plugin that manage "large files".

So, I have my code repo and my assets repo (in fact several repos, one by plugins of the game).

My code repo references the assets repo as a sub repo and get a specific revision of it. When I need to make my code and some recent revision of teh assets in sync, I make my code repo's subrepo target a more recent revision of the asset repo.

That way I can work on code without updating assets. With the large files extension, artists can freely modify the assets in the separate repo (if they are binary - if mossible I get text). I get almost the same features for code and for assets, but without friction, as I update assets only when I need it.

It's far more complex than using DropBox, so if you want a simple solution, it's not the best.
However, it allow non-friction work with artist. The main problems are making your artist understand how to commit, then push their changes and the idea behind mercurial (that might be the simplest DSVC available). That might be a problem because even with graphic tools like TortoiseHG (that does provide Mercurial 2.0 in it's last version), it's still something to learn that is not necessary if you use DropBox.

For me I'll go this way because I think it will avoid a lot of problems. But I don't think it's good for everyone.

Dropbox is pretty great, we use it for our projects. Did you know it has a versioning system? It keeps every version of your file up to 1 month ago (I can't imagine needing beyond that except in extreme circumstances). It's not as advanced as proper version control, but if you're in a small team it should be OK!