[MUD-Dev] Social Networks

Koster Koster
Thu Sep 5 10:52:36 CEST 2002


From: Jeff Cole
> From: Dave Rickey

> I think that it has been demonstrated time and again that humans
> are socially inclined.  Certainly, within the context of
> multiplayer games, a developer can safely assume that every node
> seeks, to whatever extent, a social experience.

One of the qualities of scale free networks is that they are
emergent. In any given newly formed aggregate of humans, you'll find
a scale-free network starting to develop.
 
> Assuming the number of links an individual establishes represents
> (rough, even?) measure of the individual's fitness (your
> socialness), then it is the manner in which individuals are not
> equally fit (the link distribution) that is so important: fitness
> follows a power curve.

Actually, there is an important distinction to make here, one which
I haven't seen much study of in the literature on scale free
networks (and I am onto my fourth book and I dunno how many papers
at this point):

There's fitness before the fact and fitness after the fact, or to
put it another way, the innate propensity of a node to acquire
links, and the fitness measured by how many links it actually
acquires. Call it "talent" and "achievement" if you like.

In any scale free network is is easy to see which nodes are the
fittest; in some cases, it's from first-mover advantage. In other
cases it is from innate fitness. It's very important to point out
that most of the models used for scale free network modeling use a
constant for initial fitness. The classic winner-take-all model is
one where "more links to a node means the node is more likely to
acquire additional links."

Much is made of this as being a way in which the network "knows
about history." But it doesn't do so good at predicting variations
in fitness from the get-go.

Fitness distribution in different arenas may or may not follow a
power law distribution. For example, in IQ there's a bell curve
(though not as smooth as many would expect).

In designing, we can select for various sorts of fitness "talent"
among our players. And IMHO, one of the major reasons why
skill-based online games have always proven less popular than RPGs
is because the fitness criteria are different. Competitive ladders
of all sorts (based on what I've been able to research and graph) do
form power-law distributions, whereas achievement in RPGs is
primarily driven by time, not fitness.
 
>> I've been thinking of it in terms of "defining social conflict".
>> There is something that individuals want that they can only
>> achieve through cooperation of a larger scale.  In EQ, it was
>> managing the spawns of high-level encounters, in Camelot it is
>> control of relics and access to Darkness Falls.  The problem in
>> both cases seems to be that they have nothing *else* to do that
>> requires that level of organization, and a limited scope of
>> activity that contributes to that goal.

>> I've been trying to think of ways to establish multiple hubs.

> That a social network is scale free, implies that the fitness
> curve is going to largely depend on the nodes and not the content;
> that is, that additional or different content is not going to
> drastically change the networks link distribution.

I believe the actual answer is "multiple overlapping networks." 
Selecting for different sorts of fitness. Which in the end gets back
to the Law about multiple achievement ladders.

> Decreasing the transaction cost associated with demonstrating
> fitness-- and, therefore, establishing links-- would have a much
> more profound effect on the distribution.  Also, decreasing such
> costs would increase the likelihood that a network could recover
> from the loss of a hub insofar as remaining nodes could more
> easily and quickly establish new links.

In other words, making it easier to acquire friends.

It's important to note, however, that most of the social mechanics
that we have built into online games thus far are conducive towards
retaining strong ties. But Granovetter's research showed early on
(and Watts and Strogatz' work seemed to confirm) that it is weak
ties that really bind a scale free network together.

Remember, scale free networks are built out of clusters connecting
via bridging links. Friends lists, guilds, even player cities
(though to a lesser extent) are about encouraging strong ties, aka
clustering. And when we see guild migrating, it's mathematically a
cluster departing, because the weak tie is much easier to break.

> Currently, the costs associated with demonstrating fitness and
> establishing links are a far higher hurdle than lack of incentive
> or content.

So really, how do we reinforce weak ties? By finding friendship
mechanisms that aren't about strong ties, like guilds and friends
lists--but about weak ties, like regular customers at a shop or
tickler files for acquaintances or matchmaking services that
introduce you to subcommunities with radically differing interests.

Another mechanism that seems obvious--permitting players to belong
to multiple guilds--ideally, guilds thematized around different
interests. I'm a member of MUD-Dev and ASCAP and two writing
workshops and my company and three or four different,
non-overlapping game designer groups; in most online games, I'm a
member of one group and one group only.

>> What I find myself wondering is, if we can create explicit
>> support (or even encouragement) of multiple hubs and more
>> cross-cluster random links, will that make guilds less likely to
>> migrate?

I've said in the past that I want online games to bring different
kinds of people together, and that I like player cities precisely
because you don't entirely have a choice on whom you associate
with. That gut instinct appears to be mathematically borne out by
scale free network theory, in that both of those are avenues to more
weak ties, which in turn makes the network more robust, reducing the
diameter of the network.

-Raph

_______________________________________________
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