You are on page 1of 9

ShareAll sharing options for:How to be heard by game

developers
Disclaimer:

All individuals and examples in this article are inspired by experiences in my career; any resemblances to real peo-
ple, organizations, or situations are in no way associated with my current employer. The views represented here are
my own and don’t reflect those of my employer.

MyMy dream has always been to get game developers and players to a place where they’re able to get along better
and understand each other, and one of the ways to get that done is by talking about the best, most effective, and
most helpful ways to be heard as a player.

Let’s imagine the following scenario:

You, a passionate player, are playing one of those video games everyone is talking about. But something in the
game is bothering you. Maybe it’s a specific mechanic, or a new hero that you don’t like, or a level that makes you
feel frustrated or angry. You’d like to find a way to express those emotions to the people who made the game, and
actually be heard.

Which is a problem! The feeling of being heard as a player can be rare in gaming, for many reasons. There are so
many players, and only so many developers, and the conversation between them doesn’t always look like what
you’d imagine as “normal” communication. But the two groups are always in conversation, even if you don’t see it
yet.

I’m here to give you a general guide to increase your chances of actually giving useful feedback to the developers
of your favorite games, and expressing it in a way that increases the possibility of something actually being done
about your note or complaint. That’s the hook to get you into this story, but my real goal is to help explain why it
may often feel like you’re shouting into a void when you try to complain about your favorite game, and what it can
look, and feel, like from the other side.

So to help you understand things from the point of view of game developers, I’d like to explain, in a general sense,
how developers receive and use feedback.

The path of a piece of feedback to implementation

I need to make one thing very clear at the very beginning: All the games you play, especially larger games with
many players, need to consider a multitude of different pieces of feedback by necessity.

Many of these notes or suggestions actually contradict one another, or serve different kinds of players in different
parts of the community. That’s why pretty much all implementations — i.e., the inclusion of a full feature or sys-
tem — fixes, and changes to a game are based on a variety of different pieces of information coming in through
different channels.
But let’s keep it simple. Imagine a piece of direct player feedback. It’s filtered through community managers (if
applicable); developer interpretation of the feedback; technology assessment and producer assessment of what it
might take to change something in reaction to the complaint or note; and data we collect from the game itself,
including crash reports and other pieces of data, such as the popularity and overall use of whatever is to be
changed.

“Does this sound exhausting? Good. It is”

That information is also filtered through the channels of many experts, and finally, internal testing sessions that
include the proposed change — and then the bug hunting begins! You can’t just change one thing in a game; doing
so almost always makes something go wrong somewhere else, and so you want to find and fix those issues before
they reach the players themselves.

Does this sound exhausting? Good. It is. And it’s necessary; there are no shortcuts to this kind of thing. And this is
a simplified look at a piece of feedback that everyone agreed pointed to something that needed to be changed. In
most larger-scale games, making that decision is, on its own, a complicated process involving a lot of people.

Developers also have to consider whether a reported problem is a real issue in the game, or an issue with percep-
tion. Sometimes, people talk up a problem, but the data shows that the thing is working fine for the vast majority
of people; adjusting it may risk something else going wrong with the game’s balance. So now you have to fix the
perception of something being broken among some folks in the fan base, instead of the thing itself.

This doesn’t mean feedback based more on perception than fact isn’t valuable — it just means these issues need to
be approached in different ways. Perception can be everything in gaming; how people think something works will
always cause more waves than an explanation of how that thing actually works.

Let me give you an example, from conversations with the development team behind Overwatch:

The concept of a hero-based shooter was new when Overwatch was first announced in late 2014. The game
requires you to think about, and counter, a variety of heroes in a way that’s more similar to games like League of
Legends than other shooters.

Early in Overwatch’s life, a common perception among the community was that the character Bastion was dispro-
portionately overpowered, and seemed to receive more Plays of the Game than other heroes. This “problem” was
discussed just about everywhere people were talking about the game, and was often accepted as fact.

But here’s where it gets interesting: The data that the Overwatch team collected from the game did not show this
problem as strongly as the feedback suggested. The hero was doing well, but not so well that it seemed like he was
overpowered to the extent that a fix was needed. If Bastion were truly overpowered, it would be reflected in the
game’s data: Too many people would be picking him, and those people would be winning most of the time. The
numbers that should demonstrate that a character is overpowered instead showed a hero that was, more or less,
working fine in the context of the overall game.

