next »

[alvarop]

Once you get people trying out your game, you are bound to get feedback.

Usually, I tend to care more about the problems people seem to have with my game, than the solutions they propose. But sometimes, the problem comes with an implicit solution. For instance, if the problem is that the player movement is too slow, then the solution would be to make it faster, obviously.

Now, this gets very difficult to deal with when people give you contradicting feedback. To continue with the player speed example, as a developer, you set those values initially out of trial and error and some intuitive feeling of what feels good. But once you get contradicting feedback, how are you supposed to tweak it?

Do you go with your gut feeling? Do you try and go with what the majority says?
I'd like some of your opinions on this, as I'm having trouble dealing with this sort of issue in my game. The idea here is to maximize the feedback that you get to make the best game you can.

[AntonTesh]

When I get conflicting feedback I think about what type of player I'm making my game for. It's not that a person's opinion is less right than another (for them the game does need to change to feel better) but if they're not my target audience I take their opinion with a grain of salt. You can't please everyone with your game so try to figure out which person that gave you feedback is more in your target audience.

If they both are then It's still good to listen to everyone and collect as much feedback as possible.

[alvarop]

When I get conflicting feedback I think about what type of player I'm making my game for. It's not that a person's opinion is less right than another (for them the game does need to change to feel better) but if they're not my target audience I take their opinion with a grain of salt. You can't please everyone with your game so try to figure out which person that gave you feedback is more in your target audience.

If they both are then It's still good to listen to everyone and collect as much feedback as possible.

That's a good angle you got there. Maybe I should select the people I show the game to more... selectively. As in try to get feedback from people who actually play this sort of game and can give me some in-depth insight rather than just gut feelings from an unexperienced gamer.

Or just get both and prioritize

[AntonTesh]

Maybe I should select the people I show the game to more... selectively.

I think getting as much feedback as possible is still valuable even if it's not from a target audience. They may not have good feedback about the core mechanics, but maybe they catch/reproduce bugs or help you polish the look and feel of your game. I've gotten great ideas before just from watching people play so get it in as many hands as you can

[Alec S.]

My advice is two-fold.

A) pick a direction, but try to sell that direction better.  Make it seem like the way it's supposed to be.  In other words, if you decide to make a character go slower, use the character, their animation, and the game around them support that speed.  Use everything at your disposal in the game to make the best case for your decision being the right one.

B) Realize that your game isn't for everyone.  Everybody has their own taste.  Know what you want your game to be, and use feedback to see if you are succeeding in conveying that vision.

[JWK5]

You could get the comments of "This game has an awesome combat system!" and "This game has a terrible combat system!" and both could have degrees of truth. The combat system could be terrible to one set of players because the timing feels off but could be awesome for other players because despite that the sense of weight and recoil feels really good.

Don't look at it as contradicting statements, look at it as different experiences. Your goal shouldn't be catering to this group or that, your goal should be refining the experience into something that does and represents what you are envisioning as effectively as possible.

So in that scenario I gave as an example above, maybe on deeper investigation into the statements you realize that you are heading in the right direction with the sense of weight and recoil but the timing needs work and by improving it you've expanded your game's appeal to both groups.

The only type of feedback you should ever want to disregard is insincere feedback, where the feedback (positive or negative) has no real substance it is just aimed as an attack or ego stroking.

[ProgramGamer]

+1 to what JWK5 said.

[dspencer]

Also - remember that people like to give feedback in terms of *actions* they want you to take ("make the player move faster!") but it's your job to see through that and identify the *problem* they are having (maybe it's "There's not enough to do in a level"). Contradicting feedback (put more hazards in the game and make the player move slower / make the player move faster and remove those damn surprise spikes) can sometimes share the same root cause; as long as you fix that it doesn't matter as much if you followed the specific requests or not.

[Dacke]

@dspencer

Yeah, that's my thought too. You can try to look for the underlying experience that results in a specific complaint. And then decide if that experience is something you want create or not.

Why do some people feel the movement speed is too slow? Possible answers: slower than comparable games they are used to, the game gets boring, perhaps there is a lack of maneuverability in tricky situations?

Why do some feel it's too fast? Possible answers: lack of control in tricky situations, faster than comparable games, not enough time to experience the level and details in it, maybe it's "unnaturally" fast compared to reality?

