2000Q1/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD&#45;Dev] Re: MUD&#45;Dev digest, Vol 1 #288 &#45; 9 msgs -->
<!--X-From-R13: "Re. Qng" <pngNernygvzr.arg> -->
<!--X-Date: Wed, 23 Feb 2000 19:45:47 &#45;0800 -->
<!--X-Message-Id: 200002231956.NAA69506#sullivan,realtime.net -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: E12MoLk&#45;0000bi&#45;00#kanga,nu -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: MUD-Dev digest, Vol 1 #288 - 9 msgs</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cat#realtime,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
      text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">

  <font size="+4" color="#804040">
    <strong><em>MUD-Dev<br>mailing list archive</em></strong>
  </font>
      
<br>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00463.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00464.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00464.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00463.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00462">Author</A>
&nbsp;|&nbsp;<A HREF="#00462">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00462">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: MUD-Dev digest, Vol 1 #288 - 9 msgs</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: MUD-Dev digest, Vol 1 #288 - 9 msgs</LI>
<LI><em>From</em>: "Dr. Cat" &lt;<A HREF="mailto:cat#realtime,net">cat#realtime,net</A>&gt;</LI>
<LI><em>Date</em>: Wed, 23 Feb 2000 13:56:18 -0600 (CST)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
-- Start of included mail From:  Caliban Tiresias Darklock &lt;caliban#darklock,com&gt;
&gt; "Dr. Cat" wrote:
&gt; &gt; If you're going to have a limit on your population at all, it should
&gt; &gt; be as high as possible.
&gt; 
&gt; Not necessarily. What these worlds *lack* IMHO is a good in-game
&gt; explanation of why things on different worlds can't interact. Given
&gt; that, this liability could be overcome by simply making it an expected
&gt; "feature" of the game world. 

I don't think it's "overcome", I think it's "masked".  Granted, if you're
stuck with this disadvantage you should put the best possible face on it.
But no cover story is going to change the very real facts that you might
have friends on two different servers and be forced to choose which ones
you can interact with each time you play, that the total pool of people
you might meet and the size and complexities of societies that can form is
smaller, etc. etc.

Some people might prefer to found 20 small societies rather than one big
one.  But I'd rather be making that choice deliberately rather than being
forced to by limitations in server design or implementation.  And I think
putting up walls that sometimes cut off friends from each other is
generally not good.  With a server design that can scale really well, if I
want to encourage the development of smaller societies for design
purposes, I can do it with any arbitrary set of limitations on movement
and interaction between areas, while still allowing SOME contact.  Having
no ability to provide any contact just gives me the most minimal set of
choices possible as a designer.

&gt; Distributed processing is Good. I've often toyed with the idea of
&gt; independent servers run by independent people, but with players capable
&gt; of moving between them transparently... but this creates way too many
&gt; "soft" issues that can't really be solved in software.

Distribution gooooood.  Independent operators baaaaad.  Well it's an
interesting experiment for the hobbyist mud community, but I think past
efforts have shown that there aren't really enough mud admins interested
in doing this to get a really huge set of linked worlds going, and I'm
not convinced that there's much benefit to doing so other than proving
that you can make it work.  No, what I'm interested in is a distributed
server operated by ONE person/group/company/whatever.  The purpose of
distributing the processing is to enable the mud to scale huge, with all
the machines at the same site, talking to each other through a LAN.
That's more efficient than a WAN connection, and you don't have all the
issues that arise if you have dozens of different muds trying to have some
semblance of consistency, fairness, reliable interconnection, etc. etc.
At a really large scale, you may want to have more than one cluster of
servers, such as one on each continent or some such arrangement.  At that
point, I think an approach such as Origin takes of saying the European
players are in a separate world from North American players may be the
most reasonable solution.  Though I am a bit curious about the pros and
cons of saying "You can visit this other kingdom, but you'll experience
more lag when you're there".  Certainly Furcadia has people meeting and
making friends from all over the world, which is an important step in
reducing the amount of prejudice and war in the world.  It's harder to
hate and kill a group of people if you actually know some of them
personally!  I also have a very nice dolphin sculpture that was given to
me by a young lady in Austin who's now engaged to a fellow in England that
she met on Furcadia.  So I guess it's good for something.

&gt; &gt; Mind you, I should admit that voice chat changes all the math, and that I
&gt; &gt; think voice chat will be ubiquitous and necessary to be a major
&gt; &gt; communications app or multiplayer game in the future.  
&gt; 
&gt; I would disagree here, because I think it would be rather difficult to
&gt; maintain a role that way. I can "talk like a girl" all I want, but if
&gt; you heard my voice there is positively no way you'd take me for anything
&gt; but a big middle-aged man. (I may only be thirty, but I *sound* a lot
&gt; older and bigger.) Most people don't play games to be themselves, and
&gt; when I was much younger I adored the way I could act like an adult on a
&gt; text-only medium...

