One of the most valuable tools available to a game developer is a reliable version control system. A good version control solution can be the cornerstone of any development environment, but especially so with a distributed team, like we have at Urbansquall. Getting a reliable version control system in place is one of the most important steps to supporting effortless development and is crucial for any team based development. In this article, we’ll explore some of the benefits of source control, and how best to leverage this to move us closer to effortless game development.

NOTE: There is a lot to cover in regards to version control, so I’m going to strive to be as brief as possible for this article so that it remains easy to digest.

Why Version Control?

• Recover from catastrophe: In the event of a harddrive failure or natural disaster, you know that you can lose no more than a few hours of work. Also useful if your cat walks across your keyboard and deletes a few essential files.

• File sharing: A good version control system works almost exactly like a shared harddrive. This is a great way to share files with team members.

• Versioning: Track every important revision of a document and access older versions at any time. Good for referencing how you implemented a feature before you broke it.

• Concurrent editing of text files: Edit a file without needing to be worried about who else in your team might be working on it. Your version control system will automagically merge the two files when you are done.

There are many other benefits of version control, but these are by far the most important.

Major Concepts

Typically a version control solution is a combination of the version control Server and the Client that accesses it. The Client operates on your local machine. It will pull an instance (called a checkout) of the project (called a repositry) from the Server to your local machine’s harddrive. You interact with these files like you would any other. Your Client will remember which ones have changed and how. When you are satisfied with your changes, typically after completing a revision of a document, or implementing a new feature in code, it is time to send your changes to the Server (called a commit). If someone else has changed something that you were working on, the Client will force you to pull an update from the Server to verify that the changes you wish to make are consistent with new state of the repository.

If that sounds confusing, then let me use an analogy. Pretend that the version control Server is just like an FTP Server, except that it stores (in a different place), a copy of every file you ever uploaded to it so you can access them at a future date. If you want to update a file on your FTP Server, you usually download it to make sure you have the most up to date version, make your changes and then upload it. This is conceptually similar to how you will interact with an version control Server, except if you use a good version control Client, the interaction with the server is almost entirely invisible (unlike FTP which can be a real pain in the neck to use!).

The core version control actions are:

Check Out: You usually do this only once, and it is to pull all the files from the repository onto your local machine.

Update: This updates your local Check Out with any changes that have been made since your last Update or since your check out. If a team member has Committed a new file, then this is how you would retrieve it.

Commit: This is how you send your file modifications (including new files, or file deletes) to the Server. You usually just Commit the root folder of your project and your Client will recurse the folder and look for all the files that need to be Committed.

Version Control Solutions

There are various version control implementations out there. You can go hunt out the rest if you like, but Subversion is probably the most useful one to discuss given its open source nature. What’s the best way to get access to a Subversion server?

• Set one up yourself - If you’ve got a box with a decent connection to the net (and know how to keep it safe from hackers), then you can start by running your own Subversion server. This is how I first started using Subversion. It’s a good start, but there are better free solutions available.

• SourceForge - If your project is open source, your best option is something like SourceForge which will give you a Subversion repository for free.

• DreamHost - Each DreamHost account actually comes with a Subversion server for no additional cost. You’ll have to mess with an SSH client to administer the server, which is not a hassle I’m personally willing to deal with, but if you have an existing DreamHost account, then it is worth looking into.

• CVSDUDE - We used CVSDUDE for awhile at Urbansquall. They’re good, fast, reliable and cheap, but we wanted something that was more integrated with a project management interface. CVSDUDE offers Trac as one option in this regard, but we felt it was not good enough.

• Unfuddle - Unfuddle is the backbone of Urbansquall. This tool is essential to our daily operation. They offer a decently sized free account to get you started. Plus you get a lot of sexy groupware along with your Subversion functionality.

Once you have access to a Subversion server, you’ll need a client with which to access it. The best Subversion client out there is TortoiseSVN. Unfortunately, it’s only available for Windows. I’m still looking for a good one to use on my MacBook. Know of any?

Final Thoughts

If I wasn’t forced to learn how to use a version control system, I don’t know if I would be where I am today. Version control is one of the pillars of effortless game development, and if you don’t have one in place you ABSOLUTELY need to get started with one now. The time you invest in learning how to use a version control system will be paid back to you the first time you use it to salvage a corrupted file. There are dozens of benefits to having a solid version control system in place for your project. You’ll be glad they’re there when you need them.