[MUD-Dev] Re: META: What are you looking for in this list?

[Hal Black]

Dual reply here.  First for Raph's issues:

> I am somewhat curious, because I know that there are a lot of people on
> the list who just listen but do not post much. I was wondering about
> those people, and what they are interested in seeing on the list.

For me, I am still digging through the 10,000 posts or so in the archive to
see if any of my concerns have been discussed, as well as reading the current
posts.

Also, it is has been rather remarkable lately.  As I was starting to write the
client-server architecture part, I thought "Hmm, how do I deal with this
blocking I/O."  And at that very time, the same thread popped up unprompted!
This happened a couple more times on other topics as well, the most startling
was the mention of the book "Permutation City" - the only book on my bookshelf
that I haven't read after finishing a book the night before, and not only that,
a book that my girlfriend selected at random to purchase.  Freaky.  And yes,
it is very good and seems pertinent so far.  8')

> How many of you are from a Diku background, like me? And might be

I have an LP background.

> interested in stuff that is codebase specific? How many find that stuff
> anathema and think it should be avoided at all costs? How many think the

I personally am not interested in any codebase-specific stuff (but language-
specific stuff is good).  I also don't think it is anathema, I can choose not
to read the thread pretty easily.

On the other hand, I really enjoy hearing the anecdotes about what people
have tried on their muds in a general sense.  The experiments with UO and
M59 and the reactions by players give me a lot of insight.  I think that is
an invaluable part of the list, because anyone here can find and read the
volumes on technical topics and make a fine program, but what makes this list
special is these GAME DESIGN issues that you just have to learn from
experience.  Namely, what makes a game fun for players, and what affects do
game design decisions have on the player culture.  The greatest resource we
have to draw upon is the experience of each-other (IMHO).  8')

> list is too theoretical, or feel intimidated by the frequent posters and
> by the volume of past history and discussions that seems to be required
> knowledge in order to participate?

I like the technical topics.  There is a lot of application-oriented
information here that is very useful to me.

I am a bit intimidated.  I am a duffer in a world of professionals.  Several
list members make successful muds for a living - I just do it in my spare time
for fun and I don't have anything to show for it (yet).  That won't keep me
from throwing my hat in, though.  I just try to be very succinct in my posts.

> -Raph

Now JC's...

On Tue, Sep 22, 1998 at 02:31:19PM -0700, J C Lawrence wrote:
> 
> Writing as list owner:
[...]
> 
>   In a telephone call today, Raph raised the question of the purpose
> of the list: educational or research?  Translation: Is the purpose
> of the list to bring the rest of the field up to the current state
> of the art, or is it to advance the state of the art?  The two are
> of course related, but they are also different.  
> 
> It can be awfully exciting and interesting to work on the fringes,
> pushing the art out even further.  The problem is that we loose the
> people still in StockMUDWorld who then have no idea what we are
> talking about, why it is important, or even if it is interesting.
> In essence this is the problem of the isolation of the ivory tower
> (remember Prince Hal).
> 
>   There's even a third possible purpose ouside of education and
> research: documenting the current state of the field.  For many of
> us writing networking code, a mini byte-coded language, algorithmic
> simulations, or whatever is no longer a concern.  Its old hat, we've
> done it a few dozen times and can do it nearly in our sleep.
> Similarly, some of us are quite expert in the softer sides of MUDs,
> in running heavy RP games, cummunity growing, etc.  

  I think this issue ties in tightly with the education issue.  If there
is a means for people to read good, organized articles about the state of
the art, as opposed to reading threads and trying to follow the issue,
then I think this does a lot for bringing everyone up to speed (myself
included).  I would love to see something like a MUD 101 textbook 
(electronic, of course), which would be self-contained - given knowledge of
procedural and object-oriented programming.  I know it would certainly be a
good resource for me.  More on this later.
  One of the problems I have in following some of this list threads is that
