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.
|
Great article, and great game! I wished the movie had a better success, and that the game got more sales. It is really shameful that such work is ignored by the public while shovelware gets million sales.
An excellent article that reinforces key strategies to help ensure a broad acceptane of an entertainment product. No you shouldn't design to "please everyone", but quite often it's the simple tweaks that make the world of difference.
"Shunt issue" reminds me of an issue with Wii Fit, with the soccer minigame where the players need to balance left or right to hit the ball with their head. The problem was that the developers coded it so that the character would move the way the players pressed the board, however they missed the fact that, when in equilibrium, the player would slightly press with their opposite foot to quickly move to the other (so if you are standing and want to balance left, you would first press with your right foot to swing left, instead of gradually letting your weight on the left side). Therefore first players almost always have problems with that game, since the board reads both and the character just stays in the middle.
What you assume as a programmer is never what the end user wants, no matter the industry. For example, who the heck likes the Visual Studio 2005 immediate window after having used the Visual Studio 6 one for years?