Archive for the ‘mud’ Tag
1) Start it yourself, and be prepared to do it yourself. This doesn’t mean you will be doing everything yourself, and it doesn’t mean you can’t give things to other people. It means that if you don’t have anyone else to do something, you have to be prepared to do it yourself.
2) Get something working, even if it’s simple and sucks, as quickly as possible. If you have something that works and sucks, you’ll want to improve it and make it suck less, which is good motivation.
3) Get users as quickly as possible, and if they want to help, let them. Make sure you talk to them and tell them about what you’re doing and why.
The way #3 worked out for me was that I got other mudder friends involved pretty much as soon as we were able to build areas online. They built areas, which gave them a creative outlet and helped the game, and I built code, which helped them be creative. They pushed me, and I pushed them. Great motivation.
4) Take good care of your users, and reward them for finding bugs in your stuff. The value of testers and testing cannot be overemphasized.
5) If something needs to get done, sit down and do it. Don’t wait around until you find someone to do what you need done; if other people wanted to do it, they would tell you, and if they do it when they don’t want to, the result will be poor.
You don’t often see young MUD coders learning about what’s out there before they sit down to write their own codebase. I first wrote that line several weeks ago. For the past few days, the DGD mailing list has been swamped with email from a fellow who has decided that the existing codebases for DGD are too complicated and intricate to bother understanding, so he’ll write his own that works better. He seems to be a quite decent coder, yet he uses that reasoning. Am I the only one who sees that as a fundamental contradiction?
New programmers set out to solve problems, to write a grand new codebase, and that’s wonderful. But why do they read through only a little documentation, and only two or three existing codebases at most?
I believe that the very biggest reason is a lack of existing literate coders. The various MUD camps (MUCK/MUSH/MOO, Diku/Merc/Rom, LP*) don’t mingle much, and few people know a reasonable amount about more than one of them. It’s hard to become literate in existing MUDs if you have no role models, no overviews and surveys, no people who can answer broad questions like “has anybody ever tried this before on a large scale?”. It’s hard to become a literate coder in a vacuum, having nobody to compare notes with. The lack of decent programming documentation for any existing MUD doesn’t help. Reading source code takes a lot of time and effort, and few new coders understand just how important it is. So few of them bother to do it.
At this point, it’s obligatory to mention brash young programmers, considering themselves cowboys, who are going to revolutionize the world of MUDs all by themselves, and how they start over not because the existing code is bad, and not because they know nothing about it, but because that’s their way.
Balderdash. I’ve gone to school with those brash young programmers, worked jobs next to them, trained them in programming, worked with them on open source projects in 3D graphics and 3D modeling… MUD programmers aren’t all that different a breed. They’re just in a deceptively easy-looking discipline and have nobody really impressive to compete against. They are neither good software engineers (who is, when they start?) nor awed. They believe they can do everything that the existing codebases can do, given enough time. And sadly, they’re mostly right. At least, if they had a decade going spare.