LP-mud needs this
Lars Aronsson
First, an enormous THANK YOU to Lars Pensjoe <la...@myab.se> who hacked
LP-mud. You did a wonderful work and we hope you keep doing it. LP-mud
as it is today has many posibilities and the "concept" contains even
more. For those of you who did not know, LP-mud is a mud in which all
objects (persons, robots, giants, rooms, ...) are defined by wizards
in an interpreted, C-like language.
At Lysator, we discovered LP-mud just a few days ago, but we are quite
active players. You will see the IDs aronsson (me), paul, and linus
(and maybe some more guys) running around in there. Myself, I am a
humble "utter novice", really more interested in programming than in
killing people. Thanks also to Johan Andersson of CD who hinted me
about the existence of LP-mud. We are fortunate to run this
telnet-accessed mud from within Sweden, the Americans seem to face
problems with the somewhat unstable Transatlantic link.
Lars, (nice name, btw) you announced that you will make the sources
available for FTP. We are looking forward to this. If we find enough
disk, we expect to have a copy of LP-mud running here in Linkoping.
Lysator has its own Sun workstations, just like Chalmers Dataforening
(cd.chalmers.se, where LP-mud is run). As some people here also are
active programmers, I suppose you will receive some support in further
extending of the software,
At the moment, you are probably reading some of the reports I made
using the BUG and IDEA commands in LP-mud. Below are some suggestions
that need more discussion, and that I hope you and the rest of the
readers will find interesting and useful.
DISCUSSION
Is alt.mud a good forum for discussions on LP-mud? Is there an
international interest or should we create a newsgroup swnet.mud for
discussions inside Sweden only?
SPEED
LP-mud is slow today. This, I have heard, is partly due to some
malloc-free bug, which I hope will be corrected. But, as I was told,
the sponsz machine running LP-mud is also the file (NFS) server for
your network. Since the core of LP-mud is less than 3 MByte, I suppose
it could run on a diskless client (Sun 3/50 4 MByte RAM) without too
much swapping. This might increase speed. At least it seems worth a
try. The issue of speed is also addressed by some other suggestions
below.
USER INTERFACE
Today, LP-mud has no user interface whatsoever. You just use telnet
sponsz.cd.chalmers.se 2000. After a command has completed, you receive
a new prompt, but the prompt, as well as the command line you are just
typing, gets blurred with lots of asynchronous text messages. If
there are more advanced interfaces used at chalmers, please let us
know.
Something like the IRC (Internet Relay Chat, a multi-user talk) user
client would seem ideal to me. You get a command line at the bottom of
the screen and the rest of the screen is used as a scrolling region
for all messages. Looks a little like the emacs text editor.
Actually, anyone could hack this. Someone here might if they get the
time.
USER AGENT PROTOCOL
Today, all communication with LP-mud is done with text commands and
text messages. This forces the server to do a lot of text parsing and
it also consumes network bandwidth. Assigning numbers to the commands
and the objects in a place looked at would constitute a simple
protocol, that I think would add speed.
The question of a protocol is more complicated than in other
applications since the available commands vary from one place and one
time to another. However, the user agent (client process) need not
know more than the user does today. Thus, a localcmd command would
retrive the entire translation table, and perhaps some syntax rules,
for the current position. This might not be the exact way in which to
do it, but i hope you get the idea. All spelling errors would be
detected in the user agent and not put load on the server.
COMPILING OBJECTS
Lars Pensjoe just told us in an article that all objects in LP-mud are
written in a C-like language. Lars, is this code interpreted every
time I issue a command? If it does not already, LP-mud ought to use
some byte-compiling (lexical analysis once and for all) or
semi-compiling (compiling to a FORTH-like language) technique. As in
GNU-emacs, one could have a command-to-function mapping, where some
functions (common commands) are hardcoded, without loss of
flexibility.
NETWORKING
The ultimate hack is a mud in which the servers (worlds) are
transparently distributed over a (real-world wide) network. In LP-mud
this could be achieved by wizards if the C-like language (has it got a
name?) were to allow manipulation of sockets. Some of this magic also
requires part or whole of a castle/robot to be an independent UNIX
process (or maybe a light-weight subprocess of the server).
A castle (extension to the world built by a wizard) could then include
a magic room that sends all commands to another server. It might also
listen on a port for incoming calls, thus providing a separate entry
to the world. Further, a castle might communicate with other programs
(such as mail, text editors, or news readers). This is what I mean by
stating the concepts of LP-mud (full programmability) containing more
possibilities than at first expected.
Lars Aronsson
Aron...@Lysator.LiU.SE
Lysator Computer Club at Linkoping University, Sweden
On the internet via workstations donated by Sun Microsystems
Lars Pensj|
>Is alt.mud a good forum for discussions on LP-mud? Is there an
>international interest or should we create a newsgroup swnet.mud for
>discussions inside Sweden only?
There are many players from outside Sweden (most), and as the source some day
will be public, I guess we can have discussions here in this group.
>SPEED
>
>LP-mud is slow today. This, I have heard, is partly due to some
>malloc-free bug, which I hope will be corrected.
Most of the allocated memory are freed when it should be. The real problem
is that the game requires quite a lot of memory (at least 3 Mbyte), and
the used computer only has 4 Mbyte. The machine is also used as a NFS server,
mail server (sendmail) and yp server etc. So everytime someone sends a mail
locally, the game will start swapping out.
>Today, LP-mud has no user interface whatsoever. You just use telnet
>sponsz.cd.chalmers.se 2000. After a command has completed, you receive
>a new prompt, but the prompt, as well as the command line you are just
>typing, gets blurred with lots of asynchronous text messages.
There are interfaces, but I don't know how far they have advanced.
If you play Tinymud, you have the same problem. There is Tinytalk,
which is not immediately adaptable, because LPmud has a prompt that can
change anytime.
>Today, all communication with LP-mud is done with text commands and
>text messages. This forces the server to do a lot of text parsing and
>it also consumes network bandwidth. Assigning numbers to the commands
>and the objects in a place looked at would constitute a simple
>protocol, that I think would add speed.
I have done extensive profiling, and know quite well where the bottlenecks
are. To send a number instead of a short string as a command would not
decrease the network bandwidth, because there would only be a few number
of bytes less, and the message protocol overhead is probably much bigger
for each command anyway.
>The question of a protocol is more complicated than in other
>applications since the available commands vary from one place and one
>time to another. However, the user agent (client process) need not
>know more than the user does today. Thus, a localcmd command would
>retrive the entire translation table, and perhaps some syntax rules,
>for the current position.
The 'localcmd' command was a debug command, and is now only available to
wizards. The puzzle solving is much to easy if you know all commands that
are available to you. And an automatic call of 'loalcmd' would add much
more overhead to the communication.
The time required to parse the player commands is very small. To be honest,
I was worried about this in the beginning, but every command parsing results
in just about 50 strcmp() of strings in a linked list. This is fast.
It is probably more expensive to maintain this linked list, because it is
changed every time something is changed in the environment to the player.
But not even this maintenance shows up in the profiling.
There has been 30 concurrent players on the game, and as long as it didn't
start to swap, speed was no problem.
However, most data structures are searched in a linear way, and the time
required is thus quadratic. So in the future, some tables has to be hashed, etc.
Most time today is spent inside either the language evaluator, or
inside the parser (yacc/lex). Lex was replaced with flex, and some speedup
was measured.
>Lars Pensjoe just told us in an article that all objects in LP-mud are
>written in a C-like language. Lars, is this code interpreted every
>time I issue a command?
Yes, it is.
>If it does not already, LP-mud ought to use
>some byte-compiling (lexical analysis once and for all) or
>semi-compiling (compiling to a FORTH-like language) technique.
It already does that. The interpreted program is represented in a tree.
>The ultimate hack is a mud in which the servers (worlds) are
>transparently distributed over a (real-world wide) network.
Portals will be implemented some time in the future. When a player moves
over a portal, he can even get his things with him, even if they are not
defined at the destination. The object program tree and current variables
are simply sent over, and thus an exact copy is created.
It is another question if this should be allowed, as it can be badly abused.
I am currently concentrating on two things:
1. Get the game stable. It dumps now and then.
2. Make more effective use of memory. Objects not referenced for a while
are "swapped out" (written to a file), and loaded at next reference.
Is there any interest on the net to gain access to the source by ftp ?
If someone else than me tracked bugs, the development would speed up much.
Extensive knowledge of C is probably required.
The current version (1.3.1) dumps about once every 4:th hour, with
8 players active (on avarage).
I will also be away from development in maj and june, so no version will
be made available at that time. I may come "home" shortly during this period.
--
Lars Pensj|
la...@myab.se
James Seidman
>...We are fortunate to run this
>telnet-accessed mud from within Sweden, the Americans seem to face
>problems with the somewhat unstable Transatlantic link.
Actually, it's been much better as of late. I heard that the cable had been
broken, causing most of the problems, but has now been fixed. I actually
played a continuous 4-hour session without link-dying once!
>Lars, (nice name, btw) you announced that you will make the sources
>available for FTP. We are looking forward to this. If we find enough
>disk, we expect to have a copy of LP-mud running here in Linkoping.
I'm quite confident that someone in America will want to start one up too.
>Is alt.mud a good forum for discussions on LP-mud? Is there an
>international interest or should we create a newsgroup swnet.mud for
>discussions inside Sweden only?
I really don't think the discussions should be limited to Sweden. If the
people I've run into when playing are any indiciation, there are *many*
Americans on LPmud, and probably lots of people from Norway, Finland, U.K.,
etc. (Of course, the people I run into may be an atypical cross-section,
since I usually play around 04:00 - 08:00 MET.)
>SPEED
>[stuff deleted]
Too technical for me...
>USER INTERFACE
>Today, LP-mud has no user interface whatsoever. You just use telnet
>sponsz.cd.chalmers.se 2000. After a command has completed, you receive
>a new prompt, but the prompt, as well as the command line you are just
>typing, gets blurred with lots of asynchronous text messages. If
>there are more advanced interfaces used at chalmers, please let us
>know.
I've tried using tinytalk which is a client designed for use with tinyMUD.
It works very well except for the fact that it doesn't echo what the server
sends until it receives a newline. Therefore such prompts as "Enter your
name:" and "Password" and ">" don't appear until *after* you type your
response. Probably the code could be hacked to make it handle LPmud very
nicely, though, and it already has all sorts of neat features such as
macros, keeping your command line separate from incoming messages, etc.
>USER AGENT PROTOCOL
>
>Today, all communication with LP-mud is done with text commands and
>text messages. This forces the server to do a lot of text parsing and
>it also consumes network bandwidth. Assigning numbers to the commands
>and the objects in a place looked at would constitute a simple
>protocol, that I think would add speed.
I think you're looking for trouble here. Now you're assuming that everyone
is going to have access to some LPmud-specific client program. Since people
could be using a variety of operating systems (VMS, OS/2, Aegis, etc.) they
might not have access to a client program which they can run. Perhaps if it
was an optional thing, where either some client *or* a simple telent could
be used, then it would make sense. Especially if you hawk it as giving
better performance from those slow trans-Atlantic Internet lines. :-)
>The question of a protocol is more complicated than in other
>applications since the available commands vary from one place and one
>time to another. However, the user agent (client process) need not
>know more than the user does today. Thus, a localcmd command would
>retrive the entire translation table, and perhaps some syntax rules,
>for the current position...
I'm not sure how much of a performance bonus you would actually see,
though. As you point out, the commands vary from place to place. I don't
think very many commands are consistent enough to be easily tokenized.
Also, I'm not sure what you mean by "retrieve the entire translation
table." Sending this table over the net each time a person enters a room is
obviously not efficient. And since new rooms (with corresponding new
commands) are being added all the time, you can't just have it built in to
the program.
>NETWORKING
>The ultimate hack is a mud in which the servers (worlds) are
>transparently distributed over a (real-world wide) network. In LP-mud
>this could be achieved by wizards if the C-like language (has it got a
>name?) were to allow manipulation of sockets. Some of this magic also
>requires part or whole of a castle/robot to be an independent UNIX
>process (or maybe a light-weight subprocess of the server).
While this is great for a game such as tinyMUD, I question its use in a
competitive game like LPmud. How would you handle transferring over the
person and his current score, state, etc.? (And how would you keep people
from figuring out the protocol and cheating by sending false stats?) Also,
several items might not exist on the other system. For example, if the
target system does not have "fish" and the associated code, it won't know
what happens when you eat it (or even that you can eat it).
--
Jim Seidman, Harvey Mudd College, Claremont, CA 91711. (714) 621-8000 x2026
"It doesn't need to work. They'll be paralyzed laughing at me."
- The Doctor, "Shada"
Kim Flowers
>Is there any interest on the net to gain access to the source by ftp ?
YES! MAKE THE SOURCE AVAILABLE!
Christopher Hassell
(Lars, I hope you are listening :-)
I have found that ALOT ALOT ALOT of compression-speed can be produced with THE
MERELY FORMATTED COMPRESSION OF ENGLISH <er... or any language that is used>
This means that if you could make a front-end program which would allow for
this kind of compression (VERY VERY SIMPLE IN MOST STANDARD UNIX's) then the
speed could be even doubled or tripled.
That is merely one idea <technically: tokenizing english words for optimal
compression> and several others I've been interested in doing for other types
of serial communication, are:
automagic specialized compression for the data-type transmitted :
(english text / graphics / you name it).
simple error check packets <irritating.. but not too hard>
speed-monitoring to give stats on the speed of the net (check
consistency.. to retry for another connection?) (possible use of
datagrams instead of actual IP-links <more adept for network
delays> )
local manipulable buffers for "cacheing" of lengths of text to REuse..
like for object descriptions or other things. (for normal BBSing
.. this could allow ANSI-sequences to be used too.. for
remotely-run windows/images etc..) HIGH SPEED UP POSSIBLE!
automagic means of retaining/using sections of text or descriptions...
or even long textfiles or other offered "images"... or even
letters (doubly compressed?)
And anything beyond these are improvements to the User-Interface <which should
stay separate and less standardized> or to the way a user sees the database.
Helps for the User-Interface, however, might be a way to store and recall
specific descriptions... so that the User-Interface can have them up.. or can
put them somewhere other than just a single screen / window etc....
As you might guess... this should be only implemented as an option which very
likely only translates normal output from the system. There should be few
changes necessary inside the program... except possibly to do good
text-"cache"ing so that stuff is re-used well, instead of retransmitted through
the Bottlenet (the Internet).
This sort of thing seems very possible ... and it is HIGHLY practical.
I would be willing to even <gasp... shreik... faint> PROGRAM the sucker with
some help from Lars or anyone else who knows the code.
I've wanted to see how well this sucker can work.. given a decent amount of
text to put over systems. But I've always needed some sort of testing ground.
Besides that.. this could make longer messages useful and practical too.
What say eh? I'll be busy but I always answer mail.
### C>H> ### { uunet!rutgers!sunybcs , ncar , nbires } !boulder!tramp!hassell