Thanks and some questions :)

[folderol]

First of all, a big thanks to Ralph & Mike for this fabulous game! Being an former D&D player (many many years ago), the freedom experienced while playing Universalis is highly refreshing. I played it once at a friend and was so excited about it I immediately went ahead to buy the book as well. Now, the week after, I ordered about 400 small decorative glass beads and 72 small D6 dice to be fully set (I tend to overdo it a little bit sometimes.. OK, I admit, quite often actually). Now I only need to start bothering all the people I know to get them to play

Anyway, I went through the book in a couple of days, designed my own player's aid and (awaiting the arrival of my dice & glass beads) I've been reading a lot on this forum looking for some answers to my questions. I found many, but not all, and I still have some doubts about the concept of Control. Any help or comments about these topics is highly appreciated! And looking back on the amount of text I wrote, I want to throw in an apology for the length of this post

1) Control without Introduction

Considering "you Control any Component that you Introduce into a scene (either existing or newly Created)" (p49, Control), can a player choose not to Introduce a newly Created Component (e.g. a Blue Piglet called Nugget that Can Alter Its Size and Can Talk for 5 Coins) into the current scene (located in The Forest) without specifically "spending a Coin to explicitly state a Component as not being in the scene" (p27, Introduce Components) (which prohibits other players from Introducing him later on in the same scene), because Nugget is not physically present (yet) at the current Location? Or does Nugget need to be Introduced (for free) into the scene after all, simple because there's being talked about by some Character, i.e. any mention of a Component in a scene, physical presence or not aside, requires Introduction? Is the latter correct?

If Control without Introduction were possible, could another player Take Control (1 Coin) over Nugget (without Introducing him as well) and state that he Lives on the Roof of a Skyscraper for 4 Coins: the Skyscraper and its Roof being two newly Created Locations (2 Coins) linked by a two-way ownership Trait (Skyscraper: Has Roof / Roof: On Top of the Skyscraper) (1 Coin) and the Roof linked to Nugget by a two-way relationship Trait (Skyscraper: Nugget Lives on the Roof / Nugget: Lives on the Roof of the Skyscraper) (1 Coin). All of this without ever introducing Nugget nor the Skyscraper into the current scene (which is located in The Forest) because neither the Skyscraper nor Nugget are 'present' there. Correct?

Furthermore, if Control without Introduction is possible, then what if someone wants to Introduce a Component already Controlled (but not Introduced) by another player, like Nugget as described above? Is a Take Over (1 Coin) required before Introducing him (another 1 Coin). This would mean that introducing a newly Created Component costs 1 Coin: "If the Component has not yet been Created, then it is Created now with that Coin" (p27, Introduce Components) and Introducing an existing Components also costs 1 Coin only if it's not Controlled by another player yet, otherwise it would cost 2 Coins to Introduce it. Correct?

Writing all these situations here made me actually change my opinion and I'm now favoring the idea that Control is only possible once something has been Introduced and that Introduction is required, even when merely mentioning a Component, thereby having it "available to talk about" (and not necessarily "present" in the physical meaning of the word). In that case "spending a Coin to explicitly state a Component as not being in the scene" (p27, Introduce Components) would mean a Component is very much Introduced into the scene (if newly Created) to be able to talk about it, but is not physically present at the Location, therefore, Introduced, but absent in the scene. Correct?

2) Convert Component into a Master Component

It's easy to turn a regular Component into a Master Component by just buying the Master Component Trait (1 Coin). However, a regular Component with a Proper Name (e.g. Nugget as in the example used above) poses a problem because "A Master Component cannot have a proper name" (p70, Master and Sub Components). How would you deal with that? Would you create the Master Component Piglet ("What? There's a whole race of those?") from scratch as Master Component, Piglet, Blue, Can Alter Its Size and Can Talk for 5 Coins (no Proper Name this time) and consider the duplicate Blue, Can Alter Its Size and Can Talk Traits Nugget has as extra Importance because he was the first one in the story? Or would you "upgrade" Nugget to a Master Component (1 Coin), then Create a Piglet Sub Component (1 Coin) and finally "move" the Proper Name (1 Coin for removing Trait, 1 Coin for adding a Trait) to the Sub Component (because it put the Master Component actually in an invalid state) for a total of 4 Coins? I'd probably go with the first suggestion because it doesn't put the Master Component in a invalid state (albeit temporarily).

