The No-Feedback Loop

One of the things I have never been good enough at as a developer was sending feedback to my freelancers. Yes, a great deal of that is the industry standard and driven by work conditions–if I am already at 50 hours in a workweek, I have to turn over finished text in the morning, and there is something in a freelancer’s turnover that has to be fixed, it’s faster and easier to just fix and send it to the next step (be that editing, approvals, layout, or whatever) than write to the freelancer explaining what needs change and hoping they give me a usable version in time. And that means that writing up and sending feedback becomes extra work I am doing that doesn’t directly help hit my next set of deadlines.

On the other hand, the more I can help freelancers become better writers, the better chance I have of not being in the same situation in the future. Sadly though, the decreased chance isn’t decreased by a lot. Firstly, people who stay in the industry tend to be the ones who figure out what they need to improve even if they don’t get specific feedback. Secondly, the percentage of freelancers who stay in the freelance-ttRPG-writing biz for more than a couple of years is pretty small compared to the fraction who dropout for whatever reason. Third, even if a freelancer gets feedback, sticks around, and gets better, there’s a good chance they’ll get grabbed up by someone else and not have time to do whatever projects I happen to be working on three years later.

Of course, all that doesn’t mean there’s no value in giving that feedback, however much extra work it is for me. If nothing else, it makes it more likely I’ll get to buy a good product later down the line. But more importantly to me, I care about games and gamers. I want to help if I possibly can, and feedback is a great way of doing that. However, in addition to lack of time, I’m not omnipotent. My feedback could be *wrong* for any number of reasons. I might lack the technical knowledge to understand why a freelancer is representing a specific real world event in a certain why. I might not have the cultural, social, or personal viewpoint to see why some inclusion or deletion is significant and important. I might just have a dumb opinion no one would agree with (it happens!). And when feedback is given privately in a professional setting, even if I am wrong, a freelancer might be intimidated by the imbalance of influence within the industry, and not feel safe to tell me I am wrong, or even suggest I am missing something.

(By the by, if you are ever working for me, and I am wrong in my feedback, let me know. I don’t promise to agree with you. I do promise to consider my own biases and limitations, and not punish you for having a differing opinion.)

So, now that I have begun looking at old emails and direct messages I have sent to freelancers over the years, I have concluded that scrubbing these of any specific details (to protect both the freelancer and whatever company I was working for when I wrote it, even if it was MY company), and posting it publicly may overcome a lot of these issues. Yes, the feedback isn’t going to be specific to the issues of everyone who reads it, but it can get into a lot of hands with a single post on my part, and if I’m wrong people are more likely to feel free to point out why (even if it’s just among themselves).

The Issue

Since I am redacting a lot of the details in the first part of this letter, I have to explain what the issue was in the freelancer’s handout, that I felt the need to both fix, and explain why I was fixing it.

In a d20-based fantasy ttRPG adventure, the Freelanced has included a room with a treasure chest. This was not a major villain’s cache, nor even the main focus of the room. There was nothing in the chest relevent to the adventure’s plot, nor tightly linked to the themes of the adventure. It was just one element of a typical encounter within the adventure.

And it had a fire trap.

Now, an occasional trapped chest is a good idea. There was no note as to who had the keys for the chest (after all, whoever trapped it wants to be able to open it safely), but that’s a minor issue. But more importantly, the trap did a variable amount of damage based on how much you failed to disarm it by, and by how far away from it you were, and by how much you failed to pick the lock (if you didn’t even try to disarm it), and special rules for determining how much damage each thing in the chest took depending on which of the above conditions happened.

It, by itself, took up more wordcount than any other part of the encounter, and more than most complete encounters within the adventure. And, weirdly, it’s not the ONLY time I got a overly-complex-random-fire-trap in a freelancer adventure turnover, nor the only time I’ve given feedback about it.

So, I wrote a short note of feedback to the freelancer. letter in response. I have copied it here, minus any identifying information and with a dab of editorial clean-up, as the second “Letter from a ttRPG Dev to a Freelancer.”

After a polite intro, and some minor notes on lesser matters, I wrote:

“About the fire-trapped chest. In the final version, you’ll find it just does flat damage in an area (Reflex save for half), and goes off if you fail the roll to pick the lock, or smash the chest, or fail the roll to disarm the trap by 5 or more. I wanted to explain why, and it’s not because the rules you wrote are wrong, or don’t work, or that they don’t make sense.

It’s just because, the rules eat up a lot of space, they are a lot for the GM to absorb and run correctly, and the players have no way to know how detailed the rules they are interacting with are. Even if the GM knows that the trap could have done more damage, or could have done less damage, or could have eliminated more items, all the players will ever hear is that it goes boom and does some damage.

So, the play experience for the players is nearly the same, and the cognitive load on the GM is much lower, if the trap just has a simple trigger, and does set damage. The very fact that damage is rolled already creates a wider range of possibilities, and does so in a way the players and GM are used to an expect. While the players aren’t likely to find out that a trap that ends up doing 4d6 fire damage to them could have done 8d6 fire damage, they will know if they made or failed their save, and are likely to know if the GM rolls 12 damage on 6d6.

That’s not to say a trap should never have this level of complexity, but the ‘weight’ of these rules is so great, the chest or trap would need to have a bigger narrative role within the adventure to justify the number of words on the page, and the amount of time the GM needs to figure out how to run it, and how much time it would take at the game table in play.

For example, if an important part of the adventure was getting a MacGuffin, famously locked in the Cask of Conflagrations, you could build up to this complex and detailed trap as part of the adventure leading up to that moment. Players could have chances to speak to people who failed to get past the trap, or find scraps of ancient descriptions of it. They could have a side quest to get some anti-fire salve to help survive it, and be aware that it was an especially devious and complex mechanism that would take more effort and carry heavier consequences than ususal.

Ultimately, this is an issue of thinking about the end play experience for the GM and players. (Note that there certainly ARE people who primarily engaging with adventures by reading them, which may react to something like this differently, but in my experience those people enjoy any well-written encounters, so there’s no actual benefit of having any rules section be longer and more complex than is justified by the narrative value the players will experience.) Every unusual exception to how rules elements are used is one more thing the GM has to spend mental energy understanding before they can run an adventure. Asking GMs to do so isn’t inherently bad, but the extra effort should be linked to extra fun for GM and players both.

There’s also nothing wrong with wanting to do something out of the ordinary with a trap, but being creative and being complex aren’t always linked. If the trap did fire damage, and sprayed alchemical materials that attracted more wandering monsters to attack the PCs as an additional effect that would be unusual, but could be explained in 1-2 more sentences. If it triggered a wand of magic missiles from inside that had just a few charges left, which the PCs could then recover as treasure, that would be unusual, and the end experience for the players would be something fun and new linked to loot, which means that wand then has a story connected to it, which can boost roleplaying opportunities.

I also want to make clear that the overall encounter was good, and this was a pretty easy fix for me as developer. But while I think the extra design work you did here doesn’t serve the adventure well, it was mechanically sound and an interesting read. I want to make sure the end message you get is not just “this was bad” or “this is too long,” but “this didn’t work well where and how it was–but keeping thinking about how to deliver unexpected things for GMs and players to enjoy, and know that if used a different way, these well-done game mechanics could work great.”

So, there’s some of the advice you might get from me, if I was contracting you to write for me.

Support My Patreon
The more support I get, the more time I can spend on writing things like this. 

If you enjoy any of my articles, please sign up, for as little as the cost of one cup of coffee a month!