Contents
Practical Game Playtesting: A Wii-Based Case Study
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest News
spacer View All spacer
 
November 22, 2009
 
Video Game Watchdog National Institute On Media And The Family Shutting Down [11]
 
Modern Warfare 2 Infinity Ward's 'Most Successful PC Version' Yet [12]
 
New Tech, Design Details Of Project Natal To Emerge At Gamefest In February
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
November 22, 2009
 
Trion Redwood City
Sr. Environment Artist
 
Trion Redwood City
Sr. Evnironment Modeler
 
Sucker Punch Productions
3D Environment Artist
 
Sucker Punch Productions
Network Programmer
 
Sucker Punch Productions
Texture Artist
 
Sucker Punch Productions
Character Artist
 
Crystal Dynamics
Sr. Level Designer
 
Monolith Productions
Sr. Software Engineer, Engine - Monolith Productions - #113767
spacer
Latest Features
spacer View All spacer
 
November 22, 2009
 
arrow Upping The Craft: Susan O'Connor On Games Writing [6]
 
arrow Small Developers: Minimizing Risks in Large Productions - Part II [7]
 
arrow iPhone Piracy: The Inside Story [49]
 
arrow And Yet It Grows: Analyzing the Size and Growth of the European Game Market [5]
 
arrow NPD: Behind the Numbers, October 2009 [13]
 
arrow Reflecting On Uncharted 2: How They Did It [5]
 
arrow Sponsored Feature: Rasterization on Larrabee -- Adaptive Rasterization Helps Boost Efficiency
 
arrow Postmortem: Wadjet Eye's The Blackwell Convergence [2]
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
November 22, 2009
 
Time Fcuk [1]
 
Accepting the Inherent Value of Games
 
Planckogenesis, Part II: Song Structure & Gravy Train [1]
spacer
About
spacer News Director:
Leigh Alexander
Features Director:
Christian Nutt
Editor At Large:
Chris Remo
Advertising:
John 'Malik' Watson
Recruitment/Education:
Gina Gross
 
Features
  Practical Game Playtesting: A Wii-Based Case Study
by Gareth Griffiths
7 comments
Share RSS
 
 
January 15, 2009 Article Start Previous Page 2 of 4 Next
 

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.

Advertisement

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.

 
Article Start Previous Page 2 of 4 Next
 
Comments

Robert Allen
profile image
Thank you for an article with such a high signal to noise ratio, jam packed with useful information!

Razien Bordello
profile image
Thank you!

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.

Jerome Strach
profile image
From a QA perspective, it is incredibly important that developers check their egos at the door and learn to embrace the feedback from focus group testing. You cannot get this information early enough by the way; how else will you have an opportunity to embed solutions within the code.

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.

Dave Mitchell
profile image
Really great article, thanks :)

Roberto Alfonso
profile image
Great article!

"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?

Shawn Yates
profile image
Great article, made for a very interesting read. Game testing is a huge part of making appealing games and I think that some designers let their ego get in the way of fully appreciating the full value of playtesting. Great charts btw!

Bob McIntyre
profile image
Great, specific detail in here. Very useful information. Thanks for writing this article!


none
 
Comment:
 


Submit Comment