Nothing guaruntees a better game… not using a stock codebase, nor inventing your own.

What starting from scratch does guaruntee is control… control over your license… control over your code. The added flexibility can make for a more unique mud… "better" is a matter of opinion.

See, now that I can fully agree with without reservation or insult/offense. ;)

Though I've certainly heard coders look at a piece of code and go "what idiot put this in there?!?" only to realize that they themselves wrote that section of code entirely on their own plenty of times. *L*

Are you saying that's never happened to you?

There are hundreds of codebases available for download, some written extremely poorly, others extremely well, and the majority falling somewhere inbetween. But even if you believe you can do better than all of them, you'll still lose out on the years of testing, bug-fixing and refining some of the better examples have undergone.

If it's about licence restrictions, there are also many variations among the downloadable codebases out there - some are even public domain.

Wanting to create something which no existing codebases can handle is a possible concern for the more developed codebases, but not for the really bare-bones ones. Besides which, whenever I see people creating a mud from scratch, they usually end up producing something which is functionally almost identical to most existing codebases.

"Knowing the code" isn't really a valid concern, either, as it's faster to familiarise yourself with existing code than to write it all yourself.

The only real reason I can think of to create the mud completely from scratch is because you want to create it from scratch. Maybe you want to prove a point, or perhaps you just like the idea of having created it all yourself. Looks better on a CV, too, I guess.

Why did you decide to start GW2 from scratch?

If you are looking for Open Source mud drivers, I started a page that lists the ones I know about.

http://sourcery.dyndns.org/wiki.cgi?Open...

Feel free to add to it.

Well, there's another reason to start your own codebase… to learn.

MUD-like games are good for learning because of the variety of ideas and the complexity. I've found that most tutorials and references use cookie cutter examples that rarely scale to real world problems.

Generally how I learn the features of a new language, library, or algorithm.

As a result of practicing on codebases, I've found that my software holds up to user loads and changing requirements.

Because I wanted to!

I'm not saying that people shouldn't write a mud from scratch, only that it's unlikely to have any bearing on the quality of the end product.

Just in case anyone is still reading this old thread…. writing from scratch is sometimes the ONLY way you can really feel that you fully understand how everything works. One of the reasons I never switched over to using an LpMUD driver/mudlib pair was that I just couldn't get a solid grasp of how things flowed at the bottom level. Of course, maybe there are some mudlibs which document this better than they used to, but still…

If you ARE going to write a codebase from scratch, save yourself a great deal of suffering and use a language which has native support for strings. Bonus points if it supports regular expressions too. Yes, you can (and I have) put up with the strdup/strncpy/stricmp nonsense, and dealing with a zillion if(pointer && pointer->more && pointer->more->foo) printf("foo %s\n", pointer->more->foo); is not impossible. But, why? A text MUD, by definition, will be spending almost all of its time reading, writing, and manipulating… text. So why pick a language which doesn't work well with text?

Back in the 1990's, we had no choice. Most folks had to run games on university machines with the permission (you did ask, didn't you?) of the sysadmin. If they didn't want to install, or couldn't afford to purchase, anything but the barebones C compiler, that's what you used. When your game ran on a Sun 3/60 with 12Megs of RAM, and you were hogging 7M of it… you couldn't use perl as it was just too slow and used too much memory. Now, the only way you could tell the difference between a MUD written in assembly and one written in Java would be to see the source code, or to benchmark it.

Just my 2p.

There is a fine line to walk between rewriting the code so that you understand it, and spending the time to understand somebody else's code. Sometimes there's a very good reason why it was written the way it was; the design might be quite elegant once you understand the bigger picture. Of course, it's also quite possible that the code was written in that way for no reason in particular, or worse, it might actually be a fairly bad way of writing the code. The decision to rewrite should depend on the confidence you have that the original code is at least decent, and the size of the project. If a rewrite means you'll never finish, then you probably shouldn't rewrite it… :wink:

EDIT:
I should mention that I agree wholeheartedly that having decent string support – even C++'s relatively basic string class – should be considered a requirement of any language chosen to rewrite the game in.

I should also point out that anything you learn/gain by writing a game from scratch also applies to modifying an existing one to the point that all of the code is your own. The end product is likely to be extremely similar, if not identical, and the same sense of accomplishment, ownership, and familiarity is achieved. This method has long been a topic of heated debate within the community concerning license disputes, but as long as either A) you cover your tail and abide by the license(s) regardless, or B) 100% of the code is genuinely your own, then you're OK. It's worth noting that paraphrasing is still considered plagiarizing and in the same way, porting or re-styling does not constitute writing your own code.

That said, I think there's significant benefits to this method over writing from scratch - especially for a beginning/intermediate coder.

Also, while string support is one of those almost-necessary-but-not-quite luxuries, it's still better to stick to a language that you know, rather than try to learn a new one simply because it's more well-suited for a task. I'm assuming most people are talking about C here, since there really aren't any other widely used languages that lack native string support anymore. I also think that the transition from C to C++ is easy enough to pretty much negate my previous comment, so I suppose this is really a non-issue.

"A" is the only safe bet if you started working with someone else's code. "B" is legally tenuous and isn't something people should be taking to the bank as solid advice. Risking your work on an unproven legal theory is just plain dumb.

The golden rule of writing code is that you can only be 100% sure of your rights if you wrote it all yourself from scratch, or based your work on something declared to be in the public domain.