Most people play Bridge, Monopoly, Trivial Pursuit, Backgammon, Hearts,
and various other games entirely for the purpose of being themselves and
socializing with other people who are also being themselves.  Roleplaying
is still a small minority of the game-playing that the human species
involves itself in, though I think that percentage will continue to grow.

More to the point, playing games is only part of what people play MUDs
for, and I think that percentage will decrease as MUDs/VR/whatever reaches
more and more of the general public.

Even MORE to the point though, most people don't talk to far-away people
to roleplay OR to play any type of non-roleplaying-oriented game either.
They do it to stay in touch, to make new friends, to socialize.  And they
want to do it an awful lot more than the stuff people on this list
generally talk about.

Computer and video games and arcade games are somewhere in the vicinity of
a 10 billion dollar a year industry.  Television, last I heard, was
pulling in around 40 billion a year.  Local and long distance telephone
services that year, added together, amounted to about 160 billion.  That's
a pretty hefty hunk of change.

The demand for one-on-one conversation with somebody that you already know
will probably be provided by things like phones, and a next-generation
successor to ICQ.  (I'd sure like to be the person that writes that - I
think somebody could well become a billionaire if they grab that market
with a really good product.)  For meeting new people, and for group
activities - online parties, chat rooms, and yes, even roleplaying, people
will do their talking through something that has mud-like aspects to it in
many cases.  If a few thousand or a few million people don't like not
being able to change their voice, the billions of people wanting
voice-enabled apps will still dictate that such apps will exist, and will
be the dominant form of muds.  When I say "Major communications app" I'm
not talking about things as big as my current favorite text mud, which
gets 500 players online at once, I'm talking about things like ICQ, which
is passing out new account numbers in the sixty-million range now.  Yes,
text muds will still exist, just as radio still exists.  Though I doubt
they'll ever be as popular as radio, which has a very easy user interface
that most of the six billion people on this planet can handle pretty well.
Quite apart from the huge number of people that can't read written text on
this earth, typing is a really massive barrier to entry.  Of those six
billion people, how many of them can type at all?  How many of the ones
that can have to hunt and peck with excruciating slowness?  That covers
most of the earth's population already.  Of the minority that remain,
there's the ones that consider typing to be an unpleasant but necessary
nuisance - they'd hardly consider it their preferred form of chatting if
they could talk instead.  Then there's those that don't mind it so much,
but it's taking a noticable amount of mental effort to perform the task,
and if they're talking on the phone it's easier, they're more relaxed, and
putting more of their attention and energy into conversing rather than a
task that requires both physical and mental effort.

&gt; It's interesting and
&gt; instructive to be someone else for a while, but video and voice would
&gt; doom all of that... so I think the benefits of text channels far
&gt; outweigh the liabilities. 

People were playing face to face D&amp;D before the first multiplayer online
dungeon games popped up on systems like Plato (and later the first text
muds - yes I know, history will always remember MUD as the "first", but
being obsessed with computing-history and gaming-history I'm compelled to
keep gratuitously mentioning that there were earlier games).  I suspect
that the majority of roleplaying is still done face to face, sitting
around a table.  There's also people that do live action roleplaying
games, getting around the voice and the "simulated video" of seeing the
people you're playing with, somehow.

Yes, people who prefer all text will continue to use it as they do now.
Some people will continue roleplaying on IRC even, rather than using a
more full-featured MUD.  I asked a friend recently, someone who fell in
love over IRC, why he doesn't prefer having "sets and costumes" on a
social mud instead.  He explained that he uses IRC because it's simple,
and the MUCK I use was too much work to figure out.  I think for most
people ease of use is far more important than having the maximum amount of
expressive power.  Though I'm working hard on trying to develop tools that
will alow people to be more expressive while still being pretty darn easy.
It's a tough thing to accomplish.

-- Start of included mail From:  Ola Fosheim [Gr_stad] &lt;olag#ifi,uio.no&gt;
&gt; Are you by "dead reckoning" suggesting implementing all the physics in
&gt; the client?

In a word, no.  I'm a big fan of server-based logic for security.
What I'm thinking of is a solution where the clients are continuing
to estimate the positions of things based on the last known information,
and the server is modeling not only the authoritative model, but the dead
reckoning models of the various clients (or at least the parts that
matter, the close-together people/vehicles/whatever).  Decisions on when
to send a packet aren't based on "every N clock ticks", but on looking at
the amount of error the server expects the client to have, and whether
it's over the acceptable threshhold - or is expected to be over that
threshhold by one typical ping-time in the future.

