10 Mar, 2010, Scandum wrote in the 1st comment:
Votes: 0
I was gonna start a codebase related quiz thread, then I figured it'd be cool to create a comparison list of codebases, much like the comparison list of mud clients I created a while ago.

All suggestions are welcome, suggested areas of discussion:

1) What protocols are notable? (MXP, MCCP, ANSI, VT100, etc.)

2) What features are notable? (wilderness, OLC, etc.)

3) Is the programming language enough to determine what platforms the codebase will run on, or is more information needed?

4) Other than programming language, internal scripting Language, protocol support, and feature support, are there other tables that would be a worthwhile addition?

A basic entry is available here:

http://www.mudpedia.org/wiki/Comparison_...

Please try to avoid adding codebases that have no unusual features until the feature set is more or less complete, as it's annoying to update a large list of muds whenever a new field is added.
10 Mar, 2010, David Haley wrote in the 2nd comment:
Votes: 0
Maybe we should create the Mud Codebase Status Protocol so that we can automatically adjust as new fields are added.
10 Mar, 2010, flumpy wrote in the 3rd comment:
Votes: 0
.. Implemented with a hashed pointer grid?

Srsly nice idea tho
10 Mar, 2010, Kayle wrote in the 4th comment:
Votes: 0
Scandum said:
list of mud clients


This is wrong. At least as far as zMUD is concerned. zMUD has it's own client specific scripting language, and supports VB scripts as well.
11 Mar, 2010, Scandum wrote in the 5th comment:
Votes: 0
Kayle said:
This is wrong. At least as far as zMUD is concerned. zMUD has it's own client specific scripting language, and supports VB scripts as well.

Nope, the free zMud uses TinTin++ code that was directly translated to Pascal back in 1995, including all the quirks. As far as I know the lastest zMud uses a souped of version of that code. It's definitely a lot more advanced, but still derived.
11 Mar, 2010, ATT_Turan wrote in the 6th comment:
Votes: 0
I know some derivative codebases have it added, are there a sufficiently significant number of stock codebases with IMC support to add that to the protocol support list? For that matter, will you be accepting derivative codebases for the list, or only stock? If you're taking derivatives, there could be a plethora of features people might want to see represented, such as guild/clan support, randomly generated dungeons, levels/levelless…do you have a preconception of what you want included in that list? Primarily features that are significant from a coding/building perspective, or gameplay features also?
11 Mar, 2010, Scandum wrote in the 7th comment:
Votes: 0
Derivatives aren't a problem as long as there are significant changes. I guess InterMUD can be added as a supported protocol, I removed MMCP (Mud Master Chat Protocol) from the list, and InterMUD fills up that slot nicely; supporting muds can fill in IMC, I3, or whatever else they support.

The problem with classes, races, and levels is that they can be implemented poorly, but I guess that goes for any feature. But I envision the list being most significant for programmers. I definitely want to add a table covering licensing.

Clan support sounds good, same for Random Dungeons, maybe call them Instances? using the right terms is always tricky. Guess I should go over the MSSP fields and use the most obvious stuff.
11 Mar, 2010, David Haley wrote in the 8th comment:
Votes: 0
I think part of the problem with MSSP was that the meaning of fields is often unclear, so if you wish to repeat the same adventure it would be wise to spend more time defining what exactly things mean, and actually trying to make them general, if you seek to have any meaningful comparison of disparate codebases. It's relatively easy to compare things of the same family, but once you cross families life gets complicated.

Anyhow, instances mean something different than random dungeons, namely that the dungeon is not shared across all players. Many instanced dungeons are in fact not random at all.
11 Mar, 2010, Runter wrote in the 9th comment:
Votes: 0
Quote
Anyhow, instances mean something different than random dungeons, namely that the dungeon is not shared across all players. Many instanced dungeons are in fact not random at all.


Yes. Indeed something can be randomly generated once and forever statically part of a game. That in no way would be an instance yet still a random dungeon.

Also, it's possible to instance random dungeons. I toyed around with the idea at one point of random generation of a dungeon once a day and instancing the same dungeon off for every player who attempts (at a limit of one attempt per person) it as a sort of competition.
14 Mar, 2010, Scandum wrote in the 10th comment:
Votes: 0
So I have:

Clans, Copyover, Crafting, Dynamic Descriptions, Head-up Display, Instancing, Mapper, Noteboard, Online Creation, Random Dungeons, Questing, Wilderness

Further suggestions welcome.
14 Mar, 2010, David Haley wrote in the 11th comment:
Votes: 0
You should define what your features mean. For example I have no idea what a "head-up display" is in the context of a MUD. "Questing" could mean any number of things. etc.
14 Mar, 2010, Deimos wrote in the 12th comment:
Votes: 0
David Haley said:
For example I have no idea what a "head-up display" is in the context of a MUD.

