High Level Design Series: Technology Stack (The NEW 7 Layer Surprise)

[Shem (aka MadScientist)]

Software Engineering Rule of Thumb(s):        /* Why do I have 5 thumbs?  Oops   *refresh* */
One of my pet theories is that "CHAOS fosters Creativity; but CRUSHES Projects (long term)".  Another is that everyone always needs 'Another Pair of Eyes".  To me, these translate into a somewhat ecclectic (or was that eccentric ... *grin*) design process that makes a big MESS and then systematically starts organizing, reviewing, & implimenting pieces of it.  When my 'suitecase' is finally packed & orderly, I have no more project baggage to clean up and its time for me to move on to a NEW Project.

Let's discuss my R(MUD) Project; would that be the MUD(R) of all Projects ... I haven't decided yet.  Anyway, I'm using this series of posts to highlight key aspects of my design artifacts; soliciting feedback as I go to correct any obvious, or subtle, mistakes.  I assume all of you play MUDs, run MUDs, or at least dream about MUDing so this seems to be the perfect audience.  I also assume all of us hate to read long documents, so I'm doing this one bite at a time. 

After reviewing the MUD Families, with emphasis on the LP/MudOS clan as my personal favorite; I decided to start the R(MUD) Project from multiple directions simultaneously.  I'm planning to use MudOS/Dead Souls for now as an easily implimentable 'Get Off the Ground and Prototype Something' implimentation; while slowly doing the planning, design, and implimentation phases in the background for a configuration that may be much closer to my long term goals on DGD/Phantasmal based, or at least that is how I'm currently leaning.

So, with the acknowledgement that I'll be discussing two implimentation paths (over time), please consider the following design elements with those constraints in mind:

My planned Technology Stack (likely DGD based):

• OS - Host Server(s) (ie Linux, Windows Server, etc ...)
• Driver (VM Sandbox, Compiler, Security, Services, ...)
• Driver Extension(s) (3rd Party MudLIB Optimizations)
• MudLIB(s) (Game Methods, Mechanics, & Models)
• Story OBJs (Actors, Settings, Events, & Context)
• Interface (Client Tools such as Telnet, TinTin++, Adaptive Tech)
• Player (Total Wetware Interactive eXperience -Silly rabbit, TWIX is for Kids!)

So, feedback?

[Dworkin]

My planned Technology Stack (likely DGD based):

• OS - Host Server(s) (ie Linux, Windows Server, etc ...)
• Driver (VM Sandbox, Compiler, Security, Services, ...)
• Driver Extension(s) (3rd Party MudLIB Optimizations)
• MudLIB(s) (Game Methods, Mechanics, & Models)
• Story OBJs (Actors, Settings, Events, & Context)
• Interface (Client Tools such as Telnet, TinTin++, Adaptive Tech)
• Player (Total Wetware Interactive eXperience -Silly rabbit, TWIX is for Kids!)

I am of course flattered that you would consider using DGD for your project. I have one suggestion:

Put the interface at level 3, not level 6, and take the technological developments of the last 20 years into account.  Nobody wants to use telnet anymore; not even when it runs as an app on a web page.

[Shem (aka MadScientist)]

Because one of my high level goals is to reach both 1st & 3rd world infrastructures, I'm trying to figure out an infrastructure model that would be essentially UI agnostic.  Maybe something Client/Server Obj/Event ...
 
Imagine 3 players sitting in a Bar.  One could be running a TUI (Text User Interface, i.e. Telnet) data stream; one could be using a 2D/Graphical front end GUI (i.e. Genie, Storm, etc Simultronics Clients), and one might be running a 3D/??? front end *UI (ie Meridian 59, etc) ... or something else that hasn't been created yet.  However, the game server itself would hopefully ignore all the *UI type issues at the interaction/game mechanics layer and just treat them identically.  Ideally the API/Specifications would be useful enough that future UI ideas/models could just extend or wrap the existing game such that graphical and text based avatars could continue to coexist on the same platform.
 
Do I know how to do this?  Nope.  However, I'm pretty sure that if I take a minimilist approach, and try to avoid painting myself into a corner, I'll either eventually figure it out, or maybe someone else will without having to write something from scratch.

[Dworkin]

Because one of my high level goals is to reach both 1st & 3rd world infrastructures, I'm trying to figure out an infrastructure model that would be essentially UI agnostic.  Maybe something Client/Server Obj/Event ...

People in third-world countries don't have computers, but they do have phones; in a few years they'll have Android smartphones. Given that you want to reach this enormous population, perhaps you should drop support for the tiny and shrinking group of people who will connect with telnet-like clients from first-world computers. 

[Shem (aka MadScientist)]

