[MUD-Dev] Natural Selection and Communities
Paul Schwanz
pschwanz at comcast.net
Tue Sep 3 14:16:54 CEST 2002
David Kennerly wrote:
> From: Paul Schwanz <pschwanz at comcast.net> on Tuesday, August 27, 2002 09:53:
>> I don't doubt that building this sort of flexibility into
>> communities will require more effort and resources for designing
>> and coding the game, but it seems to me that the benefits would
>> vastly outweigh the costs.
>> Or am I just not seeing the whole picture here?
> Vague ideas are doomed to the worst kind of failure, the kind that
> doesn't even prove if the idea was bad or the implementation was
> bad.
It seems to me, however, that all ideas are doomed to start out as
vague ideas. ;)
>> Could not all of the above options be included in the
>> charter/city creation interface?
> What would be an example charter/city creation interface? What
> are the menus and options? What are the resulting city algorithms
> of each configuration?
Hopefully, a comprehensive design document isn't required in order
to illustrate and discuss the concept, although I can see that
specific implementations would be helpful in order to get beyond
discussing the concept to actually proving a formal game-design
theory. I don't think I'm quite there yet, but I'll try to expand
the concept to include some more details in the hopes that this may
further discussion.
Many of the details of implementation, IMHO, will have no real
bearing on this concept. For instance, whether 1, 5 or 10 founders
are needed to form a city, whether 4 houses in a square kilometer
are required or a town hall must be constructed; these are
interesting things to consider, but I don't think we have to decide
all such details prior to discussing how a natural selection process
could benefit communities.
What *is* important is that players have an opportunity to make
distinctive choices regarding issues about which they are concerned.
Eminent domain might be such an issue. Example menu choices during
city founding might include the following.
1. The power of Eminent Domain:
a. cannot be invoked
b. shall be at the sole discretion of a duly elected
official
c. shall require a majority vote of the citizens
2. If Eminent Domain is invoked, the land-owner shall:
a. receive 3 times the server-determined value of the
property
b. receive "fair-value" as determined by a duly elected
official
c. receive either a. or b. as determined by a majority vote
of the citizens
d. receive b. or, if a "dispute" is raised, c.
3. If Eminent Domain is invoked, the property in question:
a. must be used only and immediately for a municipal
structure
b. can be utilized at the sole discretion of a duly elected
official
>> When the city is formed, let the founders decide which
>> implementation will be best (with the possibility to change the
>> charter at a later date through citizen vote...or not).
>> This will then give players the freedom to choose from among a
>> number of different possible implementations the approach they
>> believe best addresses their own concerns.
> _Their own concerns_ have no necessary correlation the game
> operator's concerns or the populace's concerns.
As I understand the whole concept of customer service and
satisfaction, there is indeed a necessary correlation between the
customer's concerns and the service provider's concerns.
>> Variation, along with
>> the natural, player-choice selection mechanism, will cause the
>> most fit implementations to thrive and the least fit
>> implementations to wither away.
> The terms "natural selection," "player-choice," "mechanism," and
> "fit implementations" hold too many tentative assumptions. These
> vague terms delegate the problems without solving any one problem.
> Please elaborate by example.
> Please give an example of the selection mechanism. One form of
> natural selection would be for the poor leaders to die--not their
> characters, the players at home on their computers. Another form
> would be for all players of a failing city to die, like captives
> on a sinking ship--not the characters, the players.
In this instance, player choice simply involves becoming a citizen
of whatever city is preferred. (I'd stay away from the player death
idea unless you think you might still be able to continue charging
their credit card. ;)) Citizenship would need to be formalized
enough that the game system could recognize status. Players could
be citizens of only one city. Citizenship would determine city
population levels which would in turn be used to manage a positive
feedback mechanism. At certain population levels, the whole
community gets a "ding" not unlike the sort of mechanism used in
character levels.
> What is the exact "player-choice" mechanism? Is it a marketplace,
> a representative democracy, a meritocracy, a socialist democracy?
> How?
It is an economy. Cities compete for players. To do so, they need
to be able to offer players a "product" that is distinct. Products
that don't satisfy will not be "purchased." This mechanism pushes
businesses to offer a superior product.
> What makes player-choice selection superior to expert-choice
> selection to decide the design of a service subsystem?
The same thing that makes consumer choice superior to, "You have
your choice of color: black or black." If I don't like the color
black, what do I care that its been offered me by an "expert?"
>> If I don't like the community's implementation, I can find
>> another community within the same MMORPG, but if I don't like the
>> global implementation, I must look outside of the current MMORPG
>> if I am to find the community that fits me.
> You may, but do customers work this way? When a customer has one
> bad experience, does he usually give the service another try? Or
> does he usually give another service a try?
I don't know. But I do believe that if the customer is convinced
that no other experience is available within the same service, he
will *always* try a different service. I'm just trying to give the
ones who might be willing to give the service another try an
opportunity to do so.
>> If you then design so that community growth leads to increased
>> opportunities for individual success, won't this create an even
>> stronger selection mechanism?
> This overlooks the individuals for the group. The Tragedy of the
> Commons appears: Everyone wants community growth a little, but the
> ones in political power want political power a lot. Thus, every
> decision is skewed away from community growth and skewed toward
> personal power. Electing a new tyrant won't fix the broken system
> that the players chose.
If personal power is dependant upon community growth, perhaps the
decisions aren't so skewed. I'd strongly suggest making them
symbiotic.
> Not all communities want to be big. In Nexus The Kingdom of the
> Winds in 1998, a game designer (me) created twelve advanced social
> classes, called subpaths. These were specialized classes in the
> D&D sense, but were also philosophical and had scripted social
> structures. I began with Schwanz's premise that pressure to grow
> would be sufficient. It wasn't. The leaders adhered to my lofty
> ideals and thereby refused admittance to most applicants.
What incentives were there to grow? If players didn't receive new
spells, more hit points, more abilities, or other "dings" for
accumulating experience, would they go out of their way to do so? A
community might need similar "dings" to convince it to attempt
growth. If your incentives are not working, make them larger until
they do.
> Three, natural selection was working, but data suggested it was
> not for the reasons I intended. As I collected data, I noticed a
> trend that lead to an unencouraging interpretation. Location,
> location, location. The population of each religion was inversely
> proportional to the religion's temple's distance from the new
> player village.
I'm going to claim that your religions were not distinctive or that
your players did not care about the distinctions. At the least,
their concern about the distinctions didn't rise to the level such
that they over-rode concerns regarding convenience. I'll venture,
however, that if your religions determined (for example) PvP status,
temple location wouldn't have been the primary factory influencing
membership. Since you determined the location, and since location
was the only real distinction that mattered to your players, there
was no real opportunity for player communites to compete in order to
provide the "best" religion.
> Another misuse of natural selection is to ignore research. Some
> choices should be made ahead of time, because they are optimal.
> The point of natural selection is to arrive at an optimal.
Sure. I'd recommend always making choices ahead of time regarding
what will make your server run faster. In this instance, all your
players are likely to agree about what is optimal. On the other
hand, as it relates to eminent domain, choosing ahead of time would
appear to split one particular message board down the middle.
That's because, what is "optimal" is highly dependant upon player
preference.
So, what's the "optimal" color for Ford to offer its customers?
> It was not a sandbox to begin with, so to hear tell of a sandbox
> makes me shudder. While anything will work in the hands of angels
> (handpicked or not), it is devils that will test your service's
> design quality.
I'm advocating player empowerment, but not without boundaries. I
agree that the successful developer will have to think long and hard
about where those boundaries should lie.
Sometimes, experience can be a two-way street. For instance, I've
had a lot of experience trouble-shooting errors on fibre channel
loops. In all that time, I've never traced the problem to a fibre
cable failure. If I were to completely rule out this possibility
based on my experience, though, I'm going to be pulling my hair out
when I'm called in to trouble-shoot a case where the fibre cable
*has* failed. In other words, experience and theory need to come
together, each informing the other, when trying to sove complicated
problems.
--Phinehas
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list