It did not help that Bastion’s mechanics — such as the ability to turn into a stationary turret with a rapid-fire
chain gun — resembled a gameplay style that has always been frowned upon in competitive gaming. Yes, I mean
camping.

The intersection of an inexperienced player base with the hero switching in Overwatch; the cultural attitude
toward the camping mechanic; and an impression induced by the strong audiovisual effects of the character
skewed the feedback of the community. What they thought was happening — how they perceived Bastion — took
precedence over what was actually happening in the game.

The numbers didn’t support the idea that Bastion was overpowered, but that didn’t change the fact that that’s
what players believed, and it was impacting their enjoyment of the game.

Was Bastion overpowered in the early days of Overwatch? Perception may not have quite matched
reality.
Image: Blizzard Entertainment

In the end, the Overwatch team decided to allow the game and its new community to adjust to the unusual
requirements for the genre instead of nerfing Bastion, which is what many players were calling for. Once players
got more familiar with the game and its characters, Bastion became a more balanced hero choice and a valuable
pick for newbies in a competitive environment among more experienced players.

The problem just kind of … went away, although arguments in Overwatch about balance are still common. But in
this case, the team trusted the actions of people playing the game, and what the developers were seeing in the
data itself, over what players were reporting in the feedback online.

Data is a powerful tool when used alongside player feedback. This is what I meant when I said we’re always hav-
ing a conversation: You give us information and guidance just by playing the game, and that information is valua-
ble.

I’m not saying developers are always able to so cleanly decide between the data and the players’ wishes; every sit-
uation is a complicated mess of interconnected pieces. But I just wanted to show how many factors may go into a
decision you personally don’t agree with in a game you feel passionately about.

And if that makes you angry, it may be a good time for the next section.

How to be heard

Your first step before sending any kind of feedback should be finding the right channel to approach the developer.
So let’s start there.
Complain through the right channel

This sounds simple, but the problem with this advice is that every developer will be different in how they best
receive feedback. It may be through Steam forums, it may be through a form on their website, or there may be an
email address to send your questions or concerns to. There may be a way to contact the team through the game
itself. You’re going to have to look around a bit, but developers will usually tell you how to best get in touch with
them somewhere. Finding that information will greatly increase your chances of getting your words to the right
eyes or ears.

And let’s knock this one out right now: While I can’t tell you the best way to contact each developer, I can tell you
that tweeting at or messaging a random developer who works on the game is almost always going to be one of the
worst ways.

In larger companies, individual developers do not have the necessary means to read, process, or implement feed-
back themselves. Most developers with personal social media accounts referencing their employer don’t have the
autonomy or know-how to serve as a feedback channel for thousands, or even hundreds of thousands, of players.
In many cases, the studio may itself discourage them from engaging players directly, as another way to try to keep
feedback coming into the right channels.

Try to understand that feedback that will be turned into action needs to be filtered and assessed by people who
know how to do so. That kind of work is its own profession — community management — and community manag-
ers are skilled in ways to collect feedback, share it with the team, and discuss what may or may not be happening
to the players themselves. It’s a complicated job that’s too often overlooked when games do well and keep their
players happy, but sometimes blamed when things go poorly and players get upset.

Not every developer has a large team with a dedicated community manager, however.

If you are approaching an independent developer, be mindful of their potential lack of resources. Some indie devs
are open to feedback given to them personally, but it can also be overwhelming. Monitoring feedback from your
community is a full-time job, so it may take longer to be heard by a small team with fewer resources to spare on
that kind of work. Indie devs are just like every other team, no matter the size: They all process information in
different ways.

In the end, developers often want one thing: to be treated like humans. We are under a lot of pressure, from many
directions. One of the easiest ways to show you care about developers as people is to figure out the best way to
contact them, and use that system to provide feedback. You have no idea how much it helps to send your thoughts
to the right place, where they can be seen by the right people, instead of finding a random developer on Twitter to
yell at before they block you.

Use the right language, and leave the abuse at the door

I hope it goes without saying that any language that can be construed as harassment or hate speech is absolutely
off-limits when talking to developers (or anybody, for that matter). No matter how frustrated you may be, take a
deep breath and remember that there are people on the other side of this communication who work very hard for
you every day of their lives.

Using abusive language is also the quickest way to get your thought or note ignored. Imagine someone walks up to
you one day and starts screaming obscenities in your face. Will your first thought be about what you can do to
make them happy, or are you just going to look to remove yourself from the situation as quickly as possible?
Removing yourself from that situation when the medium is email or Twitter is pretty easy: deleting the message
or blocking the person sending it.

