06 Jul, 2010, David Haley wrote in the 21st comment:
Votes: 0
To be realistic here, it is relatively unlikely that you will find somebody who will step you through the process with personal attention. There are universities and other forms of class & private tutoring devoted to that purpose. It is a long and hard process, and so it isn't something that people will do a lot. Now, you might find somebody who would take you under their wing on an existing project and try to give you small, manageable tasks where they can point you in the right direction. So, since you already build on MUDs, you might want to try talking to the coders there to see if you can work with them. Being familiar with what the code is actually doing can be helpful in following it. But nothing will replace plain old rolling up of sleeves and studying.
13 Jul, 2010, Hakuten wrote in the 22nd comment:
Votes: 0
yea i figured as much, but would ya have guessed? i found one :). Anyhow been makin some progress, babysteps for the most part, but im retaining a lot still. Which is enough for me as not to be a pain in my mentors rear, and as I have a newborn child im also taking care of :)
09 Aug, 2010, Scionwest wrote in the 23rd comment:
Votes: 0
Idealiad said:
Someone made a mud creation program a few years ago. I think they got about 3/4 of the way with it. I'm trying to find it on TMC, found something else instead:

http://muddesigner.codeplex.com/

This other program I can't remember the name of was more like Gamemaker or RPGmaker but for muds.


Hey! You mentioned my project lol, I'm the author of the Mud Designer. Thanks for mentioning it :biggrin: I have a lot of big things planned for it ^_^
30 Sep, 2010, lockewarrior wrote in the 24th comment:
Votes: 0
Late and didn't read everything, buuuuut…..


Have we really been waiting for someone to say, "I want to write a framework for MAKING MUDs?"

With the way technology has advanced, and with the development of higher-level languages, I can't believe we are still beating our heads over functional, low-level codebases. If I wasn't so gosh darn busy, I'd start writing an engine or MUD SDK myself.

The LP-MUD driver/mudlib combination is a big step in the right direction. I still would be inclined to say that the code behind it is a bit outdated.

Some generic framework should be built for mud design. Things like sockets, connections, state management, file I/O, telnet, serialization, databases connections, debugging, profiling, garbage collection and memory management, encryption, compression, etc. should be FULLY abstracted, scripting should be embedded, making use of dynamic loading and compilation where possible for improved speed.

Scripting should be a domain specific language configured exclusively for interaction with the 'driver' and manipulation of game objects.

Lua/Ruby, C++? Both? This doesn't seem like it would be too hard. MUD's could be brought up to speed in a major way. Some things I think about..

64-bit
multiple processors
multithreading
solid-state storage
01 Oct, 2010, David Haley wrote in the 25th comment:
Votes: 0
What are your memory requirements that push you to need 64-bit machines? Similarly, what are your speed requirements that push you to require multiple processors? Multi-threading can be a convenient programming tool, but it can also be a self-inflicted nightmare; why do you need it? Why are your IO needs so high that solid-state storage would actually be useful?
01 Oct, 2010, jurdendurden wrote in the 26th comment:
Votes: 0
I don't think he was saying that it was necessary to have those things for an updated codebase, I think it was more of a "this is what we COULD be doing" type of thing. Although I do agree those things aren't really necessary in a text based game however, I will agree with him that building a MUD in a much more organized, higher tiered programming language would make things faster, easier, possibly more fun, etc… Not to mention it could possibly help bring in people new to the hobby with less frustration than before. Learning the .NET framework is a helluva lot easier than trying to understand oldschool C code, and even Lua (what he mentioned as a possibility) is MUCH more human readable than C. C++ also has the advantage of OOP with class structures, etc…
01 Oct, 2010, Zeno wrote in the 27th comment:
Votes: 0
Quote
This other program I can't remember the name of was more like Gamemaker or RPGmaker but for muds.


This? http://www.mudmaker.com/
01 Oct, 2010, jurdendurden wrote in the 28th comment:
Votes: 0
Oh I've toyed around with that in the past… certainly is a fun little tool, but not as flexible as you would of course get by just getting in the codebase and adding whatever you wanted. I'm sure you could probably whip up a reasonably decent game in a couple weeks or so with this though.
01 Oct, 2010, Rudha wrote in the 29th comment:
Votes: 0
You know, a MUD codebase that offered a web-based front end for building/editing would be a neat thing to have. Maybe I'll code that in for NM/Elvenblade.

