Reply to thread

Message: <blockquote data-quote="EzekielRaiden" data-source="post: 9288761" data-attributes="member: 6790260">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.Again: it is not. It is not part of:<ul> <li data-xf-list-type="ul">Defining some gameplay-concept as valuable</li> <li data-xf-list-type="ul">Setting an evaluation metric to measure the rule's functionality, and (if relevant) the breadth of acceptable results</li> <li data-xf-list-type="ul">Drafting a rule which implements the defined value</li> <li data-xf-list-type="ul">Playtesting and collecting data</li> <li data-xf-list-type="ul">Reviewing and rewriting the rule as needed</li> <li data-xf-list-type="ul">Repeating the previous two steps until the desired function is achieved, or you determine that the initial concept was unworkable</li> </ul>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.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.</blockquote>

Verification