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.
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.
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.