Enhanced MUD protocols

 
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding
View previous topic :: View next topic  
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Thu May 12, 2005 11:13 pm    Post subject: Enhanced MUD protocols Reply with quote

(Beware, rambling ahead)

So I've finally got the server end of things on Aetas to the point where I can work on supporting multiple protocols (and thus, my own custom protocol) without feeling too dirty. Essentially, output is abstracted through a small template language. It's a tiny functional language with template-like syntax, which I will probably post the manual for later. Now that I have this, I've been thinking about what the actual protocol is going to look like. There are a few main things that I want to use this for:

- Meta-stuff. I'd like to have a threaded BBS system built into the MUD, with an interface reminiscent of my favorite news clients. This seems to indicate that some sort of remote scriptability on the client side will be necessary, but I'm not sure how much permission I can grant to a script without creating security concerns. I'm building the client in XUL/XPCOM/JS, and obviously Mozilla has a fairly sophisticated (ha) system for running scripts on web pages, but I'm a bit fuzzy on the details. Other meta-niceties would include things like a 'snoop' (for debugging purposes!) that redirects to a separate frame, etc.

- Building (and related tasks). I'm really torn on this; I've been thinking about several different possible building interfaces and I don't know if any of them satisfy me. One might take the traditional form-based approach, but Tyche's comments have given me reason to believe that we can do better. I considered a sort of 'direct manipulation' style which would be similar to traditional OLC interfaces, but would provide command completion, etc with some minor UI enhancements like an ever-present sidebar with links to the objects in the zone, and some rudimentary batch-mode features (select N things, execute some expression on each of them).

An absolute necessity here is to have a real text editor widget. This could be a bit problematic. Pre-existing widgets vary wildly in terms of features and portability. The current building client uses Scintilla, but it does not yet support OS X, so it would be necessary to port it or write an entirely new widget (nontrivial). There's also the matter of integrating with the Moz UI - I'm not totally sure how to do this yet (the codebase is 3 million lines and the docs are sparse) but I'm certain it can be done.

The other thing I'd like to explore is balance and testing tools. It would be nice to have an automatic combat simulation utility that could produce a fancy report, not just for zone construction but also as a kind of regression testing to see what kind of impact changes to game systems and AI would have on existing content. I've been playing with SVG lately, and the next Firefox release is supposed to have SVG support, and it's quite straightforward to produce various views of data in this way.

- Online, context-sensitive help. I like systems like ColdCore, Glad3's help files, etc. It would be nice to have a hypertext system for convenient browsing, dynamic examples, and so on.

- Combat. While we've significantly simplified the design of our combat system, it would still be nice to be able to present information in a more sophisticated way. I'd like to at least be able to match existing protocols here: images, guages, sounds. Long ago, we discussed a generic mapper protocol which we were going to use. That project fell through (twice!) but I think we can do this using a fairly small set of building blocks.

- Mini-games and other doodads.

Okay, so, now that that's out of the way, I'd like to establish a concrete set of features and a protocol design that will accomplish All This and More. I'd like to use a very simple protocol: negotiate through telnet and then send VT-like escape sequences (ESC { and ESC } perhaps?) to enclose xml messages (there's an implementation reason to use xml). I considered the idea of using telnet subnegotiations, but I'm currently leaning against it. To me, a subnegotiation is a piece of out of band data about the connection, rather than an in-band piece of data. I should be able to strip out all the telnet stuff and store a session transcript in a file without losing too much information.

As far as features go, here's the minimum I think I need to accomplish my goals:

- Multiple windows containing multiple frames. This one is a no brainer. This should be configurable either client-side or server-side, and there should be a command to redirect output to a named frame.

- Markup. Since output is done with Gecko, we can include arbitrary markup (not even just html, at that, as XBL allows you to define custom tags). This covers a vast swath of what I actually want to do: forms, graphics, etc.

- A URI protocol for serving content from the MUD. Imagine, for example, the BBS example. Say you've got your BBS window, split horizontally with a tree of messages on top and the actual messages below. You want to have links on top that will open the respective message. So you need some kind of asynchronous request/response mechanism, and the most obvious way is of course to have a URI protocol. I'm thinking this would be like mud:<connection-id>/<resource>, but I'm not totally sure yet. This could be implemented in-band pretty easily.

- Hyperlinks and popup menus. Pretty straightforward stuff, like MXP has.

- Completion. Or rather, control over the input line in general. I think the telnet LINEMODE option has some good ideas here that would allow this to be done in a general manner.

- Text editing support. Like I explained above, I'm just not willing to use a line editor, and Moz's built in text area leaves, shall we say, a bit to be desired. Ideally the server would be able to provide syntax highlighting info, but I'm not too picky and it's not strictly necessary.

- Sound. Simple stuff.

- Scripting. This is going to require serious thought. Basically I don't know to what extent the server should be trusted. Obviously if you're installing my custom client you trust me to run arbitrary code on your machine, but the client is also general purpose and can connect to Random MUD X just fine.

- Various miscellany - loading new CSS stylesheets, xbl files, etc.

Now, the question is: what have I forgotten, and what is horribly bad and will never work? I'm also a bit worried because a client like this would almost certainly never be feasible to implement as anything but a Gecko-based program. So there will be very little choice of clients. IMO, it's a worthwhile tradeoff.

Anyway, just some thoughts.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Scandum



Joined: 13 May 2005
Posts: 28
Location: I'm in the TV

