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.

Sindyr wrote: So 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?

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?

Sindyr wrote:
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?

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

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?

Sindyr wrote: 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?

2) Create A Master Component "Squad" that "contains" 3 Master Components "Soldiers". Cost = 4 Coins? (Squad + Soldier * 3?)

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.

[Squad]
Role/SubComponent: Soldier -- 1 Coin
Group: Squad of 3 -- 1 Coin.

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

Ralph wrote: Heres why *I* wouldn't recommend trying this.

Sindyr wrote: 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"?

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:

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.

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

Valamir said:

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

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.

Sindyr wrote: I think eventually most of my games will be multisession - maybe one long story over many months, even years.

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"?

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?

Sindyr wrote: 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.

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

Sindyr wrote: 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. ;)