If the intended function is to sell units then obviously that function can't be playtested until after release, where the buying public's reaction will be both playtest and payoff simultaneously.
That's not a function of the rules. That's not a thing the rules DO. It is a consequence that follows after design is finished. Rules do not
cause success; they are one of the factors which feeds into it. You cannot
design success; you can merely make a design with the intent and hope that it succeeds.
I disgaree; and say that - if and when done - this consideration of such rules is in fact very much a part of design; though maybe not a part much desired by the designers.
Again: it is not. It is not part of:
- Defining some gameplay-concept as valuable
- Setting an evaluation metric to measure the rule's functionality, and (if relevant) the breadth of acceptable results
- Drafting a rule which implements the defined value
- Playtesting and collecting data
- Reviewing and rewriting the rule as needed
- Repeating the previous two steps until the desired function is achieved, or you determine that the initial concept was unworkable
At no point does "financial success" enter into
any part of this process. But this is, emphatically, what design
is.
Instead, success is factored in
before and
after this process. Before it, it is part of learning about your audience and determining what things are worthy of being valued as elements of gameplay. Much like, for example, one should do market research when designing a new car, so that the initial values which feed into the design process are ones likely to actually catch customer interest. But those things are not
design goals; they are
customer values. And then, of course, after the design is implemented for customer use, success obviously comes in based on sales/usage/etc.
If something can be designed with intent to fail (which is, I think, incontrovertible) then it can be designed with intent to succeed.
But that intent-to-fail is not a
design goal. It is prior to the design process: intentionally choosing unwise design goals, frittering away design time, intentionally using bad metrics or collecting bogus data, etc. It is philosophically
entirely prior to the actual process of design. Certainly, someone with an intent to fail will willingly and intentionally choose to design badly, and this will likely mean that their design goals are bad (albeit perhaps superficially good; usually one must be careful to
appear to do good design while actually doing bad design, if one's intent is to fail.)
Intent is much, much, much too broad. It covers far too many things which are simply not part of the process of design
qua design. "Design goal" is far more specific than that: it is something you are specifically doing, as part of the process of design, to implement some functionality that the rules themselves perform or do. "Succeed" is not a functionality of the rules; it is a thing one hopes that will
happen once the rules are actually out and about. But it is not actually a function performed by the rules.
Like...consider a hydroelectric turbine. There is no part of its design which has the function of "save lives." Nothing the generator does is involved in life-saving; its functions do include safety of those operating it, and it likely has various measures to prevent accidents or disasters, but it is not at any point a device whose function is to save lives.
And yet! That very hydroelectric turbine will most likely provide at least some of the electricity used to power a hospital at some point. Which means that one of the
effects of designing a high-quality, widely-used hydroelectric turbine is that lives will be saved. The designer may even
intend that such a thing happen as a result of the use of this device. (Certainly, I imagine many such designers today will be thinking about climate change, and thus have at least some intent of mitigating its effects through providing clean energy.) But that intent has absolutely jack-all to deal with the
design goals of a hydroelectric turbine.
"Intent" covers both downstream effects you hope to have, and design goals while you are in the process of design. The word does in fact refer to both. But pretending that that means ALL intents are precisely the same as design goals is like saying that every rectangle is a rhombus. Sometimes--rarely--a rectangle IS a rhombus, at which point we usually call it a "square." But most rectangles are not rhombi and most rhombi are not rectangles. Most downstream-final-product-intents that designers have are not design goals, and most design goals are not downstream-final-product-intents.