Paper Prototype Critiques for Week 11
Feedback and critique for Paper Prototype presentations from week 11. All feedback is focused on how the Prototype play test were conducted, not on the core game design idea.
Project title: Aquila
Project Manager: Mohamed El Eryan
First things first, after taking a look through their testing document, I just want to comment that they should always keep all the information separate of their testing subjects. It may be nit-picking, but you never know when you'll need that info isolated.
Once again, this didn't actually have a paper prototype: they'd managed to conjure up a full, digital prototype this early on. That makes my job more difficult.
The value of any feedback they received was, naturally, invaluable, as all the feedback dealt specifically with the gameplay mechanics working in exactly the way they had been designed for implementation.
However, expanding on what I said before, all the info they received was lumped into a single mass of text containing all their feedback. It's always important to distinguish feedback between testers so you know if one person might have encountered a lot of trouble, and others only a little. It's a simple thing to do, and can only help you in the end.
Project title: The Legend of Chopstick Chung
Project Manager: David Yao
Similar gripes, they really need to keep feedback from specific people separated in the testing document, but the kept paper copies outlining each tester's written concerns, so I'm not all that concerned.
AND, once again, a digital prototype. All the information they acquire will be instantly relevant and usable for the final game.
I really like how they documented the whole test. Lots of detail, lots of feedback. They even simulated another potential aspect of their game: competition. They allowed every tester to enter a sort of mock-competition where their results were recorded and compared to other testers. Seeing as how their game is based around mini-games that store user scores, implementing this idea outside of the game spurned the user to more focused gameplay (playing to be the best can do that, you know.)
I do think, however, they should have designed more mini-games to test, or at least simulated the other parts in paper. That would have fleshed out the entire test.
Project title: Deep Field
Project Manager: David Milam
This was one of the more complicated paper prototypes, easily. Utilizing paper as just a part of their prototype, they converted their idea (much like we did with ours) into an actual physical activity. Although they didn't have a testing document for me to brief through, let me see if I can break down their paper prototype:
Basically, they're testing the player's ability to survive against the supply of enemies approaching them. A classic 'survival' type of game. It's true, as they say, that only with a physical prototype could they have been able to test this approach accurately.
However! As with ours, you can't accurately test the finer mechanics of the game in any sort of non-digital prototype, just the more core ideas behind the game. They did this well enough, and certainly demonstrated as aspect of the dynamic values of the game. Having to follow multiple targets all around you would certainly be a stressful thing to deal with, in any situation.
Well done, but a little light on the details of the testing: I would have liked to have seen their testing document, though. I'm also a little concerned with their use of Torque 3D . . . we've already had to abandon it because of time constraints: I don't know if they'll be able to make the game they want in time.
Project title: Dynasty
Project Manager: Denesa Yip
Break it down! This team's approach was pretty basic on the actual procedure for the prototype: paper version of an RPG-like game, with some exploration and puzzle solving elements in there for good measure.
But! What I really liked was how they broke down their questions: very detailed, very specific, and plenty of them.
They kept careful track of the responses of the testers, and kept the feedback they provided for each part of the game AND each question completely separate. Plus, based on the number of questions and the detail, they really thought things through before actually conducting the play test. They really knew what they wanted out of the test, and made sure to get the information they need. Very nice, very thorough. I like that.
Thankfully, too, the game's basic design matched up well with the paper version, so they were able to the test the basic dynamics of the game early on. That'll help them in the long run.
Project title: Aquila
Project Manager: Mohamed El Eryan
First things first, after taking a look through their testing document, I just want to comment that they should always keep all the information separate of their testing subjects. It may be nit-picking, but you never know when you'll need that info isolated.
Once again, this didn't actually have a paper prototype: they'd managed to conjure up a full, digital prototype this early on. That makes my job more difficult.
The value of any feedback they received was, naturally, invaluable, as all the feedback dealt specifically with the gameplay mechanics working in exactly the way they had been designed for implementation.
However, expanding on what I said before, all the info they received was lumped into a single mass of text containing all their feedback. It's always important to distinguish feedback between testers so you know if one person might have encountered a lot of trouble, and others only a little. It's a simple thing to do, and can only help you in the end.
Project title: The Legend of Chopstick Chung
Project Manager: David Yao
Similar gripes, they really need to keep feedback from specific people separated in the testing document, but the kept paper copies outlining each tester's written concerns, so I'm not all that concerned.
AND, once again, a digital prototype. All the information they acquire will be instantly relevant and usable for the final game.
I really like how they documented the whole test. Lots of detail, lots of feedback. They even simulated another potential aspect of their game: competition. They allowed every tester to enter a sort of mock-competition where their results were recorded and compared to other testers. Seeing as how their game is based around mini-games that store user scores, implementing this idea outside of the game spurned the user to more focused gameplay (playing to be the best can do that, you know.)
I do think, however, they should have designed more mini-games to test, or at least simulated the other parts in paper. That would have fleshed out the entire test.
Project title: Deep Field
Project Manager: David Milam
This was one of the more complicated paper prototypes, easily. Utilizing paper as just a part of their prototype, they converted their idea (much like we did with ours) into an actual physical activity. Although they didn't have a testing document for me to brief through, let me see if I can break down their paper prototype:
Basically, they're testing the player's ability to survive against the supply of enemies approaching them. A classic 'survival' type of game. It's true, as they say, that only with a physical prototype could they have been able to test this approach accurately.
However! As with ours, you can't accurately test the finer mechanics of the game in any sort of non-digital prototype, just the more core ideas behind the game. They did this well enough, and certainly demonstrated as aspect of the dynamic values of the game. Having to follow multiple targets all around you would certainly be a stressful thing to deal with, in any situation.
Well done, but a little light on the details of the testing: I would have liked to have seen their testing document, though. I'm also a little concerned with their use of Torque 3D . . . we've already had to abandon it because of time constraints: I don't know if they'll be able to make the game they want in time.
Project title: Dynasty
Project Manager: Denesa Yip
Break it down! This team's approach was pretty basic on the actual procedure for the prototype: paper version of an RPG-like game, with some exploration and puzzle solving elements in there for good measure.
But! What I really liked was how they broke down their questions: very detailed, very specific, and plenty of them.
They kept careful track of the responses of the testers, and kept the feedback they provided for each part of the game AND each question completely separate. Plus, based on the number of questions and the detail, they really thought things through before actually conducting the play test. They really knew what they wanted out of the test, and made sure to get the information they need. Very nice, very thorough. I like that.
Thankfully, too, the game's basic design matched up well with the paper version, so they were able to the test the basic dynamics of the game early on. That'll help them in the long run.
posted by Cody Church at
8:27 PM
<< Home