It's a matter of opinion, I think my 2nd definition of rooms as unique containers is the better one.


Guess a "ROOMLESS" option should be added?

Are two rooms with different contents any more unique than two mobs with different equipment or inventories?

And yes, I think a roomless option would be nice, either that or the ability to respond "N/A" to questions that don't make sense. Then, you just ask as many questions as you like, and if one isn't relevant, the MUD just tells you so. Easier to reply N/A than to add a flag for each question.

I'm not quite sure what you mean by "template rooms". Do you mean a standard room which is used in many places (eg copy&pasting the same room to create a large desert area)?


Merc has some rooms which share exactly the same description.


So what would be a "non-unique room" then? And what about rooms with nodrop flags?

My only concern with using "0 unique rooms" for roomless is if the same definition can also refer to a certain type of room-based mud. That's why I wanted to clarify what was intended by "unique" - because I think there is a big difference between "none of our rooms are unique" and "we don't have rooms", and it could be useful to distinguish between the two.

Perhaps in this case "unique" means as in "unique index" - because in Merc even when the descriptions and contents are identical, the memory address is not, nor usually the Vnum either. That may not fit in a lot of other places though, but that's how I view "unique".

Good point there. I guess Samson's "unique index" definition will do.

Protocol so far, with a new 'simple handshake' option, which should be easy to implement server side.

MSSP            70

MSSP_GIVE        1
MSSP_TAKE        2
MSSP_VALUE       3
MSSP_MUDVAR      4  

/* Complex handshake example */
                             
client - IAC   DO MSSP
server - IAC WILL MSSP
client - IAC   SB MSSP MSSP_GIVE MSSP_MUDVAR IAC SE
server - IAC   SB MSSP MSSP_TAKE MSSP_MUDVAR "ROOMS" MSSP_VALUE "15000" MSSP_MUDVAR "PLAYERS" MSSP_VALUE "52" MSSP_MUDVAR "ALPHA" MSSP_VALUE "1" IAC SE

/* Simple handshake example */

client - IAC DO MSSP
server - IAC SB MSSP MSSP_TAKE MSSP_MUDVAR "ROOMS" MSSP_VALUE "15000" MSSP_MUDVAR "PLAYERS" MSSP_VALUE "52" MSSP_MUDVAR "OBJECTS" MSSP_VALUE "12345" IAC SE

/*
        Official MUDVAR values:
*/

"UPTIME"             Unix time value of the startup time of the MUD.
"HOSTNAME"           Current or new hostname.
"IP"                 Current or new IP address. 
"PORT"               Current or new port number.
"CONTACT"            Email address for contacting the MUD.
"ICON"               URL to 32x32 256 color icon in bmp, gif, or jpg format.
"NAME"               Current or new name of the MUD.
"WEBSITE"            URL to MUD website.

"CODEBASE"           Name of the codebase, eg "Merc"
"PREROGATIVE"        Name of the prerogative codebase, eg "DikuMUD" or "Custom"
"LANGUAGE"           Name of the language used, eg "German" or "English"
"LOCATION"           Name of the location of the server, eg "France" or "USA"
"LAUNCHED"           Year the MUD was launched.

"GENRE"              "Adult", "Fantasy", "Historical", "Horror", "Science Fiction", "Fan Fiction"
"SUBGENRE"           "BDSM", "LASG", "Medieval Fantasy", "High Fantasy", "World War II", "Western", "Frankenstein", "Dracula", "Cyberpunk", "Post Apocalyptic", "Harry Potter", "Dragonlance", "etc"
"GAMEPLAY"           "Adventure", "Educational", "Hack and Slash", "Player versus Player", "Roleplaying", "Social", "Strategy"

"MINIMUM AGE"        Current minimum age requirement, use "0" or omit if not applicable.

"PLAYERS"            Current number of players online, if multi-playing is allowed report unique IPs instead.
"BANDWIDTH"          Current average bandwidth per month in Megabytes.

/*
        The following values should be generated at boot time, use "0" or omit if not applicable.
*/
  
"AREAS"              Current number of areas.
"HELPFILES"          Current number of help files.
"MOBILES"            Current number of unique mobiles.
"OBJECTS"            Current number of unique objects.
"ROOMS"              Current number of unique rooms.
"SCRIPTLINES"        Current number of world related script lines.
"WORLDS"             Current number of worlds.

/*
        All values are assumed to be "0" if omitted. Use "1" for yes, "0" for no.
*/

"ANSI"               Supports ANSI colors ?
"MCCP"               Supports MCCP ?
"MCP"                Supports MCP ?
"MSP"                Supports MSP ?   
"MXP"                Supports MXP ?
"PUEBLO"             Supports Pueblo ?
"VT100"              Supports VT100 interface ?
"XTERM 256 COLORS"   Supports XTERM 256 COLORS ?

"FREE TO PLAY"       Free to play ?
"PAY FOR PERKS"      Pay for perks ?

"ALPHA"              Game is in development ?
"BETA"               Game is beta testing ?  
"HIRING"             Game is hiring ?