I could be wrong, but I would imagine he's talking about VT100 magic. I can't think of anything else that would apply.
14 Mar, 2010, David Haley wrote in the 13th comment:
Votes: 0
Well, that's my best guess too. But it's still unclear what exactly that means, and therefore unclear what a codebase needs to qualify. When comparing features, I think it should be pretty clear what those features mean. For example, do MUSHclient's miniwindows count as HUDs? What about prompts? etc.

EDIT: in retrospect, "I have no idea" was hyperbolic… sorry about that.
14 Mar, 2010, Runter wrote in the 14th comment:
Votes: 0
Deimos said:
David Haley said:
For example I have no idea what a "head-up display" is in the context of a MUD.

I could be wrong, but I would imagine he's talking about VT100 magic. I can't think of anything else that would apply.


Or any visual queues in any form.

edit: (In regards to your position in the game.)
14 Mar, 2010, Deimos wrote in the 15th comment:
Votes: 0
I would argue that anything implemented client-side is, by definition, not really a feature of a codebase (referencing the MUSHclient mini-windows comment), but rather a feature of the cooperation between server/client. It might seem pedantic, but I think it's a very important distinction, since you're then restricting codebase features to certain players.
14 Mar, 2010, David Haley wrote in the 16th comment:
Votes: 0
On the one hand I agree with you, on the other hand such features require server-side cooperation. Without wanting to get into too much detail, it depends on what exactly is meant by a codebase feature.
15 Mar, 2010, Scandum wrote in the 17th comment:
Votes: 0
It's tricky cause we normally don't categorize these things. I'll remove the heads-up display field as it's currently covered by MUDs utilizing the VT100 protocol.

Questing is tricky as in ROM muds it's a quest master, and in others build in support for area based quests.

I'd prefer the big features that easily easily reach 5.000 lines like OLC, wilderness, and mapping engines.
15 Mar, 2010, jurdendurden wrote in the 18th comment:
Votes: 0
As far as questing goes, you could always branch out a bit and go with 'stock/snippet questing', or 'custom questing', or maybe even take it further. Example here being: basic questing, linear questing, multiple quests at once (someone please insert better name.. :P), etc.. In fact there are really many variations of your garden variety questing that could apply here.

Edit: My custom quest code is pretty large… not sure exactly but it's pretty thorough, and I'm sure it's at least 2k lines of code if not more. This wouldn't count in your 5k rule? Even though it supports multiple quests at once, up to 10 types of quests, different rewards, level restrictions, guild quests, different places to receive/turn in, etc…?
15 Mar, 2010, KaVir wrote in the 19th comment:
Votes: 0
Scandum said:
So I have:

Clans, Copyover, Crafting, Dynamic Descriptions, Head-up Display, Instancing, Mapper, Noteboard, Online Creation, Random Dungeons, Questing, Wilderness

Further suggestions welcome.

Out of curiousity, are there actually any public codebases with dynamic descriptions, instancing, random dungeons or a mapper (is that an ASCII map?)? I know there are numerous muds with these features, and most of them are also available in snippet form, but off-hand I can't think of any codebases that have them as stock. I'm sure there must be some, but perhaps it would be worth listing at least one codebase for each proposed feature?

Regarding copyover: Some codebases (eg LPmud) don't require any reboots to introduce changes. Might it be better to use some umbrella term that also includes such muds? Maybe something to indicate that changes can be added on-the-fly without disconnecting the players.

How about:

Multiclassing: Could include anything from AckMUD (players gain levels separately in each of the five classes) to GodWars Deluxe (players can choose a 'hybrid' class that combines the abilities of two regular classes).

Races: Diku and Merc didn't have races, for example, but some later derivatives (such as ROM and Smaug) introduced them.

Level-less: GodWars-style.

Customisable classes: ROM-style.

ANSI colour: Many people take colour for granted these days, and it's easy enough to add in snippet form, but older codebases such as Diku and Merc don't support it by default.

Equipment saving: The original LPmuds didn't save eq. You could also make this a three-choice option perhaps, with "No", "Rent" (Diku/Circle) and "Yes".
16 Mar, 2010, Scandum wrote in the 20th comment:
Votes: 0
Emud has a mapper for builders. I think LPMuds can instance (not 100% sure). And if left blank it might make it more tempting for someone to release a MUD with said feature as a way to stand out.

Changing the term Copyover would be nice, not sure of a better term.

ANSI is covered in the Protocol table. I considered adding races, classes, etc, but I think the list will be more useful if it includes significant features, rather than stuff most people can add?

Player run cities come to mind, real economies, and player controlled ships. Not fully sure what the best way to name those fields would be: Player run Cities, Economy, Player Ships?
0.0/26