Gamasutra is running an in-depth article on debugging memory corruption today:

• Debugging Memory Corruption in Game Development (www.gamasutra.com) – This six-page article looks at symptoms of memory corruption, ways to track down what kind of memory corruption you might have, and different causes and effects. In all my time spent tracking down bugs in game development, it’s the memory corruption bugs that take the most work to find and fix. This is a great article that provides some really useful tips.

The other thing I wanted to talk about today is the prototype, which is not related to memory corruption. I went over to a friend’s place last night to play some board games and he insisted that I bring a copy of my prototype with me. I know he plays a lot of video games, and a lot of puzzle games in particular, so I thought it would be a good idea to get some feedback from him.

Be careful what you wish for…

Seriously though, I got some great feedback from him and my other friends who were there. They were able to clearly express some of their frustrations to me that I couldn’t quite put my finger on.  This leads me to my first point:

• It’s incredibly valuable to get feedback from a lot of different people early on.

There were a few key things that they were able to point out to me. Some other people who have played it expressed the same frustrations, but this is where it all came together for me. Here’s the list of things I need to deal with:

• The learning curve is too steep – I’ve seen this watching other people play, but it wasn’t until someone said last night: “Your game is too hard at the start. How do you expect me to get addicted if I don’t want to keep playing?” that I really realised I had a problem.
• The game is too difficult overall – Even once the players got used to the game mechanics they were becoming frustrated with the game. This is the same problem I’ve been dealing with since the beginning: the game ends up being too easy or too hard. I think I’ve swung back to too hard. The players felt like they didn’t have enough control over when they lost.
• The game needs “special items” – This is something I have already planned for but haven’t implemented yet, but last night I saw how important it will be to balancing the game. Games like Bejeweled have bonus pieces that appear that help you get through sticky parts of the game, and I need something like that. I think it will help the player feel more like the game doesn’t “want” them to lose.
• The presentation sucks – Well of course it does, it’s a prototype! That being said, the more I watch people play, the more I see how important things like animations and particle effects are going to be to “sell” the gameplay experience. Right now there’s not enough reward to doing good things; all you see are the penalties.

At this point I’m kind of torn about how to proceed. Do I attempt to make some of these changes in the prototype, or do I start implementing the game properly and make the changes on the fly? On the one hand, I don’t really want to do the presentation stuff until I’m working on the game proper. On the other hand, I don’t want to make sweeping changes to the game logic (if I can avoid it) once I’m implementing my proper code.

I think what I’ll do is spend another day or two fiddling with the loss condition part of the game and see if I can’t improve that further. I think dropping in some special item code into the prototype might also be the way to go. Then once I’m happy with that, I’ll start working it into a proper game.

Owen