@HelloProject said:
I feel like this would all be solved if everyone just agreed to make a MOO, somewhere in between a MUD and a MUSH.
Yep. There will always be random players that claim they can't code for moo but can for mush. It's best to smile, nod, and ignore them. If they can't pick up moo coding in a few minutes, they probably shouldn't be "coding" on a mush either.
Damn, I sound so jaded and elitist.
In summary, MUSH should refer to a technology type centering around MUs that implement command queues and quasi-quoted function evaluation over a primitive hierarchical object database. It's a soulcrushingly bad design. Like MUDs, mushes have a lot of hardcoded commands and concepts. The community tends to favor RP, but there are always outliers and extras.
Similarly, MUCK is the same idea, but with the "softcode" implemented by a dialect of Forth. Whether that is a good thing or not depends largely on how much you like Forth, but I think most sane developer types would still consider it a step up from MUSH. A very, very big step. Less hardcoding here, so much more flexible. The community is predominantly furry. Whether that is a good thing or not depends largely on how much you like the whole furry concept. They're more accepting of my fascination with octopuses, at least...
MOO went a step further, and instead of using Forth-- an extensible stack-based language-- it uses a stack-based bytecode VM. A javascript-like (but much earlier) language then compiles down to moo bytecode. The bytecode structure is conceptually analogous to JVM or CLR bytecode, but users don't interact with it directly. There is no community left that I've found.
MOO also spun off coolmud and coldc. It's a pretty flexible design, but the implementations are very much showing their age. The beautifully abstract and minimalist hardcode that is its strength is also a community weakness; every MOO is very different.
So. What about MUDs? Well, the have a reputation for -- whatever, who cares; like any technology you can do anything with it. The unifying idea, if there is one, is that more of the game is implemented in hardcode and less in softcode, if any softcode is present. That can be good or bad depending on the implementation language and the nature of the problem you are trying to solve.
Moving forward, why aren't we all using (insert whatever perl/python/java/javascript/etc mini server is popular this week)? Similar too MOOs, there isn't much of an established codebase, and what is there is still far too primitive or incompatible with existing user expectations.
My current direction is actually much more MUD-like; throw almost everything into hardcode and implement it faster/cleaner/better THERE rather than in the softcode layer. Why use a crap baby-language when we can just use a proper one? Mushcode is training-wheels without the bike.