No one should have to sit through abuse in order to hear if you actually have a point, so sending it wastes your
time, and theirs, and it adds to the general antagonism that can be so common in gaming.

Your problem may be someone else’s solution

You’re going to disagree with some implemented features, or some elements of your favorite games will not work
well for you. Maybe that’s because you’re not the target audience of this particular bit of the game, or the devel-
oper had to consider its economy or monetization model for a variety of other reasons.

Successful modern online games serve a large audience, often made up of hundreds of thousands, if not millions,
of people. It is likely that you will encounter parts of the game that do not suit you but might work really well for
other types of players, and many of them might not be obvious or visible to you.

There are many reasons for why developers have to serve a multitude of different players. But the main reason is
that communities stand on multiple legs of engagement to be healthy, from a more casual fan base through begin-
ners and newcomers right up to the hardcore audience. We need to maintain a balance for all of them, which is
why not every solution or design decision will make sense to you.

An example:

In earlier iterations of Gears of War’s multiplayer mode, developer data showed that over 90% of players who did-
n’t get a kill in their first PvP game would never return to play another round. To combat this, the team imple-
mented a system where new players would automatically get the reload damage bonus applied continuously until
they scored a kill, after which the bonus would taper off.

Now, you could argue that this isn’t the most fair implementation, but try to look at it from multiple angles: A
multiplayer mode is useless for everybody if it doesn’t have a large enough player pool with players of varying
skill levels to satisfy matchmaking.
It is vital to the health of the player pool to encourage new players to stick with the multiplayer component. That
takes precedence over fairness, especially if the adjustment is a temporary bonus. New players have a better time
and a much higher chance to turn into long-term players, which ultimately benefits everybody.

It’s a solution that only targets a specific group of players for a specific reason, and would likely be rejected by
other parts of the community. That doesn’t make it a bad solution to the problem of player retention and growth,
though. It just means it’s one that may not suit you, even though you benefit from all those players sticking
around.

Focus on emotions over solutions

The No. 1 rule for any useful feedback may be surprising for players to hear, but it’s an important one: Don’t
worry about possible solutions to the problem, as I noted before, but always let us know how the mechanic, sce-
nario, or balance decision makes you feel.

You don’t have to make the case for the facts — we have those available in the analytics of the games themselves;
we know how many people use a particular feature or choose a certain weapon — but you can absolutely help us
understand the one thing the numbers can’t tell us, and will never tell us: how players feel while they’re playing
the game and encountering this situation.

“Always let us know how the mechanic, scenario, or balance decision makes you feel”

Learning about your feelings is an important step in fixing whatever the problem may be, if indeed it’s something
that needs fixing. Remember, the facts about game design are often less important than the perception of how
things work.

A perfectly fair game on paper may feel horrifically unbalanced in some ways when you begin playing. Knowing
that you feel that way gets us one step closer to finding a way to improve your emotional reaction to the game.

For example:

“Having to play this level over and over again with as few resources as the game currently seems to give me feels
very frustrating,” a player might say. “I can’t tell what I’m doing wrong, or how to get better.”

This is great feedback, and it’s based on an emotional reaction. It’s two sentences long, but I’ve learned three
things: My messaging on how to play the game may be failing for some players, I may want to look into how my
resources are marked on the screen or whether they’re balanced out for that scenario, and I can go to my data to
see if other players are stuck playing the same section over and over.

Those two sentences, which just convey an emotional reaction, gave me a ridiculous amount of information to
begin looking over the issue and seeing if I can improve the game for everyone.

It’s so much easier for me to identify the cause of the issue and be more precise in my solution when I know how
it made you feel, versus how I’d like you to feel in that area of the game. And finding the cause of the issue in this
way will often cost me and my team less time and resources, for a more satisfying solution, to improve the game.

Gaming is like many other aspects of human life: Being open with your emotions is a good thing. Everyone wins.
How to best report bugs

If you are reporting an actual bug, and not a frustration you have with the feature, try to give us as much infor-
mation as you possibly can. If you think you’re sending in too much information, you’re probably not sending
enough. Seriously.

Internally, we can pretty much never fix a bug if we can’t reproduce it, especially if it didn’t show up in our tools
and internal testing.

