We constantly do general "play testing" - or rather, a general form of playing the game and noting any discrepancies that happen. This could be referred to as finding bugs, but really it isn't. It serves as a way to see if the game is any fun, if the design is "good" and what may have been overseen as pitfalls earlier in the design stages of production. Can things be improved? Does everything "feel" right? Are there overlapping aspects? Simply put, this form of testing finds design flaws not software flaws.
This method of testing happens all throughout the development of the product. This is by no means the only form of testing (nor should it be), but instead gives us the ability to second guess some of our designs as it is being developed and explore some options before publishing the product - more on software testing coming later.
One of the fairly humorous aspects of this is that back in our article about the graphics design where we showed the proposed layout for the game, we had big black circles at the bottom of the screen above the ads that indicated where marbles would occupy. These "slots" were to be used to launch marbles from.
During the development, we ended up shrinking those slots to about half that size so that the launcher graphic underneath could be seen more; since we made those graphics, may as well have people see them, right? Well over dozens of play tests, we found that it was difficult to correctly touch and drag marbles from those slots and be able to actually play the game. We ended up increasing their sizes back to the original layout sizes - taking up the entire height of the launcher.
The gameplay became much smoother and easier to drag marbles out, but the launcher graphic isn't seen easily, yet overall, the game is now smoother and the user should have an easier time actually playing the game; rather than seeing some eye candy. Aesthetics versus function is the issue here, and we chose gameplay over showing off artwork.
This detail was really only found after performing a lot of play tests and from different people. The general feedback was "we like this... but...". This should be taken seriously and addressed during development. Yes, the catch phrase of what users say can take a lot of extra time to implement. Fortunately for us, the slot sizes in this case was easy to change because only two variables controlled the width and height of the slot which "magically" handled both the visual display, and the collision detection of the user input. If these values were hardcoded, this could have been a fun hour or two adventure hunting down and "fixing" all the math that referenced the slot sizes.
When your friends say they want to be game testers, this is generally what they mean without actually knowing it. They want to be play testers, not software testers. Unfortunately for them, usually play testing is a team effort and isn't a dedicated job. For example, this is why software publishers utilize beta tests, they literally outsource play testing to users and gather feedback about the design of the game in a distributed manner -- if they find actual software bugs as well, that's a nice side benefit, but in reality the primary purpose is to assess the value of the design of the product. It is also a nice way to get the word out and serves as a nice marketing gimmick, but that's a whole other issue.
No comments:
Post a Comment