So lets say I want to create a Master Component, Soldier.
Would it work like this:
Soldier - 1 Coin
Combat Training x 2 - 2 Coins
Disciplined - 1 Coin
Uses M-16 Machine Gun - 1 Coin
Determined - 1 Coin
----------------------------
Total Cost = 6 Coins
From now on I can bring in a generic soldier for 1 Coin that has access to all the dice that the above attributes would bring? Although his Importance will only be 1, he has a potential 6 dice to bring to bear in certain situations?
OK, what if I want to create a Master Component like the above Soldier, but have it be a Squad of 3? What about a squad of 5? 10? 30?
On the other hand, if I do NOT create a Master Component for Squads, but only single Soldiers, then I have to pay 1 Coin to introduce each one, right?
How do I create a "rabble", like a bunch of townspeople? Or an "army"?
What if I want to take a soldier and give him a name, and other individualizing things?
So if the subComponent Soldier #4 gets the following traits (Named:Norm, trained in Gulf War, Marksman, Quick) what happens to the traits he got from being a subComponent? Is his Importance 5 or 11? What are the max dice he could bring to bear on a complication, 5 or 10?
Thanks.
By the way, I will be running/playing Uni for the first time at a local gaming shop tonight. Nervous and excited. Hope to hear a response about master components before the game.
Quote from: SindyrSo lets say I want to create a Master Component, Soldier.
{snip example}
From now on I can bring in a generic soldier for 1 Coin that has access to all the dice that the above attributes would bring? Although his Importance will only be 1, he has a potential 6 dice to bring to bear in certain situations?
Yes. You don't want to pay for all the Traits on every damn Orc, do ya? And you don't want to have them be the pushovers they are in other games, do ya? This allows every Orc to be as thematically interesting as the one's that Frodo meets along the way (like the ones he meets in the tower), but for them to be essentially disposable at the same time.
Yes, if one is looking to abuse the game, this is a prime way to do it. Challenge inappropiate uses ruthlessly.
QuoteOK, what if I want to create a Master Component like the above Soldier, but have it be a Squad of 3? What about a squad of 5? 10? 30?
There are a number of ways to do this. What I do is to create a "Squad" or whatever that's a member of the Master Class (sorry, slipping into OOP terms), and has a Trait like "Personnel".
When doing a "numbers" Trait like "Personnel", don't fall into the one for one trap. I'd call a Fire Team of five "Numbers". A Squad of ten Numbersx2. A platoon of forty, Numbersx3. A company of 200, Numbersx4. Etc. These things really only have to represent relative importance of the size. One could have Huge Army of Thousandsx2. These don't represent anything in the game other than the narrative importance of the particular Trait. So it's very possible that the number of men in a particular platoon is much more important than the size of the opposing army.
Sorry for the minirant; back to the regularly scheduled thread.
QuoteOn the other hand, if I do NOT create a Master Component for Squads, but only single Soldiers, then I have to pay 1 Coin to introduce each one, right?
Nope. Just create the Squad, and pay for numbers again. The only difference is that you'll have to pay for all the other Traits every time you do this.
QuoteHow do I create a "rabble", like a bunch of townspeople? Or an "army"?
Hopefull the above answers this?
QuoteWhat if I want to take a soldier and give him a name, and other individualizing things?
He's a new component. The Component that spawned him doesn't change, but is merely a narrative excuse for his appearance (he could just as easily "walk around the corner"). He may, or may not be a member of the Master Component at your discretion. A cool thing to do is to use the results of Complications of groups to produce individuals who the specific narration of the results then revolves around.
QuoteSo if the subComponent Soldier #4 gets the following traits (Named:Norm, trained in Gulf War, Marksman, Quick) what happens to the traits he got from being a subComponent? Is his Importance 5 or 11? What are the max dice he could bring to bear on a complication, 5 or 10?
He gets one Importance fro being a "Soldier" subcomponent. And four more for his other Traits. So five in this example. If you want to make him more important one way is simply to buy him from scratch with all the same Traits.
This is important. Because if you do this, then the Master Component can be eliminated, but the character remain. If he's a subcomponent, and some player wants to eliminate the Master Component, they'll have to off the individual sub-component first.
So in deciding which to use, consider how thematically linked the character is to the Master Component. If he could exist without it as a protagonist, then don't make him a Sub. If he's intrinsically linked to the Master Component, then he should be a Sub.
Mike
Quote from: Sindyr
From now on I can bring in a generic soldier for 1 Coin that has access to all the dice that the above attributes would bring? Although his Importance will only be 1, he has a potential 6 dice to bring to bear in certain situations?
Correct.
Note the following important thing, however. The number and power of the Traits you add to a master component should be consistant with the number and power of Traits added elsewhere. For instance I have been in games where the above outline for a soldier would have made this guy the most incredible combat god powerhouse in the game. Because in that game even the main characters had been given few traits beyond their name, role, and a particular special feature.
If this guy is meant to be the template for a mook/goon than 6 dice of combat nastiness should equate to a mook/goon level of effectiveness. That is the protagonist...say Rambo...should be able to call on maybe 2 dozen combat Traits. If Rambo has only 6 Combat Traits himself, than the above generic soldier template might better have only 2 Coins worth of nastiness.
This is one area I didn't make real clear in the rules. In fact, my example of the Slytheran Shock Trooper is even a nastier badass than your soldier. Written at a time when I assumed longer term play would be the norm and protagonist characters would wind up being measured in 10s of Coins just to start. Given that actual play by most people seems to generate protagonists with far fewer Traits than I'd assumed, this example Component is a little misleading.
I shouldn't be too surprised by that, actually. I created a system which intentionally allows the play group to only create and detail exactly what is necessary to move the story forward. Why did I expect them to give a horde of extraneous detail to characters? Beats me. Instead characters are generally designed in a very minimalist fashion, which works quite well. But in games where things are designed less minimalist and more "try to assign a Trait for every detail" the above soldier would probably work fine. This is why the rules suggest that adjusting the number of Coins in play is necessary based on the group.
Also note that all traits used in a Master Component should be true for all typical representatives of that "class". Is it accurate to say that all soldiers are "determined" in your game. Would there be a noticeable number of soldier who aren't? Does the game focus enough on soldiers that different personality traits like this should be left to the individual characters rather than the template? If so, than this Trait might not be appropriate at the master level.
Quote
OK, what if I want to create a Master Component like the above Soldier, but have it be a Squad of 3? What about a squad of 5? 10? 30?
Yup. There's even an example of this in the rules.
Keep in mind that the Group Trait does not necessarily correspond 1:1 fashion with actual numbers (although for some reason it does in both of the play examples I used). Group x1 can mean simply "more than 1". Group x3 can mean "alot more than one". Group x5 can mean simply "a whole bunch". If desired it is simple to propose a Rule Gimmick that equates each Group level to a specific size. For a military based campaign Groupx1 might equal "Fire Team", x2 "squad", x3 "platoon", x4 "Company" or whatever. However, such is not necessary. The trait in the rules is just an abstract measure of "the advantage of numbers".
[group]On the other hand, if I do NOT create a Master Component for Squads, but only single Soldiers, then I have to pay 1 Coin to introduce each one, right?[/quote]
you don't need a master component to make a group. You can assign a group trait to any individual component to make it represent more than 1 person "Mob of Rioters x5" for instance. If you want to introduce 3 soldiers but don't want to make a single component with a group trait, than yes, each would be introduced individually.
"How do I create a "rabble", like a bunch of townspeople?"
Role: Rabble of Townsfolk -- 1 Coin
Group Trait: Mob x3 -- 3 Coins
Armed with Torches and Pitchforks -- 1 or 2 Coins depending on how your group feels about such things.
Or whatever traits would be relavent. No Master Component is required unless Mobs of Rabble are to be a frequent reoccuring feature.
QuoteWhat if I want to take a soldier and give him a name, and other individualizing things?
So if the subComponent Soldier #4 gets the following traits (Named:Norm, trained in Guld War, Marksman, Quick) what happens to the traits he got from being a subComponent? Is his Importance 5 or 11? What are the max dice he could bring to bear on a complication, 5 or 10?
Thanks.
Think of the Master-SubComponent thing as being a Character Class. If you were using Universalis for a D&D style game you might create "Paladin" as a Master Component and add things like "Detect Evil", "Lay on Hands", and "Special Warhorse" as Traits of what it means to be a Palidan. In this example you've done something similiar for "Soldier".
So now you create Norm.
you have:
Name: Norm --- 1 Coin
Role/Subcomponent: Soldier --- 1 Coin
Trained in Guildwar --- 1 Coin
Marksman --- 1 Coin
Quick --- 1 Coin
Importance = 5. He still has access to all of the Traits of Being a Soldier, because he is still a subcomponent of that Master.
You could also do a Master Component for veterans of the Guildwar: "Mistrust of Corporate Bureaucracy", "Stealth Insertion Training", "Implanted with Core Tech tracking chip"...etc.
In this way you could use Master Components as "Profession Packages"
"Sniping School" becomes a Master Component with all of the Traits typical for a trained Sniper. Etc.
Ordinarily you'd just treat "Sniper" as a role and assume it incorporates everything that a player can justify as being something a sniper would know and that isn't questionable enough for another player to Challenge him on. But the game is really designed to let you get as detailed and crunchy as you want...explicitly listing out an explicit skill package for Snipers as a Master Component.
Just keep in mind that such things needs to be done consistantly to keep the relative importance of all characters and other Components in the story in parity. If you give someone Demoskill x3 and Plastic Explosive x2 as traits you'd also better define that "Reinforced Concrete bunker" with more traits or else it will go down like paper mache in a Complication to blow it up. The level of detail you want to bring to the game is a good thing to decide upon during the prep phase...as well as the number of Coins to give out. This level of detail will require more Coins than minimalist play.
Can I create SubComponents to SubComponents?
For example, Can I create an Army Master Component, which has a subcomponent of Squad, which in turn is the Master Component to the subcomponent Soldier?
Also, if I already have "Soldier" defined as a Master Component, and I want to bring a squad of three Soldiers into the story, which of the following will NOT work?
1) Pay 3 Coins for 3 Soldiers. Cost = 3 Coins.
2) Create A Master Component "Squad" that "contains" 3 Master Components "Soldiers". Cost = 4 Coins? (Squad + Soldier * 3?)
3) Create a Whole new and seperate Master Component "Squad"
Squad - 1 Coin
Numbers (3 people) - 1 Coin
Combat Training x 2 - 2 Coins
Disciplined - 1 Coin
Uses M-16 Machine Gun - 1 Coin
Determined - 1 Coin
Cost = 7 Coins?
Of the above choices, given that the Master Component "Soldier" exists as outlined above, it seems that choice #3 is a waste of coins.
#2 would be good, but I don't know if it is legal.
#1 would work, but seems inelegant - and what if I want a squad of 10?
I think I like #2 the best - is it "legal" without a rules gimmick or addon?
Quote from: SindyrCan I create SubComponents to SubComponents?
For example, Can I create an Army Master Component, which has a subcomponent of Squad, which in turn is the Master Component to the subcomponent Soldier?
Yes...but.
This sort of thing works well. IF (BIG if) it is consistantly and reasonably applied. It can have ripple effects and repurcussions throughout the game, because you are adding a great deal of leverage to the game. This will change the nature of buying Traits dramatically. Certain Coins will buy ALOT of power apiece (those that purchase into a cascading Master Component series), while others buy comparitively little (buying an individual Trait directly).
Master Components work well (and have been thoroughly tested) as a great way to generate cheap disposable mooks who are tough, but go down easy.
Master Components work well as a template system for bringing "Class" and "Race" concepts to the Game. The "Elf" component grants "Infravision 60 feet" and "Long Sword" and "Bow" Traits for instance. Also well tested.
There is no reason why what you are attempting to do wouldn't also work very well...but it is inherently more dangerous. If you are going to try this (and frankly I'd love to see it)...I'd recommend starting with a straight up "world building" session where there are no characters or actual play going on. Rather set up all of the Master Component classes and such that you intend to have in advance where they can be thought out individually without worrying if this is someone's sneaky way of getting an edge in a Complication. I wouldn't try to create nested Master Components on the fly in game. CERTAINLY not in a first game.
In fact, I'd recommend you keep your first game pretty devoid of these details until you've seen the engine in action. Then you'll be better able to judge what does and doesn't work for you.
Quote
Also, if I already have "Soldier" defined as a Master Component, and I want to bring a squad of three Soldiers into the story, which of the following will NOT work?
Again. Master Components and Groups are entirely seperate concepts you do NOT need a master component to make a group. In my mind the best way to do this is not even on your list.
Role/SubComponent: Soldier -- 1 Coin
Group: Squad of 3 -- 1 Coin.
(note How many Coins "Squad of 3" should be in your game depends entirely on the scale you want the trait to represent. )
Alternatively you could make "Squad of 3" a trait of the Master Component, but then ALL Components linked to that Master MUST be squad's of three. And the squad itself will have an Importance of only 1 instead of 2 as it does above.
Quote1) Pay 3 Coins for 3 Soldiers. Cost = 3 Coins.
sure
Quote2) Create A Master Component "Squad" that "contains" 3 Master Components "Soldiers". Cost = 4 Coins? (Squad + Soldier * 3?)
No. Heres why. Soldier + Solder + Soldier = Soldier x3...which is a measure of how "skillful" or effective a Soldier is...Soldier x3 means this guy is a significantly better soldier than the guy with Soldier x1. It does not mean there are 3 of him.
Quote
3) Create a Whole new and seperate Master Component "Squad"
Squad - 1 Coin
Numbers (3 people) - 1 Coin
Combat Training x 2 - 2 Coins
Disciplined - 1 Coin
Uses M-16 Machine Gun - 1 Coin
Determined - 1 Coin
Cost = 7 Coins?
Legal. But in my mind the better choice is as I described above. Just leave the master as Soldier without the numbers trait and add the numbers trait to the sub.
Quote2) Create A Master Component "Squad" that "contains" 3 Master Components "Soldiers". Cost = 4 Coins? (Squad + Soldier * 3?)
I think I phrased this in a confusing way, I meant:
2) Create A Master Component "Squad" that "contains" 3 Master Components "Soldiers". Cost = 4 Coins?
Squad = 1 Coin
Contains Soldier #1 - 1 Coin
Contains Soldier #2 - 1 Coin
Contains Soldier #3 - 1 Coin
Total = 4 Coins
Does this change the responses?
PS. (Added by edit upon re-evaluation)
Importance of an instance of this Squad? Max Dice?
Maybe Importance = 4.
Maybe Max Dice = 6 per soldier, or 18?
OK, I guess that would get crazy fast - one would be rolling hundreds of dice for an army.
Maybe I should have said:
2) Create A Master Component "Squad" that "contains" 3 Master Components "Soldiers". Cost = 2 Coins?
Soldier = 1 Coin
Squad (3 units) = 1 Coin
Total = 2 Coins
Importance = 2 Coins, Max dice = 6 (from Soldier) + 1 (from Squad) = 7?
Is this way of doing the same as using a Group?
QuoteAgain. Master Components and Groups are entirely seperate concepts you do NOT need a master component to make a group. In my mind the best way to do this is not even on your list.
[Squad]
Role/SubComponent: Soldier -- 1 Coin
Group: Squad of 3 -- 1 Coin.
If the Squad were diefined as above, what is it's Importance and max dice? Importance = 2 and Max Dice = 7? (6 dice from Soldier Master Component and one from "Group"?
Yes, as Master Components and Subcomponents are Components, they are all subject to being Masters or Subs themselves. But this is very tricky, and ought to only be used in rare cases. Such cases usually only include games that you intend to have run for a long time. In fact, for a single session game, I recommend not doing any Master Components at all. The chances of them being used more than once is slim (in which case, the extra recordkeeping and complesity are useless). If you can't see the Component being used three times, don't do a Master. Which means that if you can't see a Master Master, and each "Sub-Master" being used three times each, separately (for a minimum of six uses, and probably more), then don't even think about it.
But you can't do the particular example you're trying. Because your subcomponent, Squad, doesn't have individuals as subcomponents. The last subcomponent in a chain has members that are "individual X" where X is the Master just above it. Thus you could have.
Soldier Master Component
Basic Training
Weapons
Squad (Subcomponent of Soldier, Master of individual Squads)
Member of Soldier Master Component
Numbersx2
Esprit de Corps
So what you'd create with your one Coin would be:
Squad (Member of the Squad Master Component [and hence member of the Soldier Master Component])
Basic Training
Weapons
Numbersx2
Esprit de Corps
All for one Coin.
Or you can just create an individual Soldier right from the Soldier Master Component. But he won't then have the Numbers or the Esprit de Corps.
See how that all hangs together? As Ralph points out, be careful to put only those traits that are intrinsic to the Component at that level in. For example, you could put Esprit de Corps in the Soldier Master, but that would indicate that the individuals of this army would feel that sense of Elan, even if they weren't with any of their compatriots. Would make sense for some armies, and not for others.
Mike
Quote from: RalphHeres why *I* wouldn't recommend trying this.
Same caveat goes, BTW, for nested Complications. In fact those are so potentially problematic that we didn't even put them in the main rules. But with a simple Gimmick, you can eliminate the restriction on starting Complications while others are going on, and then put in a rule for resolving them from the "inside out".
These are fun when used right, but extremely dangerous if allowed to run amok. Basically there are lots of ways to extend the use of the basic rules that are potentially empowering. But they can also lead to some terrible play, potentially (you find with nested Complications that it often requires a Challenge to get the nesting to stop). As such, only extend the rules with extreme care.
Basically the potential problem is that, with these extensions, the ramifications of the results can be hard to see from the outset. So, start small until you get some experience with the rules, and then use them more later.
When in doubt, remember that you can get everything that you want to do done with the basic rules, and that sometimes it's better for everything to just go that way.
Mike
Edit to note: How in the hell did Mike manage to post as Me. don't know. But this was Mike's post...very odd.
Quote from: SindyrIf the Squad were diefined as above, what is it's Importance and max dice? Importance = 2 and Max Dice = 7? (6 dice from Soldier Master Component and one from "Group"?
Yes.
As opposed to writing up the squad as having the six Traits on it's own, and the Group Trait. Which would be Importance = 7, Max Dice = 7.
I'm a bit uncomfortable with this whole "max dice" idea. It smacks of the notion that every Trait should be activated for every Complication that the Component becomes engaged in. In a cake-baking Complication, the squad would have "Max Dice" in my book of zero (one if named). But, yes, theoretically the squad can produce seven dice in a Complication.
Mike
And more...
If Company is defined as 12 Soldiers, then as I understand it so far, there are at least two ways to do it:
A)
Create Component: Company.
Soldier Component - 1 Coin
Group - Numbers x 2 - 2 Coins
Total Cost = 3 Coins
So, each time you introduce a Company, it costs 3 Coins.
If instead, you create it *this* way:
B)
Create Master Component: Company.
Soldier Component - 1 Coin
Group - Numbers x 2 - 2 Coins
Total Cost = 3 Coins
It makes you spend 4 coins to introduce the first Company (3 for the MC and 1 for the instance) but only 1 Coin for every subsequent company. This could be a savings if you will be introducing many companies.
Example A's way would have an Importance of 3 (I believe) and a Max Dice of 8 per squad.
Example B's way would have an Importance of 1 and a Max Dice of 8 per squad.
Does this sound right?
Mike Holmes wrote:
QuoteYes, as Master Components and Subcomponents are Components, they are all subject to being Masters or Subs themselves. But this is very tricky, and ought to only be used in rare cases. Such cases usually only include games that you intend to have run for a long time.
I think eventually most of my games will be multisession - maybe one long story over many months, even years.
QuoteBut you can't do the particular example you're trying. Because your subcomponent, Squad, doesn't have individuals as subcomponents. The last subcomponent in a chain has members that are "individual X" where X is the Master just above it. Thus you could have.
Soldier Master Component
Basic Training
Weapons
Squad (Subcomponent of Soldier, Master of individual Squads)
Member of Soldier Master Component
Numbersx2
Esprit de Corps
How can a "Squad" be a subcomponent of "Soldier"? Shoudn't it be the other way around? First create "Soldier", and then define "Squad" as a collection of "Soldiers"?
Also, sorry if this gets confusing, guys. Cross posting can be difficult. :)
Valamir said:
QuoteThere aren't many standard guidelines for how you want to word Traits. If this makes sense to you great. But you are falling into what Mike above referred to as the 1:1 trap.
See what you have above is essentially the same as
Master Component: Squad --- 1 Coin
Subcomponent: Soldier --- 1 Coin (to give the squad access to the soldier traits).
Numbers: 3 soldiersx2 --- 2 Coins.
Key difference...you cannot use "Contains Soldiers" three times in order to draw upon the same set of Soldier Traits three times in the same component. Or perhaps more accurately I should say "should not" since that will get crazy fast.
Yeah, I just realized that. The Trait "Numbers" is our friend :) Nice for logarithmic math too.
I only bring up Max Dice for 2 reasons:
1) A way to check that I am correct about the number and relationship of the traits of the subComponents.
2) For components designed with a single purpose, ie, Squads and Combat, it is reasonable to expect that most or all of their Traits will be utilized when employed in their area of function.
Quote from: SindyrI think eventually most of my games will be multisession - maybe one long story over many months, even years.
Excellent.
But then you'll have plenty of time to get into it slowly. Wait until you have some sense of where things seem to be going before putting a lot of effort into some Master Component scheme that might end up not getting used a lot.
Quote
How can a "Squad" be a subcomponent of "Soldier"? Shoudn't it be the other way around? First create "Soldier", and then define "Squad" as a collection od "Soldiers"?
You're thinking heirarchically. If you can't break out of that mindset, don't use Master and Subcomponents beyond one level. A subcomponent simply inherets Traits from it's master. There is no other logical linkage. If you can create ones that have a more intuitive linkage, great. But there's no "must" other than it must make sense for the Subcomponents to always inherit from the Master.
For example. If I give Squad a "numbers" Trait, how would a Soldier Subcomponent inherit that? You'd have to make individual soliders who were, therefore somehow multiplicitous when they inherited the numbers Trait.
Basically there's nothing that you can say about the Squad that pertains to every soldier. But there are things that you can say about the soldier that pertain to every squad made of such soldiers. Not all Soldiers are in Squads (if they were, then we could skip the Soldier Master), but all Squads are composed of Soldiers.
See how one ought to stay away from this until it's sunk in deep as to how it works? I'm a programmer who works with OOP languages all the time, and it's still difficult for me to make these things work right sometimes.
Interestingly, a Component can inherit from more than one Master. Thus, one can have an individual character who's a Dwarf Subcomponent and also a Fighter Subcomponent. Or he can be a Dwarven Warrior Subcomponent which is in turn a subcomponent of Dwarf. See how much fun this is? :-)
(Moral: always consider whether a Master is really universal before assuming that it belongs under another Master)
Mike
P.S. yes this has been a massive cross-post-o-rama. But it's producing interesting things.
QuoteExample A's way would have an Importance of 3 (I believe) and a Max Dice of 8 per squad.
Example B's way would have an Importance of 1 and a Max Dice of 8 per squad.
Does this sound right?
That's exactly right...except you forgot the Coin for the Component itself. The "Create Component: Company", is defining the role of the Component and thus costs 1 Coin. This would make the total cost 4 Coins for each, Example A would have an Importance of 4, and Max Dice would be 9 (assuming every die applies).
But you can see how with 1 Coin:
Create Component: EZ Company --- 1 Coin
you get 9 Dice worth of traits.
That's ALOT of leverage and needs to be used with caution. The stacking effect gives you a great deal of added efficiency. If you'd simply made a single Master for the Company with all of the Soldier Traits included you have the exact same effect, but less efficiently. By stacking you have the ability to carve out the Soldier piece and recycle it into "Battalions", "Military Police", "Combat Engineers", or any other Master whose members went through Basic Training. Thus you can multiply those initial Soldier Coins over and over. Doesn't break the game...but you need to REALLY be aware of how this will effect Coin spending before you try it.
BTW: I LOVE to hear that you want to play an extended campaign. I think the game is well suited for it -- especially a cycle of stories involving different characters like the Greek Myths, or a episodic series with shifting characters and locales like Band of Brothers. But I would recommend getting a game or two under your belt before jumping in the deep end.
Quote from: Sindyr2) For components designed with a single purpose, ie, Squads and Combat, it is reasonable to expect that most or all of their Traits will be utilized when employed in their area of function.
This is only true if they are brought in as a source of Complication, but yes, then it's true. But only for the first Complication. You seem to assume that the only result of Complications will be the elimination of one of the Components. While this is more thematically likely in combat, even there it's only one option.
If I won a complication against a Squad, I'd have them surrender, and keep them around for more fun stuff (for one thing, I don't have to pay the Importance off). For example using their Traits for figuring out other enemy positions and such Complications. In any case, there will subsequently be potentially many Complications with the Component that involve it's Traits only peripherially. And eventually I'll buy off the Importance by handing them over to the MPs getting them out of my hair forever (death is only one of many options).
But not before I've milked them some in story terms. Is it more "profitable" to use them in repeated escape attempts in which all their traits can be used again and again? Yes. Is it any fun? No. I'd Challenge after the first one, unless the escape was well desinged narratively (perhaps as the result of some other combat Complication).
Call this the "Orc Ambush" phenomenon. Yes, it's cheap and efficient to throw Orc Ambush after Orc Ambush at a group of protagonists. Does it make for a good story? No, not even in D&D is it considered good play. Once again we see how important it is for the participants to be thinking in terms of making a good story, and not about simply building huge piles of Coins.
Sorry to harp on that, but I worry. :-)
You don't have to treat each Component in such a detailed fashion. But if it was worth introducing in the first place, then it may be worth looking at in more detail. Simply consider the idea that the character that, at first, looks like a "red shirt" might in fact be something more interesting.
Mike
OK, I think I have got exactly where I became confused.
Master Components are Classes. They are NOT Instances (usually).
SubComponents (that are not themselves also Master Components) are Instances of Master Components.
Groups *ARE NOT* Classes, but collections of Components that are ALSO not Classes.
Perhaps it would be less confusing NOT to call them "Master Components", but instead, call them "Classes".
Note that the initial confusion was my fault and my fault alone.
SO, *now* I understand. For one Class to exist within another, it must include all the attributes of it's daughter Classes, and more.
For example, one Class might be Elves. All the shared Traits among elves gets added to the Class Elves.
Another Class could be Grey Elves. This Class would inherit all the traits of the Class Elves, being a Class *Instance* of Elves, and thereby by a subComponent of the Class(Master Component) Elves.
Let me double check - A subComponent must get ALL the Traits of its Master (unless specifically noted), but may add additional traits beyond.
In this example:
Class:Immortal - 1 Coin
High Magic Resistance - 1 Coin
Ageless - 1 Coin
Unaffected by Disease - 1 Coin
No Bodily Needs (sleep, food, air, heat) - 1 Coin
Unaffected by non-Combat or non-Magickal Damage (poisons, etc) - 1 Coin
Class Cost = 6 Coins
Importance = 6
Traits of Instantiated Member = 6
Class:Elves (Master Component) - 1 Coin
Instance of Class of Immortals - 1 Coin
Pointy Ears - 1 Coin
Tall - 1 Coin
Haughty - 1 Coin
Class Cost = 5 Coins
Importance = 5
Traits of Instantiated Member = 6 + 5 = 11
Class:Grey Elves (Master Component) - 1 Coin
Instance of Class of Elves - 1 Coin
Silver Eyes - 1 Coin
Dominant Elf sub Race - 1 Coin
Magical in Nature - 1 Coin
Resistant to Death x 3 - 3 Coins
Class Cost = 8
Importance = 8
Traits of Instantiated Member = 11 + 8 = 19
Component:Fred - 1 Coin
Instance of Class of Grey Elves - 1 Coin
Swordmaster x 2 - 2 Coins
Spellmaster x 2 - 2 Coins
Estranged from own people - 1 Coin
Component Cost = 7
Importance = 7
Traits of Instantiated Member = 19 + 7 = 26
Have I done this right? Now, if I want to create a City of Grey Elves, I could make a Group Component:
Group Component:
Named - Aerlinthe - 1 Coin
City - 1 Coin
Contains Mostly Grey Elves - 1 Coin
Numbers x 5 (1000ish) - 5 Coins
Located in the Northern Reaches of the Country of Arcadia - 1 Coin
Group Cost: 9 Coins
Now, if Fred moves to Aerlinthe, I can give him the Trait:
Member of Group of Aerlinthe - 1 Coin
right?
However, Aerlinthe is a Group, not a Class because it's members do NOT inherit the Traits of Aerlinthe - ie, they are not ALL Grey Elves (tho most are), they are not ALWAYS in Arcadia, etc...
However, Fred IS an member of the *Group* Aerlinthe.
So this is good.
Master Component = Class
Sub Component = Instance
An Instance can itself be a Class, and vice versa. An Instance inherits all the Traits of the Class(es) it is an Instance of, unless otherwise stated.
Collection of Components = Group
A Component in a Collection = Member
A Group may be a Member of a larger Group, and a Member may be a Group of narrowed Members. IE, An Army Group may have Battalions as Members, Battalion Groups may have Companies as Members, Company Groups may have Squads as Members, and Squad Groups may have Soldiers as Members.
To make things even more confusing, Soldier can be a Class, and the Group "Squad" may contain members which are Instances of the Class Soldier.
While a little complex, I think I "get" all this now.
Unless the above is wrong. Let me know.
Yup, I think you get it. The elf example is exactly right and basically what I would do if I was going to create a nested hierarchy representing the elves in my campaign world. In fact this type of thing is exactly what I was envisioning while I designed the game. Mike and I even spent some time talking about "genre books" as supplements where exactly what you have here would be defined in advance in the supplement suitable for immediate insertion into any D&D/tolkien-esque fantasy supplement.
In actual play, I've found games to be much more minimalist. The features you've noted about grey elves being the most abundant type of elf and so forth would get noted as color but not normally defined out. In most single session pick up games NOTHING gets defined that isn't of immediate importance to the specific activities going on in the scene at hand. This is why I think alot of people come to the conclusion that Universalis isn't suited for campaign play.
But the ability to do exactly what you just did with the elfs is built into the rules intentionally EXACTLY for the purpose of supporting a longer term campaign and designing a whole world. I suspect (and encourage) that world to get developed as you go in much the same way as the world got developed piece by piece with each new installment of Conan. If you actually wind up playing a game where you take the time to define the elements of your world like this I'll be ecstatic because to my knowledge, no one has glommed onto this possibility even though it was one of the important design considerations as we wrote it.
I will note just in case that the breakdown of groups and members that you have in the second part of the post is quite accurate from what I can tell, but is not a specific feature of the game rules. One could give Fred the trait of "Citizen of Aerlinthe" without needing there to be a Component for Aerlinthe at all. And if there is such a component, there is not necessarily any specific linkage between Fred and that component from a mechanics perspective (unless one wants to get creative with the Possession Traits which might be the next section you want to study).
That said, Citizen of Aerlinthe *could* be defined as a Master Component / Class if you wanted it to be (although with the Traits defined differently). What you consider a Class and what you consider a group (by your useage) depends entirely on your willingness to accept and promote stereotypes...which is what Class systems basically do. For instance, if you defined "American Tourist" as a Master Component, what traits would be appropriate underneath it (to be inherited by all members except those who pay a Coin to be exempted) would depend entirely on how broadly your group is willing to portray the stereotype of an American Tourist.
As a side note: The rules use "Group Trait" to mean a trait which portrays the numbers present in a group. For example in the previous examples, "3 Soldiers x2" is what the rules call a "Group Trait". I mention this to distinguish what you are referring to as a Group above from this.
I could have called Master Components, "Classes" and I believe that from the world of logic and mathematics that would be a very appropriate term. However, the word "Class" has taken a very specific meaning in roleplaying and I wanted to avoid that association. Calling them Classes might have players thinking only in terms of "Fighters" and "Rogues" and "Jedi Knights" and such, when in reality Master Components are much more general.
I'm sure with a little thought you could come up with a way to categorize Armored Vehicles, or Air Craft, or religious affiliations, or political parties, or social castes, etc using Master Components (again within the guidelines of how willing to stereotype your group is.).
By George I think he's got it.
Didn't know you programmed, or I'da gone right to the program-speak right off. We decided not to get to much into the programming language in the text, as it would just confiuse some people. But all your linkages are exactly right.
BTW, if you want to extend programming to groups, think of Traits as Properties. As such, numbers are simply another Property of the Component (Class Instance or no). A Group of 1000 soldiers is simply, for mechanical purposes, one Instance of the Soldier Class with an extra Trait associated with it.
Now, if you have several actual Instances of something, then you could think of that as an array of Components or Instances of a Class. Thus you could create Soldier(1), Soldier(2), etc. Even better is to think of them as Records. Very much the "individual" level Component is a Record in the old (Pascal) programming sense. They have only Properties associated with them, and no methods or events.
Mike
The thing that's hillarious is that at work right now I am dealing with Classes, Arrays, and Records as I am designing a VB interface and Access Database combo for my company. ;)
Quote from: SindyrThe thing that's hillarious is that at work right now I am dealing with Classes, Arrays, and Records as I am designing a VB interface and Access Database combo for my company. ;)
I am, between typing to you, working on using Access to make reports off of an Oracle DB using ODBC. Small world. :-)
Mike