Hmmm, a Non Telnet MUD?!? ... I had assumed Telnet as a lowest common denominator.  I wonder what my other options are.  (I know of Telnet and HTTP, and I can imagine something akin to SOA* architecture as well.)  Throwing out my own experience with Telnet as "the way its always been done"; ...
 
Anybody know more about this topic?  Throw a few keywords at me for starting points for further reading?  It's hard to imagine things in a vacuum.

[Nilrin]

Wasn't Dworkin speaking of smart phones with telnet based clients as apps?

[quixadhal]

Dworkin was correctly pointing out that TELNET is a stupid interface for a game, because it provides no structured data capabilities, beyond using arcane subnegotiations that break half the clients out there.  It would be much more sane, if you really want to reach the larger audience beyond this group of dinosaurs, to use a strucutred data stream (such as JSON), and let your client choose how to display various data elements as appropriate for the client's environment.

IE: On a large screen, I might want to divide the screen up into several text panes for various event-specific data, a main screen for general room descriptions and such, and some hit point bars, maps, etc.  On a phone, I'd likely NOT want that, as the screen is very tiny already (size, not resolution)... so maybe a hit point bar, a map, and the main screen.... but using flashier colors to draw attention to events.

The only reason MUD's use TELNET is because they've always used TELNET, and those who have a player base are too afraid of losing their players by forcing them to adapt to a modern client.  No new game should have that concern.

[Camlorn]

Hi.

    So, normally, I don't even check this, but with the tmc craziness going on (if you don't know, you don't want to-really), I decided to look at forums I haven't looked at in a while; didn't expect to actually reply, as I'm usually a lirker, but:

    As soon as you abandon telnet, you abandon blind players.  Mostly.  The thing is, most people don't know how to make an accessible web client, and I'm not even sure this can be done (yet--we'll have to wait and see how well screen readers support html5).  We're a small part of the mudding population, but, as I am a part of that population, I think it's worth considering.  That said, so long as the game is room-based, making a desktop client (c/c++/java/etc) isn't so bad, as there's apis that can be called to send information to the screen reader (this is what mushclient does atm).  To be honest, even if it isn't room-based, given certain constraints, you could make a client--basically, what godwars2 does with it's interface only moved to the end-user's computer (but, you'd have to follow some of the constraints that godwars2 does--there's only a few well-known tiles for dungeons, and most places are completely open; you can't run into trees etc.).

    I've seen the telnet protocol, yes, and I agree it sucks.  You get no disagreement from me there.  Just saying: some of us can't use the new graphical clients that are everywhere.  As for supporting both, I've had some discussions about it, and the general consensus is that you need to divorce the interface from the data, which is much easier said than done and probably something you've considered anyway.  What would be really nice, ultimately, is probably a new mud communication protocol and clients that support it, but again, much easier said than done (we kind of have this with msdp, you might want to take a look at that).

    DGD is really, really nice, though, if you're smart enough to figure it out--I wasn't, but I did try once.  I suspect that, more than anything, is why a lot of muds don't use it--as soon as you throw the words "Persistent world" out there, the words "area reset" go away, and the balance headaches start (why have a persistent world if you reset it anyway?).

    I'm sure you've probably thought about a lot of this stuff, but you did open it for discussion, so.

[quixadhal]

One thing to realize, is that when I say "custom client", I am not in any way implying "graphical client".  If MUD's used a data packet format (like every other MMO does), it would be trivial to write a text-only client that looked just like telnet, but actually understood the data being passed back and forth.  So, screen-reader users would likely gain the benefit of single-keystroke commands, and editable input buffers, without losing the ability to have their screen readers actually work.

For that matter, you could design a client specifically for blind people that doesn't bother with a display at all, but directly does text-to-speech (and accepted spoken input, if desired).

Of course, for the sighted, adding graphical elements is certainly possible, and not difficult, if the MUD itself is sending data that's well-formed, rather than spewing arbitrary text the way they do now.

[Camlorn]

True, true.  With issues.

    As soon as you start doing anything graphical, it becomes easy to say "display this graphic" instead of sending information about what's actually going on and, in fact, to do away with the room.

    The issue is, for the most part, any custom client for the blind has to be written by the blind.  Without being able to play the game, that can't happen, as knowing what information is important, only a bit important, and trivial comes from playing the game.  It can be done with input from blind players, yes, but for the most part the current blind mudding sollutions (which are, really, trivial) are written by the blind.  Most people (and I include mud admins in this) don't even know where to start.

   But the truth is, I'm not trying to put anyone down or anything, just raise awareness of the demographic and the required support.  I'd write more, but my computer is doing something odd wherein it's not actually keeping up with my typing, and I need to go figure out why.