[MUD-Dev] wherefor in-game artists?

Christopher Allen ChristopherA at skotos.net
Tue Sep 14 20:59:47 CEST 2004


"Ola Fosheim Gr=F8stad" wrote:
> "Christopher Allen" <ChristopherA at skotos.net> writes:

>> scale well. Socialization requires trust, and trust doesn't
>> scale. One of the interesting anecdotes of our experience with
>> this is that one of the limits may be the Dunbar Number

> I am very weary of these socio-biological number-games, especially
> when they are based on studies of non-human primates. It makes
> sense of animals, they belong to one primary group and are more
> dependant on instincts. Makes little less sense for modern humans
> who participates in many groups, and err... think?

> You can twist and turn these numbers and make them fit just about
> everything. Why are these numbers interesting for MUD design
> anyway?  Any uses? I've noticed that guilds tend to split up into
> main/recruit/alt guilds when they cross around 600 characters, yet
> another number... Of course, in a MUD you have a S/N ratio to take
> care of, so yes, there is an upper limit for a single guild
> chat. That is of course not limited by the number of members, but
> the number of simultanously chatting members.

> At a much lower number affiliate-type individuals may feel
> over-looked and anonymous. How many people do you need to get
> crowd behaviour?  Less than 40?  *shrug* Anyway, with enough
> empathic guild members you can probably compensate for over-sized
> guilds, or by having rules, or by making it difficult to leave,
> or...

> Other number examples:

>  Soccer: 11
>  School class: 25
>  Army-school unit: 50
>  Pop group: 4
>  Orchestra: 20-100
>  Church community: 10-1000
>  Village: 1000-2000

> There is no silver number...

There may be no silver numbers, but there are some interesting
statistics. Take a look at the UO numbers that Raph provided me that
are printed in my blog entry
http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html -- in
it you will see that a definite point of diminishing returns at
around 150; however, you will also see that most groups are around
60 large.

I do take your point that all groups are not the same -- just that
each has different behaviors.

The essential point of my blog entry is that as your groups become
larger, either the trust level has to go down and be made up by some
other factors, or you have to spend more time keeping the trust
up. As you approach 150 people in a group, maintaining that high
level of trust is very time-consuming and expensive. I've heard from
many a large guild leader who spends all of his/her time on people
issues rather then on guild goals.

If you read through the comments of that blog entry, I think you'll
find some interesting other pointers -- in particular the sizes of
typicaly mafia groups, which obviously require a lot of internal
trust to be able to going.

What has happenned with Castle Marrach is that the consensual game
mechanics of our social game require a lot of trust -- if nothing
that but that the attention you give will be returned by sufficient
attention of others to be worth your while.

As the core members of the game exceed 150-200 people (these are the
active US evening players) trust appears to break down. People feel
that that their social efforts are not being rewarded as per the
social contract. If we had more non-socializer mechanics, people
could "get away" and go do something else for a while, however, in
Castle Marrach all of the game elements and game the mechanics are
social, so they can't.

Part of the mystery of the castle is why they can't leave, so we
can't give people another "town" to establish their own trust
groups, and other methods of separation have not worked well due to
alt characters. As a result, when it gets crowded some people quit,
or start playing with a non-US timezone, and things begin to calm
down and the social contract appears to work again.

-- Christopher Allen
_______________________________________________
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