"CLASSLESS"          Game has no classes ?
"COMBATLESS"         Game has no combat ? 
"LEVELESS"           Game has no levels ? 
"RACELESSS"          Game has no races ?  
"ROOMLESS"           Game has no rooms ?

Should some of the following values be included, and is there a glaring omission?

Extended race selection, Extended class selection, Multi-classing allowed, Free Character Creation, Quests available, Newbie Friendly, Currently Hiring Builders, Clans Offered, Player Crafting, Equipment Saved, Currently Hiring Coders, Detailed Char Creation, Player Cities, MSP2, ZMP?

I glanced at smaugfuss and implementation of the simple handshake should be trivial.

else if( iac == 2 )
      {
         iac = 0;
         if( d->inbuf[i] == ( signed char )TELOPT_COMPRESS2 )
         {
            if( d->inbuf[i - 1] == ( signed char )DO )
               compressStart( d );
            else if( d->inbuf[i - 1] == ( signed char )DONT )
               compressEnd( d );  
         }
         else if (d->inbuf[i] == ( signed char )TELOPT_MSSP && d->inbuf[i - 1] == ( signed char )DO )
         {
           mssp_report( d );
         }

Might be more consistant to have "PAY TO PLAY" and "PAY FOR PERKS".



Might be better to combine these, as you can't have both. You'd then need a third option for a game which is fully open.



Could also be "CLASSES Number of classes (0 if classless)". Could do the same for LEVELS and RACES. Also note that if it's not possible to have a room-based mud which lists itself as having "ROOMS 0", then you wouldn't need a separate option for ROOMLESS.

Those are all good suggestions. I can't think of a good word to describe a mud that is up and running.

Something like: "STATUS" -> "ALPHA" - "BETA" - "RUNNING" ?

Software release life cycle.

I would go with "live" or better yet "production" instead of "running". If need be, there could be something for "development" to be used on a dev port for instance. The "software release life cycle" doesn't fully apply because MUDs are not really released per se, at least not like software-in-a-box. I'm not even sure that "release candidate" makes sense except as an internal measure.

I don't think it's useful to be too fine-grained about the status of the code. Either it's in very heavy development and testing (alpha), or it's settled down but still being seriously tested (beta), or it's doing what most mature MUDs do and is still being developed anyway (production).

Alright, made the following changes:

"STATUS"             "ALPHA", "BETA", "LIVE"

"CLASSES"            Number of classes, use "0" if classless.
"LEVELS"             Number of levels, use "0" if leveless.  
"RACES"              Number of races, use "0" if raceless.   
"ROOMS"              Number of rooms, use "0" if roomless.

"PAY TO PLAY"        Pay to play ?
"PAY FOR PERKS"      Pay for perks ?

"HIRING BUILDERS"    Game is hiring builders ?
"HIRING CODERS"      Game is hiring coders ?

The reason I don't like "live" is that every MUD server is "live". It's kind of like asking "are you awake?" and getting the answer "no".

Also, whichever protocol ends up being implemented should specify how to answer boolean questions. Is it 0/1? Yes/no? True/false?

All boolean values are assumed to be "0" if omitted. Use "1" for yes, "0" for no.

I don't like "live" as an option either. I'd say mud directories should just ignore it if it's not either "alpha" or "beta".

Sorry, I hadn't noticed that for the booleans.

Why not just use 'production'? It's the closest thing to "everything other than alpha and beta". If people want a dev port, with unstable features, they can always call it the beta version of the next production version or whatever.

"production" would to me imply that some kind of development is going on, which more often than not isn't the case.

Thinking about it "live" isn't too bad given it's mainly a place holder to indicate that a mud isn't alpha or beta.

Production in software means that it is the version being used "for real". The "production" version versus the "development" version, for example. The wikipedia article explains this, for example. Although the article isn't always relevant to MUDs (which after all are not really on official "release cycles") it does explain what the term means in this case.
It's not that people are producing something in the sense of manufacturing: they are producing in the sense of displaying. Or, just ignore that definition and follow the standard used in industry. :smile:

http://en.wikipedia.org/wiki/Software_re...

"A live release is considered to be very stable and relatively bug-free with a quality suitable for wide distribution and use by end users."

Looks like "live" has as much going for it as "production"

I realize that, which is why I said earlier that nonetheless I feel that 'production' is a better term than 'live' even though both apply.

One could argue the majority of MUDs never get out of "beta" since they are constantly being tweaked in one way or another to maintain the interest of players and to try and attract new ones. One could even argue this is necessary in order to stay viable.

I think if the MUD is participating in the protocol (and has presumably registered with at least one MUD aggregator to do so), then it's open to the public and the status isn't relevant. If the MUD is truly buggy and no where near ready for prime time, that'll quickly be reflected in the player stats.

I think it's fair to allow MUDs to say up-front that they don't consider themselves "prime-time ready". That said, I think it's also fair to say that a MUD is "mature" enough to not consider itself beta. Yes, there is constant development – that is why the normal release cycle doesn't apply – but there is definitely a difference between active testing (beta) and active tweaking ("production", "mature", whatever).