I'll pose this as an analogy. Your initial question is comparable to: "Go into Lowe's, go pick your favorite tool."
Favorite tool for what? For framing out a small house? For laying concrete? For roofing? What am I doing? What am I building? A car jack doesn't help me lay concrete, just like a Diku-derivative won't be appropriate without lots of work for certain games.
Another example: If I wanted to run a Hack 'n Slash, there would be a whole lot more re-invention of the wheel using a MUX/MUSH rather than one of the Diku derivatives or offshoots. If I wanted to just do a talker, there are a number of great codebases that would fit this well, but you wouldn't want something like a Diku-derivative unless you stripped it down to fit your talker's needs.
Given different kinds of games to build, my favorite would be different. I personally would never build a talker on a Diku-derivative, but wouldn't hesitate to go Diku with certain hack 'n slash designs. If I wanted to do more of an exploration and player-building-heavy game, MUX/MUSH have that and excellent security/permissions systems that have been maturing for ages. If I was wanting to screw around or test a very different concept, I'd roll my own.
27 Jun, 2013, Ssolvarain wrote in the 22nd comment:
Votes: 0
A builder could tell you what his favorite tool is, and why.
It's just that some people like to argue semantics for the sake of argument. One of the major pitfalls in attempting a casual thread on mudbytes.
27 Jun, 2013, quixadhal wrote in the 23rd comment:
Votes: 0
There are no casual threads on Mudbytes. ALL THREADS ARE HARDCORE PVP THUNDERDOME MATCHES!!!!! :evil:
P. S. Also, I prefer real coding to hypothetical questions.
Yet here you are trolling.. then again we all cant put skins on top of circlemud and claim we reinvented the wheel.
Most people who come to this website are seeking some kind of help, or greater opinion to gather inspiration. It's incredibly rude to treat others like this when they simply want better parameters and a better understanding to help you. Even if that wasn't the purpose of your post, it was not clear in the beginning.
That said, with everything there is going on out there, I'd probably write something from scratch based off one of the bare bones codebases. I'm rather partial to Python so, I'd probably go with Miniboa as a starting point. If I wanted something more fully featured, I'd go with Evennia, because I'm also partial to Django. I would steer clear of the old C bases. They require a ton of work to simply get to where I'd want them to be.
I agree, Evennia seems to have a lot of potential. Generally, though I'd recommend looking for a codebase that meets most of the desires you have because trying to implement new things and integrate them into a codebase or writing one from scratch is a ton of work and distracts from creating the game end of things. That's not to say it can't be fun or helpful to go that route, but if you just want a game, don't make your own hammer and nails from scratch…
MUDs haven't significantly evolved since the launch of LPMud.
I would suggest to take a 3d graphical game with a physics engine and try to add a dynamic description generator on top. Game-wise I would suggest copying WoW (which resembles the Emlen codebase) while adding elements of Prince of Persia 3d. I don't think Prince of Persia 3d has been copied in any MUD codebase even though it's not super difficult to code.
Hm. I think if I were going to try to really renovate the concept of a MUD, first I'd start with one of the existing engines. I'd layer over it a graphics engine, and on top of that, a client-server architecture in which players must use a custom client. This client would control the player's character, communicating with the player– and I think it would be best to remove the textual command interface and instead replace that with the use of the mouse and WASD keys to move the character, with maybe a hotbar for abilities. At this point players aren't going to be receiving much information from the MUD text, so I'd replace status indicators and other events with images to make the text-based experience more intuitive.
Good evening! I propose the following interface for 2013/future MUDS:
05 Sep, 2013, quixadhal wrote in the 30th comment:
Votes: 0
All this talk of making MUD's graphical…. you now, MUD's were born from an unholy union of Zork (Adventure) and Dungeons & Dragons… there used to be a really successful company called Infocom, who specialized in text adventures. Then they decided they needed to make graphical games like everyone else….
Hmm… I've heard that was just from Zork. A Fortran implementation of Zork called Dungeon (DUNGEN) that the guy wanted to be multiplayer (multi user). Nothing to do with d&d :) But monkey island/space quest/first Larry interfaces are good!
05 Sep, 2013, quixadhal wrote in the 32nd comment:
Votes: 0
You're correct about it being Dungeon instead of Adventure… however, since Dungeon had no combat mechanics, they borrowed the combat systems from D&D.
All this talk of making MUD's graphical…. you now, MUD's were born from an unholy union of Zork (Adventure) and Dungeons & Dragons… there used to be a really successful company called Infocom, who specialized in text adventures. Then they decided they needed to make graphical games like everyone else….
What would you say is the lesson here?
A. You shouldn't do anything badly.
B. You shouldn't do things purely to capitalize on a trend, especially if you're going to do them badly.
C. You shouldn't try anything that others have tried and failed. Examples include: getting into very tight jeans, swimming, breathing.
All this talk of making MUD's graphical…. you now, MUD's were born from an unholy union of Zork (Adventure) and Dungeons & Dragons… there used to be a really successful company called Infocom, who specialized in text adventures. Then they decided they needed to make graphical games like everyone else….
What would you say is the lesson here?
A. You shouldn't do anything badly.
B. You shouldn't do things purely to capitalize on a trend, especially if you're going to do them badly.
C. You shouldn't try anything that others have tried and failed. Examples include: getting into very tight jeans, swimming, breathing.
Return to Zork was released 20 years ago by Activision (they'd already bought and shut down Infocom years earlier), and it received quite a lot of praise for its interface. Activision Blizzard is now the world's second-largest gaming company by revenue.
So to quote your earlier question, "What would you say is the lesson here?"
06 Sep, 2013, quixadhal wrote in the 35th comment:
Votes: 0
Ooooo, now that's a great misdirect KaVir! +20 troll points for you!
Return to Zork was a dismal failure, and Activision Blizzard is the world's second largest gaming company based on the revenue from Blizzard (mostly World of Warcraft, but also a good number of box copies from Diablo 3 and Starcraft 2), and even moreso the Call of Duty franchise, which is a huge seller on the xbox 360.
So yes, the "lesson" is… drop games that involve puzzles and thinking, and make games that involve shooting people and repeating quests to fetch boar hooves without reading the quest text. :)
Misdirect? You were the one implying that Infocom shut down because they tried to move into graphics. The fact is that Infocom were bought and shut down by Activision before Return to Zork was developed, and Activision Blizzard is now one of the most successful gaming companies in the world.
Return to Zork actually received pretty good reviews, particularly for the graphical interface. Criticism mostly revolved around the stability, with one reviewer describing it as having "one of the most frustrating bugs ever in the history of adventure gaming". Another complaint was that the developers weren't familiar with the earlier text-based games, having never actually played them.
07 Sep, 2013, quixadhal wrote in the 37th comment:
Votes: 0
Misdirect.
Because you are attributing Activision Blizzard's *CURRENT* success with an action that took place *TWENTY YEARS EARLIER*.
07 Sep, 2013, Ssolvarain wrote in the 38th comment:
Votes: 0
And Lucas Arts was a great game studio back in the day…
It's 2013 and the number of codebases available to start a mud are staggering. If you were to choose an existing codebase to start a mud from, what would it be and why?
Just looking for peoples thoughts and opinions.
I just went through this thought process a couple of months ago. I had a very mature ROM mud that I could use. More than a decade of coding changes, lots of custom systems. I had planned on converting it to C++, using MySQL for all storage, and changing the theme of the mud. But then reality hit me - converting a huge, 15 year-old C mud to C++ would be difficult, tedious, and time consuming. I didn't want to code in C, either, as I felt that ignoring all of the advances in programming that have come out since ROM would be shortsighted.
So, I decided to write my own. That's what I'm doing now, albeit slowly. I'm using PHP (yup…) 5.4 and MongoDB as my database of choice. So far it's going swimmingly.
I'll pose this as an analogy. Your initial question is comparable to: "Go into Lowe's, go pick your favorite tool."
Favorite tool for what? For framing out a small house? For laying concrete? For roofing? What am I doing? What am I building? A car jack doesn't help me lay concrete, just like a Diku-derivative won't be appropriate without lots of work for certain games.
Another example: If I wanted to run a Hack 'n Slash, there would be a whole lot more re-invention of the wheel using a MUX/MUSH rather than one of the Diku derivatives or offshoots. If I wanted to just do a talker, there are a number of great codebases that would fit this well, but you wouldn't want something like a Diku-derivative unless you stripped it down to fit your talker's needs.
Given different kinds of games to build, my favorite would be different. I personally would never build a talker on a Diku-derivative, but wouldn't hesitate to go Diku with certain hack 'n slash designs. If I wanted to do more of an exploration and player-building-heavy game, MUX/MUSH have that and excellent security/permissions systems that have been maturing for ages. If I was wanting to screw around or test a very different concept, I'd roll my own.