3) Taking Control of Master Components

Does one need to Take Control of Master Components to add/remove/restore Traits? This has already been asked elsewhere on the forum but didn't get answered. However, if there is no Control without Introduction (see my first question above), then one cannot Take Control of a Master Component to be able to add or remove traits to/from it, because "Master Components cannot be introduced into scenes" (p70, Master and Sub Components)? But this is in contradiction with the rule: "you may not directly do these things to any Component that is not under your Control" (p49, Control). This leads me to believe that maybe Master Components are the only Components that don't need to be Controlled to be able to manipulate. Correct?

4) Drawing Upon Events

OK, I know that only Traits can be Drawn Upon, not Events. However, it often happens in our games that someone regrets not adding a Trait instead of "just" an Event. Let's reuse one of Ralph's examples "Jack stands up on his chair to get a better view" would be an Event. It wouldn't be very practical to attach a Standing on a Chair Trait to Jack because then Jack is on the chair forever until you pay another Coin to remove him from the chair (poor Jack). In a Complication however, Standing on a Chair could be a beneficial/detrimental Trait to Draw Upon. In this case I would - while having a Complication - still add the Trait (which is easily justified) and then Draw Upon it and not allow the Event to be Drawn Upon of course.

I can't get my head around Jack standing up onto his chair but in the end not "really" standing there and still having to pay an extra Coin to actually add the Trait. One could say that 1 Coins suffices to buy both the Event and the Trait in this case, because it's the logical consequence. Although I suppose things could get rough while "Jack climbs onto the chair" (1 Coin) in case of an Obstacle Complication, e.g. a player Taking Over the Chair and Buying Dice because the Chair Has Wheels and the Location seems to have a Wet Floor. Jack might not get to his Standing on a Chair Trait, but instead Fall of the Chair and end up with a Broken Leg instead. More Coins for everybody and far more interesting than just letting him reach the top of his Chair

The thing is that I don't feel comfortable adding Traits like Standing on a Chair because they don't signify a long-lasting property for Jack. Maybe the answer here should be: if it matters, add it when you need it, otherwise don't. Or don't add it at all and just Buy a Die for it during a Complication because chances are that Jack could benefit from Standing on a Chair only once anyway.

OK, that's it for now! Sorry for any serious headaches my ramblings might have caused, but thanks if you've actually read this far. Any comments are much appreciated!

[EvilCat]

Hey, Folderol! %) I encountered some problems you mentioned, so I'll try to answer and add some related questions. Sorry, I don't have a book at hand to reference pages.

1) Control without Introduction. Actually, it bothered me as well. "Control doesn't last beyond scene", so, either non-controlled components are communal or can't me modified. There is no clear rule or prohibition for this, so I take it they are communal. This is somewhat strange: not even a victory in Conflict lets you take over a component unopposed, and the right to modify non-controlled components is one of the prizes in Conflicts. Yet, in the next scene, if a component isn't directly involved, you can mold it all you wish unless someone challenges. It's not like you must Introduce a planet into the scene to have some bartender spill a few coin-proven facts about it.

I didn't have problem with that unclarity yet (except for PC Add-on, in Universalis you have to think communal), but I don't have an answer.

2) Convert Component into a Master Component. I've done this once. It was dramatic, actually %) The character found a strange dog carcass on the beach and had to overcome the dread (in a Conflict). The dread side (mine) lost and the character just smirked, but once she got to the high ground, she saw that the whole beach was littered with these corpses... I was planning to raise them further in the game, but we didn't finish -_-

About named characters conversion, I think, it goes like this:

