There is a goal I have, regarding this game project. I want to get to the point that I was with Warcraft III nine or ten years ago: everything is in place, and I just ride off into the sunset making and never finishing levels. I want my development kit to be such that I can just play around with scenarios, throwing them together so quickly it doesn’t matter if they don’t pan out. I have hundreds of these nascent Warcraft maps stacked away.

That goal is a long way away. Before I can even truly begin writing the engine, I have to get the tools in order.

Version Control

Pretty much everything Unity stores on the hard drive during construction of a game seems to be a text file within a folder structure. Levels, prefabs, scripts — all simple text files (which makes Unity even more my kind of engine, assuming it compiles them all into hyper-efficient binaries for the final build and my precious level data is not left wide open for anyone to edit). This makes it ideal for version control, so that nothing will be lost when I make silly changes that break everything.

Of course I like to keep things offline and local (when the bombs fall and cockroaches inherit the Earth… or BT spuriously cut the wires), while most version control systems are client/server driven, so I had to dig around a bit to find a suitable approach.

It actually turns out that Subversion can be used completely offline, and without a dirty service always running in the background as I was initially led to believe. Since I use SVN at the office, it seemed like the best fit.

S-S-Subversion

You know I’m terrible at command lines, though. The power of Warcraft III‘s World Editor is its nice, friendly, Windows-colour-scheme GUI — take a shoogley 14-year-old and present them with its warm embrace and they won’t run away screaming (unlike, say, Unreal Tournament‘s UnrealEd 2 with its brooding future-tech grey/teal scheme). That’s what I grew up with, so that’s the end goal: all the complexity hidden behind fluff.

SVN is obviously an enterprise productivity tool so of course it doesn’t have a GUI in its basic form. While I don’t mind grubbing around with the command line to create the local repository (this being an operation required precisely once), I do mind grubbing around with the command line for every-day commits and reverts and checkouts.

(Let’s face it — the primary motivation for this is being able to revert my day’s work when I try to do something clever with the unit movement code and end up completely blitzing it.)

At work I use TortoiseSVN, though, so why not use that here? Well, you know how irrational I am. TortoiseSVN is a Windows shell extension, which means it pollutes the whole computer with its radiance. That’s fine at work where everything is work, but I’m at home here and poor old Daedalus is always going to be more than just a canvas for this game. I need something more self-contained and, as noted previously, something that can be integrated into my utopian development kit.

A New Client

I might be irrational and a little bit unhinged but I’m not stupid (at least, not that stupid). SharpSVN is a .Net library that handles all the actual grunt-work of doing actual stuff with SVN, leaving me free to encapsulate it in a tidy WinForms interface. It’s the same library that powers things like AnkhSVN, the Visual Studio plug-in that I can’t use because I’ve only got VS2010 Express at home and it explicitly denies version control plug-ins. (Kind of hoping that when we upgrade to 2012 at work they’ll auction off the old 2010 Professional editions for cheap.)

The desire for a clean and simple interface is another overriding factor. SVN provides a hundred million different options that I just don’t need on a daily basis, so I’m tailoring this client precisely to my needs: update, get modifications, add, revert, commit, get history. Everything else will either be added as it becomes necessary, or stay in cmd-land.

Background Colour

I might have spent a lot of time with WinForms, but I’ve never actually (successfully) done anything with BackgroundWorkers. After my first few SVN operation implementations, I noticed that SVN can be quite sluggish (obviously the fact that it’s not exactly snappy at work either completely slipped my mind). That meant that the interface siezed up whenever it did anything, and that would have become extremely tiresome over the years had I not dealt with it up front.

The move to using BackgroundWorkers actually forced me to do a much-needed migration of logic out of the client form anyway. I created little wrapper classes, one for each operation, to encapsulate the actual logic — once the work is done, it used a given Action callback to give its results to the interface.

Obviously I blamed SharpSVN when it started tripping over itself. In reality, I was firing two operations at once instead of in sequence (commit then check for modifications to refresh the file tree).

The Next Step

Well, now that I have SVN I can start actually working on the game. When I try to do something clever to the unit movement code and end up breaking it completely, for example, (and not that I did that once before, no sirree), I can safely revert the changes and keep going from a position of strength.

So, I’m making a game and I’m making a pile of my own development tools. Told you I wasn’t one for half-measures.