[MUD-Dev] On socialization and convenience

[John Buehler]

Raph Koster writes:
>> From: John Buehler

>> As far as I'm concerned, there's no need for architected downtime
>> periods in order to encourage socialization.

> Obviously, I still disagree. What I will agree with is that the
> downtimes can be made much smaller if you support a faster means
> of communication; and I'd say that this is a universal
> principle. You can encourage more communication in any game by
> either a) slowing the pace of the game or b) speeding up the
> communication facilities. It's a simple mathematical equation. You
> can either make the window bigger or the throughput greater.

While you have suggested that you're after more than a straight hack
and slash style game, it seems that you are restricting your design
space to fairly intensely engaging gameplay.  In a game that relies
on intensity in order to entertain (retain?) the players, I agree
that downtime periods need to be architected in.  In such a world, I
would guess that downtime/socialization should comprise about 30% of
time played.  But consider that I don't LIKE intense games because
they don't permit me to socialize about what we're doing.  They're
TOO intense.  If I had my druthers, I'd prefer a game where we can
socialize just about all the time, but that spikes of intensity
occur where we all shut up because we're paying attention to the
SHORT TERM goal that we're facing.  Once that goal is resolved, we
can go back to being fairly casual, doing this or that, and always
on the lookout for the next intense situation that might arise.

There is a genre of game, probably not unlike The Sims Online, that
will permit players to do interesting things in a large population
setting that doesn't involve intensely engaging gameplay.  In such a
game, architected downtimes will not be necessary.  Architected
'spiketimes' will be.

>> What we need is to move socialization to a separate game
>> 'channel'.  This could be done with players talking to each
>> other, or with characters talking to each other.  In the case of
>> players talking, provide low quality audio through that broadband
>> connection.  In the case of characters talking, use
>> speech-to-text on input and text-to-speech on output.  Do the
>> same with the NPCs.  Impractical with current technologies?
>> Probably.  This is why I started with offering a simple
>> observation.  I don't see a 'solution' with current technologies.

> It's not entirely impractical. Cybertown, for example, uses the
> text-to-speech stuff.

It's the speech-to-text that's the nasty part.  Continuous speech
recognition still has a ways to go.  I've played with selections
from both sides of the path of STT and TTS.  It can certainly be
done, but I have no idea if players would tolerate the result for
long.

Cybertown is fairly limited, using a single voice for all
participants.  I noticed that I still read along with the TTS voice
because the TTS voice wasn't all that distinct.  I think we need
another generational advance (or two) before TTS and STT are ready
for primetime.

JB

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