When I finished Venture the Void, I was thoroughly DONE with it. There was a bit of bug fixing to do but overall, I wanted nothing more to do with the project because I had spent such a large amount of time on it.

@p Since then, Microsoft has released Vista and introduced a few simple incompatibilities. There also seems to have developed a few issues for linux, and so I wanted to address these. I'm not interested at all in adding new features, but keeping the game "alive" is something for now I do want to take care of.

@p The problem is, the part of my brain that understood how the file system/build system was organized has now been allocated (thankfully) to other more meaningful pursuits (and I don't even mean game development!) So if I'm going to dig this beast up, which I do want to do, how am I going to keep it current?

@p The answer is afewfold:

1. Set up a subversion repository for the core source code.
2. Organize the file structure, and set up some kind of structured backup.
3. Unify and document the build/release system as much as possible.

By doing this, I can bring the code into eclipse as I need to (and delete it when I'm done developing), make changes/fixes, build it, and then release. So far step 1 and 2 are complete. When I have the bugs squashed, that I wanna squash, I will figure out step 3.

@p The key, really, is the subversion repository.

@p I can mirror the repository somewhere with rsync, to keep backups automatically. Minimal fuss and bother, and I can keep my past projects organized and available without having to think too hard about it.

@p By organizing the files, I can choose what needs to go into subversion and what can just be archived. As well, I can save my sanity if I ever need to find some information or a past beta release or something along those lines.

@p The build/release system is a harder nut to crack, because it uses two tools: one on linux and on windows something called NSIS which doesn't really work commandline. But even here I think that *most* of the process can be automated with a SCons script (there is a certain amount of data collection, etc.) and beyond that I will just write a small .txt file describing what to do to push out the next release.

@p Another part of the "release" system is umake, which builds the universes. I might as well unify and document this, too.

@p I don't love working on this. But it's better to keep it at least somewhat alive for bugfixes/etc. as it might come up, or for pulling bits of code out as I might like to. And there are parts of the code I'd definitely like to pull out and play with in the future!

2009-08-07

◀ Back