I agree with you that game rules are aimed at uses or purposes. VB contends that the use that should most motivate rules design is
How does it procure that players will add the unwelcome and unwanted to their fiction?
Well, I've already said that I don't entirely agree with that perspective. That is one thing rules can do, yes. But rules also
provide definition to what is actively welcome and wanted.
After all, the rules of golf indicate that a high score is bad. The rules of most other games indicate that a high score is
good. Neither of these things has anything to do with adding the unwelcome or unwanted to play.
Not that I even agree with Mr. Baker's characterization of "unwelcome" (nor "unwanted") in the first place. At
absolute best, I would grant that it is what I might call "zeroth-order" unwelcome/unwanted: that is, something which is undesirable at the layer "closest to the metal", to use a programming analogy, something undesirable at the level of binary numbers. But at many (indeed, probably
most) higher orders of abstraction, these things are not only NOT unwelcome/unwanted, they are
deeply desired and wanted. E.g., nobody
wants to give the opponent penalty shots, but people
do want bad behavior punished in warranted ways, and penalty shots are one of those things. Likewise, nobody wants to be thrown in prison, but we do want murder to be punished so people have a good reason to choose not to do it. Etc.
Which speaks to the constitutive effects of rules
I'm not sure what this means--"constitutive effects"?
What play will the rule give rise to that would not be seen in its absence?
Considering VB's suggestion that otherwise live negotiation and collaboration will do a better job than formal rules, it seems like a good question to ask
I continue to contend that live negotiation and collaboration, while extremely useful and important, are in fact
highly augmented by significant design work which has nothing to do with inducing unwanted/unwelcome results, but which
does have something to do with play that would or would occur in the absence of those rules.
Case in point: Page 42 (of the 4e DMG). One of the important things that needs to happen if you want players to
choose to improvise responses on the regular is...having results that are actually worthwhile, and having chances to achieve those results that are actually reasonable. That's what Page 42 provides. It provides damage calculations that are apt for any given level, and appropriate skill DCs for checks where you don't already know what is needed, and just need something that you know is reasonably challenging for improvisational skill checks that the rules can't possibly hope to have fixed answers for.
In the absence of rules like that--as I have personally seen in both 5e and 3e--you get things which...unfortunately tend to deaden player interest in improvisation. With 5e, it's because that negotiation process often produces inadequate results, again
purely in my experience. Every GM has nothing but their gut intuitions to guide them, and I'm sorry to say, but most 5e GMs I've had do not have good gut intuitions for the benefits that improvisational actions should have, nor for the difficulty that improvisational checks should require. (I will note, here, that my
current 5e GM is an exception to this pattern on both fronts.) With 3e, conversely, the issue was that with so many things so perfectly nailed down already...most players became pretty quickly convinced that if they hadn't
specifically built their character to be very very good at a particular thing, it just wasn't even worth attempting; they'd much more than likely fail, and if they did fail, they'd likely
suffer for it, not just facing opportunity cost.
What do players do without the rule? (What patterns or norms for live negotiation and collaboration are going to be followed?)
Authoring a rule casts doubt on the standing of existing norms. If there is a rule that I can narrate my character flying on Tuesdays, that seems to rule out my narrating my character flying on other days. So another question
Does it? I don't agree with that at all. SOMETIMES it does. But if you design the rules in the right ways, it should not.
A rule like what you describe says nothing about what you can narrate on any day except Tuesday. On Tuesdays, you can narrate that way--it is officially confirmed. It's a logical fallacy to conclude that, simply because you phrased it in that way, you therefore
cannot narrate your character as flying on any other day, or that anyone other than you is expressly forbidden on any other day.
This is one reason, among many, why I don't care for rules that set a
baseline of bad performance, which one can only claw out of by significant investment. I instead prefer rules that set a baseline of acceptable competence, which one can then grow beyond. I also prefer extensible framework rules--rules which apply a common structure to many situations--rather than trying to tackle the genuinely insurmountable task of creating a single, discrete rule for the infinitude of tasks one might conceivably attempt.
What will the rule imply that we should not say?
Some other core questions that perhaps come up more in commercial design
What problems do players have to solve?
What jobs do players have to do?
How does the design address those in ways players will uniquely value (i.e. why should they prefer this design over others? How is it differentiated?)
All on top of your questions, of course!
These are all questions to ask
once you have the rules. They're part of the testing process. Generally, the alpha process, since this is all about developing the elements so that there is enough game to actually play, and it won't just collapse on itself when you look at it from juuuust the wrong direction.
In other words, these questions--including the ones above that I responded to--are one or more steps
less abstracted than the questions I asked. The questions I asked were at the highest tier of abstraction while still being useful, where we are looking at something--either a single rule, or a set of rules--in the broadest possible way without collapsing it down to an uninformative "Does it work?" question. In this sense, design is a pyramidal structure. "What should I do?" is the
absolute highest-abstraction question, and thus mostly useless because it lacks enough information, enough context. The three questions I asked are immediately below it, having enough context to divide the space into domains (rather than canvassing the entire space with a single over-broad question). Your questions are varying levels of abstraction below that, mostly concerned with the answers to the second of my questions, "Does the rule(set) actually
do this?"
Please don't get me wrong here; I'm not saying your questions
aren't worth asking. They very, very much are. But they are fine-detail questions, process questions, things we must work through on the journey to being able to answer "yes" to the question, "Does the rule(set) actually
do [what it was made to do]?" It's very important to ask, and answer, most if not all of the questions you've posed here. But that's not really what I was aiming for. I was, very intentionally, aiming for the maximum
useful abstraction, separated as far from the details as possible while still having utility and relevance.