often discussions start in the middle.  Someone has done some work on one
of their pet projects, has encountered a stumbling block, and appeals to the
list for help.  Some very good technical discussion ensues.  Doubtless many
members of the list have gone through the same stages as the questioner, so
they immediately know the context.  However, I can see how a beginner such as
myself would have trouble even understanding the question, or where to look
to start learning about the topic.  Now, I don't mean to ask people to
give the whole history of their mud before asking a question.  If we had a
resource such as the mud textbook, newbies could do a search on it and have
centralized access to problem definition, foreground, basic discussion,
research areas, and resources.
  Anyway, I realize this is a lot to ask.  I have been wary of asking it
because I don't believe it is my place to ask for such a resource.  Certainly,
the veterans don't owe any such thing to us newbies.  But, since JC has raised
the issue, I will speak in favor of the value such a resource from a newbie's
point of view.  I guess the question remains to determine the quality of the
mixture of the list as to educational vs. research.  I certainly don't want to
lose the research portion.

>   What is *YOUR* purpose and interest in this list?  What would you
> really like to get out of the list?  What would you like to do with
> the list?  Some I know are here purely for the technical aspects of
> server development (an area that has received little coverage on the
> list of late): how to write performant networking code, how to tune
> and design their data model, what the concerns and techniques are in
> writing a MUD programming language ala LP/MOO/MUF/ColdC/etc.  Others
> I know are interested in hack'n'slash game design, RP, real virtual
> world creation, etc. etc, etc, etc.

I am interested in all of the above, plus many other topics, especially some
of the more grand issues such as creating and controlling stable economic,
ecological, cultural, and even virtual-physical systems.

  My main purpose and interest in this list is stimulation of ideas.  More than
a few times I have been reading the archives or the active list and someone
says something that I'd never even thought of that makes me just sit and stare
for about and hour while my mind reels with the possibilities.  For instance,
the rollback of the database by player actions for time travel.  Wow.  Perhaps
I could have the Robert Jordanesque baelfire into my mud that would smite
out not only a player, but any impacts that they have had in recent history.
Amazing.  And it goes on.
  Another benefit I find is when someone says something succinctly or
puts a label on something, which in turn brings together a lot of loose ideas
that I had been thinking about previously into a coherent whole.
  Also, because I am actually buildng a mud from scratch like many here have
done, I am interested in a lot of the implementation issues: what are ways
to do the I/O, the database, and the client rendering of character sensations?
  Another primary interest when I get the skeleton of my mud running is to
take part in some of the research, to try out some new things and share what
I've found.

In any case, while on the subject of a textbook, I would like to propose
a layout that I think would be useful.  It is inspired by the canonical FAQ,
but not strictly so.  I believe the great failing of the school and university
systems is that they aren't sufficiently motivated.  Therefore, I propose a
motivation-solution format to bring the technical issues closer to the thought
process of the aspirant game designer.

Some examples of motivations.

Motivation: I would like a player to connect to my mud through the Internet.
Solution: Use sockets.  (Brief description and resource links follow)

Motivation: I would like my mud to connect multiple clients to a single game
            engine.
Solution: (insert solution here)

Motivation: I would like to implement a system such that players reaction
            times and network latency aren't strong drivers to their
            characters' success or failure.
Solution: Implement a turn based system.  All commands from players in some
          given time segment are processed as if they were requested
          simultaneously.  Then the game engine arbitrates based on character
          attributes and resource conflicts to determine the results.  Cons:
          This can produce fringe effects, when one user types something one
	  millisecond before the break, and the next user types something one
          millisecond after the break.  (more discussion follows)

Motivation:  I would like to minimize this fringe effect
Solution: (...)
Motivation: I would like users to be able to give NPC's orders in the form of
            programs.  
Solution: (...)
Motivation: I need to make sure the game engine is secure from the player
            programs.
Solution: (...)

(etc)
Of course we can have multiple solutions to some questions, with some
discussion on which option is suitable under which circumstances.

Anyway, there's my wish list and $0.02.  8')