Skip to page content

[2020-09-21 Mon 11:24]

I’ve “successfully” ported over the old areas from the Teraum MUD into my MUD, where they’ll exist as part of the emsverse; a multiverse I’m implmenting with… qtMUD, though I’m increasingly unattached to that name.

“Successfully” is in quotes here because while the emsverse declarations execute without raising any exceptions, there are a tremendous number of things that don’t actually work: areas exits are mis-set, thing’s have descriptions that are lists instead of strings, and so on. That was expected: there’s almost no work to sanitize a thing’s inputs.

Now, I essentially have a corpus of realistic game content: it is riff with typoes and misplaced paratheses, just like code submitted to a “real” MUD would be. This’ll help me write those checks, and provide a basis for writing tests to make sure changes to the underlying procedures let folk know about errors they may introduce.

Now, onto the name: qtMUD: the qualities of things multi-user dimension.

The problem with the name is, it’s frequently not a multi-user dimension. I use qtMUD’s code for all sorts of stuff, and that’s only expanding as I use it more. Like, I’ve got a file that’s essentially a ledger for my fridge. (Working to have it tell me when things are spoiled.)

Also, qualities have become a bit of a fuzzy concept, since they are really just “a chunk of procedures that get added all-at-once to a thing.”

So, it’s… well, let me think of adjectives and nouns I might use to describe it:

  • mine, like, I, emsenn, made it, for me.
  • in Racket, like, it’s implemented in Racket. (Though part of me wants to switch to some other tinier or more default LISP, so it’s easier for me to rebuild it on arbitary systems, at least in part.)
  • it deals with objects, in the programming sense - though they’re rather hackily implemented, so I still prefer to call them things.

Often, traditional objects have attributes and methods: my things just have methods - though I call them “procedures” because unlike (most) object/method systems, it’s easy enough to change a thing’s procedures.

The codebase has code for creating things, but also comes with a library of procedures intended to be added to a thing. But what those procedures are used for is rather… non-specific: the only thing I can safely assume is that they’re made by me, and that they’re using the things framework.

“Library” as I’ve just used it is a holdover from traditional MUD lingo, and in contradiction with Racket’s lingo: to Racket, each “library component” (MUD lingo) is a “library,” and qtMUD is a collection of libraries. I guess, then, let me look at how that would be organized:

  • qtmud/
    • qtmud/things.rkt
    • qtmud/qualities/container.rkt
    • qtmud/utilities/lists.rkt

I’ve abbreviated it down to one file for each category of the library: it’s qtmud and qualities that I’m considering renaming.

I think I do want to stick with “qualities,” because it implies a… vagueness I think is appropriate for things: a thing having qualities of a container, that is, the same procedures with the same returns, does not necessarily mean it is, exactly, a container.

So, qtqtOperations? It is essentially a collection of libraries for performing operations on and with the qualities of things. Abbreviated to qtOps

Let’s see how that feels in some sentences.

Talking as a server admin, emsMUD is made with qtOps. As a Racket developer, emsMUD is made using the qtOps collection.

I’ve started using qtOps to measure how long the past-due bread we get from the market is.

I’m transitioning to handling my website with qtOps.

If you replace qtOps with “quality of things” operations each sentence makes, more or less, sense: assuming you know about things and their qualities.

I’ll sit on it for a day or so but: I’ll probably rename the project to qtOps.