Obviously there are many more options than my suggestions. But with that mindset, you may be able to understand what the actual experience is and come up with tons of different solutions to the problem. Like maybe if it's a matter of maneuverability you need to modify something else (like acceleration/slide) or modify the levels or add a double jump. Or if it's a matter of players getting bored, then perhaps you need to add more checkpoints or enemies or interesting art, or better establish the mood etc. etc.

[starsrift]

Topics like this remind me of one of the COD developers having trouble getting a shotgun to feel right. Testers kept complaining it was too weak, but numerically, the math didn't hold up. After spending a while going back and forth with QA and different damage numbers for that shotgun, eventually they adjusted the sound asset - and that was the fix that the playtesters wanted. The actual mathematical, systems-based power of the shotgun was not the problem, but that it 'sounded' weak, so the testers assumed it was weak, no matter what the math behind it was.
That tale's filed on Gamasutra somewhere. 2014 or 2013, I wanna say. Could be mixing up COD for another brown shooter, too.

Someone complaining that the character moves too slow could be side-lining a complaint that, for instance, the level is not visually busy enough to keep them looking around. Attractive as it is to discard the complaints you don't agree with or don't suit what you think is your target audience, it's always worth giving them a much more holistic look over.

[J-Snake]

Some valuable feedback has already been given.

Here is my more formal guideline how to deal with this:

First know what your game is supposed to be, know what it is supposed to achieve for the players playing it. Let's call it your vision. This is the root you have to set right and be aware of, otherwise all these insecurities will start to arise.

 It follows:

  - Discard all feedback that violates your vision.

  - Take all feedback into account that doesn't violate your vision but satisfies as many players as possible.
    
For example, if it doesn't matter for your vision that the player can move within a certain speed range, let's say within
the interval [x,x + 1], and the majority of players prefer speed x+1, then go with it. On the other hand, if this speed is
too high to enable certain gameplay possibilities which are a fixed part of your vision then discard their feedback.

If you still have insecurities then it only means that you don't have a sufficiently clear vision yet. You might be processing the feedback loop, and potentially using it as help to find a clear vision. And hopefully this iteration will approach a fixed point where the vision becomes clear.

Hope it helps:)

[s0]

- Discard all feedback that violates your vision

disagree. regardless of how clear you think your vision is, it might still be flawed, especially if you lack experience. therefore don't discard any feedback without considering it first.

what's more, sometimes good feedback can actually help you sort out your ideas and aid you in your quest for clarity (also why prototyping is frequently recommended).

[J-Snake]

- Discard all feedback that violates your vision

disagree. regardless of how clear you think your vision is, it might still be flawed

And so does the feedback, which is why this statement makes no logical sense in the context of my formal approach.

[AntonTesh]

- Discard all feedback that violates your vision

disagree. regardless of how clear you think your vision is, it might still be flawed

And so does the feedback, which is why this statement makes no logical sense in the context of my formal approach.

Flawed doesn't necessarily mean completely useless though. Flawed feedback may still have good intention or ideas which is why you shouldn't discount it.

[J-Snake]

I think there is a misunderstanding:

What you and Silbereisen suggest ignores the structure of my guideline. You describe what can help to work out the vision, as I have called it. While my guideline also describes how to act when the vision is already worked out.

Now if you still insist of not discarding feedback that violates your vision, then it only means that you don't really have a clear vision. Now you can continue working on your vision, which in the end sets up an educated guideline to all further work.
Instead you can just continue developing the game while it becomes a punching bag to external influences. But games which are created without a clear vision are more likely to end up disappointing.

[ProgramGamer]

But what if my vision is a game that tries to please everyone at once and for different reasons?

:^)

I actually agree with you though, but only if you care about having the highest standard for your game, and the most solid integrity to your design haha.

[J-Snake]

But what if my vision is a game that tries to please everyone at once and for different reasons?

Only a 12 year old knows the answer to that question:P

[AntonTesh]

I think there is a misunderstanding:

What you and Silbereisen suggest ignores the structure of my guideline. You describe what can help to work out the vision, as I have called it. While my guideline also describes how to act when the vision is already worked out.

Now if you still insist of not discarding feedback that violates your vision, then it only means that you don't really have a clear vision. Now you can continue working on your vision, which in the end sets up an educated guideline to all further work.
Instead you can just continue developing the game while it becomes a punching bag to external influences. But games which are created without a clear vision are more likely to end up disappointing.

Ah interesting I see what you mean now. I guess I always like to have my games open to new ideas at every point of the process. Or maybe I've never had a completely clear vision