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.