<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: Just a bit of musing -->
<!--X-From-R13: "Qnegre F Eubpx" <pgfbNhzvnpf.hzq.rqh> -->
<!--X-Date: from babe.globecomm.net [207.51.48.8] by mx4.ibm.net id 857395352.23710-1 Mon Mar 3 13:22:32 1997 -->
<!--X-Message-Id: 199703031327.NAA17484#lupa,umiacs.umd.edu -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: Just a bit of musing</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:ctso#umiacs,umd.edu">
</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>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00044.html">Previous</a>
| <a href="msg00046.html">Next</a>
]
Thread:
[ <a href="msg00042.html">Previous</a>
| <a href="msg00046.html">Next</a>
]
Index:
[ <A HREF="author.html#00045">Author</A>
| <A HREF="#00045">Date</A>
| <A HREF="thread.html#00045">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: Just a bit of musing</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI>
<LI><em>Subject</em>: Re: Just a bit of musing</LI>
<LI><em>From</em>: "Carter T Shock" <<A HREF="mailto:ctso#umiacs,umd.edu">ctso#umiacs,umd.edu</A>></LI>
<LI><em>Date</em>: Mon, 3 Mar 1997 08:27:26 -0500</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
> In the past, when I've been "lurking", reading everyones contributions,
there
> seems to be a lot of emphasis on making things more realistic (unique, I
> suppose, which is good), but it seems to me what is often overlooked is
the
> "fun" factor. It's a game.
Amen brother. Spent 3 years as an imp trying to convince the players of
that little fact... but that's another story altogether :)
Anyhow, as I see it, the discussion hasn't necessarily been about making
things real. The way most muds store their database (cuz that's what we're
really talking here folks) of rooms, critters, and objects is atrocious.
The code tends to be littered with for loops that iterate thru lists (room
lists, player lists, etc etc). I, among others, feel this is a Bad Thing
(tip o' the hat to coder@).
Most of the tricks,structures, algorithms being proposed have the primary
advantage of letting you store lots of data in reasonably efficient ways.
One of the side effects of this is that you can add more realistic physics
to your mud if you desire. It isn't a requirement. Now... let's start
another thread while we're here :)
I posit that, in general, command interpreters for muds are Bad Things. The
proposal runs sorta like this:
The command interface to a mud can be viewed as a context free grammar. As
such, one should be able to whip up a command interpreter with lex/yacc.
I've started on it at least a dozen times but never managed to quite
finish. Is this worthwhile? Thoughts?
While I'm at it, let's try another pet peeve. Most mud codes I've run into
run as a unified process. That is to say, there is one huge executable that
does everything. One nasty side-effect is that any socket-related problems
can bring the game to a grinding halt (in particular, a user connects on
the mother socket and ends up in the queue. The OS then steps thru the
mother socket's queue and creates new sockets for everybody it finds there.
If one of the connections has died on the queue, you go into a linger state
regardless of the socket settings while the OS tries to find the socket it
thought was on the queue). The suggestion goes like this:
run the game as a daemon. run another process to host the mother socket.
For each connection on mom, spawn a new process that acts as a comm link
between the user and the daemon. We'll call this intermediary a proxy.
The proxy and daemon communicate through shared memory or semaphores or
some such. Advantages:
the proxy <-> daemon link conform to a single interface scheme
the proxy <-> user link can conform to several protocols... say one for
text-based users, another for binary messages etc.
if the user has link troubles, or is idle or whatever, it's the proxy that
hangs.
the proxy-daemon comm method is thru semaphores/shared memory. daemon
writes updates to a shared segment that is read-only to all proxies. daemon
reads new info from one segment per proxy. If the proxy has trouble and the
segment isn't updated, the daemon skips it. Look ma... user A's troubles
don't cascade and screw user B. Thoughts?
-Todd (who's now had some coffee... way too much coffee)
PS: one more advantage to splitting up the mud process. One huge process is
_much_ more likely to get swapped out by the OS than several "small"
processes. Extra bonus points if you're lucky enough to run on a
multi-processor. Who wants to open the can of worms called "MUDs in a
distributed processing environment"?
</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="msg00044.html">Issues from the digests and Wout's list</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00046.html">Re: Just a bit of musing</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00042.html">Re: Just a bit of musing</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00046.html">Re: Just a bit of musing</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00045"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00045"><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: Just a bit of musing</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00037" HREF="msg00037.html">Re: Just a bit of musing</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 03 Mar 1997, 02:47 GMT
</LI>
<LI><strong><A NAME="00038" HREF="msg00038.html">Re: Just a bit of musing</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 03 Mar 1997, 03:05 GMT
</LI>
<LI><strong><A NAME="00039" HREF="msg00039.html">Re: Just a bit of musing</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 03 Mar 1997, 03:13 GMT
</LI>
<LI><strong><A NAME="00042" HREF="msg00042.html">Re: Just a bit of musing</A></strong>,
Dmitri Kondratiev <a href="mailto:dima#paragraph,com">dima#paragraph,com</a>, Mon 03 Mar 1997, 09:36 GMT
</LI>
<LI><strong><A NAME="00045" HREF="msg00045.html">Re: Just a bit of musing</A></strong>,
Carter T Shock <a href="mailto:ctso#umiacs,umd.edu">ctso#umiacs,umd.edu</a>, Mon 03 Mar 1997, 21:22 GMT
</LI>
<LI><strong><A NAME="00046" HREF="msg00046.html">Re: Just a bit of musing</A></strong>,
Wout Mertens <a href="mailto:Wout.Mertens#rug,ac.be">Wout.Mertens#rug,ac.be</a>, Mon 03 Mar 1997, 22:51 GMT
</LI>
<LI><strong><A NAME="00049" HREF="msg00049.html">Re: Just a bit of musing</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Tue 04 Mar 1997, 23:49 GMT
</LI>
<LI><strong><A NAME="00050" HREF="msg00050.html">Re: Just a bit of musing</A></strong>,
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Wed 05 Mar 1997, 08:53 GMT
</LI>
<LI><strong><A NAME="00051" HREF="msg00051.html">Re: Just a bit of musing</A></strong>,
Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 05 Mar 1997, 14:31 GMT
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>