High Level Design Series: Blue Sky WISH List(s)

[Shem (aka MadScientist)]

As I'm doing my own Planning & Implimentation, I realized I might actually write something that is universally applicable to the MUD Community as a whole.
 
My 3, er 7, High Level Feature WISHes are:

• D.R.A.G.O.N (Dimensional Roleplaying & Gaming Online Network) - Players can MUD Hop (as a Multi-Verse)
• Universal RPG System - MUD mechanics autoconverts (Many:1) systems, with Easily overloadable HouseRules
• Interactive Fiction Scripting - Creators autobuild from INFORM, ADRIFT, TADS, HUGO, ...
• MultiMedia MUDing - Client Front Ends that provide: Text to Voice, Voice to Text, streaming Music, etc
• Economies of Scale & AutoMapping - Size is Everything, and the MUD knows how to hangle very diverse scales
• Enhanced Behavior Modelling - Carnivor, vs Herbivor Mobile behavior, for example
• Enhanced 'Virtual Tabletop' RPG ToolBox - Storyteller EVENT (ie Neverwinter Nights) Gaming Platform

If you could WISH for ANY Feature for your MUD, what would it be?

[Shem (aka MadScientist)]

• MultiMedia MUDing - Client Front Ends that provide: Text to Voice, Voice to Text, streaming Music, etc

BTW, just for the record.  I'm aware of MM support in various telnet Clients/Front Ends.  (CMud being a recent example.)  I"m willing to solve the problem that way if I must; however the closer I can get to the core of the game, and therefore potentially for all players ... the happier I am.
 
However, speaking of front ends.  Here is a link to the Bedlam (DIKU) MUD, which happens to be selling iPhone/iPad based front ends via the iTunes store.  (Bedlam LT Free, Bedlam for $2.99)  It seems that paying a little for a upgraded interface/wrapper around the game is compatible with most MUD license restrictions; and not a bad idea in general even from an advertising perspective.
 
http://playbedlam.com/
 
Does any LP MUD have such tools, or are DIKU's ahead of the pack in this area?

[chaos]

D.R.A.G.O.N (Dimensional Roleplaying & Gaming Online Network) - Players can MUD Hop (as a Multi-Verse)
Universal RPG System - MUD mechanics autoconverts (Many:1) systems, with Easily overloadable HouseRules

Oh, god, not again.

Someday you will realize that these two items are semantically equivalent to "all MUD admins stop operating their own games and become content to operate distributed nodes of mine".  I'm not going to to the legwork, though.  Too old for this shit.

[Shem (aka MadScientist)]