Maya/Rudha
02 Oct, 2010, Kline wrote in the 30th comment:
Votes: 0
CoffeeMUD does IIRC.
03 Oct, 2010, lockewarrior wrote in the 31st comment:
Votes: 0
David Haley said:
What are your memory requirements that push you to need 64-bit machines? Similarly, what are your speed requirements that push you to require multiple processors? Multi-threading can be a convenient programming tool, but it can also be a self-inflicted nightmare; why do you need it? Why are your IO needs so high that solid-state storage would actually be useful?


Programming 101: Don't reinvent the wheel: The codebases around today work. Sure.

What we have around now works. The wheels are good. I want to fly though. I'm not saying, "Let's rewrite what's already been done."

I'm saying that personally, I would be much more interested in devoting my time and energy to projects that were pushing development. Let's write something that -hasn't- been done. *shrug*

I don't think any codebase around either 1) has needs for those things or 2) is written to efficiently utilize those hardware advancements.. but what would a MUD look like if it did? What could a MUD built for more modern platforms do that MUDs aren't doing now?

I don't have solid answers for these questions, though I'm sure I could come up with some. I'm just asking questions hoping to inspire some thought.

Considering latency on even commercial MUDs like Achaea can still get pretty bad, I'm sure one could argue the benefits of faster processors, 64-bit memory, and solid state drives. Most gaming computers (for graphical games) now days consider these things to be 'standard', or at least pushing in that direction. What's the reason to keep text-based games anchored to outdated hardware?
03 Oct, 2010, Runter wrote in the 32nd comment:
Votes: 0
Because it can pile on complexity with absolutely no benefit.

Furthermore, all these things have been done in various projects. I think davids questions actually were asking why do you need it. All of those things are firmly in the realm of wheel based technology yet rather useless to determining the latency of archea.
04 Oct, 2010, David Haley wrote in the 33rd comment:
Votes: 0
Quote
The codebases around today work.

I wasn't saying that they're all good. I was saying that most people who are looking for "clean slate" MUDs are not looking for what they should be looking for.

Quote
Let's write something that -hasn't- been done.

Like what? What do you want to write for a MUD (not a game in general) that has such demanding requirements?

Quote
Considering latency on even commercial MUDs like Achaea can still get pretty bad

For all we know, the code there is utterly terrible and things are slow due to inefficient code, not old hardware. Or perhaps their network connection is slow. Or perhaps your connection to them is slow. (…and so forth.)

Quote
I'm sure one could argue the benefits of faster processors, 64-bit memory, and solid state drives.

Last time I asked you what you were actually going to do with all this stuff, you ignored the question… As Runter said, my question here is why you actually need this stuff. The bells and whistles are shiny, but don't seem to actually fulfill some need.

Quote
Most gaming computers (for graphical games) now days consider these things to be 'standard', or at least pushing in that direction.

Most games are also doing dramatically more things with the computer's resources…! When you add that 'little' caveat "graphical" to "games", you're completely changing hardware requirements.

Quote
What's the reason to keep text-based games anchored to outdated hardware?

Because you don't need super-fancy solid-state drives and the most recent quad-core processors to run a server supporting a small number of players and a small amount of data throughput and a small amount of bandwidth usage and …..

Look, I'm not saying there isn't anything that would be better off with more advanced hardware – AI comes to mind – but really, the main answer to your question is that most stuff MUDs need to do simply isn't complicated. The main problem is scalability: most approaches might work fine for 10-100 players but fall apart at, say, 1000 players. But, well, if you show me more than a handful of MUDs with 1000+ players, I'll eat my hat – in other words, that simply is not the common case for MUDs and so it isn't worth spending time on it.
04 Oct, 2010, Rudha wrote in the 34th comment:
Votes: 0
If you need a server cluster or some sort of liquid-cooled processing server made of mithril by the dwarves of Moria to run a text MUD, you're probably doing it wrong. The server I have is head-and-shoulders above what most MUDs have and I still probably wouldn't have need for it even if I hit the kind of popularity that those … interesting little adult MUSHes got, or Achaea, or whatever. Even if I had the number of users WOW had, the bottleneck for MUDs is not server hardware, it's network topology. Sure, it's certainly not as bad as it used to be, when you basically had to find a MUD in the same province/state/whatever if you wanted decent connection speeds, but you do not need a sophisticated machine to handle a MUD.

