08 Sep, 2011, Rarva.Riendf wrote in the 41st comment:
Votes: 0
Quote
I have trouble conceiving how somebody could even claim that a unit test captures high-level design. It's as if we're speaking of entirely different concepts.

Err I dont think I said that unit test was for that…High level design is the kind of thing that is in your head, that probably evolves depending on feedback and playtesting. Reason why writing it in the first place too precisely will probably do no good as it will change and documentation will not get updated accordingly every time.
Especially in small one-two man project. I pretty much agree everything KaVir said about the process developpement of a hobbyist mud. Off course if you want to get a professional project that does not apply.
08 Sep, 2011, Cratylus wrote in the 42nd comment:
Votes: 0
I don't see a need for design docs when you have bash and awk.
13 Sep, 2011, Baiou wrote in the 43rd comment:
Votes: 0
I have not read the entire thread, but I just want to say that MUD Design Documents are a must IMHO. They're like the business plan and it makes it easier to see complications before hand.
13 Sep, 2011, Cratylus wrote in the 44th comment:
Votes: 0
Baiou said:
I have not read the entire thread, but I just want to say that MUD Design Documents are a must IMHO. They're like the business plan and it makes it easier to see complications before hand.


Did you have one for your super secret mud? You never shared :(
13 Sep, 2011, Runter wrote in the 45th comment:
Votes: 0
A Cratyphant never forgets.
14 Sep, 2011, Cratylus wrote in the 46th comment:
Votes: 0
Runter said:
A Cratyphant never forgets.


or forgives
14 Sep, 2011, Baiou wrote in the 47th comment:
Votes: 0
Cratylus said:
Runter said:
A Cratyphant never forgets.


or forgives


touche'
06 Jan, 2012, slapbass841984 wrote in the 48th comment:
Votes: 0
Step 1: acquire codebase or create custom one(I personally would have to use one that somebody created because I dont feel I could create one on my own.)

2: Implement "X" amount of features, and "X" amount of areas. (Good idea. And a suggestion if I may…Don't try to do so much that you get burnt out on the projects like I did. And if you need help ask on the forums…I'm sure somebody would be happy and willing to help you.)

3: Seek extra staffing help.(That seems to be the problem with a lot of muds i've seen. If you arent up to their standards then your mud just isnt a mud to them.)

4: Beta Test(If you beta test I feel you will find bugs that one could have missed and be able to fix them in a timely manner. And the beta testers can give out their ideas of what would look good added to the MUD.)

5: List MUD and open to players.(Players as well will give their opinions of what looks good and what doesnt. Listen to your players to their needs and concerns because in most cases they can and will help you.)

Just a few of my thoughts on the topic. Hope you guys and gals get something useful out of what I have said.
06 Jan, 2012, quixadhal wrote in the 49th comment:
Votes: 0
Step 1) Copy some existing MUD codebase and be a cookie-cutter, like the other 9001 MUD's out there.
2) Randomly add features and churn out boring areas full of generic rooms full of random NPC's that drop goodies.
3) Beg others to come do stuff on your MUD because it's so much better than the other 9001 MUD's just like it!
4) When your MUD crashes, due to drunken programming back in 1992, whine on the forums until someone tells you how to fix it.
5) List your MUD on all the public MUD sites as ready to play, and offer people 1337 gear to post good reviews!

Yeah, I'm being a smart-arse. But really, none of those kinds of details means anything when you're not making a product in a budget, on a timetable. Get an original idea, write it down, keep writing more stuff about it. When you have a good solid story and background, figure out what kind of game you want to make and write or find some code that works in a way you can understand. Then start writing code (or convincing others to help you) to make it work more like your vision.

Don't focus on features and areas and stuff. Focus on your story and the feel of the game. Areas will grow as you start describing your vision. Features will get coded as your story finds a use for them. If you have people to help you, items and stuff will get balanced as you and they playtest and see what works and what doesn't.

The "design document" is really your collection of stories, notes, formulas, and mechanics. If they're thought out solidly and written down clearly, coding them is natural.
06 Jan, 2012, Runter wrote in the 50th comment:
Votes: 0
To truly be successful as a mud developer I'd give these few tidbits of advice:
  • Protect ideas from the unscrupulous in this community. Never divulge them.

  • No test driven development. Just shoot from the hip.

  • Pay Expect someone to host your software in their basement. Preferably on the oldest, most unreliable hardware possible.

  • Don't balance your game systematically. Let builders and the whim of personalities do it.

  • Ignore the popularity of MMOs. Study their popular mechanics only to do the opposite.

  • Don't make multiple ways to solve a problem in game.

  • Don't make it clear why mechanics succeed or fail.

  • Make sure the games controls are the definitive factor from which difficulty may be derived.


And perhaps the most important of all.

  • Write your software in C.



edit: A huge error on my part was pointed out and fixed.
06 Jan, 2012, Ssolvarain wrote in the 51st comment:
Votes: 0
What do you when your compiler only returns:


make
I hate you.

make
No. Not Now. Not ever.

make clean
You know what? You're specific. I like that. But you can still go die in a fire.
06 Jan, 2012, Rarva.Riendf wrote in the 52nd comment:
Votes: 0
Ssolvarain said:
What do you when your compiler only returns:


make
I hate you.

make
No. Not Now. Not ever.

make clean
You know what? You're specific. I like that. But you can still go die in a fire.


You go beat Stallman, it is all his fault.
40.0/52