[Ar-list] Machines MRS

[W Isaac Carroll]

Carter Butts wrote:
> W Isaac Carroll wrote:
> > I see several kinds of people who will want to use the Machines MRS:
> >
> > 1- Reality designer
> > 2- Machine builder (or tweaker)
> > 3- Machine user/destroyer
> >
> > Each type of user will have different, though overlapping, needs. So the
> > question is, which audience are we writing for in this MRS? Perhaps a
> > section for each?
> 
> Separate sections, I think.  The initial idea was to have a system for
> designing machines which would "compile" a complex "source" design into
> a simple set of attributes and rules for the end user (the "executable
> code", if you will).  This was quite a challenge, and remains so, but
> perhaps you have some ideas on how to proceed.

As I see it, you design a machine by selecting from a group of primitives
(kindly provided by your friendly neighborhood reality designer) those which
produce the attributes you intend your machine to possess. You then select
additional primitives which provide attributes that the first set will require
in order to function. This process continues until the machine is sufficiently
self-sufficient. (ie, it still may require input or support of some kind, but
shouldn't need 12 people to hold the parts together in order to function--
unless that's the sort of machine you were trying for...) At this point, the
machine design is usable in an AR gaming session, but its design probably
contains a large amount of unnecessary detail. So we need to design
simplifying transformations which preserve the important features of the
machine, while eliminating superfluous detail.

The main question we have to consider when simplifying a machine is, how
interested are we in the machine's failure behavior? We can represent a
machine as a single AR object which is incapacitated or scrapped as a unit, or
as a collection of related components which can be incapacitated or scrapped
individually, resulting in complex behavior where the failure of each
component will have a different effect on the machine's ability to function.

The next question we have to answer is, how do we handle the incapacitation of
a primitive in the complex original machine design? The obvious solution is to
specify the attributes of each primitive in its incapacitated state. Then,
when a primitive is incapacitated, replace the original attributes with the
incapacitated ones and find out if there are other primitives whose operating
requirements are no longer being satisfied. If that is the case, replace them
with their incapacitated versions, etc. In this way, the failure of a critical
primitive can cause a cascade which will incapacitate the entire machine,
whereas the failure of an auxiliary primitive may incapacitate certain
attributes of the machine, but will leave the machine's primary functions
unaffected.

A machine can be simplified by aggregating primitives into components. Each of
these components may again be aggregated further, up to the level of
simplicity desired. A collection of primitives and/or components (hereafter
referred to generically as components) can be aggregated by creating a new AR
object having the same external attributes as the original collection. By
external attributes I mean any attributes which are visible when considering
the collection as a "black box". For example, the components' combined mass is
an external attribute (in most cases). However, if a given component's energy
requirement is entirely supplied by a battery component which is part of the
collection, then the energy requirement is not an external attribute.

The physical layout of the final set of components will guide the creation of
the hit diagrams of the machine. The diagrams must take into account
situations where the incapacitation of certain components exposes other
components to damage (armor, for example).

The machine's components must also be analyzed to produce a dependency chart
which describes what happens when each component is incapacitated. It will
give details such as which other components are also incapacitated, and which
attributes of the machine are affected and in what way. Care must be taken to
describe cases where multiple failures must happen before a particular effect
is created (redundant power supplies, for example).

The end product of these procedures is an AR object which describes its
properties in its intact state, and also gives the information necessary to
quickly determine what effect any damage to the machine will have.

The End

Carter and Karim, how close is this to the original ideas you had for Machines
MRS? What, if anything, am I doing differently?

Everyone, please comment on this. Am I missing any issues that need to be
addressed?

I really have no idea how to turn ideas into rules supplements. I would
appreciate some help with that.

In my next message I'll give an example of the machine designing process.

TTFN