Now, that is not to say that there are not improvements that can be done in terms of efficiency and code standards - not to mention licensing; one of the reasons I gave up on more featured codebases and went with NakedMud isn't so much that they have a bunch of features that were superfluous, though that is true, or that I would have to remove many old components to have the system in place I want, though that is true also it comes down to three salient points:

1) Most MUD codebases are saddled with an increasing number of licenses.
Which … I suppose isn't much of a problem, if you don't mind your greeting screen polluted with a bunch of credits that could probably be better put in HELP CREDITS (which most also require), but to me this is a bit problematic, for that reason, and also keeping in mind drama of the past.

2) Many large projects suffer from uneven, varied, and sometimes contradictory coding standards.
Trying to dig through tbaMUD segments was one of the most arduous things I ever had to do in my experience as a MUD admin. Some sections are fairly documented and easy to follow. Other ones would probably be more understandable in bytecode. Programmers often get going so much on a programming problem that they do not take the time to use understandable programming logic and conventions, and … well, if you do have to start doing some voodoo programming, it would be great if it were documented, and in many cases, it isn't. This doesn't just go for MUDs, as many who have actually programmed for a living could tell you. I don't miss that.

A refactoring of the old codebases into something that follows modern coding conventions would be nice; computer science has made a lot of progress in the last couple decades; progress that many MUD codebases haven't kept up.

3) Most MUD standards … aren't.
I wasn't a party to most of the discussion that happened in regards to mud "standards", but it's pretty evident that it wasn't successful. Adoption of MUD standards is pretty abyssmal.

I haven't done a formal survey, though I'm now kind of academically interested in doing one, but I would hypothesise that probably about 90% of MUDs don't implement TELOPTs at all, and I consider that a pretty generous number. There's a lot of factors as to why this is, but it ultimately comes to the root problem: standards only work where there is a willingness to accept them. Most MUD admins aren't. Some of them don't have the technical knowledge to implement them. Some don't see them as terribly beneficial. Some just don't want to, because that would involve work. I could get a big prolonged explanation of the three, but this presents a problem in many ways.

First of all, there is uneven support in MUD clients. Different MUD clients support different TELOPTs. Many don't support many of them at all. Most offer differing implementations that can be problematic. The same goes for servers. This leads to standards … not being very standard. And that undermines their whole point.

Furthermore, it might be beneficial for more MUDs to try to adhere to the commands that people are used to seeing and using from past MUDs. One of the reasons I stick to certain MUDs is familiarity. Different MUD codebases have different conventions for their common commands and save perhaps a very specific few, commands for common tasks can vary. For example, some MUDs have you TRAIN <whatever> to advance. Some have you PRAC[TICE] <thing> to advance. Even others have LEARN <stuff>. I don't think 'usability' is something that enters into the average MUD admin's considerations. It ought to.



Before we start going on about supporting hyper-threading or solid-state storage, or the ability to ride magical winged unicorns to the sherbet kingdom, I think there are more pragmatic problems to be solved, and as far as I can see, those are the main ones to me.

Do I think they'll be solved? Licensing can easily be fixed by using codebases with more lenient licenses, or that are public domain. The other two are trickier, as they essential boil down to a certain 'x' factor, which is to say the human element. Any time you have a community of any appreciable size, there are a lot of people who have varying and sometimes conflicting ways they want to go about things. Are people ever going to get together and collectively agree on a set standard for code conventions or MUD commands, or the related issues? I'm skeptical to say the least, though I'd like to see it. That kind of thing, more than anything else, is what I think MUDs could improve upon as a whole.
04 Oct, 2010, Runter wrote in the 35th comment:
Votes: 0
Designing an application to be multiprocessor(with a meaningfully balanced load) is hard and confusing. You better have a good reason for needing it at the time. Otherwise its just high premature optimization. It can even lower performance. It only increases it typically where it would have bottled necked on a single core otherwise. And that's not easily justified on a mud.
20.0/35