"UNIQUE PLAYERS" Current numbber of logged in players. Multiple characters with the same IP address must be counted as one.
World
"AREAS" Current number of areas. "DBSIZE" Current number of valid universal objects. "EXITS" Current number of exits. "EXTRA DESCRIPTIONS" Current number of extra descriptions. "HELPFILES" Current number of help files. "MOBILES" Current number of unique mobiles. "MUDPROGS" Current number of mud program lines. "MUDTRIGS" Current number of mud program triggers. "OBJECTS" Current number of unique objects. "RESETS" Current number of resets. "ROOMS" Current number of unique rooms, use "0" if roomless.
Game
"ADULT MATERIAL" "0" or "1" "MULTI-CLASSING" "0" or "1" "PLAYER CITIES" "0" or "1" "PLAYER CLANS" "0" or "1" "PLAYER CRAFTING" "0" or "1" "PLAYER GUILDS" "0" or "1"
25 Mar, 2009, David Haley wrote in the 3rd comment:
Votes: 0
Crat's very good question aside, questing should also allow any combination of the options. Also, the distinction between "automated" and "integrated" is not at all clear to me.
Equipment system should say "no restrictions", not "none", which makes it sound like there is no equipment…
If DBSIZE is merely a sum of other fields, it's unclear why it exists. The reason for its existence should be made clear.
Muds are supposed to support the official variables if possible, Mud lists can support variables from both lists or make up their own, in turn Muds can decide to support extended variables for auto updating their listing.
What I want to avoid is forcing 70+ variables on Muds.
Muds are supposed to support the official variables if possible, Mud lists can support variables from both lists or make up their own, in turn Muds can decide to support extended variables for auto updating their listing.
What I want to avoid is forcing 70+ variables on Muds.
Most of the stuff in this "extended" set is almost certainly going to be used by most muds, making it de-facto core. It is pointless to separate it. It will be "forced" by the very nature of it being actually useful and used.
"DBSIZE" Current number of rooms, exits, objects, mobiles, and players. (TinyMUD term).
Why use Diku terminology in a description of a Tiny term? It's rooms, exits and things. Or better just "current number of objects" since not all Tinys are Mushen. There are no mobiles. Everything is an object.
25 Mar, 2009, David Haley wrote in the 11th comment:
Votes: 0
Surely even though internally it's "just an object", just as surely there is a distinction between things that are supposed to be NPCs and things that are supposed to be inert objects. Yeah, sure, this distinction might be invisible to the code, in which case the point is moot, but we're talking about information useful to players, not artifacts of implementation decisions.
I mean, I could implement everything, including rooms and exits, as "just objects"; would it make any sense for me to say that the concept of room or NPC is completely foreign to my game?
Surely even though internally it's "just an object", just as surely there is a distinction between things that are supposed to be NPCs and things that are supposed to be inert objects.
No there really really isn't.
David Haley said:
Yeah, sure, this distinction might be invisible to the code, in which case the point is moot, but we're talking about information useful to players, not artifacts of implementation decisions.
Users create rooms, exits and things, and often program them. And half the terms listed above should have (DikuMud term) appended as they are meaningless to other muds.
25 Mar, 2009, David Haley wrote in the 13th comment:
Votes: 0
Are you truly saying that people have zero conception of NPC vs. sword? I perfectly agree that the code might not, but that's a separate question.
MSSP world variables are pretty much what the engine perceives, not the people. Alphabetized, removed belligerent tagging, and added unique players.
25 Mar, 2009, David Haley wrote in the 15th comment:
Votes: 0
Scandum said:
MSSP world variables are pretty much what the engine perceives, not the people.
Umm. Are we writing a protocol for engines to talk to each other and compare implementation details, or for people to use on listing sites to figure out what games to take a look at?
MSSP world variables are pretty much what the engine perceives, not the people.
Umm. Are we writing a protocol for engines to talk to each other and compare implementation details, or for people to use on listing sites to figure out what games to take a look at?
All of the above, this list is inclusive, remember?
25 Mar, 2009, David Haley wrote in the 18th comment:
Votes: 0
My point was more along the lines of "why do we care about engine implementation parameters that people don't care about", when the point is to provide data for human consumption?
My point was more along the lines of "why do we care about engine implementation parameters that people don't care about", when the point is to provide data for human consumption?
Interesting.
25 Mar, 2009, Hades_Kane wrote in the 20th comment:
Votes: 0
If I have several individual players that share a network or two, and thus have the same IP, does that mean that I'm basically penalized in the total number of players based on how they choose to connect to the game?
Feel free to contribute and I'll update it with whatever the consensus is.