[MUD-Dev] wherefor in-game artists?

[Ola Fosheim Grøstad]

"Christopher Allen" <ChristopherA at skotos.net> writes:

> 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.

Players or characters, all active or both inactive and active? All
guilds, or a selection? The graph states "veteran members", not sure
what that means. It would also be interesting to know how many years
the system had been running when it was measured.

I don't really think the term "diminishing returns" is necessarily
obvious either. The more members you have, the more marketing you
get, the more members you gain...

Alternative explanations based on observations (disclaimer: I don't
have enough data and I have no real experience with UO):

  1. Powergaming guilds tend to be few and large (provided size is
  an advantage). Not all players are powergamers. Extreme
  powergamers might be less chatty on average than more social
  players...

  2. Guilds tend to actively recruit when they are hitting the
  bottom level. Hence, most guilds tend to be fairly
  small. Alternative hypothesis: 60 members is the lower limit, not
  the higher limit. (I don't know what the number represents and how
  it was measured, if it is characters, then it is very low)

  3. Some guilds merge when they get too small.

  4. Guilds can break up when they grow too fast, if there are
  alternatives. I.e. too much storming and norming for existing
  members. Hence, powerguilds can grow more as there is nowhere else
  to go... ;-) Just a deduced hypothesis, the last one.

  5. Guild chat is a very visible bottleneck.

I am actually more interested in the linear growth. That might
however be related to when the guilds were founded...?

> 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.

I assume you can compensate by having a cohesive group, strong
norms, strong group identity, etc.

> 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.

Yes, that is to be expected if they don't have more than one leader,
have insufficient filtering when recruiting, lack strong
norms/shared values etc. Or if the leader simply have a very high
need to control (which is typical for people taking those roles, I
believe). I am not saying that trust is not an issue, just pointing
out there might be alternative explanations.

> 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.

But why can't they just hang out with 2-3 people they have something
in common with?  That's how most overloaded social situations
develop.

> 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.

I think there is something fundamental about the design that I don't
grasp. :-) Are you saying that the castle is too small?

Anyway, I am not saying that there are no limits or bottlenecks. I
argue that there are no magic constants. So rather than looking for
a constant you need to look for functions, unfortunately the number
of parameters seem to be quite large when one starts to look into
it.

--
Ola - http://folk.uio.no/olag/
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev