Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
449 lines (282 sloc) 12.7 KB
c.allen@lancs.ac.uk (port 4206)
-------------------------------
Features: basic color, decent communication (say, shout, tell, emote), little
administrative features (users, shutdown), online coding (new commands, but
lacking security), no online creation, no objects, some player customization
(descriptions), persistence (players save, created commands save), mudftp
Stability: strange things happen with too long lines on SAY, using certain
characters locks up the session, problems handling broken connections to
users, names are not checked for special characters such as .. resulting in a
security hole.
Maintainability
Well-formatted documentation (12 pages) in postscript format.
New rooms can be by editing room.dat file
Zen room can be expanded with new nouns/mantras
Technology
Low CPU usage, medium (4MB) memory usage -- mostly because of the TCL
interpreter.
borlak@home.com
---------------
Features:
basic communication (global, personal), logging, players
save, encrypted passwords
Stability:
tends to deadlock, characters can appear multiple times on who list, using
/tell on a non-existing character seems to send the tell to oneself, dropping
link causes strange results for others, doesn't use SO_REUSEADDR resulting
in long wait times after the MUD goes down before it can go up again
Maintainability:
No tricks were used to reduce code size, some comments. (5k)
Technology
Code has certain MERC features (e.g. nanny). Low CPU usage, low memory usage
(716k). Otherwise standard C.
benwhite@senet.com.au
---------------------
Features:
basic communication (global, local), no color, no administrative features. No
linkdead handling (dropping link quits the player), excellent tactical combat
system, some informational commands (who), no player customization, no online
building coding, comes with a 18-room world, great player documentation,
command abbreviation.
Stability
All input truncated at 128 characters, unusual characters input
handled correctly. Otherwise no apparent bugs!
Technology
Low CPU usage, low memory usage (480k), some comments in the code. Lacks
buffering however, sends one character at a time taking up many system
calls. C.
Maintainability:
Several macros, tight on spaces but readable code. Decent amount of
comments. No design documentation. New spells could be fairly easily added. (10k)
ari@lusis.org
-------------
Features:
basic communication (local, emote), no color, some administrative features
(can make other players admins, disconnect them, heal them, teleport around
but no logging), no linkdead handling (dropping link quits the player but at
least others see what happened), basic rooms with named exists, no objects, no
NPCs, primitive manual combat (can hit others and cause damage but there is no
delay on how often you can attack), good online room creation (create/destroy
rooms, link them together and modify descriptions). Sparse
documentation. Contains a rather large and relatively well-described world (6
kilobytes of the source are used for this). No quit command, can only drop
link. No persistence.
Stability:
Nothing obvious outright crashes the server. Input is not checked for length
however and lines beyond 1024 bytes will overflow the input buffer. No
checking of player names. Few quirks (e.g. you can see your own exit/leave
messages).
Maintainability:
No comments in the source, no documentation describing the
design/implementation. Regardless, the code is not too hard to follow. New
rooms could be added by modifying the code and recompiling the server. (2k)
Technology:
C++, STL. Lots of fixed-size buffers rather than dynamically allocated ones
(e.g. "char d[9999];" in the "Room" class). Low CPU usage, low (724k RSS)
memory usage.
blane@adoniystems.co.uk
-----------------------
Features:
basic communication (say, emote, shout), basic combat, aggressive and moving
NPCs, basic objects (can be picked up, dropped, wielded and offered to the
gods in the temple), no color, little administrative features (MUD can be
shutdown but anyone can do it), no linkdead handling (characters losing link
disappear and can seemingly even escape combat that way), basic rooms with
standard compass exits as well as in and out (though these directions seem to
be unused), persistent (players and their score as well as all existing NPCs
and objects save) -- however only if they game is successfully shut down.
Stability:
Long input lines apparently interpreted as multiple commands. Crashed once
with segmentation fault unexplainably in the middle of combat.
Maintainability:
Uses macros to save space, unfortunately in lowercase making code harder to
read. Some comments. Since it's persistent (and even saves the rooms), it
could probably be easily expanded with a full OLC. (3k)
Technology:
C++. 100% CPU usage, low memory usage (412k RSS)
cryptic@spacemail.com
---------------------
Features:
basic communication (local, global), rooms with number-based exists, no
persistence, randomly-generated world, some online building (can change room
titles / descriptions), no administrative features, no persistence,
tea. Interesting time-based multi-player puzzle.
Stability:
No crashes. No major problems.
Maintainability:
No code documentation, sparse comments. Room names/descriptions can be
changed.
Technology:
Plain C++. Low CPU usage, low memory usage (536k RSS).
drveg@pacbell.net
-----------------
Features:
primitive communication (say), no combat/NPCS/objects, minimal color (bold)
no administrative functions, online building (create rooms, link them, edit
description when creating a room), no linkdead handling (people in the room
are notified when you quit though). Rooms created are persistent.
Stability:
No crashes were encountered. Sending large amount of data to the MUD then
later dropping link seemed to trigger a strange error condition. Commands are
in all-uppercase, everything which isn't a command is sent as a say to the
room, which can be a bit embarrassing.
Maintainability:
No code documentation but lots of comments. ADA is also highly readable even
for one not familiar with it.
Technology:
ADA, using a freely available socket library. Low memory usage (732k RSS), low
CPU usage.
icecube@ihug.co.nz
------------------
Features:
primitive communication (say), some administrative functions (make admins),
online coding (provides a bare LP-like system), mudftp, highly persistent
Stability:
No major problems.
Maintainability:
Lots of comments, but somewhat overeager text substitution to save
space. Sparse high-level documentation considering the complexity of the system.
Technology:
Python. Complex OO framework, automatic persistence.
brebionf@club-internet.fr
-------------------------
Features:
basic communication (say), inert NPCs, full color, full-screen rogue-like
map!, few non-working object, no administrative features, randomly generated
world, no online creation, no linkdead handling, no persistence, no combat
Stability:
Multiple players can connect with the same name. One player dropping link
caused the MUD to segfault.
Maintainability:
All functions have comments. There's lots of player documentation as well as a
verbose description of design decisions and considerations available. (20k+)
Technology:
Python with a C module. Low CPU usage, medium memory usage (2200k
RSS). Several compressed external data files.
kaptaink@austin.rr.com
----------------------
Features:
Primitive communication (say), little administrative functions (shutdown),
rooms with cardinal exits. No online coding/building, no linkdead handling.
Written only in a few days just before the deadline, the code doesn't take
full advantage of the 16k limit -- it's only 12312 bytes after spaces etc. are stripped.
Stability:
No problems observed. The network code is somewhat suboptimal (e.g. writes 0
bytes to each socket at each pulse), throws away extra input if it received
multiple lines in one read.
Maintainability:
Few comments, but a good amount of design documentation explaining the event
system in-depth (11k)
Technology:
Python. Implements a interesting though bare-bones event system. Medium memory
usage (1400k RSS)
kavir@kavir.org
-----------------
Features:
Basic combat, interesting stat system, excellent player documentation, basic
communication commands (SAY, CHAT, EMOTE), basic information (WHO, SCORE,
COMMANDS), basic administrative commands (SHUTDOWN), no linkdead handling,
players are persistent. No rooms, objects.
Stability:
Network code ignores multiple lines in one packet.
Maintainability:
Uses modified Hungarian notation for naming variables. Well-formatted,
extremely well-commented (though a bit over the top in places). Good
documentation (24k)
Technology:
C.
ksb@amber.org.uk
----------------
Features:
medium world, with actual room descriptions. No player documentation. NPCs
that can be fought. Rooms with the cardinal and diagonal exits. Basic combat
system (KILL, CONSIDER, FLEE) XP gain and advancement possible. Primitive
communication (SAY). No online building/coding.
Stability:
No problems found.
Maintainability:
Little documentation, almost no comments. Uses many two-letter macros, rather
terse source code. Sometimes macros are not even semantically complete
(e.g. a macro that expands to "sprintf(text,").
Technology:
C
hanelyp@calweb.com
------------------
Features:
Basic communication (SAY), sparse user documentation lists available commands,
no admin commands, no OLC/OLB, rooms with named exits, persistent. Basic
combat.
Stability:
Seemed unreliable, when multiple players connected commands such as GO started failing.
Maintainability:
Some comments. Basic documentation of the design.
Technology:
Perl. Very unusual yet interesting, file-based database system and
multi-process design.
mykael@vianet.net.au
--------------------
Features:
Good documentation of features. Decent linkdead handling (can reconnect to
existing characters). Good communication features (SAY, TELL, GOSSIP, EMOTE,
user-creatable souls (socials)). Rooms have arbitrarily named exits. Online
creation of rooms, objects. Objects that can be picked up (and entered!). Fully
persistent (thanks to Java).
Stability:
There were problems saving the world (an exception was thrown). This is
possibly due to me using a different version of the 1.2 JRE than the author.
Maintainability:
Good expansion possibilities (new rooms, objects, socials), decent amount of
comments, clear code.
Technology: Java. Large memory usage(4400k RSS, because of JRE), low CPU
usage.
quzah@hotmail.com
-----------------
Features:
primitive communication (SAY only), basic information (WHO), basic
administration (SHUTDOWN, available to anyone). No player documentation.
Stability:
Newlines are not stripped when the string inputted is given to the SAY
command, resulting in strange output.
Maintainability:
Extreme usage of macros. On the other hand, decently commented. No design
documentation.
Technology:
C. Uses 100% CPU time, unless compiled with -DNAPZ (which seems to be
undocumented).
telford@triode.net.au
---------------------
Features:
true outdoors (not room based!) with landmarks and overhead mapping,
auto-generated world, dynamically generated descriptions, decent communication
(SAY, SHOUT, EMOTE), primitive combat, some administrative commands restricted
to one account, online building (not working in the usual way because there
are no rooms) sufficient player documentation, good informational commands
(WHO, FACE/ENTRY can change your room description/who information), player
passwords, world and players are persistent.
Stability: No problems observed.
Maintainability: Good design documentation, large amounts of comments. Some
usage of macros
Technology:
C. Creates a large database file the the world. Small memory usage (892k RSS),
low CPU usage (after the first boot where a world is auto-generated).
xholan@abandoned.org
--------------------
Features:
Tradewars-like space exploration!, space combat featuring torpedoes, mines,
trading system. Decent player documentation. Auto-generated
universe. Color. Primitive communication (RADIO -- global channel)
Stability: Throws away multiple input lines sent in one packet.
Maintainability: No design documentation, sparse comments. Still, code is readable.
Technology: Python.
Other notes:
Interesting idea and execution, but lacks play balance.
zac@intertex.net
----------------
Features:
basic communication (EMOTE, SAY, TELL). Rooms, but no exits. There seems to be
a lot of functionality that is planned, or half-implemented and commented out.
Stability:
Somewhat unstable, e.g. SAY and GOTO cause an uncaught exception.
Logging in as an already existing user after restarting causes crash.
Maintainability: Sparsely commented. Short variable/function names.
Technology: Python.