Option B is not legally tenuous, strictly speaking. If it truly is 100% your own, you're completely fine. The hard part is in determining if it truly is 100% your own.

This isn't to say that it's not safer to write it from scratch, it's just that technically speaking if it really is 100% your own, and you can prove it, and haven't paraphrased etc., then you're on completely safe ground.

Actually, strictly speaking, it is legally tenuous since you're admitting you started from one thing and morphed into another over time. It's basically the Medthievia defense.

Starting from nothing at all is an entirely different scenario.

I should have made that clearer. The problem is in not separating the end result with the process. If, in the end of the day, you can prove that your code is 100% your own, you are in the clear. The problem is that it is very difficult to establish that the code is 100% your own.

The problem with Medievia, as I understand, it is that he did not in fact rewrite all of the code from scratch – in essence, he paraphrased large portions instead of actually reimplementing them.

But it's perfectly fine if you really did completely reimplement everything without paraphrasing etc. as drrck explained. Again, the problem is that it can be very tenuous to actually prove that you did just that.

But he didn't paraphrase, he just removed comments and other things, Look at the article on it that Samson has in his sig, I believe it was KaVir who wrote the article, but it really was entertaining.

Well, that proves my point then: the problem with Medievia was that he didn't actually rewrite the code 100%. It's not that there was much of a question about it. This doesn't show that, if you actually did completely rewrite something, there would still be a problem.

I believe this is another of those "not tested in court" things, and would very much depends on each individual situation anyway. However this article may be of interest:

http://digital-law-online.info/lpdi1.0/t...

"Piecewise Reimplementation

Many people have reimplemented computer programs by rewriting them to replace the source code with code of their own writing. There is no reason to believe that this would not be a copyright infringement, particularly if the reimplementer had access to the source code of the original program, even if none of the original source code remains.

When the first segment of code is rewritten, the new code will be an infringing work if it is substantially similar to the original code, or may be an infringing derivative work if it is a reimplementation in a different programming language. That reimplemented first segment is combined with the remaining parts of the original program to form an intermediate version. Subsequent modifications produce another work. So when you have completed the piecewise reimplementation, you have a set of works, each of whose creation infringes the exclusive rights of the owner of the copyright of the original program.

As an analogy, consider the translation of a novel to a different language, something that would clearly be a derivative work. It makes little difference that none of the original words remain, or that the translation was done a little at a time. The resulting translation is still an infringing derivative work.

Even if you completely replace the program with new code, nonliteral elements also protected by the original program’s copyright are likely to remain and infringe – elements like the overall program structure or architecture and data structures that are not dictated by external or efficiency considerations. Although there is no case law on this point, it would seem that the only way to break the chain of infringing works is by some extraordinary act, such as a clean room implementation."

Novel translations are a rather poor analogy because the content is essentially the same, merely in a different language. A better analogy would be rewriting the storyline using completely original chapter, paragraph and sentence structures.

You also can leave your rewritten components separate from the thing you're mixing them into. So, yes, the mix-in will be subject to both licenses: that of whatever you're rewriting, and your own license. Basically you "license to yourself" your own code, and then create a derivative work of both of those works (yours and theirs).

In the end, once you have completed rewriting all components, you no longer need to mix yours with theirs, and you can use yours in isolation. You then no longer have a derived work.

I'm not sure it's possible to copyright things like overall ideas, so I don't think that's cause for worry.

Of course, and again, this is assuming you're not paraphrasing the original components. I believe that rewriting basically verbatim but in a different language would be considered paraphrasing, much like a translation.


But yes, this is an issue that needs case law. There is case law about the clean room approach: we know that to be safe. That is what I have been trying to say, really: if you can prove that, without a trace of doubt, all of the code is yours, then you are safe. The clean room approach is a method that makes that proof easy. But it's not a logical necessity.

Wow, I really hate losing a long, thought-out reply due to internet errors.

Anyway, the jist of what I had written was this:

- I disagree entirely with the article KaVir quoted. The author is obviously trying to take copyright law concepts that work for other areas and apply them to software. This simply doesn't work, both because of the nature of programming languages and because, if taken literally, 99% of software ever created would be considered derivative work, and liable for copyright infringement prosecution.

- It's impossible to produce unique code, even using a "clean room" approach. Large chunks of your code and the intangible concepts behind it will inevitably be virtually identical to someone else's, regardless of whether you wrote it from scratch or modified an existing program. This is what happens when you have a relatively small, finite syntax within which you have to implement universally accepted data structures and algorithms.

- Software copyright law is a work in progress. It's not black and white, and never will be. The main determining factor is invariably intent. Unfortunately, because it's practically impossible to prove intent, it's also very hard to prosecute someone for infringement except in the most extreme of cases.

The author is specifically talking about people who have "…reimplemented computer programs by rewriting them to replace the source code with code of their own writing". And as stated by the US Copyright Office, "…you cannot claim copyright to another's work, no matter how much you change it, unless you have the owner's consent" (ref). So he's certainly correct in saying that you cannot turn a derivative into a non-derivative.

However the real difficulty, as DavidHaley hinted at, is proving that someone else has created a derivative of your work, and the more they change the harder that becomes. There's no clear line, so it's something that has to be taken on a case by case basis - and while a clean room implementation is certainly a strong defence, it's only one extreme. You could probably get away with less, but the further you move from a clean room implementation, the weaker your defence becomes.