Olympia: More Stacking/Object Reform Ideas (*LONG*)

John Morrow (morrow@romulus.rutgers.edu)
30 Jun 92 00:30:52 GMT

I have been giving some more thought to object reform and I have come
up with the following ideas. If you are interested in stacking reform,
cities, etc. please try to bear with me (if not, go to the next message
now :-) and read to the bottom. There is a lot of stuff in here and
you might like some of it -- then again, you might not...

(NOTE: The following ignores the concept of maintaining hierarchy within
a stack and works equally well with or without it)

I have identified the following types of regions as potential/desirable
structures in Olympia:

Regions, Cities, Buildings, Ships, Units, and Exits (resurrected from the dead)

There has been some interest in unifying the manner in which each of these
types of objects is handled and the following is what I have come up with.

Give each object two primary ways in which other objects can be
connected to it and an exit list. The two types would represent two
ways in which another object could be associated with the object in
question. The first association form is familiar. It is the "stack"
association in which a series of units are arrayed under the object
for defense, movement, etc. The second association form is new and
represents being contained inside of or being protected by the object.
Instead of using "STACK/UNSTACK", one would use "ENTER/EXIT" to
"enter" or "exit" the "inside" of another object. The exit list is
used for both locations and exits to indicate where one can go using a
move command and represents a jump to a new locations instead of a
change in association. Stacked units would be able to see the units
they are stacked with, the object they are all stacked under, and the
location where that object is stacked. They would also be able to
see the object inside the object they are stacked with. Units inside
would only be able to see the things inside the object they are in and
those objects stacked with it. (e.g. the units stacked with a city
could see the region the city is in, the units they are stacked with,
and the objects and units inside of the city. Those inside of the
city could only see the objects stacked with or inside of the city.)

This is how each of these things would be used
for each of the object types:

Stacking represents controlling and patrolling a region.
The first stacked unit also gets several "possession related"
benefits detailed below. Buildings may be built "stacked" with a
region for defense. (Possession of regions could cause problems
and may need to be prohibited but it COULD be done)
Entering represents being inside of the region as a visitor or
resident. Move commands from outside of the region also dump
a person "inside" of the destination region. Cities and buildings
may be built inside of a region. Exit objects "reside" here
(see below).
The exit list represent the familiar exit list which now appears for
Stacking represents controlling and defending a city. The first
stacked unit also gets several "possession related" benefits detailed
below. Buildings may be built "stacked" with a region for defense.
Cities may be fortified representing walls around the city.
Entering represents being inside of the city as a visitor or
resident. Buildings may be built inside of the city. Exit objects
could also exist here.
An exit list does not generally exist for cities although one could
exit to ocean locations from, say, a beach.
Stacking represents controlling and defending a building. The first
stacked unit also gets several "possession related" benefits detailed
below. Buildings could be built "stacked" with another building
representing a clustered structure (this could be made dependent
on the type of building to prevent strange combinations). Buildings
may be fortified depending on the type of building.
Entering represents being inside of the building as a visitor or
resident. Buildings may not be built inside of one another (although
there this COULD be made dependent on building type). Exit objects
could also exist here.
Exits to other regions do not exist with buildings (although they could
for certain types such as docks).
Stacking represents controlling and defending a ship. The first
stacked unit also gets several "possession related" benefits detailed
below. Ships may be "stacked" with other ships into a fleet of
clustered ships. Ships could be fortified depending on the type of
Entering represents being inside of the ship as a passenger or crewmember.
Ships may not be built within or enter other ships. Exit objects
probably should not exist anywhere on ships.
Exit lists are not used on ships.
Stacking represents an association for the purpose of offense,
defense, and/or movement. The top unit on the stack (under
which the other units are stacked) is the leader. Units may
not be fortified but may buy armor.
Entering could be used to represent a prisoner or protection scheme
or could be prevented all together depending on how people feel.
Exit list are not used with units.
(Note: Exit objects are used to represent built roads, etc. They
are BUILT by players. They contrast with wilderness travel that
exists normally between regions in that they can be more easily
defended and fees may be charged to travel them. They do NOT
replace the normal wilderness travel routes.)
Stacking represents controlling and defending an exit. The first
stacked unit also gets several "possession related" benefits detailed
below. Buildings may be built "stacked" with an exit representing
a defensive structure. Exits, themselves, may not be fortified.
Stacking should only be permitted from one side of the exit to
prevent "teleporting"
Entering would normally not be used. The "inside" location COULD
be used to "hold" players in transit with a flag set to prevent
interaction or detection.
Exit lists for exits contain two entries -- one for each end of the
road. The exit object is visible in both destinations.