Fido the Doberman (Mutated, Special Training) - 4 coins.

Fido, a B.B. Labs Doberman; B.B. Labs. Doberman (master component, Mutated, Special Training) - 6 coins. (well, I would count 7, for the expanded role - B.B. Labs Doberman can know something about the Labs, while a mutant Doberman not as much.)

So, you pay 2 (or 3) coins and it is done.

3) Taking Control of Master Components. You can't introduce it to a scene, so you can't control a master component (unless there is a rules gimmick about that). This is one of the things which led me to believe that off-scene components are communal. In some cases, though, the gimmick about controlling master components can be useful. Like PC add-on, but for concepts and archetypes.

4) Drawing Upon Events. Now, that's a problem I encountered on a regular basis! If events are less useful than traits, everyone go for traits. You end up with characters full of traits like "held by the gargoyle" and "doesn't know where he is". There's no clear way to distinct traits from events and leave a game universal: that what happens leaves a mark on us, and any process is a trait for its subject - until it's over. I think you should be able to draw on events, even as far-fetched as from long past. The line between significant and petty events is the same as between traits and color. Actually, in my games, players preferred to signify events by the mark they made - new traits and facts, but they deemed the events free. Otherwise, it made them uncomfortable paying a whole coin for something that doesn't last nor help anything. (If the event itself had impact, it was posed as a fact.)

About petty facts, there was a game when a character who was a simple hobo in the beginning became a Power in the scene before the last. But he still had traits like "has a club". Arguably, they became insignificant (and thus shouldn't have affected his Importance), but removing then would cost a coin. The club could affect the story in some way (for example, he could drop it when rising to the Heart of the City, and someone could trip on it and pull the plug while falling; classic movies have a lot of these twists). I "lost" a lot of coins on removing insignificant traits when my components transformed from quazi-human to cthulhuesque. I don't remember exactly, but these traits were still present from a logical point of view, yet the character new role made them obsolete.
I guess I'll propose a gimmick for these situations...

[folderol]

Hey EvilCat! Thanks for your comments!

1) Control without Introduction

I very much like your idea for unintroduced (and therefore also uncontrolled) Components to be free for all to manipulate without the need to Take Control of them. However, this seems to be in conflict with the rule about manipulating Components: "you may not directly do these things to any Component that is not under your Control" (p49, Control). If it weren't for this sentence, I'd happily accept your interpretation. Maybe that sentence should be changed into "you may not directly do these things to any Introduced Component that is under Control by someone else".

It would however support the theory that only physically present Components in the scene would require Introduction ("coming on stage").

Example: Jack gets Introduced (1 Coin) into the scene, talks a while to Marissa (1 Coin), then Exits the scene again (1 Coin). At this point, I'd say all Control over Jack is lost because he "got off stage" (Exit) and if the player in Control of Marissa then narrates how "Marissa noticed that Jack had a nasty cut on his hand" (1 Coin) and adds Wounded Hand as a Trait to Jack (1 Coin), I don't see the need to take Control of Jack and pay another coin for that.

It would even explain how to manipulate Master Components (no need for Control over them anymore) while not being able to Introduce them.

A side effect would be that a less tangible Component such as The Force (yes, the Star Wars kind) would never be Taken Control of before manipulating it, e.g. adding a Can Enhance Natural Physical and Mental Abilities Trait to it, because it's not actually "coming on stage" and doesn't need to be Introduced as we're used to from Characters or Props.

Also would only the current Location of the scene need to be Introduced (by the Framing Player paying a Coin to Establishing Location at the beginning of the scene). All the other Locations are never Introduced, thus Control over them is not possible. Manipulating them is therefore allowed without Taking Control.

I can see how this could be abused as well ("No, no, I'm not Introducing her into the scene, I'm just adding a Trait for 1 Coin") because it's cheaper to leave Components off-scene and manipulate them "from a distance". But I suppose such abuse should be Challenged ("c'mon man, she's there, OK?").

2) Converting a Component into a Master Component.

