OLYMPIA: Stacking Reform Concepts (was Re: Olympia Stacking 'Gotcha')

From: morrow@foghat.rutgers.edu (John Morrow)

Date: Thu, 11 Jun 1992 14:52:18 +0000

cedman@714-725-3177.nts.uci.edu (Carl Edman) writes:

>In email morrow@remus.rutgers.edu writes to me:
>> In rec.games.pbm you [Carl Edman] write:
>> >More opinions on stacking.

[Again, edited to get to the point]

>> As a matter of fact, I think that without, say,
>> observation, the command structure, to an outsider,
>> would not be readily apparant  other than, say, the
>> overall leader, which is what is shown now.

>I guess I agree with that too, though I think that command structure
>ought to be something fairly easy to see and should be immediately
>visible for any group which is at least cooperative.

I don't object, in principle, to a hierarchy structure, especially as
it pertains to stacks of units.  My main concern is winding up with
structures 100 layers deep and trying to represent that.
Subdirectories are nice but when you have to look at something like:
/usr/spool/news/rec/games/pbm/olympia/stacking/discussion/june/1992/whatever
it can turn into a real hassle.  Would you say that putting a limit
of, say, 5 levels would allow sufficient complexity and room without
extending things to absurdity?  Another option might be to allow many
levels of hierarchy but to simply not indent.  I really don't want to
start seeing:

Billy Bob [999], player character, stacked over:
  Billy Bob's Parents [2999], number: 2, stacked over:
    Billy Bob's Brother [2990], individual, stacked over:
      Billy Bob's Sister-in-Law [2991], individual, stacked over:
        Billy Bob's niece [2992], individual, stacked over:
          Billy Bob's niece's estranged husband [2993], individual,
          stacked over:
            Billy Bob's niece's son [2994], individual, Wearing a Biker's
            helmet, stacked over:
              Billy Bob's niece's son's Biker Friends [2995], number: 20,
              stacked over:
                Biker Chicks [2996], number 21, stacked over:
                  Rover [2997], individual, A doberman, unfriendly,
                  stacked over:
                    Rover's Animated Bone [2998], individual, faction
                    [814]

If you think I am exaggerating, can you picture one of Prenola's stacks?
I just see at least one joker sayings "Gee, I wonder how many levels
deep I can stack this guy..."  I also feel pretty strongly that all
the members in a stack should be visible and not summarized.  With one
month moves, it is difficult enough to track someone down without
trying to find them hidden deep within stacks.  It think that if you
want to hide, Stealth skill should have a USE that can take care of it.
In short, I can live with hierarchy but not if it adversely affects
my ability to see the units within the stack (which means I can live
with indenting but I would prefer it didn't get extreme).

>Again I mostly agree. Buildings within cities should be there I think
>and many skills ought to require stacking with the right building or
>would at least be improved by it (i.e. entertainer stacking with an
>inn), but any level of detail beyond that would be too much.

I like the idea of stacking with buildings to perform skills.  That
would address the issue that someone brought up about two units in a
stack doing different things that should require them to be in
different places to do it right.  You could also modify the WORK
command to base it on what you are stacked with (if you stack with an
inn, you might wash dishes or serve tables, etc.).  Now, to build (pun
intended) on this idea, suppose you don't start off with inns, etc.
but allow players to build them using Construction and lumber?  Once
an inn is built, the top unit (the manager) would get monthly revenue
based on the population of the city, the average number of visitors
stacked with it over the month (assume they spend part of their
maintenance there), and any entertainment good enough to pull in more
business (see my ideas below about structures and ownership).  If you
haven't noticed, I am looking at ways to allow the PLAYERS to add
depth to the game because (A) what can I say, I am a MUD player from
way back, (B) it saves the people running the game the trouble of
putting the detail in -- players do it for them, and (C) the detail
put in my players is often more varied and interesting and has a feel
of being different/unique.  In any event this idea could be expanded
to other types of buildings if it worked with inns and could become
the basis for a larger economic reform later (taxes, etc.).  It could
also lead market reform away from open marketplaces into the realm of
specialist shops (e.g. stack with the stables and buy a horse, the
stables being owned by a faction that brings in horses from the plains
and sells them...) but that is down the line (what do people think
about this?).

>> >2. More importantly, how is combat handled between
>> >substacks ? Should two stacks in the same city be
>> >completely unable to attack each other just because
>> >they are part of the city stack ? Or should one be
>> >automatically unstacked and have to attack the other
>> >through the city walls ? I think not.

>> I think cities should be dealt with like regions.  They are
>> a place that you are IN.  Towers and other buildings should
>> be dealt with like other players, as something you stack
>> WITH.

>But don't you see the beauty (aehm... ;-) ) of my proposal ? It would
>automatically give you sieges, ship-to-ship battle, battles on ships,
>assassinations aso. aso. aso. and always do what I think is the right
>and realistic thing. And the beauty of it all ? It comes from a single
>fairly simple rule without dozens and dozens of special cases.

Yes, on one level your system works VERY well.  On another level it
doesn't.  Your examples are looking for stacks to produce one type of
effect.  That ISN'T necessarily the effect I expect to get.  I have
reinserted your example below and my comments follow...

>D is outside the city:

>A
>   B
>   C

>If D attacks B now, A will be a parent stack of B, but not of D, so it
>will fight together with B. This would also automatically involve C on
>B's side.

>D is inside the city:

>A
>   B
>   C
>   D

>If D attacks B now, A will be the parent of both D and B. So D and B
>will just have to fight it out between themselves. C doesn't get
>involved.

>In other words, if an outside army attacks a city, all citizens fight
>it off together. If there is murder inside the city, that doesn't
>automatically involve anybody else.

I do not agree that all of the people inside the city should get
involved, automatically, in any assault on the city proper.
Specifically, down the road, if I pay taxes to some guy to protect me,
I don't want to get drafted "automatically" should the city get
attacked if I am inside of it.  That is why I am paying taxes to buy
guards.  In sieges, there should be people on the wall and people who
aren't.  You should get to choose where you are by where you stack.
On the other hand, your example of an assault within the city is
valid.  Others should not necessarily get involved if there is an
assault in the city, although I think there should be some way to set
a unit so it will respond to any hostilities in kind so that a city
could have a patrolling guard unit to keep the peace.  Your example
breaks down again, IMHO, within a group of people stacked under a
leader.  I currently lead units from 3 factions.  In MY opinion,
should one of the factions under my command try to attack one of the
others, I WANT my whole stack to come to their defense.  After all,
that is why *I* feel we are stacked together -- to defend one another
from being killed.  The problem I see with your system is that it does
not allow for upward or lateral activation of defense but only
downward.  I feel there are may cases where treachery in the ranks
WOULD be dealt with by the whole group.  If you want assassinations,
there could be YET ANOTHER Stealth skill USE which will activate an
attack, if successful, without activating defenses.  Your example
could also have another peculiar effect.  Suppose four factions board
Oleg's ship (sorry, Oleg, you are the only ship owner I know by
name... :-) and one faction decides to pick off another or Oleg.
Under your system, it would be a one-on-one between the attacking
faction and the defender but I think, realistically, mutinies and
brawls can work TWO ways.  In one instance, as under your system, only
the "involved" parties fight it out and everyone watches.  This
addresses one sensibility.  In another instance, however, everyone
picks sides.  There is also a THIRD variation which combines the two.
A way to deal with this is:

