[MUD-Dev] [DGN] Socialization against the fun

[Eric Random]

--- HRose <hrose at tiscali.it> wrote:

> The socialization must happen in the game. Not outside it. The
> social interaction must be about the gameplay itself, not outside
> it. Downtimes are moments where the designer choose to break the
> gameplay to offer a space. This space is empty to be filled with
> socialization. Is a break for the game. I think, instead, that the
> socialization must be brought back to the gameplay. Because I'm
> sure it's able to provide a lot of *fun* Instead of hindering it.

> The players shouldn't stop to play to discuss politics or
> football. They should play the social part.

Personally, I don't view downtime, in general, as an invalid design
element, but I do believe the extent of its use could be highly
contentious.

Further, concerning forced grouping, I think it's important to
consider the actual implementation in which forced grouping is
applied. This avoids confusion between required grouping and
grouping advantages as well as problems concerning the way it is
implemented. Communal goals could be seen as another implementation
of forced grouping. I agree that these games could offer more
reasons to interact on a larger community level, the details of
which are important.

When hosting a successful gathering, one can see that socialization
within a diverse group of individuals who do not recognize each
other is not a simple emergent process. One must take deliberate
structural actions for it to occur. In a MUD, you are basically
handing out Gameboys (ie. the solo game) to each person at that
gathering, which does not make socializing any easier. You have to
provide clear advantages to socializing, and clear episodes in which
socializing is appropriate. Grouping advantages and downtime provide
these.

I would certainly agree, though, that strongly restricting
alone-time and having too much downtime could make the gathering
unpleasurable. To me, it's not the why that's the question, it's how
and to what extent.

RL topic chat is not _always_ a bad thing. They could talk about RL
topics outside the game, but they want to be in the game, and end up
talking about it there. It's also another example of how game
relationships can evolve into RL relationships. Successful
socialization could develop into RL chatter in-game. There is
certainly circumstances in which RL topic chat is not appropriate. I
would agree that steps can be taken to create more player investment
in a game's story arc and content.

You will -always- have some degree of RL topic chat in a game, as
well as some degree of boredom. I think, plainly, this breaks down
to the simple concept of diminished returns in the human pleasure
experience.  No matter how fun your game is, people will eventually
get tired of it.  The ultimate key to retention is change.

I think perhaps from your perspective, you are getting at the
following: "don't just give people time to talk, give them something
to talk about." Although, perhaps, you may be more for: "if they
have something to talk about that is exciting enough, you won't need
to give time to talk; they'll take the time." That, to me, is a
fallacy in design. That is placing the very existence of a basic
element of gameplay completely on the reliance of a vague
expectation that the majority of your player-base will follow a
narrow emergent pattern based on a specific minimal level of passion
and committment towards your game. What happens if it doesn't
emerge? If it does emerge, how long will it be sustained? Order and
organization take a lot of energy to create, and continually
requires energy to sustain. Downtime and grouping advantages lower
that energy requirement much moreso than simply having something fun
to talk about. Although all three would be best, the former allows
the possibility they may find their own fun things to talk about
without sacrificing a basic element of gameplay.

   - Eric
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev