WITCH.md

ideas for tildemush's WITCH scripting language

Let's imagine an Alice and Wonderland themed little cake.

A MUD has a complex system of commands that interact with objects. A player typing eat the little cake would be parsed into the eat command, find a little cake object in the current scope, check for an eatable property, and enact some result, either a default player.name+"eats the"+subject.name or some custom interaction provided by the object.

A MUSH is a "shared hallucination", we avoid hard coded rules and interactions and let the users roleplay as they see fit. A player could /do eats the little cake, /do shrinks down to the size of a mouse!, and then go about pretending to be a tiny person until they got bored.

A WITCH script describes an object which can then be created in the MUD by users. How can these objects facilitate user defined interaction? The current spec has a hears directive giving access to text in the current room. Much like an IRC bot, the objects could parse this and react:

object "little cake" by "selfsame {
  describe { 'A small yellow cake with a label that reads "eat me"' }
  hears "(\w+) eats .*(little cake|cake)" {
    print(heard[0]+" shrinks down to the size of a mouse!")
  }
}

These reactions rely on the user writing good parsers, we could imagine mistakes like:

selfsame watches "Boy eats world"
selfsame watches "Boy shrinks down to the size of a mouse!

Another gotcha would be multiple little cakes in the same room, which would all think they were being eaten.

formalizing verbs & entities

What if tildemush provided the parsing? selfsame eats the cake is object verb subject, and if those two nouns could be resolved in the room scope, it could dispatch an action directive.

action "eat" {
  print("[subject] shrinks down to the size of a mouse!")
}

tildemush could use spacy or nltk to tokenize input, and the verb's lemma to avoid redundancy.

There's more complex patterns, like [selfsame] (feeds) the [little cake] to the [alligator] or [selfsame] (buys) the [jacket] from the [merchant] with a [credit card], which could be avoided or handled down the road.

@vilmibm the horse example is great, I think it's a solid goal for how parsing should work that can be extended down the road.

Some notes on resolving actions:

• the subject is always the object that issued the /do command
• the verb is always the first word /do eat
• the object needs to be resolved, initially we can assume it's the (optional) third word of the action /do eat grain and not /do eat the grain.
  • This word needs to be compared with objects in scope, if a match is found the action is called on it.
  • we don't need an object binding, since this is always the object of the action.
  • may be some issues here with dispatching "zero-object" actions (/do smile evily).
• I'd say a single argument binding for the <rest> string is sufficient.

With the current sketches, this sort of thing is possible:

# alligator
action "feed" (thing){
  room.say("The {this} clamps it's jaws onto the {thing}!")
  this.do("eat {thing}")
}

# spagetti
action "eat"{
  room.say("The {this} dissapears!")
}

/do feed alligator spagetti
*** The alligator clamps it's jaws onto the spagetti!
*** The spagetti dissapears!

What's going on now is both trying to design a language, and trying to define the interface it implements.
Wouldn't it be more useful to design the interface first in python (or hy) to have something running, and then define the witch language to make things easier that should be easier?

Many townies already know python or can adapt a python example to what they need, and I think it's a lot easier to define our own language once we can test what non-programmers find difficult and what's easy to integrate.