Thanks and some questions :)
Valamir:
Hey, thanks for the questions.
1) Control without Introduction
I didn't envision the utility of Controlling a Component without it being present in the scene, so while not explicit, the implication is that such things are not Controlled.
However, that would make a splendid Gimmick, perhaps for purposes of building up a shadowy villain in the background.
2) Convert Component into a Master Component
That's a pretty advanced question. I think by the rules once a Component has a Proper Name it cannot be converted to a Master Component because by definition a Master can only have Traits that are universal to all members. By the rules, you'd create a new Master from scratch including just those Traits of the prototype that are to be universal. However, either of your suggestions is a fine Gimmick if it feels right to do it that way for a given occassion.
3) Taking Control of Master Components
Not having a copy of the book in front of me, I can't be sure, but I don't think there's a rule against calling on Events for dice, although all of the examples refer to Traits. There is a section in the book demonstrating the parallels between Traits (facts for Components), Events (facts for scenes) and Tenets (facts for the game). I certainly wouldn't challenge you calling on the "standing on the chair" event to gain a die, and ultimately if no one Challenges it...
David Artman:
Quick follow-up, Ralph:
If I make a Master Component using a named Component as a model (i.e. pay full price for the MC, as you've said above) does the named Component get a "refund" on the coins spent to buy its (now-Master) Traits, less the cost of being a member of the Master Component 'class?' Or does the original just stay as-is, with specific traits that now just so happen to be part of a Master Component class? (The latter is more elegant, vis a vis coin management; the former seems more fair, vis a vis which player had to buy the original at what is now a 'premium.')
I've also wondered about coin costs to remove a Trait that comes from a Master Component. For instance, there's a "Birdman" MC that grants the Traits "Wings," "Eagle Eyesight," "Raking Talons," and "Vicious Beak." If I make a blind (or wingless) Birdman, which of the following is true:
* The Blind Birdman buys the MC, PLUS one coin for the Trait "Blind"?
* The Blind Birdman buys the MC, MINUS one coin for lacking the Trait "Eagle Eyesight"?
* The Blind Birdman can't take the MC, being blind, and so has the other Traits singularly, for a three coin cost?
I'm mainly interested in the core rules--I know I could Gimmick to let any (or all) of those options be legitimate.
JoyWriter:
Quote from: Valamir on November 19, 2009, 06:02:42 AM
By the rules, you'd create a new Master from scratch including just those Traits of the prototype that are to be universal. However, either of your suggestions is a fine Gimmick if it feels right to do it that way for a given occassion.
After I've got a bit of experience playing, I'd like to try adding prototype inheritance as a gimmick. Haven't quite got it clear yet but I think it could produce some interesting dynamics, based on the current link to object orientated programming.
folderol:
I think I'm starting to get a bit a feeling for Rules Gimmicks: they are actually the way to elaborate, clarify or even oppose (if desired) the core rules in a way that fits to your own style of play. The core rules have no intention to explain every little detail and exceptional case that could occur in play and also doesn't need to, e.g. if there's suddenly a need to start manipulating a Component that's not present in the current Scene, then make a Rules Gimmick out of it: either require taking Control of it for 1 Coin, or don't and allow players to manipulate them for free, or forbid handling Components unless they're Introduced into the Scene. It doesn't matter much: as long as your own group of players is OK with it, go for it! In the past, I saw them more as variations on the core rules, but I'm starting to see them, not as alternatives, but simply as additions and the core rules are not a set of laws to strictly abide by.
@Valamir:
Thanks for your answers! It's good to know that's how you see Control, i.e. something that only matters for Components present in the Scene. It makes deciding on a Rules Gimmick for it a bit easier. I'll go with what EvilCat already suggested before: Components not Introduced into the current Scene are free for all to manipulate without the need to Control them.
@David Artman:
When making a new Master Component from scratch based on a prototype Component, I wouldn't allow refunds on its Traits as this could lead to arguments concerning who added which Trait to the Component. If these Traits weren't added to the prototype to begin with, the story (or at least the prototype Component) would have been far less interesting, so the Coins spent are well spent. And it's, as you say, more elegant to just leave them in place on the prototype Component, thereby adding to the prototype's Importance.
However, I would not always deem it necessary to create a Master Component completely from scratch if a prototype Component already exists and therefore: When turning a regular Component into a Master Component and additional Sub Component that represents the original Component, the Master Component and the Sub Component Traits are paid for (2 Coins), but the already established Traits may be reorganized for free. But remember that a Master Component cannot end up with a Proper Name and this Trait should be moved to the Sub Component for sure.. It all depends on the given situation: is this Component Important enough for it to have a high Importance because of all (duplicate) Traits that also exist on the new Master Component. Or has the Component just recently been introduced, given a Proper Name, given tons of Traits and now, just a bit later in the story, needs to be upgraded to a Master Component? In the latter case, I would use the Rules Gimmick proposed above.
When overriding Master Component Traits, I would pay 1 Coin for the Trait Blind which overrides Eagle Eyesight just as the example in the book with the Zombies with Slow Shambling Gait Trait and Fred who's having the Doesn't Have a Slow Shambling Gait Trait. The overriding Trait doesn't need to be in the format "Doesn't Have ..." but can be described in a nicer way like Blind overriding Eagle Eyesight. One could say that Doesn't Have a Slow Shambling Gait actually offers no added value but just negates Slow Shambling Gait while Blind doesn't just override Eagle Eyesight (otherwise it would be Normal Sight) but adds even something more than just negating the Trait. I think that's acceptable: a Master Class of Wisdom Trees being all Very Old doesn't mean that one can't be Young instead, thereby overriding Very Old, it doesn't need to be Not Very Old and Young as well. I'd say that an overriding Trait has the power to do whatever it wants to the Trait it is overriding: it can simply negate it, or be the opposite or even empower it, e.g. one of the Wisdom Trees being A Lot Older Than the Other Wisdom Trees and a Birdman Master Component having Eagle Eyesight Equals Almost Blind Compared To How Well This One Can See.
But I also know you want Ralph's opinion, not mine, because you want to know "how the core rules would do it" as I wanted to know how the core rules deal with Controlling Components that haven't been Introduced. That's OK with me :)
@JoyWriter:
Check out Sindyr's post here where he describes a Master Component of Grey Elves to "inherit" from a Master Component of Elves, which in turn "inherits" from a Master Component of Immortals.
Valamir:
Quote from: David Artman on November 19, 2009, 08:08:28 AM
Quick follow-up, Ralph:
If I make a Master Component using a named Component as a model (i.e. pay full price for the MC, as you've said above) does the named Component get a "refund" on the coins spent to buy its (now-Master) Traits, less the cost of being a member of the Master Component 'class?' Or does the original just stay as-is, with specific traits that now just so happen to be part of a Master Component class? (The latter is more elegant, vis a vis coin management; the former seems more fair, vis a vis which player had to buy the original at what is now a 'premium.')
The core rules do not envision a refund.
Quote
I've also wondered about coin costs to remove a Trait that comes from a Master Component. For instance, there's a "Birdman" MC that grants the Traits "Wings," "Eagle Eyesight," "Raking Talons," and "Vicious Beak." If I make a blind (or wingless) Birdman, which of the following is true:
* The Blind Birdman buys the MC, PLUS one coin for the Trait "Blind"?
* The Blind Birdman buys the MC, MINUS one coin for lacking the Trait "Eagle Eyesight"?
* The Blind Birdman can't take the MC, being blind, and so has the other Traits singularly, for a three coin cost?
By the Core rules you pay the Coin (and gain the Importance) for designating the individual as Blind.
Quote
, I would not always deem it necessary to create a Master Component completely from scratch if a prototype Component already exists and therefore: When turning a regular Component into a Master Component and additional Sub Component that represents the original Component, the Master Component and the Sub Component Traits are paid for (2 Coins), but the already established Traits may be reorganized for free.
I wouldn't oppose that gimmic.
Navigation
[0] Message Index
[*] Previous page