Version Control
If you haven't started using this, now is a good time. What is version control? It's basically a backup program. Instead of having backup files and folders -- if that's been your backup system -- version control takes a snapshot of your project with every change you make. Every snapshot is a version of your project in development, and you can go back to it at anytime.
I used to backup my projects with zip archives (backup-2012-01-01.zip, for example). This is better than nothing, but frustrating. If I went of the rails on some new feature and need to roll back, it might be to a backup a week or month ago -- whenever I saved it last. It's too much work to back it up every day, let alone for every change this way. It can be demotivating to work back to where you were from when you last backed up (which could have been days, weeks, or longer). But with version control, every change is recorded, so I don't run into this problem -- or if I do it is just a couple changes needed to get back to where I was.
I use Git. If you develop on Windows, then Mercurial is a good alternative. SVN is okay, but Git and Mercurial are much better. This article isn't a tutorial on version control. You're on your own here, but there are great articles on the web. Just Google them.
Keep a Log
Keep a log of your project. I don't mean some boring summary every day. Whenever you make a change, just note it. This makes it easy to get back up to speed in case you left your project for longer than a week. You can look back at what you did without struggling to remember.
Version control programs let you take notes with each commit (version, snapshot, etc.). I use this feature in Git to keep notes on the changes I make. Sometimes it's just a one-line summary, other times a couple paragraphs. Writing something someone else would understand is a good rule.
Here's an example of some notes for Toadman 3:
commit 561f32bd9b5ad211055b53d08e68a87e9d066b94
Author: Joe King
Date: Sun Nov 18 12:09:53 2012 -0700
Add title background
This will be used for the game menu.
commit 44b1af17d755e8f9d0630e5f6ce31ae7c4b7404d
Author: Joe King
Date: Sun Nov 11 20:46:42 2012 -0700
Add font module
I consolidated the font rendering responsibilities into this module.
I also added a text centering method.
commit b840795611af50f19dc6c350f70f2ed1e8a28107
Author: Joe King
Date: Thu Nov 1 23:01:26 2012 -0600
Fire puffs of smoke when tree is destroyed
It looks cool and gives a more rewarding feel to the destruction.
commit 1705174faa5288f44fb6c83fa48b5f0d9e3a8a28
Author: Joe King
Date: Thu Nov 1 22:58:22 2012 -0600
Give ice-brick graphics winter theme
For the ice-brick levels, I updated the tiles to reflect a more winter
type of theme.
Keep track of your bugs!
Write down every bug you encounter. These are easy to forget. Yes, you don't completely forget all of them. But it's easy to release a demo with some bug you meant to fix, sometimes finding that no one could get passed level one because of it.
Not only this, but I bet you'll record more bugs than you thought you had. You can only juggle so many bugs in your head at a time; it's easy for the not-so-annoying ones to slip under the rug. Once you clear your head of the bugs that are currently bothering you (by writing them down), you're able to spot more bugs. These might have been bugs you spotted before, but subconsciously ignored because of more pressing bugs.
Once you have them all written down (or as many as you can), you now have a list of bugs you should fix before releasing your game. Or you could at least prioritize them and take care of the ones that are worth fixing.
No comments:
Post a Comment