[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.

Some of the issues

Speed Racer was an interesting title because while it was a car-combat racing game, there were no traditional weapons the player could use. Instead the car itself was the weapon, and by utilizing the Wiimote, players were required to perform a number of "Car-Fu" maneuvers.

In order to do this, we had to ensure that the controls were tight and that the player would not be required to carry out complex combinations -- as Speed Racer was meant to be an extremely fast racing game. If anything deterred from that, it just wouldn't work.

It's a Car-Fu game, but they don't use it!

We had hoped that Car-Fu would be a breeze to pick up and play and that players would be excited to use it. Imagine our horror when the first problem we encountered was that players were just not using the Car-Fu. This was a pretty big deal because Car-Fu was a huge part of the game and if players were not "getting it" then we had a problem.

The problem was that players saw the game simply as a racer, and even after an hour and half of play they would simply forget that Car-Fu was available. The way around this was to therefore remind them that this was available in the game (visibility and affordance rules once more people) but we didn't want to explicitly instruct the player to use Car-Fu, as this would break immersion.

Instead, a more subtle way was needed. So the best way of doing that was by simply showing them Car-Fu happening within the game.

This was done by simply getting the opponents to do more Car-Fu against one another, and on the player too. By giving players this reminder, they then realized that they could also do this. This also served as a way to increase the challenge, because when a player got attacked, they would instantly get the desire for revenge and charge down the infidel and carry out Car-Fu on them.

When they realized what they could then do, the enjoyment of the game simply rocketed.

They're not using the Wiimote correctly!

Using the Wiimote for a driving game was something we thought would instantly be intuitive. While the game supported the Mario Kart wheel add-on, it could also be played without it. What we didn't foresee was the way people would take it upon themselves to use the device.

The player was given a small animation showing how to hold the Wiimote, and we assumed that it was straightforward enough. However, what happened was that the majority of players perceived the animation as if it were from the top-down, and so would control the car as if they were using the steering wheel of a pickup truck.

Of course this meant that the movement wasn't picked up and it was clearly obvious that they were quickly becoming frustrated when the car would simply collide with the wall -- being totally unresponsive to their needs.

This went on for some time, and no matter how we adjusted the images or the animation, players were just not getting how to hold the Wiimote. This was getting to be a huge problem, because the game was effectively stuck in the water. Nobody could play it.

The solution to the problem was actually incredibly simple. Observing people reading the instructions, I realized that while they had the animation and the images, they had no frame of reference to them. Each person would see and interpret them differently.

Therefore, for the loading screen we put in a simple black and white image of a television screen, with the Wiimote in front of it. It was hoped that this image would act like a frame of reference for holding the Wiimote. And it worked! The next time we ran a playtesting session the players picked up the Wiimote and were able to instantly drive.

Car handling: extremely twitchy

This issue was something which slipped by us simply because we were so used to the handling of the car that we didn't realize there was a problem.

As players took hold of the controls, they found that the handling of the car was so sensitive that doing simple things such as driving in a straight line was difficult to achieve, which meant that trying to get the car successfully around a corner almost always resulted in the player crashing with the barrier. This was obviously viewed extremely negatively by players.

By spending some time tweaking the car handling, we were able to drastically improve the game. Figure 1 shows a graph giving us a before and after view.

Figure 1. Error comparison between sensitivity changes

As can be seen, the number of errors made was drastically reduced, while the average time between errors was increased. Additionally, players often found themselves winning the first race, therefore giving them strong, positive feedback early on and enticing them to continue.

Shunt issue

Performing a side-shunt meant having to shunt the Wiimote quickly to the left or right, as shown in Figure 2.

Figure 2. Example of how shunt was performed

This would cause the car to slide sharply in the direction and hopefully hit a car. While there was no problem performing the action, it was the result which was not expected. At the apex of the movement, we found that instead of the Wiimote coming to a stop, the laws of physics kicked in and there was a slight jerk, which was equally as strong, in the opposite direction.

Unfortunately, the game would pick this up, and this resulted in the car going the opposite direction to what the players wanted, as shown in Figure 3.

Figure 3. But what actually happened

This really frustrated the players because of obvious reasons; the car wasn't doing what they wanted it to do.

The solution to this was to use both the player's actions and software combined. We found that the player always shunted with vigor; there was never any half-movement to it.

So, we decided to utilize this, and toned down the sensitivity of the Wiimote quite a bit. This meant that when the player performed the shunt, it wouldn't pick up that little bit of after-movement at the end of the gesture.

UI Issues

Ah, the dreaded UI. I'm sure every developer has had issues with their UI and this was no exception. The UI relayed information as and when it was needed. For example, it told the user if their health was low, or that boost was available.

Additionally, the color of the flame coming from the car would change in relation to its health. Therefore when the color was a deep red, the car was pretty much on its last legs and an explosion was imminent.

What we had decided, however, was that this would be available for early races -- but to increase the challenge, it would be removed for later stages. It was hoped that the player would become more adept at using the UI and be aware of their car situation. This was not the case.

The first time we implemented this, players kept blowing up and, from their perspective, they had no idea why. The problem here was that players were becoming accustomed to the game informing them about their status, and when it no longer did this, instead of learning how to play the game without it, they just blew up.

The first thing we did to try and solve this was to simply remove it altogether -- to force the player into learning how the UI worked. Unfortunately this approach completely backfired, with players simply blowing up all over the place. This was not a good turn of events.

So, the only thing left was to put everything back in and make sure it flashed up whenever the player's health was low or when boost was available. This is actually an interesting situation, because it shows how much players rely on the game informing them about important states.

How far behind or in front of me are you?

One significant thing about the tracks in Speed Racer is that they are pretty long. The problem with this was that players sometimes found that they had no real idea where they were in relation to the other cars, and actually found themselves wanting more in-race information.

This was intriguing because no other racing game required this kind of feature. As long as players saw what position they were, they were usually happy. However, it seemed that when a race was quite long, then more information was needed as a result.

The solution to this was to include position information to the left of the screen. This showed the person in first place, the person immediately before the player, the player, and the person immediately behind the player. This was all in relation to the player's position, so the times were all relative, and as a result of this, we were able to give players the information they required.

They were able to immediately ascertain how far ahead the next player was and also how far ahead the first position was. Not only did this aid the players, but we found it actually increased the challenge level of the game, too -- a win-win scenario. This is shown in Figure 4.

Figure 4. Racing UI

Discussion

The solutions we found for the above issues were also adapted and used in one way or another for many of the others found within the game, and by spending time playtesting, which did not tax the development process, as sessions can be run concurrently with development itself, we removed a huge number of issues that would otherwise have potentially remained within the game after it had shipped.

You need to ask what would have happened if that had been the case. It is certain that not only would the reviews have been a lot lower, but the word of mouth between the players themselves would have been extremely negative too.

The final part of playtesting is to verify that the changes you have made actually work. This is a relatively easy matter and can be carried out when running other sessions. Observing if issues come up or not will quickly determine whether the problems have been solved.

However, it is entirely feasible that problems still occur -- but chances are that there will still have been a drastic improvement. Simply keeping an eye on problems during the sessions should reveal that any required changes will probably only be a few simple tweaks here and there.

For us, the whole game simply evolved over the months, as we were able to fine-tune everything within the game (time permitting) so that whenever a person picked it up -- be it a child or adult -- they would be able to instantly drive the car and perform every action possible.

Conclusion

It can be daunting to go back to the developers with a load of bad news, because these guys work their butts off. To have someone come up to them with a list of negatives is surely not going to be viewed favorably.

However, this is where a willingness to be open and a commitment to free communication is essential.

The developers need to understand that they are not being criticized; instead, they must understand that the information is simply there to enhance the already great work they do. I'm lucky at Sidhe, because people are always willing to listen and to take on ideas and to use the reports constructively.

Regular playtesting with external players is not merely important when developing games. It is vital. Only by getting first-hand player feedback can we know where the problems truly lie within the game.

Those of who play the game every day learn to compensate for many of the problems with our own shortcuts, and can never look upon the game with fresh eyes. Real-world gamers will never play like this.