#20: Hobgoblins, Part Two -- Inheritance

[ShannonA]

What in the world is this?

http://www.skotos.net/articles/artwork/TTnT20_2d.gif

Go read TT&T #20 at http://www.skotos.net/articles/ and learn more than you ever wanted to know about how objects inherit attributes in Castle Marrach.

Then come back here and offer comments.

Shannon

[JeffC]

Are you interested in TT&T articles like this one which discuss how we do things technically in Castle Marrach?


Very. But you probably suspected that.

I'm a little confused by your example of the teapot. Why would you inherit brass, etc.? Unless you wanted at some point to affect all brass objects, or to make all brass objects react the same way to certain verbs. Is this it?

[Atama]

Let's say you have a variety of materials, say, copper, brass, silver, iron, steel. And let's say you have an axe, which can cut anything brass or softer. Then having an inherited type of material would be good. Or, say you have a brass kettle and an iron one... You could say the brass kettle warms up faster. I see alot of benefits for this.

[ShannonA]

Atama's got it pretty dead on.

From the "top" you inherit the shape of an object, which can define *all* of an object's characteristics.

From the "side" you inherit specific attributes which many modify *some* characteristics.

In the simplest example, we have a shirt. Right now, every time we want to create a different color shirt we have to create a different parent object: UrRedShirt, UrBlueShirt, UrGoldShirt, etc.

We can't have all of those shirts descend from a single shirt because of our restriction of data inheritance to one level.

But, by having property-based inheritance we can get over this hurdle. We just have a generic UrShirt which specifies no color, and then we inherit color as a property. Poof! A gazillion Ur objects are condensed to one object and one property.

The simple method of doing this is pretty close to being implemented in our system: We'll be able to inherit a simple property (like "red") that changes descriptions and allowable adjectives.

The more complex method is further off but still on our radar screens. Then we'll be able to do that brass pot that heats up differently, or that worn hat that is further down the decay scale ... or that red shirt which makes you more likely to get shot in a science-fiction show.

Shannon

[JeffC]

Sorry, I can't see the point of red as a property unless you really do want to do things like make red an easier color to see in certain environments, or easier to hit, or whatever. The only reason I can see to inherit properties is, as you said, for consistency of reactions. You want that axe to cleave every brass object, and you don't want each designer to determine his own idea of the hardness of brass.

However, on the opposite side, if you do this, you determine the hardness and other qualities of all brass objects. In other words, there is no variation. A brass pot made by an apprentice heats just as evenly and last just as long as one made by a master. Which means that the only reason to take a skill would be to improve your chances to succeed, not to improve the results of success.

If you don't do this, if someone can modify the hardness and conductivity of the brass object inheritance on their pot object, then what is the point? you'll lose consistency whether you go in the front door or the back.

Or am I completely misunderstanding this?

[Monkey]

I would assume that craftsmanship could be another inherited property that would modify the teapot. Brass has a higher conductivity rating, so brass teapots in general warm faster than iron ones, whether it was made by an apprentice or a master. Craftsmanship could work as a modifier to the teapot's conductivity, so that the master's brass teapot warms faster than an apprentice's brass teapot (which may or my not warm faster than a master's iron teapot).

hmm...I can think how to code this, but I don't know if I am explaining it well.

--Monkey

[JeffC]

Originally posted by Monkey:
I would assume that craftsmanship could be another inherited property that would modify the teapot.

Ow, oh, god I just realized this would mean that either all game mechanic systems would have to be the same (craftsmanship being a constant based on the concept of a skill level), or each game would have to have its own modifier objects. And both Sam and I want to avoid skill levels/thresholds. Craftsmanship would have to be a variable modifier dictated by the requirements of the game. The pot I make today may not be as good as the pot I make tomorrow.

Right?

[SamW]

Originally posted by JeffC:
And both Sam and I want to avoid skill levels/thresholds. Craftsmanship would have to be a variable modifier dictated by the requirements of the game. The pot I make today may not be as good as the pot I make tomorrow.

Well, I'm not opposed to the idea of skill levels, in general, I'm opposed to the idea of them becoming the prime motivator of the game. I want players to want to become good enough to make a plasma recombination cell, not want to 'get a 30 in engineering.'

But back to the point at hand, I think most games are going to have their own libraries of modifiers/items/properites/whatever. There may be things we can borrow from one another's libraries to strip out the core properties (things like weight, mass, description, etc.) and then plug in our own mechanical bits.

While it'd be nice to be able to come up with a unified mechanic and revolve everything around that so all object libraries are interchangeable, I'm not sure it's feasible given the wildly divergent playstyles of the different games being offered.

Still, just being able to take copies of the physicality of objects will be a great boon - I'll be able to swipe a whole set of oriental clothing styles from Qigung, and probably get some genemods from the descriptions of animoids from IronClaw, and maybe get some weird nanoeffects from the abilities and whatnot seen in Arcana.

It'll all have to be tailored, but the core building blocks will be there.

Just my $.02,

Sam