Theoretical Battlestar Galactica Play Example

[Zamiel]

One of the things I do when I'm trying to get a handle on how a game is played is work up a session / scene, with mechanical notation and embedded references.

It's like playing with yourself without the hairy palms you might get from other systems.

To that end, I've put together such a construct based on an initial Battlestar Galactica setting at http://zamiel.livejournal.com/1071114.html. Of course, in doing so I managed to find a couple questions unresolved in my understanding. That's why you do these things, no?

• When you have a Master/Sub Component, the text speaks of the state of being a Master or Sub Component being a Trait. But it suggests in the examples though not explicitly that such a Trait doesn't count for calculating Importance. Yex/no?
• Is there any real difference, mechanically, between a Component with only a Role, and a Component with a Role and one Trait? The canoniacal Horse gives one die to Complications where a horse might be useful. A canoniacal Horse with the sole Trait "Strong" ... would let you add one die to a Complication where a horse's strength would be useful.
  
  It would appear that adding a Trait makes a Component less useful by limiting its applicability. Unless Role is considered a Trait entire, which makes sense in it's way but means all my Importance costs in my example are 1 too low ... and all the examples I could find in the text as well.

Just a couple things that came up in the course of construction.

[Valamir]

Love these sorts of questions.

I'm somewhat confused by your indication that the examples don't add up.  I spent some considerable time making sure the math all worked.  I don't have a book in front of me, but if you want to shoot me the pages you're looking at I'll check them out.  They should all add up.


A Role is a Trait.  It is a Trait exactly the same as any other.  The reason why its highlighted with a special name in the text is to make sure that every Component ties into the story in some way so that its purpose is known. 

For example:  if you had a Component whose only Trait was "Strong"...that's not a real Role (for most stories, anyway).  That tells me nothing about what that component is, what it does, what its purpose in the story is...it doesn't even tell me whether "Strong" refers to an ability to lift heavy objects, avoid being damaged, or how badly it smells.

"Horse" on the other hand, is a suitable Role (for most stories, anyway).  The component is a horse, its purpose is to do things that horses do.

If you have a "Horse" who also has "Strong", then you have a Component with two Traits and hense an Importance of 2.

