Questions abour Master Components...

[Mike Holmes]

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

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.

[Valamir]

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?

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.

[Mike Holmes]

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.

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

[Sindyr]

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.

[Valamir]

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

[Mike Holmes]

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

[Sindyr]

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. ;)

[Mike Holmes]

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. ;)

I am, between typing to you, working on using Access to make reports off of an Oracle DB using ODBC. Small world. :-)

Mike