Development Process
First of all, I’m sorry about the lack of updates. I’ve gotten stuck in a loop of feeling like I’m behind schedule
and freaking out about making survival mode as fun as I can.
I’ve decided to take things slow for one more week,
then start fresh August 1 when I work three days full time on minecraft each week. I’ll keep you posted. =)
I got a request to blog my development process for minecraft, so here it is:
There is no design document. There are, however, two very good text files: bugs.txt and features.txt. The former contains a list of bugs that I can’t fix straight away but want to fix. The latter contains a list of ideas I like but am afraid I’d forget if I didn’t write them down.
I start by checking my email and the purchase transaction logs. Sometimes a purchase has failed to automatically verify and I have to do it manually. Sometimes one of them is someone trying to buy the game for €0.01. I don’t really mind people doing that as I consider that money a donation unless told otherwise (in which case I would issue a full refund, but that’s never happened).
Then I start up Eclipse and some kind of music service. Usually spotify, sometimes just mp3 files from the local hd,
sometimes internet
radio. Then I start up the IRC client. I start IRC last because otherwise I have a tendency of getting stuck
in there.
Usually, I know what I want to do that night/session and get started on that. When I don’t, I check
features.txt. I say hi on irc and check if there’s anything urgent going on I should know about.
When coding, I try to make things work first of all. I get something at all happening in game first, even if
it’s a horrible hack, then I refactor the code afterwards to clean things up. I find that helps make sure the code
doesn’t get over designed, and it really helps motiviation to actually see things happening in the game. One
down-side of this is that sometimes I code myself into a corner and have to spend two hours just cleaning up the
code, but my gut feeling is that I’m more efficient this way.
Besides, since the feature’s in the game from the
start, I get free testing of it when testing the code refactoring.
That’s another thing. I spend a lot of time testing, probably more time than I actually spend writing code, except when doing things like network or server or website code. It’s very important to me that things are actually fun, and the only way to make sure they are is to play with it. (And since I find the game fun, it’s also fun to play around with it).
When I’ve finished a feature, I try to release it to the public as soon as possible. Before doing so, I check buglist.txt to see if anything there has gotten to the point where I can fix it immediately. Then I bump the version number, run the build script (takes about 30 seconds, if you’re wondering), increase the version number in the jsp page, then upload them in the correct order to the web site and blog about the new version.
I don’t keep any schedules on when I want to have stuff completed, but rather keep striving towards my mental image of what I want the game to be like. If I’m ever unsure of what to do next, I play the game as if it was completed, then add the first thing that doesn’t work yet. Sometimes I can do rough guesses on when things are going to be done, but doing so is a great way of making sure they won’t be delivered on time, and it just adds stress.
This way of working works great for me and lets me prototype things quickly. Since refactoring is so built into the process, I think the code becomes more flexible as a result. When working in bigger teams, you obviously need more organization. I’d use scrum for teams with more than two developers.
