Zzot!

I’ve been working on this, off and on, for a while now. In theory, it shouldn’t be that big of a thing to make a simple roommaker. Reality, of course, is another matter. Here’s a screen cap of my prototype, and some related details the image doesn’t really convey:

• The data is stored in a custom XML markup language.
• The tool I’m designing would be incapable of reading or writing LPC — the
  mudlib takes care of that (or, if you want to extend the loader object, you
  just inherit the XMLRoom object).
• It is designed as a web application that directly handles the XML markup.
  Because of this:
  • The read/write gateway (a server-side PHP script) will need to do some
    validation (it doesn’t yet).
  • It requires a modern-ish browser with an implementation of
    XMLHttpRequest and JavaScript enabled.
  • There’s no SOAP or XML-RPC going on — it is just a simple REST API.

If anyone wants to know more, let me know. At the moment, this more closely resembles a mock-up than a prototype, so there’s nothing anyone can interact with yet. The corresponding markup is in the extended entry.

Update: No, it isn’t. What was in the extended entry got lost somewhere, so I deleted the mess that remained.

IgorMUD | Permalink | No Comments

Regular LPC objects are loaded from an LPC source file — these new objects are loaded from a source file, but not an LPC one (and not named whatever.c). This makes the object loading path more complicated, so here’s an attempt to put a few of us on the same page.

This is obviously a first draft, scribbled down quickly so we have something to discuss. Let me hear any thoughts you might have.

Continue reading…

IgorMUD | Permalink | No Comments