FUSS is hardly bare essentials, in fact it's not even close. Socketmud is bare essentials… circleMUD is a lot closer to bare essentials than FUSS as well. tbaMUD is also probably a lot closer to bare essentials than FUSS (though a lot less bare than the now very-outdated circleMUD).

Here's some size figures of all 4 codebases uncompressed which should show exactly how far off they are from being 'bare essentials' (I am not including the world of any of the 4 codebases in any of these figures).

SocketMUD: 160 KB
circleMUD-3.1: 3.32 MB
tbaMUD-3.56: 4.21 MB
SMAUGFUSS: 4.99 MB

Here's the same 4 codebases with areas and nothing removed:

SocketMUD: 160 KB
circleMUD-3.1: 3.85 MB
SMAUGFUSS: 7.52 MB
tbaMUD-3.56: 15.3 MB

Again, that depends on what you're considering "bare essentials". If all you want is the socket code and some basic char_data type support, only SocketMUD can fit that definition. Smaug, Circle, Merc, Rom, whatever you want, none of them are "bare essentials" for a codebase. They all have things that were added on top of the basics to provide more to work with.

I will readily grant that Smaug in general is feature rich. It comes with a lot more than most codebases. It always has. FUSS only added the usual stuff everyone adds anyway, on top of the bugfixes for Smaug. Any Smaug derivative is going to feel heavy. It's the nature of the beast though. Everything evolves, and someday we'll look back and think about how lean things like FUSS and tbaMUD are compared to whatever is current at the time. Provided we haven't all been eaten or something.

I don't want to be eaten :P

On a serious note, I'm not at all trying to say FUSS should be bare essentials or bashing it for being the largest of the four (not including areas anyway, tbaMUD comes with a freaking massive world,(12,029 rooms; 4,311 objects; 3,612 mobiles; 315 shops and 1,393 DG Scripts (think mobprogs, but more flexible)) something I personally don't care for), so much as showing the difference in size between it and what truly is just the 'bare necessities' and therefore only what is essential.

I find it kind of odd to speak of "bare essentials" as nothing more than networking code and nominal connection handling. A MUD certainly needs just a little bit more than networking code to even start to be an interesting place to play…

Perhaps a better term would be "foundation" or "framework" or "common ground", but implying that the necessities are no more than networking seems like stretching it to me.

Well, there's a fundamental difference between bare essentials for a mud with a players, and bare essentials for a mud in development.

While I can certainly see your perspective, Fizban, I'm in David's camp on this one. To me, the term, "bare essentials", means a bit more than what comes stock in SocketMUD. I'll readily grant that if you want to write your own codebase but need/want a basic foundation to build on, SocketMUD is the way to go, and that, as Samson said, Smaug, Circle, Merc, and Rom are all beyond strictly bare essentials too. But maybe the term that should be getting used in this particular case isn't really that one.

I suppose that there's a quick way to solve the dilemma of what constitutes a "stock" MUD. As was mentioned earlier, one can't really legitimately claim a MUD isn't stock anymore if all they have done is "trivial" modifications - changing the greeting, installing a few snippets, renaming a bunch of classes etc. I think most of us are in agreement with that. A non-trivial modification might constitute changing a major component of the codebase in a major way, say more than 50% difference. An example of this might be converting the stock level-based class system to a leveless skill-based system or converting the "automatic" combat system to a manual one. An alternative method might be to add to a currently existing system. An example of this might be to add lua-based scripting to compliment or replace mprogs or to write a custom quest system.

This is fine and dandy for determining what modifications are trivial and what are not, but how does one determine whether a MUD is stock or not? Well, this determination might be split out into two parts - the code and the world. There are many MUDs that have completely original worlds, e.g. areas that are written from scratch and have an underlying theme that has nothing to do with the packaged stock areas. In most of these cases, the stock areas are all but completely removed, save for those that are integral to the functionality of the game (limbo.are, gods.are, help.are). One can effectively have an original world without ever touching the code. That's one of the selling points of SMAUG, for example. Advanced OLC (advanced compared to it's predecessors and similar codebases) allows this to be so.

There are varying degrees of claims that can be made here. I think a great deal of MUD listing sites have this part down in their descriptive ratings of how your world is built - Completely original, mostly original, mostly stock and so forth.

The second portion as we discussed in the opening statement is the code.

With these two ideas in mind, how much needs to be changed in order to claim that a MUD is no longer stock? Well, the answer is none of it. It's quite apparent (if you don't believe me, look at a lot of the muds listed on TMC that claim originality and dig through them, you'll see what I mean) that many MUDs can claim originality and there is no real way to prove it unless the actual code is examined. Ultimately, it's all about advertising. It may look the same, but might function completely differently under the hood.

People will claim what they want and it's a waste of time to prove their claims. For the most part, it's either blatantly obvious that a MUD is no longer stock, or it's not. There are probably many MUDs out there right on the border of obviousness, and ultimately it's up to the owners to decide whether or not they want to claim it as anything other than what it was originally.

With this in mind, DRM is quite obviously it's own codebase and no longer stock. Work has been done to retain the "Smaugish" feel to for gameplay's sake, but almost everything has been restructured. Major systems have been vastly changed, new systems have been added, some old systems have been removed. Hell, the code itself isn't even written like SMAUG anymore.

By using a simple line count utility (there are many available) I came up with the following statsitics:

Stock SMAUG:

[exodus@mud.drmultiverse.com ~]$ ./lines ~/dist/src/

—————————————-
Total Lines: 134314
Actual Code: 85033 (0.000000)
Directives:  2200
Whitespace:  11703
Comments:    35378

