Thread by @emshort

I retweeted this yesterday, and it's a great thread.

I've been thinking about it more since, as well as the methods I use to try to proof against the problems that I know are almost definitely going to turn up despite my best efforts.

https://twitter.com/danctheduck/status/1344357310399877120

a few things I find helpful (not by any means a complete list):

- document design intent. even when working alone, but especially when working with a team, it's easy to add a feature, discover in testing that the feature isn't working, and then get hung up on fixing the feature

...when in fact a good part of the time it's worth asking "is this actually even doing the thing it was spec'd to do? what were we trying to solve with that? is the 'fixed' version of this feature actually going to do what it was supposed to, initially?"

- especially with a narrative game, be cautious of assessing a purely mechanical prototype without any kind of fiction attached -- story can change completely how players experience something and how they make choices

- again, for narrative: build your system so that it offers consistent knobs/methods for controlling how much work the player has to do to get the next narrative beat.

that might be anything from automatically offering hints in a text adventure after N failures to solve a puzzle

to building a conversational game where the NPC agent is motivated to advance the story in some direction

but it's almost always necessary to tune pacing, and you really don't want to have to rewrite a whole quest/puzzle/level/chapter in order to achieve that