PostPosted: Fri May 13, 2005 8:42 am    Post subject: Reply with quote

When it comes to escape codes it's probably best to use \e{B and \e{E for the begin and end. That way it will resemble ECMA-48:
Quote:

CSI (or ESC [) is followed by a sequence of parameters, at most NPAR (16), that are decimal numbers separated by semicolons. An empty or absent parameter is taken to be 0. The sequence of parameters may be preceded by a single question mark.
The action of a CSI sequence is determined by its final character.


Though it looks nice in theory I don't think it will work well in practice. Creating an xml terminal might be a better way to go about it, and it would be useful for more than playing 1 mud. Some people seem to be working on one, though I haven't checked it out myself yet: http://xmlterm.sourceforge.net/shots/prompt.html
Back to top
View user's profile Send private message Visit poster's website
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Fri May 13, 2005 8:45 am    Post subject: Reply with quote

Scandum wrote:

Though it looks nice in theory I don't think it will work well in practice. Creating an xml terminal might be a better way to go about it, and it would be useful for more than playing 1 mud. Some people seem to be working on one, though I haven't checked it out myself yet: http://xmlterm.sourceforge.net/shots/prompt.html


What in particular looks nice in theory and won't work well in practice? The client exists and I'm using it right now (and not on my own mud, either). I will of course publish a complete protocol manual once it's finalized and implemented, but the client operates with standard servers just fine. XMLTerm does not really do the same things that I want to, any more than xterm does the same thing as zmud.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Scandum



Joined: 13 May 2005
Posts: 28
Location: I'm in the TV

PostPosted: Fri May 13, 2005 11:08 am    Post subject: Reply with quote

eiz wrote:
What in particular looks nice in theory and won't work well in practice? The client exists and I'm using it right now (and not on my own mud, either). I will of course publish a complete protocol manual once it's finalized and implemented, but the client operates with standard servers just fine. XMLTerm does not really do the same things that I want to, any more than xterm does the same thing as zmud.

The main problem I see is that your client won't be VT102 compatible, nor xterm compatible. Windowing and mouse support have always been existant, just that most people found it too complicated to use. So you're reinventing the wheel by doing a step backward in order to take a step forward.

Another problem is that while it's easy to combine a terminal, command line editor, and a mud parser, complexity tends to get too big when all 3 are combined. Muds generally don't implement something that is only supported by 1 client. With mud clients continously dropping old protocols while inventing new ones there's little chance of succes. I believe Mushclient claims that it has correctly implemented MXP while it's inventor Zmud hasn't.

As a custom mud client for your codebase this will likely work, but if you want to develop a protocol you will run into the same problems as other clients. The only way to avoid that is to focus on a terminal emulator, adding a server side library to make implementation easy, and a protocol to go along with it.
Back to top
View user's profile Send private message Visit poster's website
Author Message
eiz



Joined: 11 May 2005
Posts: 152
Location: Florida

PostPosted: Fri May 13, 2005 5:58 pm    Post subject: Reply with quote

Scandum wrote:

The main problem I see is that your client won't be VT102 compatible, nor xterm compatible. Windowing and mouse support have always been existant, just that most people found it too complicated to use. So you're reinventing the wheel by doing a step backward in order to take a step forward.


I can actually get a decent (ok no, but colors and other basics) level of VT compatibility fairly easily. There are some things that will be difficult (especially cursor positioning which just doesn't make sense with a hypertext widget) but most muds don't use that stuff anyway, and most clients don't support it properly either. I'm not too worried about this. To be honest, it really is intended mainly as a client for 1 mud, but it's not that bad: I can play just about any 'normal' mud un-impeded simply due to their very low feature requirements.

Yes, it's reinventing the wheel. I looked at various other wheels, and I don't think they do what I want, and besides, reinventing the wheel is fun. Basically, the other protocols lack the sort of silly features (the most featured I saw was Pueblo, but even that is fairly limited) I want to play with.

Scandum wrote:

Another problem is that while it's easy to combine a terminal, command line editor, and a mud parser, complexity tends to get too big when all 3 are combined. Muds generally don't implement something that is only supported by 1 client. With mud clients continously dropping old protocols while inventing new ones there's little chance of succes. I believe Mushclient claims that it has correctly implemented MXP while it's inventor Zmud hasn't.


Well, I'm obviously going to implement something that is supported by 1 client. My hopes for taking over the world with this little project are not too high, and I write documentation more for my own benefit. Wink

Also, this is part of why I chose to use Gecko as a rendering engine: most of the hard work in terms of supporting layout is already done. I am well aware that doing this myself would take a lot more time and effort.

Scandum wrote:

As a custom mud client for your codebase this will likely work, but if you want to develop a protocol you will run into the same problems as other clients. The only way to avoid that is to focus on a terminal emulator, adding a server side library to make implementation easy, and a protocol to go along with it.


Right. Like I said above, I don't expect this to come into widespread use (especially because it would be nearly impossible to implement in multiple clients unless they were also Gecko based). But since we are doing an open source project, I figured I would share anyway.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Scandum



Joined: 13 May 2005
Posts: 28
Location: I'm in the TV

PostPosted: Fri May 13, 2005 8:43 pm    Post subject: Reply with quote

eiz wrote:
Right. Like I said above, I don't expect this to come into widespread use (especially because it would be nearly impossible to implement in multiple clients unless they were also Gecko based). But since we are doing an open source project, I figured I would share anyway.

I see. Goodluck =]
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Coding All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign