Here’s one for all the students out there.  Since I’m still relatively fresh out of grad school (though I don’t know when one starts ripening, honestly) I often have students approach me with questions about what they need to do/learn/etc that will help them get into game development.  I try as much as I can to remember the state of not-knowing I had before, which is difficult to do as what once were new insights turn into normal routine.

The other day I was futzing around on the internet, trying to find if there was a way to integrate Devtrack and Perforce, when a thought hit me so hard that I nearly fell out of my chair!  Version control software!  Using version control software is so routine, so intuitive, and so integrated into my daily life that I forget there was ever a time in my life when I had no idea what it was.  I feel like that’s probably the case with most game developers who use version control every day.  So it’s not usually the first thing we think of when people ask us what sorts of things are helpful to know/learn for game development.

So, if you’ve never used version control software, or perhaps don’t even know what version control is at all, this article is for you.  Everyone else, please feel free to comment and add other version control tips for new users that I didn’t cover here.  (And remember that not all version control users are programmers)

What’s Version Control?

First up, what is this mysterious version control software of which I speak?  Version control (also called source control or revision control) software manages changes to files to files over time, keeping track of the revisions of files and who made them, creating not only a backup of your files, but a complete history of the project.  It can be used on single-person projects, and is used on large multi-developer projects where many people may be accessing and changing the same files.

Here’s a basic overview of how you work with version control.  Since I’m used to working with Perforce, I will use that as the basis for my example here and throughout the article:

  • With Perforce, all files in a project are stored on some central server.  Some other software, like Git, use distributed version control (which is peer-to-peer, so without a central server)
  • You synch files locally to your machine to work on them, and when you are done, submit them back to the server
  • When you work on a file, you mark the file for edit, so when anyone looks at the file, they see that you have it open to edit.  In Perforce this is referred to as checking out the file (though other software uses “checking out” to mean different things).
  • For most files this means that it is locked and no one else can edit it (even locally on their machine!) while you have it checked out.  Some types of files, like text files, can have people working on them at the same time, and the differences can be merged.
  • You can look back at the history of all the different revisions of a file and see what has changed over time and who made those changes.
  • You can synch back to an old version of a file if you need it, without jeopardizing the most recent changes to the file.

There’s a lot of advanced stuff you can do with version control software, but at its most basic, those are the things to know.  More details on wikipedia for those who want them: 

Screenshot of Perforce: This is what awaited me on my first day of graduate school