I'd read it the other way myself; current MUD Admins are happy running their own MUDs and likely will stay that way.  However if they want to impliment something I've written I'd be happy to share code.  I'm not trying to mess up everyones' Ponds; I'm merely throwing out the idea of adding canals, if both sides agree.  (And I'm willing to do the legwork)

[Sluggy]

In-game features are not on my wishlist. Either I have made them, am making them currently, or plan to make them in the future. Instead, my wishlist consist of Developer-side things because despite being quite old, many of the mud-related technologies have not matured and developed. They often lag behind modern day programming practices, techniques, and tools.

• A modern LP driver. Yeah, everyone wants this, don't they. Though my preference is for NOT being multi threaded. Most code would choke and die in such cases. And for less skilled programmers, performance and stability would take a big hit.
• An IDE workspace that supports LPC. Currently I use a java workspace in Netbeans using SVN support. Running the simple java app copies all recently updated files to the test server for, well, testing. When it's time to upload to the live server I just commit the changes and wait for my daily update script to pull it in. But this is still really clunky and a LOT of syntax and logical errors find their way in. Having an IDE that could check LPC syntax (rather than C++ syntax with error hilighting turned off), check for runtime syntax errors (yeah, they exist), give warnings about potentially unintended data transforming, etc, would save a ton of time. While I'm dreaming, maybe a built-in runtime debugger and unit tester! Hey, what about remote debugging too! Yeah, that's the ticket!
• How about better tool support in general. I'm and artist and I like buttons and visual stuff. Stellarmap was my small and cluttered attempt at making this situation better but really there needs to be a much biggerr, more general, and much smarter tool than can interface with LPC and allow creators to make content without having to open up notepad all the time.
• Dunno how many of the other LP mudlibs are built but DS has a few issues. You already mentioned a mixup of client and server-side code and a lot of code performing more tasks that it should (or is documented to!) but the biggest one to me is the perverse nature of its reliance on multiple inheritance. A component-based approach for a mudlib from the ground up would make extending existing code a lot cleaner and easier.

So yeah. There's my wishlist. Can't say I've not been tempted to try my hand at some of these but like most admins I would rather work on my mud than on tools for other peoples' muds.

[chaos]

I'm pretty sure we have a modern LP driver, the Pike programming language.  Just, y'know, somebody probably has to make a mudlib for it.  (Which will be challenging because it actually follows through on the separation of concerns that MudOS and DGD were aiming at and doesn't have game server model assumptions baked into its core.)

[Dworkin]

I'm pretty sure we have a modern LP driver, the Pike programming language.  Just, y'know, somebody probably has to make a mudlib for it.  (Which will be challenging because it actually follows through on the separation of concerns that MudOS and DGD were aiming at and doesn't have game server model assumptions baked into its core.)

This suggests that DGD does have game server model assumptions baked into its core.  Can you name one?  I do not think there are any, but perhaps I overlooked something.

[chaos]

This suggests that DGD does have game server model assumptions baked into its core.  Can you name one?  I do not think there are any, but perhaps I overlooked something.

I thought that some assumptions were in there that the system is going to be a Telnet server hooking up connections to objects.  Meaning, I didn't think DGD made you write your own socket handling model like Pike would.  If I'm wrong, I humbly apologize.

[Dworkin]

I thought that some assumptions were in there that the system is going to be a Telnet server hooking up connections to objects.  Meaning, I didn't think DGD made you write your own socket handling model like Pike would.  If I'm wrong, I humbly apologize.

DGD is a server, yes; it doesn't make LPC into a scripting language, as Pike does.  But what about the game server assumptions?

[chaos]

DGD is a server, yes; it doesn't make LPC into a scripting language, as Pike does.  But what about the game server assumptions?

I'm entirely certain you were successful in pulling all the game-mechanical cruft out of DGD, and hopefully all of the freakishly broken "performance optimizations" too.  (My favorite is the behavior I discovered under LDMud after various of my daemon objects stopped working: if nothing attempts to call a function on an object via call_other() for some period of time, reset() stops getting called!  And there is no driver config switch for this behavior!  So awesome.  You can imagine how much of my hair I pulled out trying to debug that idiocy.)  The only assumption I had in mind for DGD was that of being a telnet server.

[Dworkin]

I'm entirely certain you were successful in pulling all the game-mechanical cruft out of DGD, and hopefully all of the freakishly broken "performance optimizations" too.  (My favorite is the behavior I discovered under LDMud after various of my daemon objects stopped working: if nothing attempts to call a function on an object via call_other() for some period of time, reset() stops getting called!  And there is no driver config switch for this behavior!  So awesome.  You can imagine how much of my hair I pulled out trying to debug that idiocy.)  The only assumption I had in mind for DGD was that of being a telnet server.

The telnet part is optional; some DGD mudlibs use HTTP.

[chaos]

The telnet part is optional; some DGD mudlibs use HTTP.

Neat!  I wasn't trying to trash-talk you, honest.

[Dworkin]

To return to the subject of modern mud drivers, if DGD were not available today, I would take a look at Node. Javascript, event-driven like LPC, and it's a server not a script.

[Sluggy]

Oops, I really didn't mean for that to spark yet another one of these 'modern driver threads'. That comment was really just an afterthought.

To make my point clear, the other items on my list are far far more important to me. Developers, developers, developers...