For example, a server might think "This player thinks this rival player's
hovercraft is 3 inches to the left of where it really is, and that's ok.
I'm expecting I can usually get packets to him in 400 milliseconds, and by
then he'll be off by about 5 inches, and that's ok too.  But in two
seconds he'll cross over my threshhold of 12 inches inaccuracy in
positioning of rival hovercrafts, so I'd better send him a packet in 1.6
seconds or sooner".

You can mess around with using assumptions closer to worst-case latency
rather than average, assuming the inaccuracy is based not on the very
latest packet you sent to the client but the one before, to be more
resistant to dropped packets, etc.  Anyway, the Battletech and Red Planet
games at Virtual World Entertainment were moved to a scheme like this,
and my friend that coded it told me it dropped the bandwidth requirements
between the cockpits far more than he was expecting.  Often they could
wait five seconds or more between sending packets, rather than sending a
constant stream of "Hey, this guy is almost exactly where you already
think he is" information.  This was of a little benefit on a LAN that was
perhaps already getting a bit saturated - and provided lower latency for
the packets that really mattered, rather than potentially getting ethernet
collisions with unimportant data.  But it also dropped the bandwidth down
to where they could very easily run games between centers in different
cities over their private WAN, without requiring a great deal of bandwidth
either.

I do think they may have been running a peer to peer architecture in their
case, by the way, I don't remember for sure.  But there are cases where
that architecture may be more appropriate than client/server - in their
centers all the hardware was owned and controlled by them, so hacked
client software wasn't an issue.


&gt; Competing with the big telecoms is not a good idea. They have the
&gt; skills, the technology, the money and own the infrastructure.

You could have said the same of the first companies to offer cellular
phones, companies like MCI and Sprint that started competing with AT&amp;T in
the long distance market, or ICQ (which lets you send a voice message to
another user after all, and whose founders sold the company to AOL for
over three hundred million dollars).  I'd be very content to carve out a
hundred million dollar obscure niche in a hundred billion dollar market,
or to start developing a technology way ahead of the big telecoms and then
sell the company to them a few years later when they decide they want to
get in, and that it's a better strategy to buy out a company than to
develop the technology from scratch.  I can accept "I'm too busy with
other innovations" or "I wouldn't enjoy doing this" as excuses for me to
stay out of a field, but "there are huge companies in it" isn't going to
necessarily persuade me there's nothing I can accomplish.  (In some
industries it would, sure.  You wouldn't see me trying to break into any
commodity industries like food or toothpaste or toilet paper, I have no
business being there.)

-- Start of included mail From:  "Justin Rogers" &lt;justin#mlstoday,com&gt;

&gt;     Text to speech is becoming quite a technology nowadays and speech
&gt; to
&gt; text is even more inevitable than text to speech is.  So the option
&gt; could be
&gt; inline to transfer the speech to text for command purposes and also to
&gt; use
&gt; that generated text to be put through a text to speech processor where
&gt; the
&gt; user can choose his voice.

Text to speech and speech to text both make errors.  A regular speech to
speech conversation like a telephone call introduces no errors, usually.
For the vast majoroity of users, I don't think there are any benefits to
going through speech to text and/or text to speech when chatting with
other humans that would outweigh the downside of the added errors.  Also
you lose all the nuances of inflection and mood that a person puts into
their voice.  Not to mention, when two people are *not* roleplaying and
want to hear each other exactly as they sound, there's sentimental value
in the fact that it sounds exactly like them.

I'm not sure how prevalent text to speech and speech to text will be for
various other applications.  But for chat it'll be pretty rare, I'm
confident, if anyone uses it that way at all.

-- Start of included mail From:  "John Bertoglio" &lt;jb#pulsepoll,com&gt;

&gt; Message:  8
&gt; Reply-To:  &lt;jb#pulsepoll,com&gt;
&gt; To:  &lt;mud-dev#kanga,nu&gt;
&gt; Subject:  RE: [MUD-Dev] voice vs. text
&gt; Date:  Sun, 20 Feb 2000 16:58:53 -0800
&gt; Importance:  Normal
&gt; Reply-To:  mud-dev#kanga,nu