-SHIP-
                           / |  | \
                          A  B  C  D
                         / \      / \
                        AA AB    DA DB

A STRUCTURE (ship, castle, city) does NOT transfer defensive reactions
but UNITS do.  If A attacks B, A + AA + AB will all attack B and C, D,
DA, and DB will all watch.  If A attacks D, DA, or DB, on the other
hand, D, DA, and DB would all defend.  If B attacks C, neither A's
stack or D's stack would get involved, etc.  Now, if DA unstacks, it
will be stacked directly under the -SHIP-.  If DA is then attacked, D
and DB would NOT come to DA's assistance.  If DA issued ANOTHER
unstack, he would exit the ship if possible.  If AA attacks AB, he
would first unstack to the -SHIP- level and then attack A and AB.
Now, what about the -SHIP- itself?  The FIRST unit stacked below the
-SHIP- (in this example, faction A) owns the ship.  That unit gets to
move the ship and declare any dispositions for the ship to limit
boardings.  In addition, should the ship get attacked, Only the first
unit and any units stacked beneath that unit will come to the defense
(in this example, A, AA, and AB).  IF the other units want to be able
to defend the ship in case of an attack, THEN then should stack
beneath the owning unit when they board the ship.  You can apply
this approach to inns and other structures as well.  A unit winning
an attack on a ship or inn would then replace the defending unit as
the "first stack".  I think differentiating between a "structure"
stack and a "unit" stack would solve any problems I see with your
system.  In addition, since this system gives the ability of
possession, it could help pave the way for ownership, a market
economy system, taxes, etc.  The way the type of unit would be set
it is if is "form"ed, it is a "unit" of living beings.  If it is
"made" by a "use", it is a "structure" which is owned and houses
living beings.  What about cities?  I had previously suggested
having a structure defined as a "seat of government".  Possession
of that structure would mean possession of the city.  Now, suppose
you want to help defend the city but also make some money or
study?  Fine.  You stack below the owners.  You can study.  If you
work, you will get the "clean sewers" or "guarding" civic jobs at
reasonable pay.  But "use" skills would be out for the most part.
You CAN deal with cities as structures themselves, sort of like
the old exits, I suppose.

>I disagree. Much of the above just adds more complexity instead of
>actually simplifying things (at least conceptually) as I think my
>proposal would.

Yes and no.  The structure of Olympia is already one of regions that
you MOVE between.  Would you suggest the structure of Olympia be:

