Reply to thread

Message: <blockquote data-quote="EzekielRaiden" data-source="post: 9000356" data-attributes="member: 6790260">My initial pass of reading this simply made me think, "This is over-stretching the programming metaphor; designing a tabletop game is very unlike that, because programming something as user-side simple as a clickable button can be incredibly complicated, while TTRPGs literally have to tell the entirety of their rules to the players. However, on reflection, that would be reductive, so I'll dig into this, both what I think is liable to mislead and likely to be useful.Liable to mislead: The "SDK"/software-toolkit/prefab library/etc. analogy, if employed without extreme care, because...there is no such thing with TTRPG design. Not even families of games like PbtA have more than a completely superficial similarity here, for the reason cited above. This isn't to say that there's nothing to this--PbtA is a perfect example of how this analogy can be useful--but it's perilously easy to generalize things from software design that are simply untrue of TTRPG design.The notion that you can meaningfully save time and avoid testing by simply slotting in pre-made components from other software. In actual program stuff, this can be quite thorny, but it is at least conceivable that you could nick the (hopefully open-source!) code for doing some specific thing. I would absolutely never support just randomly nicking entire subsystems without substantial testing in TTRPGs. Even really really simple things like the frequently-borrowed 13A Escalation Die need to be reworked and adapted to be slotted into some other system.Likely useful:The idea of testable solutions. UX solutions to stuff can not only be tested, but have been and include quite a bit of important technical achievement. Not only do these things need testing, but they hugely hugely benefit from it. Making a user interface without rigorously stress-testing it is a recipe for absolute disaster in software, and a similar lack of testing (albeit of very different things) is exactly what has plagued many major TTRPGs.The idea of meaningful theory. Programming and software design are meaningfully technical fields, and have serious, real theory that you would be foolish to ignore if you're trying to design a new piece of software. Fitts' law, for example, and the fact that the corners of the screen are targets of "infinite width"--the law itself is useless for TTRPG design, but the idea that you can have "user experience" rules is not.But...how is that "design flexibility"? It sounds like literally exactly the opposite of design flexibility, being rather design specificity. Being able to narrowly specify exactly what you want. I still just don't understand how this can be parsed, in any way, as "flexibility," unless we take the meaning to be "you are able to make things you like." Which...is trivially true. You can make what you choose to make. Hence why I asked my question before. What, exactly, is lacking for "design flexibility" in TTRPG design? Anyone can choose to write whatever they want! Doing it well is, of course, significantly harder, but you are able to do whatever you feel like doing. It's not like a programming language where it may literally be actually impossible to write something because the structures or definitions simply do not exist and cannot be created.I don't see how it can possibly be of "doubtful relevance," because--again--the whole point of TTRPGs as a whole, and certainly for nearly all of the most popular ones, is to cover as much as possible the entire space of imaginable actions, given some premise. Sometimes that premise is fairly narrow, as with Masks or Paranoia or what-have-you. Often, however, that premise is incredibly broad, like "fantasy" or "science fiction with FTL spaceships." Yet for nearly all of them, being sufficiently flexible in play such that you can take any plausible desire a player might have, consistent with the premise, and implement it as an effective contribution to playing the game is extremely important. Indeed, I would call it one of the most important considerations possible, unless the premise is so restrictive it doesn't actually permit very much. Without that flexibility in play, at least for a game with a premise as open as "fantasy adventure," you will--as I'll discuss more below--need to be constantly re-negotiating what is and isn't allowed. You will be forced to grapple with the meta-considerations of play (what is permissible? How is permission gained? Who decides what makes sense, and when? What constitutes a fair exchange? etc., etc.), rather than, y'know, actually playing.Okay. I'm not saying flexibility is some like...utterly absolutely universal, "literally ALL games will ALWAYS need to PERFECTLY maximize this" kind of thing. But it is pretty clearly a virtue for lots of games, because it is supremely useful for the specific thing that (nearly) all TTRPGs are doing: trying to translate the breadth of human imagination, within an accepted premise, into meaningful consequences. Absolutes are rarely applicable. But for the vast majority of things claiming to be TTRPGs, especially those claiming to embrace the length and breadth of something like "fantasy adventure," openness to player imagination is incredibly important, yes?Words have meaning and names have value. If the name has no value, stop using it. Labels are tools; a tool that serves no purpose is no longer useful, and a tool that has negative utility should be replaced. Muddling the issue by making it sound like anything at all related to Free Kriegsspiel is a detriment, not a benefit, unless the name is supposed to mean something.Every game has these objectives. You need to be able to teach people how to play and run it in order for people to, y'know, play and run it! That's essential to playing the game at all. Is this really such a strange thing to say? If no one can learn how to GM nor play, the game is dead.Have you ever run a game for someone who had never played that game before? If so, you have (by definition) used it for teaching. And, given it is impossible for you to have a priori knowledge of any game before you actually play it, you have both played at least one game for the first time and run at least one game for the first time, which (by definition) means either someone was teaching you, allowing for the option of teaching yourself. It is impossible--even with FKR!--for people to not have a first-time, learning experience doing these things. Hence, teaching and learning are necessarily part of play. The original Free Kriegsspiel just had an extra layer of teaching on top.By definition, absolute freedom includes the freedom to do harm. Locke called it the "state of nature." Hobbes--there's a reason I've spoken of a "Hobbesian central authority"--used the Latin phrase bellum omnium contra omnes, "(the) war of all against all." But both of them believed that this state naturally must give way to the "law of Nature," which (more or less) means that rational individuals come to realize that actually exercising truly absolute freedom is kind of crap, and leads to bad outcomes, e.g. "no one ought to harm another in his life, liberty, and or property" because it's just not smart to do so. Through the application of the "law of Nature," men can then work their way out of the state of Nature and into civil society.Everyone has been rather consistent in telling me that FKR does not do point 2, and in fact considers it anathema. That's the secondary goal of the invisible rulebook (after the alleged benefit that the invisible rulebook is always functional because it relies only on natural reasoning.) That is, do not assign authority up front, on anything, ever--because that's making a visible rule, and visible rules are not acceptable.Have I been misled?As for point 3, it very much seems to me that that's exactly what FKR is doing. It's just that it takes the length and breadth of RPG design to be "DON'T assign authority, except moment-to-moment." Because the whole point of an invisible rulebook is that it isn't designed at all. It can't be. A designed thing is, necessarily, a visible thing, at least in order to be designing it. An invisible rulebook is, by definition, the absence of design.Doesn't seem so, because as stated, FKR chucks the very concept of design out the window by using invisible rulebooks. Where there is nothing to observe, test, or communicate, there is no design. There can't be.</blockquote>

Verification