DRM Dev code:

[exodus@mud.drmultiverse.com ~]$ ./lines ~/cport/src/

—————————————-
Total Lines: 199920
Actual Code: 133565 (0.000000)
Directives:  2379
Whitespace:  22156
Comments:    41820

This shows roughly a 60% addition of actual code.

Difference:

[exodus@mud.drmultiverse.com ~]$ diff -bB ~/dist/src/ ~/cport/src/ > diff.txt
[exodus@mud.drmultiverse.com ~]$ wc -l diff.txt
190452 diff.txt

224,331 190452 (1) lines of code that are different from the original, excluding adding or deleting blank lines or whitespaces. (SMAUG code formatting is horrendous) as well as files in DRM code that don't exist in stock SMAUG.

I would guess that that based on these figures (please note that the actual numbers will vary depending on the method and utilities used, your mileage may vary) there are 134314 lines in stock SMAUG and DRM has 190452 different lines so it seems to be safe to say that every line was changed in some way or another on top of any additions that were made.

Using this, I surmised that the codebase was "stock" up until about a third of the MUD had been altered, at which point it became a true derivative (though this can be argued, since technically changing even one line constitutes derivative work) and after more than half the MUD had been altered, it was no longer just a derivative and could then be construed as it's own codebase.

Keep in mind that these assumptions are merely my opinion. Depending on context of the changes, as little as a quarter of the MUD might be altered to break free of the "stock" status. Changes to some systems are more visible than others.

If I had to guess the totals for all the changes and additions, I'd guess that DRM is about 65% different from out-of-the-box SMAUG. I hope to go as high as 80% one day. One must be careful here though, because I know some of you out there have MUDs that may have started out as SMAUG or something similar, but they are definitely not SMAUG anymore and more than likely have lost the "smaugish" feel that I spoke of.

(1) Edited for actual figures. The original number includes modules that do not exist in stock SMAUG. –Exo

Now that was the sort of answer I was looking for. How to tell when your MUD could be considered a true derivative. I'd say 60% addition is a pretty good point where you can say that you're not stock, just because there's so much new code and changes. So, 60% folks. Make it a new standard.

It does not make sense to pin a precise number on it like that. So what if your MUD is only 59%? There is no need to make a standard. Just handle it on a case by case basis when it comes up. Note that I have never seen the question come up except in this thread, so it is (IMO) not really a question that gets seriously asked. The only scenario in which I can see it coming up is some dispute like Medievia, but that really was about a rather different question: it was about the claim of total originality, not just about being "stock".

In a scenario like that it doesn't really matter either. Medievia isn't guilty because it's say 43% stock still, it's guilty because it was once stock, and even if it were only 3% stock today it would still be guilty. Essentially, being modified enough to not be considered 'stock' does not mean that you are no longer derived from that stock codebase, as that is something you will always be no matter how much you change.

As was stated above in regards to the Medievia comment, DRM may not be stock, but it will never be its own codebase. You can label it DRM 1.0 etc if you please, but it is still smaug, it is still merc, and it is still a DikuMUD. That won't ever change, and in fact can't ever change.

I think that's pretty much exactly what I said. :tongue: (see "total originality")

Fizban is right with the fact that regardless of all the changes, one can never really claim that something is 100% different because in all actuality, it began as stock SMAUG or whatever codebase one starts out with.

If it wasn't written from scratch, that still only makes a mud a derivative of the parent code no matter what the owner claims. (And even then, we get into a gray area about outside influences compromising that claim if they have ever seen a MUD before. It happens to writers all the time)

Ah, well, that is a topic that we covered at great length before on this forum, so I suppose it suffices to say that I think we need simply agree to disagree on this one. :smile:

I'm not seeing how you can really intelligently disagree that something that was once DIKU derived can leter be considered to not be derived from DIKU. It's not an opinion, it's an established fact. It's not to say it'll always be stock by any means. But as an analogy, you were derived from your parents, you can't change that they're your ancestors it's just the way it is. You being derived from them doesn't even mean that you're anything like them, other than that your DNA is based off of theirs. Much the same way any MUD that was once DIKU is still DIKU, it began as DIKU, it's "ancestry" is that of DIKU and therefore it will always be DIKU.

I have no idea why the ancestry analogy is remotely appropriate given that to complete the analogy, you would have to fully and completely change your DNA. I mean, seriously, your DNA is based off of theirs, but other than that detail, you're not anything like them? Well, anyhow, if you really want to trudge through the discussions I suggest you look at the "legal issues" section of the forum…

Derivation is a pretty well established legal fact. If you start as A and make lots and lots of changes, becoming B, that doesn't mean you get to say A never existed and therefore B is entirely new and original. Much like you'd be laughed off the street for starting with a Toyota, changing all the parts one by one until it became like a Nissan and then trying to convince everyone it's a Nissan now and Toyota is no longer a part of it.

Well, actually, if you took a car and changed every single component including the chassis, you'd be laughed at if you tried to say it was still related to the original car… especially if you made it look like a Nissan and not a Toyota. :tongue:

A better example might be taking our pieces one at a time, replacing them with fixed pieces. It's like the age-old philosophical question: if you take a ship, repairing it piece by piece over the years until eventually all original pieces are gone, is it still the same ship?

According to copyright law, yes. It's the same ship. Same car. Same codebase. :)

I think that Toyota would laugh at you if you tried to tell them that it was the same car and therefore they were responsible for damages etc. :wink: And I think that Nissan would have issues if Toyota tried to claim that the car was their design…