OK, I scratched my earlier novel on the subject for what I hope is a
shorter discussion on data structures within Olympia. Note, this is
still very dense and not for the feint of heart... :-). What I am
trying to do here is identify the issues surrounding which data
structure to use for which purposes and to make some of my own
suggestions.
There are two kinds of structures in Olympia right now. One is the
multilinked list, represented by regions, and the other is trees
represented by stacks, towers, and ships. When one looks within a
region, all of the items within the region are visible, arranged in
such a way as to indicate their stack affiliation but one region is
not visible from another. In general moving down a link between
regions takes time where stacking with a tree does not. The
characteristics, therefore, of a tree is that its members are visible,
it takes no time to join or leave a tree, and represents a hierarchy
where the characteristics of a multilinked list are lack of visibility
across links, travel time down links, and no hierarchy. I will skip
the multilinked lists right now and focus on the trees. The trees
currently are very simple consisting of only a top node with all of
the units underneath the node stacked at the same level. No further
depth is possible. What has been suggested, however, is that "stack"
trees be made multi-leveled so that when one multi-unit stack stacks
with another, all internal command structures will be kept in place.
In general, I feel this is a good idea. (There are some minor
problems including checking declared attitudes up the stack if a unit
lower in the stack does not have the correct attitude and loss of
stack integrity if we allow selective within-stack defense which COULD
be a real problem - I explain these problems at the bottom). If such
a system is implimented, a great deal of detail becomes possible.
I have come to agree that the best way to represent a city is as a
tree form stack. As I stated above, the characteristics of a stack
are that the members of the stack are visible (as I feel the occupants
of a city should be to keep things playable), it takes no time to
stack (I feel that entering a city should be a zero time move for
reasons I can explain at length -- try me :-) -- this has mainly to do
with attacks and blocked entrances), and the structure is hierarchical
which allows a representation not so much of X owns Y but Y is inside
of X which is correct for cities. In other words, if Y is stacked
under X, Y is inside of X -- if a unit is stacked under the city, it
is in the city. To take it a step further, you can have a building
stacked under a city with a unit stacked under the building meaning
that the unit is inside the building which is inside the city. It
takes no time to move from one building to another or into or out of
the city, in other words, less than a day which is correct. The
building would be visible stacked under the city and the patrons of
the building would be visible stacked under the building which I also
feel is correct for the purpose of this game. Now, buildings and
cities (and ships, as well) need to have a way of determining which
faction owns the structure. The current means of doing this is to say
that the first unit stacked with a structure owns it. I think this is
generally a sound way of determining ownership. In addition, you
could build another structure, stacked in the first position, which
could represent a castle or defensive tower protecting the citys.
That structure's owner, then, would be the city's owner. How then
does one go about making a city? Well, I suggest the
following. Create a command FOUND, ESTABLISH, or SURVEY which will
create the initial "city" object and drop it in the region the command
was executed in. The unit executing the command would be immediatly
stacked under it. Such a command should cost 1000 gold or more to
prevent every Tom, Dick, and Zyzak from making one for taste. At this
point, construction could be used to build up the fortification level
of the city (ultimately, taxes could be levied on any income or
expenditures within the city but that is another issue...). As for
buildings, different construction options and building materials could
be used to build a variety of structures. They could be built either
within a city or outside of a city, depending on where the unit
building the structure is located. I would suggest the following as
well. If a city is founded within a region containing loose
buildings, up until the time that the city's fortification level
becomes 1 or greater (i.e. before the first wall is finished), you
should be able to RELOCATE a building to within a city's limits (the
assumption being that it happens to be in the area already and you
have a turn or two to adjust the surveying...). This way, you could
sort of simulate a city growing up around other structures that have
been there for a while. OK, now you have your cities, buildings, and
a way to move between them (stack/unstack) and markets could be
simulated with a structure "market" with its own inventory, etc.
OK, so now what? What is the dynamics of the stacks? That is the big
argument/discussion Carl Edman and I are having. Suppose we have:
REGION WHERE:
/ | | \ A, AA, AB = Faction 1
A Q C CITY B = Faction 2
/| | / | \ C = Faction 3
AA AB B D E X D, DA, DB, DC, DD = Faction 4
/ \ / \ E = Faction 5
DA DB F G F = Faction 6
/ \ G = Faction 7
DC DD Q, X = Buildings
First, suppose that D is unfriendly towards E. If E tries to stack
with DC, would it be possible if DC and E were cooperative? We must
make sure that attitudes are checked to the top of the stack. One
"simple" way to deal with checking attitudes is to say that E executing
STACK DC means "UNSTACK; STACK D; STACK DA; STACK DC" then at each
phase, the attitudes would be checked. Now, suppose the city is neutral
to E. Should E be allowed to enter? I would say yes. Then does the
attitude of and towards a city differ from that of and towards a unit?
I would say yes. Keep this in mind. Neutral for a city is not equal
to Neutral for a unit. Now, if A should try to stack with DC, it
would be "STACK CITY; STACK D; STACK DA; STACK DC". What do people
think of this? As a note before continuing, using the present system,
D "owns" the CITY, B "owns" Q, and F "owns" X. Regiosn cannot be owned.
The big issue, though is what happens when a unit, city, or building
is attacked from within or without. I would like people to work out
rules to govern the following situations. They can be simple or
complex but must give reasonable effects. I would like to see what
other people think and then I will express my own opinions (actually,
I have already but they may change like they did about cities...).
One idea that would be difficult to work out is the idea of setting
each unit to who it will defend and who it won't. The danger of such
a system, to take from the example above, is that DA might be set to
intervene on someone's behalf but DC and DD might be set NOT to
intervene on someone's behalf. In that case, what happens? Does rank
take precidence? Does DA leave DC and DD behind? This could cause
problems if not carefully thought out.
Anyway, if you got this far, chew on this and comment.
Thanks,
John Morrow - Varian [856]