[Sidhe's Griffiths discusses in depth how the GripShift developer playtested, and then took that feedback to improve, their Wii version of the recent Speed Racer game, from Wiimote tweaks to difficulty changes.]

Playtesting a game for the very first time is an incredibly daunting task. I'm not talking about all the preparation that goes into it; I'm talking about the abundance of negativity that is bound to be thrown your way.

The first time players get their hands on the game always results in problems -- and when it comes time to write up the report, I realize with each soul-destroying point that it's my job to then present this information to the developers.

However, the light at the end of the tunnel is that we can find and tackle these problems while the game is still in our hands. Once it has been released, it is too late, which is far from a good thing.

There is always the tendency, though (and I myself am guilty of this) to believe that your game is going to be perfect. Surely, after all the hard work put into it, there can be nothing wrong! However, I usually don't have to wait two minutes into the first session to see the hard-hitting truth quickly come to light. Something is always too difficult to do, or the player does not understand how to go about a certain problem.

What is important to note however, is that even though a number of issues can come to light during the playtesting sessions, factors such as time and budget considerations means that some, unfortunately, cannot be addressed.

This article looks at how we went about playtesting Speed Racer the game, highlights a few of the issues we came across, and what we did to address them. Hopefully from this, it will be easy to see the benefits of playtesting and putting the user experience at the forefront from the onset.

So, what did we do for Speed Racer, then?

Sidhe worked on the Wii and PS2 versions of Speed Racer (although this article is aimed solely at the Wii version).

It was our first ever Wii title and we had an incredibly tight timeline of 10 months' development, so this meant that whatever we did, it would have to be right pretty much the first time. However, as you can probably imagine, things didn't go right first time, and a variety of issues came to light that were a mixture of expected and unexpected.

Yet, we did get it out on time, and it actually received pretty good reviews. In fact, it is one of the few movie license games which consistently scored higher than the movie it was based on.

One of the ways we were able to create such a solid game was through playtesting on those players who would be playing the game (in this case the target demographic was 9 - 14 year olds). Once they were in, every aspect of the session was recorded; from the gameplay to the player's expressions and the way they use the input device. While it may seem overkill, everything can potentially be used to fine-tune a game.

When running my playtesting sessions, I always split them into two. The first session is held with only around four players and is used as a way to conduct a general exploration of the game's main features and to get a basic feel and understanding of how players approach the game.

I then take the issues found and group them together, which lays a good foundation of reference during the remaining sessions. Of course, there will be many more issues found, but it is always good to have something to work from and I find that this serves quite well. Then, by combining these playtesting sessions with my own in-house methodologies, I can offer potential solutions that go along with the report.