So please describe in as much detail where, why, and how it happened. Do you remember what you were doing?
Which buttons you pressed? Which quest you were on, which enemy you were fighting, and if you used a special
ability? Can you give us details on what platform you play on and maybe even system details, like your GPU or
whether it was a standard PS4 or a Pro model? Do you have screenshots to illustrate your problem, or crash
reports? Did you take video?

The more information we have, the more likely it is that we can fix the bug as quickly as possible. And if you are
just realizing how much information we need in order to successfully find and fix bugs, congratulations! Now you
know why quality assurance testers are so important. They not only find and log bugs; they track exactly what
they were doing when they found it. It’s exhausting work, and gaming is made better by QA testers making sure
that every game is as stable as we can possibly make it.

So the more detail, the better. Put it all in there. You never know what will help.

Always remember that you’re talking to human beings

We know you’d like us to communicate as much as possible to you, but it might not always be something we can
do. There may be no easy solution to your problem, and an explanation might give away information that we can-
not share about future plans, or even the technology that drives the game itself.

It can all get better — we just need to work together to make it better.

We may already be working on something that will fix it, or have it on our list to address down the line after more
pressing issues, but can’t officially commit to it out of fear of things changing or receiving backlash if it doesn’t
work out.
There are many good reasons for why you might not receive an easy answer or fix for your concern, but I can
promise you that none of them are malicious, or because we don’t care. It’s hard for every player to see every
moving part, to understand which issues are more pressing or most expensive from our perspective. The politics
for how we can share information are complicated and require time to work through, if not explain.

Just try not to assume the worst if you don’t get the outcome you were hoping for. I’m not arguing that every
developer or publisher is always doing the right thing — just that each situation is more complicated than you
think, and starting from a place of empathy is helpful for everyone involved.

Send positive feedback!

Most of the feedback we receive on a daily basis is negative or rooted in problems that players have with our game
— and we value that feedback, because we want to improve the experience you have with our work, too. We also
know it’s much easier to get motivated by anger than by satisfaction.

Think about it: Having fun is the point, and players rarely remark on it. It’s the ideal you were hoping for when
you bought the game or invested your time into it. But not having fun is a reason to reach out and share your
annoyances. We get it. A broken car won’t get you where you’re going. A game that doesn’t provide the emotional
experience you were hoping for is likewise giving you problems. You want to hear about how your situation will
be fixed. That’s a much stronger reason to reach out.

But if you can find it in your heart to sit down and give positive feedback to a developer when you’re truly enjoy-
ing something, or are satisfied by it, I can promise you that it is deeply valued and appreciated. Developers — all
developers — love their players. We create for you every day of our lives, and we often don’t have the ability to
easily see your real, human reactions to our work.

Whenever we do receive positive feedback, we cherish it deeply. Many developers have collections of positive
feedback and messages, saved digitally or even printed out and put on the walls in the studio. These things stick
with us for the rest of our careers, so consider not using feedback channels just for negative feedback.

No one ever successes their way out of the appreciation of hearing nice things from players, and even people who
have had long, productive careers in the industry may be laid low — in a nice way — by positive feedback. Watch
this video of God of War director Cory Barlog reading reviews of his game to see what I mean:

The other side of the coin is that this habit will help you enjoy gaming as a hobby much more. I’m serious! Send-
ing in notes about what you love helps to create a sense of empathy and connection with the people making your
games. You’re reminding yourself that someone out there made this thing you love, and that they love it too. Shar-
ing that love will make both of you feel better about your connection. And that’s the ultimate goal of creating a
game, anyway: that connection. When you feel it, and you let us know, there’s nothing else like it.
Final words

Player feedback is valued, desired, cherished and hugely important to any game developer. In an ideal scenario,
we get to use your feedback — in combination with data from the game and our personal expertise — to improve
your experience with the game.

Feedback is our best tool in understanding where our assumptions failed and what we might have missed in our
initial considerations. Games have millions of small moving parts, and your input helps us put all of our thoughts
in context while maintaining creative and artistic control over how to deliver the best game we can make.

In the end, giving and receiving feedback is about empathy for one another. That includes developers, the commu-
nity around the games you play, and the experience of other players. Treat your gaming community with compas-
sion and respect, and it’s much more likely you’ll get the same treatment in response.

We’re always talking, even if you don’t realize it, and that conversation is what keeps so many of us going. You are
part of a larger picture whenever you are part of a game, whether you worked on it or you’re playing it — and
that’s the beauty of the whole thing, isn’t it?

I hope this piece helps us hear each other at least a little better.

You might also like