-OLYMPIA-
                     /    |    \
               Chardia  Ilion  Caburh

so you can say "stack Ilion" - 'You will spend 25 days unstacking from
Chardia and stacking with Ilion'?  I don't think that works well.
There is a concept of long travel to where you are near someone or
something from where you weren't.  That is what the MOVE command
represents.  It moves you from one place to another where each place
is a location in which all the inside entities are visible and the
outside ones are not.  I think this "MOVE" concept is appropriate for
when you move of sight of the previous locale, such as into a city
from the countryside, or into a cavern from above, but not when you
are simply entering a structure or stack association which implies
a minimum of movement.

>If something appears on Olegs map, then everybody knows
>where it is and how to get to it. How do you think people find the real
>world Disney World ? No, the solution to keeping something secret is to
>prevent it ever from getting into Olegs maps. (Not that I don't admire
>Olegs skill at getting all that information. I just think that all the
>people who supply him with information might try to be a little bit
>more parsimonious. Remember - information is power and should be hard
>to come by).

Good point.  I didn't feel comfortable with the implementation of that
idea anyway...

>I agree completely. As a matter of fact I would go even further. I'd
>kill all but the most basic commands and make them all skill uses. That
>would both make the instruction manual smaller and easier to understand
>and give the players more to learn in the world. And learning about new
>things is one of the facets which makes such games enjoyable, isn't it
>?

I agree.

>Ah well, I disagree. I think of stacks as units formed for the
>protection against _outside_ forces. If two forces within the same
>stack attack each other who is to tell which side the rest of the stack
>will take, where its localities will lie ?

Exactly.  Your assumption is that they sit by and watch.  That is NOT
my assumption.  It could go either way, realistically.  In MY opinion,
if someone in my stack attacks someone ELSE in my stack that I have
said I would protect, I DO want to come to their defense.  Can you
think of a way to turn on and off upward defense and lateral defense?

>If I kill a prisoner in my
>stack, will my bodyguards turn on me ? (BTW, lets do away with EXECUTE
>too. Just make ATTACK from a stack leader against a prisoner
>automatically one hundred percent successful - lets keep the name space
>clean). Under my proposal if you and somebody else in one stack feel
>particularly close and will fight on the same side automatically even
>if someone within the stack attacks you, just form a sub-stack together
>and my rule will automatically have you helping each other, even if
>another stack member attacks you.

If you want to execute a prisoner without using EXECUTE, simply drop
him and "attack kill" him.  This is another way of looking at it.
In other words, move him OUTSIDE the co-protection stack and then
off him.  In this way, execute isn't even a 100% thing which maybe
it shouldn't be...

>> >I've tried this rule on a few more cases in my head. It
>> >always seems to Do The Right Thing. Try it yourself.

As you can see above, I don't think your rules ALWAYS do the right
thing.  Sometimes they do, and sometimes they don't.  If you can
figure out a way to easily turn on and off upward, downward, and
lateral defense, then I might buy it because, in some cases, I
think those options are important.  Of course, if you simply have a
bunch of dispositions to a bunch of other units, who needs stacks?
They loose much of their significance as you could never be quite
sure what will happen when you attack one.

>> See the above.  In addition, to me, attacking a city
>> constitutes walking in and attacking the occupants.  I
>> have worked this one out.  If you want specifics, let me
>> know...

>Not a walled city with a owner who was wise enough to go 'unfriendly'
>to you beforehand, it don't. The guards wont let you in, just as little
>as tower guards will let you into my tower without my permission.

That is, if you look at a city like a tower, which you could.  In that
case, should only the "unfriendly" owner and any guards defend or
should everyone be drafted automatically, or should there be a system
to set this?  This could easily get quite complicated.

To summarize, I think your system breaks down in certain circumstances
where lateral and upward association are important because it focusses
ONLY on downward association.  While this gives "correct" results in
some situations, it also gives "incorrect" ones, both realistically and
in my opinion, in others by rearranging things so that they are your
way (which supports one reality) instead of the way they are now (which
supports another reality which I happen to like for the most part).
This is a change to a different way of doing things but I don't feel
it is necessarily a better way.

John Morrow - Varian [856]

References

Re: Olympia Stacking 'Gotcha'
srt@aero.org (Scott "TCB" Turner)
Wed, 10 Jun 1992 21:44:49 +0000
Re: Olympia Stacking 'Gotcha'
cedman@714-725-3177.nts.uci.edu (Carl Edman)
Thu, 11 Jun 1992 00:57:42 +0000

Referenced By

Re: Olympia Stacking 'Gotcha'
srt@aero.org (Scott "TCB" Turner)
Wed, 10 Jun 1992 21:44:49 +0000
Re: Olympia Stacking 'Gotcha'
cedman@714-725-3177.nts.uci.edu (Carl Edman)
Thu, 11 Jun 1992 00:57:42 +0000