OLYMPIA: More Stacking Reform [Long] <REPOST> From: morrow@romulus.rutgers.edu (John Morrow) Date: Sun, 14 Jun 1992 18:20:37 +0000 THIS IS A REPOST OF <STACKS AND TREES AND [LINKED] LISTS, OH MY> WITH "OLYMPIA:" IN THE SUBJECT LINE. THE OTHER ARTICLE HAS BEEN CANCELED. APPOLOGIES IF YOU HAVE READ BOTH... 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] Up