Feedback & You
Introduction
The topic of good and bad feedback is ever-present in any creative community, including TF2Maps. After all, feedback is invaluable when creating any kind of work that a broad audience is supposed to enjoy. As such, this community has spent a lot of time honing the process of getting useful data into the mappers' hands.
The testing servers have a feedback plugin, feeding into TF2Maps' feedback database where mappers (and everyone else, of course) may then access it. Any game can be rewatched via demos and chat feedback extracted via Coldmaps. Every map or asset uploaded to TF2Maps is assigned a forum thread. We've even got a long-running Weird Feedbacks Thread, where mappers highlight some of the more insane (but not rule-breaking) comments their creations have inspired during a playtest.
Due to the age of this community, as well as the importance of useful data for the creative process, certain conventions regarding the giving and using of feedback have been established. In this guide, I will be attempting to shine some light on some of these conventions and give useful advice to both givers and receivers of feedback. If you feel like this guide could be improved in any way, I encourage you to go to hell would greatly appreciate your feedback. Cheers!
-Brokk
Technicalities
- What is feedback?
In the context of TF2Maps, feedback is any observation about a map communicated to the mapper with the intent of informing their development decisions. This ranges from two syllables and some coordinates to a fifteen minute walkthrough video with voiceover. What all feedback shares is that it is, at its core, data: Someone else's experience with the map. - How does the feedback system work?
The TF2Maps game servers run a feedback plugin (written by Geit back in 2011) that lets players submit comments in-game using the!gf(general feedback) and!fb(locational feedback) commands.
Each submission is timestamped and put on that map's feedback page.!fbcommands are additionally given two sets of coordinates: The position of the player's feet, and the position of whatever they were looking at. Context usually tells which of these is more relevant.
The plugin also captures how many rounds were won by which team on this specific map version. This can be very useful for balance testing over long periods of time, though it should be noted that a handful of rounds is not usually indicative enough by itself. More importantly, the feedback plugin does not capture tone, intent, and context of messages. General text and voice chat is also not covered. Watch the demo! - One thread per map
Every map uploaded to TF2Maps gets its own thread in the Map Factory subforum. This thread is the home for everything related to the map: Original upload, dev screenshots, changelogs, design discussion and decisions. Basically anything that documents a map's growth from janky alpha to (if the mapper is persistent) polished RC. If the map gets inducted into TF2Maps' yearly hall of fame, the Featured Maps, this thread is what gets pinned for the whole world to see. If you want to leave long-form feedback and thoughtful notes on a map, the thread is the place to go. We recognize that a lot of discussion and WIP posting has since moved to our Discord server, though.
Server terminology
!gf I had fun on this map- General feedback comment.!fb I had fun in this spot- Positional feedback comment.- Feedback Round - The "bonus round" at the end of a map's testing period. It lasts about two minutes and is intended to give everyone some time to write down further thoughts about the map or re-check sightlines, clipping, etc. Or you can just get a snack or scroll social media, that's totally fine as well.
rtv- Rock the Vote. Can be used once 10 minutes of a map's testing time have passed. If more than 60% of players have RTV'd, the map will immediately go to feedback round. It is considered polite to leave a comment on why you RTV'd.!gf I feel like everything has been said alreadyor!gf I don't think this needs more testing right nowis perfectly acceptable feedback in these cases.- Imp Hosts (or just Hosts) are community members who have been given the privilege to run an Impromptu Playtest, i.e. a playtest session. Scheduled playtests used to be more common and are now exceedingly rare, but the term has stuck. If no TF2Maps admins are online, Hosts will also deal with moderation on the server. The name of the current host will be mentioned in the playtest announcement on Discord and Steam. By the way, we're taking imp host applications!
Feedback, historically
TF2Maps has been around since 2007, and organized playtests have been an important part of the community almost as long. The feedback plugin is only slightly younger. On this scale, it is not unusual to share the server with someone who has been mapping while George W. Bush was still president, and equally normal to share it with someone who watched Crash's tutorial series last week and is now testing their first Alpha. Both perspectives have value when testing, but their different frames of reference are worth keeping in mind, no matter where on this scale you stand personally.
Modding community feedback can feel like it concentrates around failure and polarization. People are more likely to give feedback when something goes wrong rather than right, and people tend to be more vocal about a strong reaction rather than a mild one. This means that you will only ever see the tip of the feedback iceberg represented on the feedback page. Mappers need to seek out other data themselves. It should be noted that this is not unique to TF2Maps, it's just how voluntary feedback works. Nothing short of forcing players to fill out a poll at gunpoint will stop negative experiences from being overrepresented during a playtest. Your map is almost never as bad as feedback might make you feel it is. And even if it is, at least you'll get plenty of data to work with. In statistics, this is called Sampling Bias.
Both giving and receiving feedback greatly benefit from two things: Knowledge and understanding of TF2's design philosophy, and being a good player at TF2. If you want to become better at either end of the feedback system, start reading and/or practicing.
Being a good critic
1. Be Polite
Politeness is less about sparing the mapper's feelings and more about ensuring your feedback is heard at all. Feedback is only useful if the mapper engages with it. If your tone causes them to dismiss the comment - defensively, emotionally, or simply because they stop reading before they get to the useful part - you have wasted two peoples' time.
A useful rule of thumb: Would you say this to a stranger while making small talk at the bus stop? No? Reword it.
Even a carefully worded comment can read different out of context. Most feedback is written mid-game or directly after a round or match, probably with a specific moment and clear mental image in mind. The mapper will read it later, possibly after a dozen other comments, possibly days or weeks after the playtest. Write with this context in mind.
There are worlds between "This map sucks" and "I did not enjoy this round". They may feel like the same thing to you in the moment, but they won't to the mapper. Feedback is never an outlet for your frustration. If you feel like you need to release some air, shoot some enemy players. That's what they're there for.
Finally, positive and encouraging feedback can go a long, long way. Highlighting parts of the map you really enjoyed ensures the mapper doesn't rework them for lack of feedback, and encourages them to bring the rest of the map up to that standard.
2. Be Efficient
Feedback during the game is limited by time (feedback round, in-between lives, while standing in the map during a fight) and space (feedback character limit). Learning how to express yourself effectively and efficiently can be extremely helpful. It's a skill worth practicing.
The core feedback formula is something like this: What did you observe, what effect did it have on your play experience, and (if relevant) where did it happen? Anything else is a bonus.
The !fb command will give the mapper two coordinates: The position of your feet and the position of whatever you looked at while you typed the comment. The mapper will use context to figure out which of these is relevant, though it can help to make sure these don't conflict, or to specify what you mean if they do. Specific feedback tends to be more valuable to mappers than general and overall impressions. "!gf I feel like this map is too big" vs "!gf Walking to the point takes forvever, mid feels oversized".
Hit F12 to make screenshots! If something is hard to describe, a screenshot posted to Discord or the map's thread can save you and the mapper a lot of back-and-forth. As they say, a picture is worth a thousand words. Or at least a couple dozen.
3. Have A Plan to Kill Everyone You Meet
Be aware what kind of map you're commenting on. Mappers generally use the version suffix to communicate what stage of development they're in and, implicitly, what kind of feedback they're looking for:
- Alphas (e.g.
cp_mapname_a1)
Maps that are in layout and gameplay development. The geometry is rough, visuals are placeholder or reduced to the basic minimum, and the mapper is trying to figure out if the fundamental structure of the map works. Feedback on layout, flow, team balance, and general fun potential is exactly what they need. Detailed criticism of asset choice or thematic decisions is noise at this stage, unless specifically requested. - Betas (e.g.
cp_mapname_b1)
Maps that are usually in or approaching the artpass phase. This is when detailing feedback becomes important. That said, mappers often test throughout the artpass rather than waiting until it's complete, so you may encounter beta maps with large sections still undetailed. If it's unclear what the mapper wants feedback on, it's perfectly acceptable to leave a comment and ask. - Release candidates (e.g.
cp_mapname_rc1)
Maps that are intended to be nearly finished. Here, you can (and should!) be nitpicky. Small visual issues like displacement holes or props clipping, minor balance issues, and so on are appropriate. What is unlikely to be perceived as helpful is suggesting a fundamental layout rework, or raising a thematic objection that the mapper has clearly already debated. If they've tested the map a dozen times without changing the theme, they are aware of your opinion and have made a decision.
In short, some feedback is more appropriate for certain development phases and mappers will be hesitant to follow up on feedback not fitting with the current phase. There is something of a hierarchy to feedback: First layout, then balance, then detailing, then polishing. That does not mean you cannot give theme ideas for an alpha map or encourage layout rethinking for a beta map, but you should consider the context you are giving your feedback in.
Some mappers may post specific questions in the upload comment, which will be shown on screen and in text chat during round start. Sometimes specific feedback is also requested via signs or similar development assets within the map itself. Ravidge made an overlay pack for this use case. Alternatively, point_worldtext can be used to create floating text within a map.
Remember that the mapper often has more context than you do. A map that looks unbalanced after two rounds may have been significantly worse two versions ago, and what seems like a mediocre test to you is a massive improvement for them. A design decision that seems inexplicable to you may be the result of six tests' worth of iterated feedback. One round, or three, or five, is a small sample. Mappers will sometimes run the same seemingly broken layout repeatedly across multiple tests because they want to be sure they understand the problem before they try to fix it, and because overcorrecting an issue is nothing but Verschlimmbessern. Bear with them. If you genuinely feel the test has stopped producing useful data, RTV and leave a !gf explaining why. "I RTV'd because the round has gone on for 20 minutes and nothing has changed" is fine feedback.
Mappers are never obligated to implement your feedback. They are obligated to consider it. This is the social contract of playtesting: you give them data in good faith, they engage with it in good faith. Act accordingly, on both sides.
On The Reciving End
Practical Problems
The single most important habit for a mapper receiving feedback is to acknowledge, acknowledge, acknowledge. Ask questions, don't argue. You do not have to agree with every comment, but you do need to process it. The moment you start arguing with playtesters in your own thread, you signal that being right is more important to you than being corrected, and then people will stop telling you things. The following is probably the most useful mapping feedback advice in this guide, and we are doubly lucky that it applies to game design overall:
- Players are always right about how they feel.
- Players may be wrong about why.
- Players are always wrong about the solution.
Obviously this is an exaggeration, but it is a useful framework to keep in mind. Player experience is your primary data. You are optimizing your map towards fun-ness. This means that player experience is always valid, even when you think they were playing incorrectly or misunderstanding the map's intent. At the same time, players are not designers, and their diagnosis of a problem will often be wrong. By the way, this even applies to other mappers giving you gameplay feedback: They experience the map as players first, even if they try to convince of something else. Separate the experience from the diagnosis from the prescription. "I had fun here" is the best feedback you can ever receive.
Fresh feedback may be overwhelming. After a test with 24 people over 30 minutes the feedback page can feel like a wall of conflicting and sometimes nonsensical opinions. Breathe. Do not try to process it all immediately. You can triage: what observations appear repeatedly, from multiple players? What seems most urgent relative to where the map is in development? What was the general vibe of the playtest? If you weren't present for the test, read the feedback, then watch the demo, then read the feedback again. It will make a lot more sense. Remember that Tails8521's Coldmaps app can give you the chat log without you having to load up the map and demo.
Roughly separating feedback by type, even if only mentally, makes it much easier to process. Layout, team balance, readability, detailing, performance, and theme are all different categories of problem with different solutions and different priority levels. You can solve one issue at a time and leave the rest for the next version.
If a feedback comment is unclear, don't guess. Ask. Find the player on the TF2Maps Discord and ping them about it. Most people will gladly elaborate, especially while the session is still fresh on their minds. A follow-up question also signals to the player that you read their comment and care about their opinion, which encourages them to leave feedback again next time.
As noted in the previous section, you are never obligated to implement every piece of feedback. You are obligated to consider it. Be aware that players will stop giving useful feedback if a map gets played ad nauseam without seemingly obvious issues getting addressed. They will feel like their feedback is not getting heard, at which point you cannot expect them to give more.
What is Beauty
Aesthetic feedback is the hardest category to receive because it is the most personal, and there is more going on in it than it usually appears. A comment about visuals is rarely only about visuals.
Detailing almost always has gameplay implications. Cover, visual noise, readability, sightlines, and route clarity are all affected by the artpass. Feedback that highlights a tension between how something looks and how it plays should be prioritized.
Readability is one of the most important and perhaps most overlooked considerations in TF2 mapping. The game runs fast, decisions happen in fractions of a second, and a map that requires players to parse too much visual information at once will feel sluggish and confusing even if the layout is clean and performance is good. TF2 maps with too much noise will get called out for it. Ask me how I know.
"Doesn't feel like TF2" is one of the most common and most frustrating pieces of feedback a mapper can receive. This usually means that the commenter cannot quite express what they feel is wrong with the map. When you get this feedback, try to resist being annoyed and instead ask follow-up questions in a non-argumentative way.
Aesthetic feedback is also where subjective preference is most likely to be presented as objective criticism. Use thematic feedback as a general indicator of whether your vision feels well-executed to outside observers, not as a directive to change anything specific. If one person doesn't like your theme, that is a preference. If many people independently say the map feels visually inconsistent or confusing, consider reassessing your artpass.
Getting Torn a Structurally Superfluous New Behind
First question: does the feedback actually cross a line? Is it about you as a person rather than your work? TF2Maps takes its constructive feedback rules seriously. Personal attacks on mappers are not tolerated. If you receive something that feels like it crosses a line or is not actually about the map, report it to admins. Don't respond in kind and don't let it set the tone for the rest of the feedback. Be nice.
For feedback that feels harsh but is technically about the map: try to separate the observation from the implied prescription. "Mid choke is brutal" is telling you something about their experience you can use. They are not necessarily saying your vision is wrong, or that you are bad at this, or that the map is unsalvageable. They are saying that fighting at mid produced a bad experience for them, which is data you can use. It stings, but it is data, and you can work with that.
If you are not in a good emotional state after a bad playtest, give it a day. Do not immediately tear through the feedback page sending clarification requests and defending every decision. Do something else. Sleep on it. The feedback will still be there tomorrow, and you will read it differently when you are not raw from the playtest.
Learn about the sunk cost fallacy, and about killing your darlings. Every creative person has to reckon with both eventually. The more time you have put into a design decision, the harder it is to hear that it isn't working, and the harder it is does not make it less true. Kill Your Darlings. Yes, this article is about writing, but it applies here very well.