If you have a Complication where the horse is pulling a heavy wagon (I'll leave it to the reader to determine a set of circumstances where that would make for an interesting conflict), then you could call on 2 dice.  "Does being a horse help pull a wagon?" sure, that's what horses do*.  "Does being particularly strong make pulling the wagon easier for the horse?" sure, vs. being a weak horse absolutely...hense both dice could be Drawn on for the Complication.


As for Sub Components, yes the Trait that ties the Component to the Master Component is a full on Trait.  But it doesn't necessarily have to be a seperate and distinct full on Trait.  For example, say you have a Master Component defining a "Horse" with a number of Traits that all horses have in your game.  You then have a Component with a single Trait "Horse".  That Trait is both the role of the Component (as noted above) AND designates the Component as a sub component of the Master Component for "Horse".

It doesn't have to be the Role Trait.  You might have a Master Component defining "Elfs" for a D&D type game (with traits like "night vision" and "good with bows" and the like).  You might have a Component with the Role Trait of "Leader of the Black Circle Gang" the Name Trait of "Elios" and a whole bunch of other Traits defining who he is, who he knows, what type of gear he carries.  One of the Traits happens to be "Elf".  That ties the Component into the Master Component.  Its still a regular Trait, it still increases Importance by 1, and it still can be drawn on to provide dice where "being an elf" would apply.  It also gives access to drawing upon "night vision", and "good with bows". 

So if Elios was dealing with a local lord who has as a Trait "Passionate Hatred of Elfs", and they were in a Complication, the player of the lord would be justified in Drawing on Elios's "Elf" Trait as a bonus for the lord (or penalty for Elios).


The overarching concept is:  if you spent a Coin on it you can write it down as a Fact.  If its a fact about the game structure as a whoe its a "tenet" and can get written down on the Tenet list.  If its a fact about the things that happened in a scene its an "event" and can get written down on the scene summary (if keeping one, this isn't essential).  If its a fact about a Component its a "trait" and can get written down on the Component summary.

Because they're all "Facts" theres alot of room for overlap.  For instance if a player narrates the character "Jack" killing "Bob" (and spends the appropriate Coins to do so) the fact "Jack killed Bob" could be treated as an event that happened in the scene.  Or, it would be entirely appropriate to put "Killed Bob" as a Trait for Jack (with the automatic matching Trait of "Killed by Jack" for Bob. 

Which is the right way?  Totally depends on the group, the type of story you're telling, and the significance of the event.  If you treat it as a Trait, you're increasing Jack's Importance and providing another die to draw on. 


Helpful?

[Zamiel]

Helpful?

Much, though a few bits are still hazy.

I'm going to switch into OOP programmer-mode here because all geeks speak OOP and we're all geeks here, no?

Every Component is anonymous at the time of instantiation. Any Trait / Property / Method (to be completist) defined on that anonymous Component increases it's Importance. Giving a Component a Role is just creating a Role: Property and increases a Container's Importance. Naming a Component is just adding a Name: property with a value, and increases the Importance.

Important insight: Creating an empty Component is actually free. It's just useless, a container, until a Role: is set on it ... and the cost for doing so is 1 Coin. Creating a Master Component costs at least 2 Coins, one for its Role, one for the "Master Component" Trait (which is not inherited). In practice, a Master Component'll cost 3 Coins, minimum, because creating one with no heritable Traits is silly.

A Sub-Component has the Component created for free and 1 Coin spent to give it the Role "Whatever" ... and if I'm reading you correctly, if "Whatever" is an existing Master Component, then the new Component is considered to be a Sub-Component of the Master, with no further expenditure, an Importance of 1, and no Traits save those inherited from it's Master.

Which implies that creating a Sub-Component doesn't differ from any other Component, save it's Role has an existing Master defined with a Role that matches a Trait on the Sub-Component.

So ... yeah. Assuming that all of the above is a true assessment, then I'm dead certain I undershot my pools in the example I wrote up by one die for every Component involved in the Complication, because I didn't use their Roles ("Colonial Viper," "Cylon Raider," "Asteroid Field") to Call Upon.

I can't find the example I was thinking of at the moment, unfortunately, that threw me off, but I did have another issue that I'm pretty sure I hosed up.

I'm pretty sure I hosed up the entire Complication pool-setting process, going into a Capes-esque mode where you activate Traits as you go with narration. But that's not exactly how it works in any of the examples in the book. Instead, I should have had players just picking up dice for Traits they thought would be relevant to the Complication without any narrational justification at all at the table, roll, resolve, and then use the Bonus Coins so gained to do the narration, burning them for Facts and to manipulate Traits. Which, I admit, would be roughly twice as fast as what I actually wrote up ... but I think it's even more needing of some kind of up-front stake setting so that folks can decide what Traits would be useful.

But that's another thread, so I'll go wander over that way now. :)

[Valamir]

I'm going to switch into OOP programmer-mode here because all geeks speak OOP and we're all geeks here, no?

As a matter of fact, It was designed around OOP concepts

Every Component is anonymous at the time of instantiation. Any Trait / Property / Method (to be completist) defined on that anonymous Component increases it's Importance. Giving a Component a Role is just creating a Role: Property and increases a Container's Importance. Naming a Component is just adding a Name: property with a value, and increases the Importance.

Yup.  With the note that any property can have a value attached as well.

Important insight: Creating an empty Component is actually free. It's just useless, a container, until a Role: is set on it ... and the cost for doing so is 1 Coin.

YUP!  in the rules, this is called Color.

Creating a Master Component costs at least 2 Coins, one for its Role, one for the "Master Component" Trait (which is not inherited). In practice, a Master Component'll cost 3 Coins, minimum, because creating one with no heritable Traits is silly.

Yup

A Sub-Component has the Component created for free and 1 Coin spent to give it the Role "Whatever" ... and if I'm reading you correctly, if "Whatever" is an existing Master Component, then the new Component is considered to be a Sub-Component of the Master, with no further expenditure, an Importance of 1, and no Traits save those inherited from it's Master.

Yup.  And if it helps, ALL Components are sub-components...its just the Corresponding Master Components are empty...i.e. undefined.

Which implies that creating a Sub-Component doesn't differ from any other Component, save it's Role has an existing Master defined with a Role that matches a Trait on the Sub-Component.

Yup, with the addendum that it doesn't technically have to be its Role that has an existing Master...and that any sub can inherit from several Masters.

So ... yeah. Assuming that all of the above is a true assessment, then I'm dead certain I undershot my pools in the example I wrote up by one die for every Component involved in the Complication, because I didn't use their Roles ("Colonial Viper," "Cylon Raider," "Asteroid Field") to Call Upon.

I can't find the example I was thinking of at the moment, unfortunately, that threw me off, but I did have another issue that I'm pretty sure I hosed up.

  Yup, not seeing any hazy bits.

I'm pretty sure I hosed up the entire Complication pool-setting process, going into a Capes-esque mode where you activate Traits as you go with narration. But that's not exactly how it works in any of the examples in the book. Instead, I should have had players just picking up dice for Traits they thought would be relevant to the Complication without any narrational justification at all at the table, roll, resolve, and then use the Bonus Coins so gained to do the narration, burning them for Facts and to manipulate Traits. Which, I admit, would be roughly twice as fast as what I actually wrote up ... but I think it's even more needing of some kind of up-front stake setting so that folks can decide what Traits would be useful.

Almost, but you do still have to justify the Traits when you Draw on them.  Whether you do that with lots of narration or very little is a matter of preference.

But that's another thread, so I'll go wander over that way now. :)