This weekend held a pair of grueling 14 hour QA sessions for our upcoming game. I have contract work through the end of the month (ill-timed, but monetarily important) so it’s been very difficult keeping up with QA work to get the game out the door. A few take-aways:
- Remember to take lots of scheduled breaks during 14-hour playing sessions or your arm will twist up like a pretzel. Sandra and I were both in considerable pain this weekend. When it hurts to move the mouse, video games seem a lot less fun.
- When taking a break, get away from the computer! Otherwise you’re not helping the over-mousing situation. I recommend a session of Puzzle Quest on the DS. It uses different hand muscles.
- We use an internal wiki to check things off the QA list, to make notes, and to record bugs. This works pretty well for small teams. By all means, you must have a QA check list.
- You need multiple QA sessions in order to get a real handle on game balance. Each time we played, our skill levels with the game would be different. I’m better at the game in the mornings than in the afternoons, too. Take notes about each session and average them!
- Remember that after 100+ hours of playing your game, you are the world’s greatest player of your game. Balance accordingly! Err on the side of being too easy, even though that is an incredibly hard thing for many game developers to do. “It has to have some challenge, or what’s the point of having spent all this time on it?” Two answers to that:
- Casual game players don’t want nearly as much challenge as other types of gamers. “Casual” should be a tip-off there. You still need challenge, but you need a more relaxed pace of difficulty-ramping.
- By the time you’re play-balancing the game, you no longer have ANY idea what level of difficulty is appropriate. Err on the side of easy, and then get other people to test it to make sure it’s not too hard.
I’ll post the QA list up later, too. That might help people who are trying to figure out what a QA list should look like.