You're right! Paying the difference seems the most reasonable thing to do here.

For a Component with N Traits (one of which being a Proper Name): {Proper Name, Trait₂, Trait₃, ..., Trait_N} costs exactly 2 Coins less than: {Master Component, Trait₂, Trait₃, ..., Trait_N} + {Sub Component, Proper Name}. In case the Component didn't have a Proper Name yet, but simply N Traits: {Trait₁, Trait₂, ..., Trait_N} also costs exactly 2 Coins less than: {Master Component, Trait₁, Trait₂, ..., Trait_N} + {Sub Component}. And if some Traits belong specifically to this individual: {Trait₁, Trait₂, ..., Trait_N} also costs exactly 2 Coins less than: {Master Component, Trait₁, Trait₂, ..., Trait_X} + {Sub Component, Trait_X+1, Trait_X+2, ..., Trait_N}.

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.

3) Taking Control of Master Components

As discussed above (1), given your interpretation, no Control is required over Master Components as they are considered to be off-scene and therefore "free for all" to manipulate.

4) Drawing Upon Events

Yes, I suppose a Rules Gimmick would come in handy for these cases (typically all kinds of states a Component is only temporarily in because of Events being narrated). I'm thinking of something along the lines of:

When a temporary Component state is suggested as an Event's outcome but the actual Trait describing that state doesn't get paid for as well (and added to the Component), the non-existent Trait can be Drawn Upon as if it were temporarily added after all.

Example: As Jack suddenly sees (1 Coin, Event) all the Dead Bodies (1 Coin, Component) on the floor before him, he stumbles backwards in shock (1 Coin, Event) and falls to the ground (1 Coin, Event). Another player Interrupts (1 Coin) and tells that the tile Jack landed on (one he stepped over before, when walking forwards) makes a clicking sound and a heavy tree trunk swings down from the ceiling, supported by heavy ropes (2 Coins, Buying Dice), thereby Originating a Complication. The Rules Gimmick above could be applied when the Target Player controlling Jack wants to Draw Upon Jack's temporary non-existent On The Floor Trait, which makes it easier for Jack to tuck his head in. Likewise, the Source Player could very well Draw Upon Jack's temporary non-existent Shocked Trait making it harder for Jack to react at all.

On a side note: I often wonder how much of an Event "seeing" something is as things can get quite expensive if characters have their eyes open to their environments. In the example above I'd probably let Jack see the dead bodies "for free", unless it's particularly important that he sees them and the Character standing next to him not, or something like that.

[JoyWriter]

My understanding was that in the example you gave the player who introduced Jack would still control him until the end of the scene, and the player who controls Marissa would have to take control of him to add those details. Don't forget you can add a gimmick for "welcome interruptions":

So if the currently controlling player agrees, the other player can interrupt and take control for one coin, do about one action (paying normally for this) then pass it back. If anyone feels she's taking too long, then she has to give it back or revert to normal control-taking. The player who is ceding control can also decide it wasn't so welcome after all, and require them to pay all the extra stuff, though they will also have to pay to get it back.

But as for things no one has yet introduced, dunno, I suppose I'd go with you! There's always the ability to challenge anyway to stop too much nitpicking.

[folderol]

True, the Mini Interruptions & Friendly Control Rules Gimmick render my Control question quite irrelevant, since there's no need to pay Coins to Take Control anymore.

However, I really wonder what the author's point of view on these remaining (closely related) Control questions is, since I can't finish my custom player's aid because of these uncertainties and, Rules Gimmicks aside, I'd like my player's aid to remain as closely to the core rules as possible:

• Is Control without Introduction possible?
• Is Control of an Exited Component also retained until the end of the scene?
• At what point is Introduction required (being talked about/need to manipulate/being physically present)?
• Is it possible (or required) to Take Control of Components that were not introduced in the scene to manipulate them (Traits)
• Is Control over Master Components possible (or required) to manipulate them (Traits) (since you can't Introduce them)?

[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]

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]

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.

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.

, 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.