The possessor of any object (provided it may be possessed) can set two
attributes for the object:

SET <location> FEE <amount> - Set a fee which must be payed to "enter"
the object (or move along it for exits).
SET <location> TAX <percent> - The percentage rate will be charged
against any transaction, "work", or "use" which makes money done
within the object.

How does this work with each object type?

With the exception of Regions and Exits, these represent fees charged
by the controlling unit for the service of being stacked or inside of
the owned object. Regions should not have entry fees (this causes
movement problems) and Exits do not need taxes (you don't make money
while traveling). Fees for using an exit (road) should be charged
at the start of a journey to prevent the frustrating "how far did
we go before being turned back/fighting" question.

OK, how do you prevent taxes and fees from being used to fleece people?
First, display fees and taxes on the unit listing. Next, set up the

SET <unit> PAY <amount> - Set the maximum the unit will pay in fees to
do something.

The taxes can be handled with the "maximum"/"minimum" prices in the BUY
and SELL commands and being careful on how much you expect to make
working, etc.

Next, for commands such as MOVE and ENTER which may cause a fee
to be rejected, add the following 3 options:

MOVE <location/exit> <PAY/RETREAT/FORCE>
ENTER <location/exit> <PAY/RETREAT/FORCE>
(This is not needed for STACK, see below)

PAY - indicates pay the fee no matter what it is (ignore the PAY setting)
RETREAT - abort the command
FORCE - attack any defending units and force the issue. If there are
no defending units, the unit simply performs the MOVE or ENTER. If
there are defending units, further action depends on the outcome of
the battle.

The default is "RETREAT"

Fees should be charged on a per unit basis in my opinion.

Special Note: In the case where a building is the first "unit" stacked
under an object (where this is allowed), possession of THAT structure
transfers to possession of the object. (e.g. the first unit stacked
under a tower which is the first object stacked under a city will own
the tower and the city)

OK, now why the two ways to stack? Normal stacking rules dictate that
units must be cooperative or friendly to stack. I don't think this is
appropriate for objects such as cities which might allow a more general
access. Allowing "entry" as opposed to stacking allows for general
entry without any actual control or defense of the structure. Attitudes
would work as follows.

Stack Inside
Friendly Yes - No fees or taxes Yes - No fees or taxes
Cooperative Yes - Taxes but no fees Yes - Taxes but no fees
Neutral No Yes - Taxes and Fees
Unfriendly No No
Hostile No No

In addition, having stacked and inside differentiated allow stacked units
to have a command position where they can see inside and outside of the
units they are stacked with while those residing inside can only see
inside. In addition, this allows more offense and defense options
which I can elaborate on if you find this at all interesting.

How would this look?

Here is a rough example (without full stacking reform):

Pesbrand Province [359], plains region, ocean front, population 330

Routes leaving Pesbrand Province:
Southeast, ocean, to Sea of Pesbrand [677], 3 days
Southwest, wilderness, to Ilion Province [357], 17 days
West, wilderness, to Bayarth Province [299], 19 days

Seen here:
Pesbrand-Bayarth Turnpike [10001], road, fee: 20
1) Turnpike Commissioner [999], player character
2) Turnpike Police [2299], number: 20, armor: 3, faction [999]
Pesbrand City [20001], city, tax: 5%, strength: 2, population: 1200
1) Pesbrand Tower, tower, strength: 5
1) The Mayor [2301], individual
2) The Guards [2302], number: 50, armor: 3, heavily armed
1) Stupid Oaf [2412], prisoner, cooperative
2) The Helpers [2324], number: 5, faction [999]
1) The Dancing Sloths [2289], number: 4, Entertaining the crowds
2) Joe's Steak and Ale, tavern, fee: 20, strength: 1
Joe the Cook [998], player character
The Waitresses [2323], number: 5, heavily armed
Happy Patrons [2387], number: 10, armor: 3
The Watcher [997], player character
The Watcher's Watchers, number: 20

I know this isn't perfect but I think it is a workable suggestion.
Not every nuance has been posted since I think this is long enough
already. What does everyone think?

John Morrow - Varian [856]