[Charset iso-8859-1 unsupported, filtering to ASCII...]
&gt; 
&gt; &gt; Matthew Mihaly
&gt; &gt; Sent: Sunday, February 20, 2000 11:44 AM
&gt; 
&gt; &gt;
&gt; &lt;&lt;much cut&gt;&gt;
&gt; 
&gt; &gt;I don't know that much about the
&gt; &gt; technology, but it seems to me that the client could have some sort of
&gt; &gt; capacity to alter the sound of your voice, no?
&gt; 
&gt; In the early renditions this will be an included "feature" because of the
&gt; low quality of sound. But it will quickly get better. Bear in mind that a
&gt; 6-8k bandwidth is all that is required for voice quality sound. My son would
&gt; happily give up 8k of our 768k pipe to be able to talk to his teammates in
&gt; Counterstrike. Being digital, it would be easy to make everyone sound like
&gt; James Earl Jones with preprocessing done by the client.

Someone already mentioned Voxware &amp; the fact that they've experimented
with Voice Fonts - they're the leader in that as far as I know, and they
may well have decided not to pursue it any more.  I will just add that
Microsoft bought out Battlecom - <A  HREF="http://www.battlecom.com">http://www.battlecom.com</A> - and will be
building it into DirectX 8.  So there'll be more voice-chat enabled apps
springing up like crazy, and people like me can make them without
re-inventing or licensing the technology.  And Battlecom had licensed
Voxware, so Microsoft may well be inheriting that and providing Voxware
based chat capability in Windows as standard.  I don't know for sure if
they will though, and I don't know if Battlecom's license included Voice
Fonts.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
*-------------------------------------------**  <A  HREF="http://www.bga.com/furcadia">http://www.bga.com/furcadia</A>
    Furcadia - a graphic mud for PCs!       ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*



_______________________________________________
MUD-Dev maillist  -  MUD-Dev#kanga,nu
<A  HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>

</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00463.html">[MUD-Dev] Distribution</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00464.html">[MUD-Dev] (fwd) Re: Commercial-use Restrictions on Code Bases (was: help me find 100% free  graphical mud)</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00464.html">[MUD-Dev] (fwd) Re: Commercial-use Restrictions on Code Bases (was: help me find 100% free  graphical mud)</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00463.html">[MUD-Dev] Distribution</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00462"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00462"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>RE: [MUD-Dev] [Off-topic] GDC-2000</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00478" HREF="msg00478.html">RE: [MUD-Dev] [Off-topic] GDC-2000</A></strong>, 
Justin Lockshaw <a href="mailto:jlockshaw#signio,com">jlockshaw#signio,com</a>, Sat 26 Feb 2000, 18:38 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00471" HREF="msg00471.html">[MUD-Dev] player persistence</A></strong>, 
Matthew Mihaly <a href="mailto:diablo#best,com">diablo#best,com</a>, Fri 25 Feb 2000, 06:15 GMT
<LI><strong><A NAME="00465" HREF="msg00465.html">[MUD-Dev] (fwd) ADMIN: "A Classification Of Muds" [was 'In defence of stock muds...']</A></strong>, 
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Thu 24 Feb 2000, 03:54 GMT
<LI><strong><A NAME="00464" HREF="msg00464.html">[MUD-Dev] (fwd) Re: Commercial-use Restrictions on Code Bases (was: help me find 100% free  graphical mud)</A></strong>, 
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Thu 24 Feb 2000, 03:50 GMT
<LI><strong><A NAME="00462" HREF="msg00462.html">[MUD-Dev] Re: MUD-Dev digest, Vol 1 #288 - 9 msgs</A></strong>, 
Dr. Cat <a href="mailto:cat#realtime,net">cat#realtime,net</a>, Thu 24 Feb 2000, 03:45 GMT
<LI><strong><A NAME="00463" HREF="msg00463.html">[MUD-Dev] Distribution</A></strong>, 
Geir Harald Hansen <a href="mailto:geirhans#ifi,uio.no">geirhans#ifi,uio.no</a>, Thu 24 Feb 2000, 03:45 GMT
<LI><strong><A NAME="00459" HREF="msg00459.html">RE: [MUD-Dev] Next gen MUD wishlist</A></strong>, 
Sellers, Michael <a href="mailto:MSellers#maxis,com">MSellers#maxis,com</a>, Wed 23 Feb 2000, 18:53 GMT
<UL>
<LI><strong><A NAME="00460" HREF="msg00460.html">RE: [MUD-Dev] Next gen MUD wishlist</A></strong>, 
adam <a href="mailto:adam#treyarch,com">adam#treyarch,com</a>, Thu 24 Feb 2000, 03:45 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00454" HREF="msg00454.html">[MUD-Dev] Newbies</A></strong>, 
Johan J Ingles-le Nobel <a href="mailto:xvf61#dial,pipex.com">xvf61#dial,pipex.com</a>, Tue 22 Feb 2000, 22:56 GMT
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>