Quick and Dirty Source Control

Jan 31, 2013

I recently received a number of questions from a reader about version control for hobby videogame projects. Responses follow.

Q: How big does a project need to be to benefit form version control?

A: In the laziest, simplest form, I think even a solo game jam can benefit from some crude form of version control (see my last answer here for exactly what I mean by that). As for “real” version control, I tend to only bother if at least 3 programmers are involved with the project, and the project is expected to take at least a few weeks or more.

Q: If I use version control, what should I use? Git, Mercurial, or something else?

A: My opinions on this are likely out of date, so I’d suggest investigating the options to see what’s being said about these newer options. For large-scale commercial development I’ve used Perforce, and for smaller independent student teams I’ve only used svn.

(Update: Michael Foord suggests, via Twitter, to check out Mercurial or Bazaar. He has provided some details in a comment below.)

Q: What client should I use? Github, BitBucket, or something else?

A: Likewise, my tastes here may be outdated, but I used TortoiseSVN when I was in Windows, and just handled svn via command-line when I was in Mac. I can say that I’ve witnessed a number of fairly experienced programmers, myself included unfortunately, bind up a bit when running into certain conflict or folder mismatch issues via command-line using svn, and a good client would also probably go a long way in simplifying that experience. Having a good file comparison tool is important to spot diffs in a conflict, and that’s often part of the client with Perforce or Tortoise, although on Mac I used a program called FileMerge which if I remember correctly was a tool application bundled with XCode.

Be aware that some online services that provide hosting servers or other niceties may come with strings attached, such as requiring that your program is open source, etc. That may sound fine, but even if you’re keen on the spirit of it, that can sometimes drag out a project needlessly by making someone overly self-conscious of how well organized and documented their code is. When code isn’t open source we can occasionally resort to hackery to get things done in special cases without getting self-conscious about it, making conscious tradeoffs to optimize our development time in that case (as opposed to, say, making tradeoffs in readability to optimize code execution time). Of course, if you’re a full-time software engineer and used to or interested in joining larger team environments, for that same reason open source might be a constructive exercise, in which case such licensing implications may not be a concern one way or the other.

Q: How often should I upload a new version?

A: I’m a proponent of trying to work on one relatively isolated, bite-sized (1-4 hours of work) feature at a time. I’ll tend to commit:

  • Each time I’ve completed and tied up a functional chunk, generally amounting to several hundred lines of code or less. This can even become a nice part of the ritual, punctuating a finished task, like scratching something off a todo list.
  • Whenever I finish solving a tricky or creative code issue, or finish a tuning/balancing pass I’m pleased with, that I’m not confident I could easily reproduce a second time.
  • Upon finishing something monotonous that I would not want to do again. This mostly happens when doing some type of hand-adjustment to assets, for example tweaking spacing offsets for every character of a medium/high resolution bitmap font, or renaming several folders of sound and image files to fit an improved naming convention.

It’s important to only check in code that’s ready to compile and run though without interrupting other features or debugger output (i.e. for log/trace statements: clean up, remove, or make toggled on/off in code that defaults to off, before committing to svn), or it’ll throw off other programmers on the project, including future you. If that code is otherwise incomplete, then for now make sure it has been safely isolated from other code still in use, flagged with a short comment at the top indicating it’s not ready for use. Be careful to not break the build, hog the debug output, or degrade performance with a half-finished check-in that will leave others wondering whether their local changes caused it.

Q: Is version control worth it if you are the only programmer on the project?

A: Here’s what I’ve been doing for the past 5 or 6 years when I’m the only programmer on the project (which is very often the case for my hobby projects, even when there’s a team of people involved with assets), it’s a habit I picked up from John Nesky:

  • Every night, when I’m at a good stopping point, I zip up the project’s folder. I save most of the old ones of this, or at least 1 per week, and it makes it easy for me to dig my way “back out” if I find that I’ve coded myself into a corner or introduced some nightmarish bug I’m having trouble undoing. Sometimes it’s also fun when I’m done with a project to look back on old zip files to see what the project was like earlier in development – what didn’t make the final cut, how much rougher it looked earlier, etc.
  • At least once a week, I copy the zipped folder to a location online, like a folder on my FTP server not visible to the outside world. A local external hard drive for back ups is handy, but not sufficient. Nowadays I just copy the zip with dated filename into a special folder that I keep on Dropbox specifically for development backup, and it’s automatically copied to the cloud. The idea of keeping a version of the full source at a remote location is that no matter whatever disaster could happen locally – backpack with my laptop in it falls into a deep puddle, catastrophic hard drive failure, my home gets broken into and my computer and backup drive both get stolen, home burns down, whatever – then at least I have something to pick back up from.

Loss would still be inconvenient, it would still be expensive, it would still be lame, but things can be replaced with money, whereas lost game development work is simply lost time, a huge loss to morale, and if there are other people on your team or a business counting on you to finish, not tending to this properly can make your/my misfortune spread to also become their misfortune. It’s way too simple to back up a project remotely to have any excuse to ever completely lose a project’s code and source/raw/PSD art files.

It’s not your fault if something goes wrong and a hard drive utterly fails, but it is your fault if that happens and you’ve not taken any steps to mitigate that loss.

If a project is tiny enough and you’re at a game jam, and don’t want to set up a Dropbox (but you really should, it’s free and easy to do), at least e-mail yourself a zipped copy of the source every so often. If you don’t have internet access for some reason, occasionally copy that latest zip to a USB stick so it’s not all one the same physical point of potential failure.

It’s not either-or, though. There’s a continuum of source control between having the technical infrastructure of a massive studio, which needs a fully staffed IT department to keep it running, compared to the resources of a hobbyist or student trying to moonlight. While it’s important to not become bogged down with sorting through non-game technical troubles, it would be reckless to have all of the work invested into a project living only in a single directory having one version on one machine. That’s terrifying. At the very least, make a new zip of the directory after a good night’s work on it, and occasionally toss a dated version of that file onto a server in a remote location. If the project is so large, distributed, or complicated that using that method isn’t practical, then it’s time to look into setting up some real source control, whether svn, git, or one of the other solutions out there.



Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.




Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!



All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.