Cold Take #46 - Giving and Taking Feedback

A lot of the polish in Zero-K is driven by player feedback. A single complaint can be enough to spark a re-investigation of some part of the game to check for improvements. Case in point, the recently (https://store.steampowered.com/news/app/334920/view/693142218859349679) are a result of someone complaining that the icons were too hard to see. But it takes good feedback to see this kind of result, so today it is time for some advice on how to give feedback. Then, for balance, I'll talk a bit about how to use feedback.

Do not read this post as a strict demand. Giving good feedback can be difficult and not everyone has the time. My hope is just to avoid a few common types of bad feedback. Also, "good" and "bad" does not mean positive (praise) and negative (complaints). Good feedback is useful feedback, and complaints are often useful. Positive feedback can be bad in this sense, but it has additional psychological value, so my advice focuses on giving good negative feedback.

Here are my tips for giving feedback.

1. Treat the developer as if they are hearing this feedback for the first time. They'll forgive you if they have heard the feedback before and your take on it is still likely to be useful. I really just want to avoid statements such as "Can we finally fix the plasma cannon bug?" as the first time I hear about a bug. Give some context for the issue rather than skip right to complaining that it has not been resolved.

2. Give multimedia feedback. Why spend a thousand words describing an issue when a screenshot will do? I always ask for a screenshot when responding to visual feedback as half the time a vague complaint turns out to be a clear bug. Screenshots are great for bugs as well, but depending on the type of bug you might want to send an error log or replay link as well. Replays are a must-have for feedback on balance or wonky game mechanics as every extra piece of information helps identify the problem and devise a solution.

3. If your feedback is particularly long, or important, put it somewhere permanent so that you can link to it. Scrolling chat, such as Discord, is temporary and easy to miss. In Zero-K the main forum is the best place for general feedback, while GitHub is appreciated for reporting unambiguously technical issues. The Steam forums also work and Discord is fine as long as you accept that the feedback might be missed.

4. Start new threads rather than inserting yourself into unrelated conversations. There is often a bit of back-and-forth when giving good feedback, and trying to do so with multiple people simultaneously is a recipe for confusion. Adding feedback relevant to an existing topic is often fine, although I would be wary of adding good feedback on top of bad. People are allowed to give feedback at all times, and while some terrible opening posts have lead to threads with good feedback, the experience would have been better if people with good feedback had made their own thread.

5. Do not feel pressured into giving lengthy feedback. Each player is only one voice, and while more vocal players give us a better idea about what they want, volume of feedback does not inherently make their view worth more. It is rare that people give too much feedback, but I have heard from players who are concerned about their view being trampled because they don't write essays on the forum. A small comment is fine, especially if it focuses on how you feel rather than what you would change.

Consider the following when receiving feedback.

1. Feedback cannot be wrong, or right, it just is. Unless you are being trolled, feedback comes from somewhere. The player might fundamentally misunderstand the game or propose entirely backwards solutions, but nevertheless, there is some chain of cause and effect between a problem and the feedback. If you can unravel that chain, then you might find something to fix.

2. Solving the problem in front of you is not necessarily the end of the feedback. If enough people ask how to do something, and each time they go away happy having learnt an obscure key combination, consider how many people might be struggling in silence. Perhaps making the feature more obvious is warranted, depending on how important it is.

3. It is often said that players are great at finding problems but terrible at finding solutions, and I broadly agree, but I have two caveats. Firstly, it is often easier for someone to say "Glaive should be slower" than to unpick why they feel that way, so do not try to stop people giving feedback this way. As long as they follow up with more information, you have what you need. Secondly, some players have good solutions, so keep an eye out for them.

4. Some players are complainers and this is a good thing. Everyone has a threshold for how serious an issue has to be before it is worth mentioning it, and those with the lowest threshold will complain first. Eliciting good feedback from these players can uncover problems that make the game subtly better; do this enough times and the game is noticeably improved for everyone.

5. Hold fast to a core set of design principles, at least until the volume of feedback tells you to reassess them. Without principles the design will be buffeted on all sides as you try to please everyone, meandering the game towards mediocrity. Sometimes the best you can do is have complaints from one direction cancel out those from the other side. Make a game some people will love rather than a game few will dislike.

I naturally try to wring as much from feedback as possible. This has diminishing returns and can be unhealthy, so use the advice above in moderation as many more posts would be needed to paint a full picture.

Index of Cold Takes