Ranger Archive
Thread: How to Complain: a Primer
Page 1 of 1
GunfighterSmoke
Thu Jul 28, 2005 2:57 am
#1
Hello all! I saw this on another board I visit often, and thought it would be well recevied here in our community. I have not changed any of the original poster's content, and have the permission to submit it here. Although it was created for another game (City of Heroes), I think it can apply here as well. I hope y'all enjoy it! The original post can be found here: http://boards.cityofheroes.com/showflat.php?Cat=&Number=1890478&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1 Sorry but I am clicky challenged!
Ehor
-----------------------------------------------------------------------------------------------------------------------------------------
How to Complain: a Primer.
by Boondocker
Hey there, friend! Do you have concerns about changes to your favourite MMORPG? Are you tired of being ignored by your fellow forum members? Would you like to be a positive force for change? Do you find yourself getting flamed by people who think you're not helping?
If you answered yes to any of the above questions, it might be time to work on your Constructive Criticism skills. That's why we've developed this short introductory course. With it, you might just become a more constructive critic. Let's begin!
Rule #1: Don't be insulting.
When we're providing feedback to the developers of the game, we should keep in mind that calling them things like, 'liar,' 'fool,' and 'incompetent' causes them to view our post with a smidgen less sympathy. So while we may have a valid concern, it's lost on those who we're so vigourously defaming. Let's look at an example of what not to do:
Example: "I can't believe that they call this testing. Their internal testers must be complete donkey-butts, and they must be morons for hiring them."
See? This is filled with hate. What would be better? I'm glad you asked:
Example: "I really don't think that the internal testers did a good job in testing this. Maybe next time they could try to test from a player's point of view?"
Our point was still made --- the internal testing wasn't up to snuff --- but without the venemous, acidic insults that makes the reader want to throttle us.
Rule #2: Provide reasons and examples.
The developers can't do a lot with posts that go to great length to decry changes, but don't explain why these changes are bad. We get much more mileage out of providing some hard, cold data in the form of personal examples that the Devs can reproduce. Let's look at what's wrong with this post:
Example: "OMG! If you nerf scrappers it'll be the end of the AT! You can't DO this! I already get debt and now I'll get MORE!"
What's wrong with it? Well, while we may be very concerned that scrappers will become much harder to play, we didn't tell the Devs why. How are they supposed to take this post seriously if they don't know what's bothering us? Let's try again:
Example: "OMG! Devs, I already have a hard time with even-conned bosses at lower levels. If you include a defense debuff in this power, I'll get chewed up even more!"
Much better! We didn't even provide any numbers. Let's address that in our next point!
Rule #3: Do some testing.
It's all very well for us to have an opinion on some proposed changes, but we're really handicapping ourselves by not having any data to back up our claims. Testing is a great way for us to provide some anecdotal evidence and give the Devs some real, honest-to-goodness data in their database! Here's what not to do:
Example: "This is total crap. I'm never going to play my defender again if this goes through, because she won't even be able to solo minions!"
Ooh, that's a good point! But we haven't even tried to solo minions! Let's hop on the Test Server and try it out, then change our post to this:
Example: "Devs, I just spent four hours playing missions with my defender, Shade of Grace. These were missions against even and +1 mobs, and they took me an average of twice as long to complete as they would on live!"
See? That's information that the Devs can check, because we didn't just pull it out of our hat, we really tested it!
Rule #4: Try to be objective.
I know, this one is really, really hard. After all, our tanker is our absolute favourite character, and we've got 684 hours invested in the little half-monkey, half-orc! But we have to keep a level head: if we can't look at our AT and the proposed changes to it from a middle-ground of objectivity, we're not providing very helpful information, and we're not likely to be taken as seriously as someone who's decided on a more balanced approach.
Example: "THERE IS NOTHING WRONG WITH TANKERS!!! THIS ISN'T A FIX, IT'S A NERF!"
Wow! Not only are we starting off from a pretty biased viewpoint, we're using loaded words like 'nerf' that carry their own, heavy connotations. Also, we're typing in All Caps, and a lot of people really hate that (that's rule #4.5). Let's try this:
Example: "Devs, I know a lot of players think tanks are overpowered. I don't think they are, really, and I'm prepared to argue that this fix goes too far."
Holy Miss Manners, Batman! (Can I say that here? How are we with DC, have they given us any trouble?) That was reasonable, and polite, and though we're still favouring tanks, we're not shutting ourselves off from debate!
Rule #5: Don't make assumptions.
Maybe we've got our suspicions about the changes, and maybe we think that our views are widespread among the player base. Whoopsy, we just made assumptions based on information that's not available to us! What's wrong with this example?
Example: "You Devs are just hitting us with the huge nerf bat so that we'll be glad when you pull back and only make it a small nerf. Well, I know that the majority of players think you're going too far, and you're going to keep leaking subscribers like you are now if you don't wise up!"
Wow! We sure are Russell Crowe from The Insider today! Except that we don't really have the proper information to back up our claims. We can't read the Devs minds, so it's pretty unfair to assign them motivations (also see Rule #1). We also shouldn't claim to represent the majority of players... we don't know how they feel! Also, we're making ultimatums, and a lot of people really don't like that, either (let's call that Rule #5.5).
Example: "Devs, I don't know why you handled the latest changes like you did, but I don't much like them, and I don't think I'm alone."
Much better! I think we're getting the hang of this.
Rule #6: Don't use hyperbole.
Hyperbole means: gross exaggeration (roughly). It's not productive, and causes people to take our arguments less seriously. It also gives them an immediate avenue of attack! Let's not give them the chance, as we do in this example:
Example: "HOLY CRAP! There is NOBODY on Justice server right now! I haven't seen anyone from my SG in MONTHS! Everyone is leaving for other games because it takes A MILLION YEARS to level in this one!"
Whoa there! We're saying some pretty outlandish things! We might have a couple points, but the first thing other posters are going to do it point out how crazy we are to be tossing out those exaggerating statements (then they're going to refer us to Rule #5). Let's give it another shot:
Example: "Holy cow! Are there less people on Justice these days? I'm having a hard time levelling, it just takes forever. Maybe that's why the server seems less populated?"
We're still violating Rule #5, but as least we don't sound bananas. And we're not using All Caps; always a plus.
Rule #7: Grammar & spelling count.
They do! I know, it's weird. We can read it, other people obviously got our point, and really, this isn't English class. But the sad fact of the matter is, we live in a society that sees decent grammar as a sign of intelligence. It's true! And to top it off, we're using a medium (the Internet) that's based mostly on text! One last bad example:
Example: "i c u devs dont care abot us plsyer nemore well tihs nerfis 2 much1 ND IM LAEVING LIARZ!!!"
Wow. There's probably a smart person behind that typing, someone who can fish, and make sandwiches, and play dodgeball! But the reader just sees a demented ten year-old with a learning disability. Whoops, I just violated Rule #1! Sorry. But seriously, if we can't take the time to make our argument in a readable fashion, we're going to undermine our cause! And the Devs might take our post less seriously than someone who put more care into theirs. (For bonus points, how many other rules did we violate in that example? See below for the answer!*)
Well, that was a whirlwind tour of the Rules of Constructive Criticism! Let's recap what we've learned.
Rule #1: Don't be insulting.
Rule #2: Provide reasons and examples.
Rule #3: Do some testing.
Rule #4: Try to be objective.
Rule #5: Don't make assumptions.
Rule #6: Don't use hyperbole.
Rule #7: Grammar & spelling count.
I hope you learned something today by tagging along. I know I did! Good luck out there, testers!
* The answer is: all of them!
----------------------------------------------------------------------------------------------------------------------------------------
If you answered yes to any of the above questions, it might be time to work on your Constructive Criticism skills. That's why we've developed this short introductory course. With it, you might just become a more constructive critic. Let's begin!
Rule #1: Don't be insulting.
When we're providing feedback to the developers of the game, we should keep in mind that calling them things like, 'liar,' 'fool,' and 'incompetent' causes them to view our post with a smidgen less sympathy. So while we may have a valid concern, it's lost on those who we're so vigourously defaming. Let's look at an example of what not to do:
Example: "I can't believe that they call this testing. Their internal testers must be complete donkey-butts, and they must be morons for hiring them."
See? This is filled with hate. What would be better? I'm glad you asked:
Example: "I really don't think that the internal testers did a good job in testing this. Maybe next time they could try to test from a player's point of view?"
Our point was still made --- the internal testing wasn't up to snuff --- but without the venemous, acidic insults that makes the reader want to throttle us.
Rule #2: Provide reasons and examples.
The developers can't do a lot with posts that go to great length to decry changes, but don't explain why these changes are bad. We get much more mileage out of providing some hard, cold data in the form of personal examples that the Devs can reproduce. Let's look at what's wrong with this post:
Example: "OMG! If you nerf scrappers it'll be the end of the AT! You can't DO this! I already get debt and now I'll get MORE!"
What's wrong with it? Well, while we may be very concerned that scrappers will become much harder to play, we didn't tell the Devs why. How are they supposed to take this post seriously if they don't know what's bothering us? Let's try again:
Example: "OMG! Devs, I already have a hard time with even-conned bosses at lower levels. If you include a defense debuff in this power, I'll get chewed up even more!"
Much better! We didn't even provide any numbers. Let's address that in our next point!
Rule #3: Do some testing.
It's all very well for us to have an opinion on some proposed changes, but we're really handicapping ourselves by not having any data to back up our claims. Testing is a great way for us to provide some anecdotal evidence and give the Devs some real, honest-to-goodness data in their database! Here's what not to do:
Example: "This is total crap. I'm never going to play my defender again if this goes through, because she won't even be able to solo minions!"
Ooh, that's a good point! But we haven't even tried to solo minions! Let's hop on the Test Server and try it out, then change our post to this:
Example: "Devs, I just spent four hours playing missions with my defender, Shade of Grace. These were missions against even and +1 mobs, and they took me an average of twice as long to complete as they would on live!"
See? That's information that the Devs can check, because we didn't just pull it out of our hat, we really tested it!
Rule #4: Try to be objective.
I know, this one is really, really hard. After all, our tanker is our absolute favourite character, and we've got 684 hours invested in the little half-monkey, half-orc! But we have to keep a level head: if we can't look at our AT and the proposed changes to it from a middle-ground of objectivity, we're not providing very helpful information, and we're not likely to be taken as seriously as someone who's decided on a more balanced approach.
Example: "THERE IS NOTHING WRONG WITH TANKERS!!! THIS ISN'T A FIX, IT'S A NERF!"
Wow! Not only are we starting off from a pretty biased viewpoint, we're using loaded words like 'nerf' that carry their own, heavy connotations. Also, we're typing in All Caps, and a lot of people really hate that (that's rule #4.5). Let's try this:
Example: "Devs, I know a lot of players think tanks are overpowered. I don't think they are, really, and I'm prepared to argue that this fix goes too far."
Holy Miss Manners, Batman! (Can I say that here? How are we with DC, have they given us any trouble?) That was reasonable, and polite, and though we're still favouring tanks, we're not shutting ourselves off from debate!
Rule #5: Don't make assumptions.
Maybe we've got our suspicions about the changes, and maybe we think that our views are widespread among the player base. Whoopsy, we just made assumptions based on information that's not available to us! What's wrong with this example?
Example: "You Devs are just hitting us with the huge nerf bat so that we'll be glad when you pull back and only make it a small nerf. Well, I know that the majority of players think you're going too far, and you're going to keep leaking subscribers like you are now if you don't wise up!"
Wow! We sure are Russell Crowe from The Insider today! Except that we don't really have the proper information to back up our claims. We can't read the Devs minds, so it's pretty unfair to assign them motivations (also see Rule #1). We also shouldn't claim to represent the majority of players... we don't know how they feel! Also, we're making ultimatums, and a lot of people really don't like that, either (let's call that Rule #5.5).
Example: "Devs, I don't know why you handled the latest changes like you did, but I don't much like them, and I don't think I'm alone."
Much better! I think we're getting the hang of this.
Rule #6: Don't use hyperbole.
Hyperbole means: gross exaggeration (roughly). It's not productive, and causes people to take our arguments less seriously. It also gives them an immediate avenue of attack! Let's not give them the chance, as we do in this example:
Example: "HOLY CRAP! There is NOBODY on Justice server right now! I haven't seen anyone from my SG in MONTHS! Everyone is leaving for other games because it takes A MILLION YEARS to level in this one!"
Whoa there! We're saying some pretty outlandish things! We might have a couple points, but the first thing other posters are going to do it point out how crazy we are to be tossing out those exaggerating statements (then they're going to refer us to Rule #5). Let's give it another shot:
Example: "Holy cow! Are there less people on Justice these days? I'm having a hard time levelling, it just takes forever. Maybe that's why the server seems less populated?"
We're still violating Rule #5, but as least we don't sound bananas. And we're not using All Caps; always a plus.
Rule #7: Grammar & spelling count.
They do! I know, it's weird. We can read it, other people obviously got our point, and really, this isn't English class. But the sad fact of the matter is, we live in a society that sees decent grammar as a sign of intelligence. It's true! And to top it off, we're using a medium (the Internet) that's based mostly on text! One last bad example:
Example: "i c u devs dont care abot us plsyer nemore well tihs nerfis 2 much1 ND IM LAEVING LIARZ!!!"
Wow. There's probably a smart person behind that typing, someone who can fish, and make sandwiches, and play dodgeball! But the reader just sees a demented ten year-old with a learning disability. Whoops, I just violated Rule #1! Sorry. But seriously, if we can't take the time to make our argument in a readable fashion, we're going to undermine our cause! And the Devs might take our post less seriously than someone who put more care into theirs. (For bonus points, how many other rules did we violate in that example? See below for the answer!*)
Well, that was a whirlwind tour of the Rules of Constructive Criticism! Let's recap what we've learned.
Rule #1: Don't be insulting.
Rule #2: Provide reasons and examples.
Rule #3: Do some testing.
Rule #4: Try to be objective.
Rule #5: Don't make assumptions.
Rule #6: Don't use hyperbole.
Rule #7: Grammar & spelling count.
I hope you learned something today by tagging along. I know I did! Good luck out there, testers!
* The answer is: all of them!
----------------------------------------------------------------------------------------------------------------------------------------
Message Edited by GunfighterSmoke on 07-28-2005 05:20 AM
Message Edited by GunfighterSmoke on 07-28-2005 05:20 AM
Almagill
Thu Jul 28, 2005 3:52 am
#2
Nice one.
Key points:
Rule #1: Don't be insulting.
Rule #2: Provide reasons and examples.
Rule #3: Do some testing.
Rule #4: Try to be objective.
Rule #5: Don't make assumptions.
Rule #6: Don't use hyperbole.
Rule #7: Grammar & spelling count.
and, from what I've seen, both on Live and in Test, that's about the whole of it. One thing I'd add is:
Be Patient.
Making a change to the code isn't just a case of getting Jimmy Propeller-Head to go sit at his desk and change a few variables. Even before J P-H gets sent to his cubicle to try and unravel what's gone in a mess of code that's been getting pulled this way and that for the past how many years, decisions have to be taken as to what the change should be, what priority it gets, where the job goes in the "Big List Of Things That Needed Done Yesterday", a decision needs to be taken to pull a programming asset off one joband onto this new job, etc.
Then assuming he finds what's broken and can come up with a fix, it need to be checked, checked and checked again to make sure that un-nerfin that nuna on tat isn't going to cause rancors on Dath to suddenly sprout wings, turn purple or be replaced by Bith character models...
And THEN once that's been dismissed as 'mostly improbable' they need to internally test the fix, then oepn beta it (TC) and, assuming that nothing else weird happens, it might make onto the publish after next because all the stuff above takes 'time'. That's real time, not game time or magic time, but straightforward 9-5 working day time.
Meanwhile another 25000 posts have appeared screaming blue blooded nerfage and threatening to cancel their accounts cos that pesky nuna on Tat hasn't been fixed 'yet' and this proves how little anyone cares for nuna fanciers....
Key points:
Rule #1: Don't be insulting.
Rule #2: Provide reasons and examples.
Rule #3: Do some testing.
Rule #4: Try to be objective.
Rule #5: Don't make assumptions.
Rule #6: Don't use hyperbole.
Rule #7: Grammar & spelling count.
and, from what I've seen, both on Live and in Test, that's about the whole of it. One thing I'd add is:
Be Patient.
Making a change to the code isn't just a case of getting Jimmy Propeller-Head to go sit at his desk and change a few variables. Even before J P-H gets sent to his cubicle to try and unravel what's gone in a mess of code that's been getting pulled this way and that for the past how many years, decisions have to be taken as to what the change should be, what priority it gets, where the job goes in the "Big List Of Things That Needed Done Yesterday", a decision needs to be taken to pull a programming asset off one joband onto this new job, etc.
Then assuming he finds what's broken and can come up with a fix, it need to be checked, checked and checked again to make sure that un-nerfin that nuna on tat isn't going to cause rancors on Dath to suddenly sprout wings, turn purple or be replaced by Bith character models...
And THEN once that's been dismissed as 'mostly improbable' they need to internally test the fix, then oepn beta it (TC) and, assuming that nothing else weird happens, it might make onto the publish after next because all the stuff above takes 'time'. That's real time, not game time or magic time, but straightforward 9-5 working day time.
Meanwhile another 25000 posts have appeared screaming blue blooded nerfage and threatening to cancel their accounts cos that pesky nuna on Tat hasn't been fixed 'yet' and this proves how little anyone cares for nuna fanciers....
Kaomond
Thu Jul 28, 2005 4:32 am
#3
Almagill wrote:
Nice one.
Key points:
Rule #1: Don't be insulting.
Rule #2: Provide reasons and examples.
Rule #3: Do some testing.
Rule #4: Try to be objective.
Rule #5: Don't make assumptions.
Rule #6: Don't use hyperbole.
Rule #7: Grammar & spelling count.
and, from what I've seen, both on Live and in Test, that's about the whole of it. One thing I'd add is:
Be Patient.
Making a change to the code isn't just a case of getting Jimmy Propeller-Head to go sit at his desk and change a few variables. Even before J P-H gets sent to his cubicle to try and unravel what's gone in a mess of code that's been getting pulled this way and that for the past how many years, decisions have to be taken as to what the change should be, what priority it gets, where the job goes in the "Big List Of Things That Needed Done Yesterday", a decision needs to be taken to pull a programming asset off one joband onto this new job, etc.
Then assuming he finds what's broken and can come up with a fix, it need to be checked, checked and checked again to make sure that un-nerfin that nuna on tat isn't going to cause rancors on Dath to suddenly sprout wings, turn purple or be replaced by Bith character models...
And THEN once that's been dismissed as 'mostly improbable' they need to internally test the fix, then oepn beta it (TC) and, assuming that nothing else weird happens, it might make onto the publish after next because all the stuff above takes 'time'. That's real time, not game time or magic time, but straightforward 9-5 working day time.
Meanwhile another 25000 posts have appeared screaming blue blooded nerfage and threatening to cancel their accounts cos that pesky nuna on Tat hasn't been fixed 'yet' and this proves how little anyone cares for nuna fanciers....
LIES!!!!!! it's easy, all they do is walk up to the pannel that has a big red button for each proffession marked NERF and push the relevant button and it randomly generates a change in the code !!!!!!
hehe only kidding 
Very good and informative post.
Very good and informative post.
Page 1 of 1