Search website

Mud Web Client

I’ve recently been working on a web client for a mud engine I’m writing, which I suppose will function as a web client for any mud that supports websockets. It’s been a bit rough, what with my almost non-existent knowledge of javascript and html and css. Sure, I’ve used them all, but I never really cared to get to know them. I stop with the css as soon as it looks kinda how I want. Anyway, here’s what I’ve learned.

  • Javascript blows. I’ve used ActionScript (Uh, http://jemgine.omnisu.com/projects/ld23/ ) and ActionScript is (supposably) Javascript with a type system; but that slim type system really adds a lot. Also, not having a debugging environment is kind of a pain. I’m sure they exist, but I haven’t got one.
  • Websockets are a pain in the ass. I don’t understand why there isn’t some bare socket available in Javascript. I guess websockets can punch through port 80? Who knows. Thankfully, I found a library to deal with them (called Alchemy) which brings me to..
  • Alchemy blows. It’s better now that I’ve fixed it, but the library relied on the connection object being disposed by the garbage collector to actually disconnect when a connection timed out. Actually, it needs to be disposed to raise the ‘OnDisconnect’ event at all, and this is the only hook supplied to client code. So don’t you dare keep a copy of the connection around (You know, so you can send stuff to it) and prevent it being collected. I fixed this (It’s like, one fucking line of code. Oh, and calling ‘disconnect’ doesn’t actually disconnect. Fixed that too.)
  • The way websockets work creates terrible confusion in any api trying to wrap them. What’s the difference between OnConnect and OnConnected? Who knows, but do your work in the latter.
  • Why does this blog get so much spam for essay writing services?
  • MISP ( http://mud.omnisu.com/doku.php?id=misp ) is really fucking awesome. And that’s what I’m actually going to talk about.

See, the webclient ( http://mud.omnisu.com/webclient/ – Don’t try to connect, it probably won’t work. ) (has/is going to have) little icons embedded in the text to perform basic commands in the mud. This is a straightforward system. The exit name is followed by a picture of a book; click it to go that direction. Objects have magnifying glasses for looking at them and hands for grabbing them. I ‘devised’, or, ‘made up on the spot with no forethought’ a simple mechanism for specifying these commands. Just embed {:the command} in the output of the mud. Oh, sure, there are more complicated and ‘good’ ways of doing it, but then I’d have to jump through hoops to generate the output and ignore something MISP is really quite good at.
But not everyone is using the webclient (Hell, I don’t use it.) Should everyone else have their output full of {:crap}? No! So, the mudlib needs to generate different descriptions depending on the type of client the player is using. The solution is an object with methods that generate the output. Write one object for basic formatting, write another for formatting with all the little icons.
MISP doesn’t actually have member functions, but it does have function pointers (kind of) so it’s pretty simple to implement: basic-formatter, when loaded, defines some functions that do the work, and then it is also a ‘formatter object’. Each player has a ‘formatter’, and the descriptions use that formatter for… uh. Formatting. It even looks like a member function when you call it, too.

And then room can use those last two properties in it’s description.

Of course if the actor hasn’t got a formatter, it breaks.

Switch to our mobile site