Interconnected

playsh: You can download today's cut of the playsh code, since the talk today.

Here's what comes in this download:

playsh is a MOO-like text environment that runs on your local computer. The basic object types and verbs are based on LambdaMOO. It's organised geographically, so you can walk north and south and so on. You have a player, so you can take and drop items. You can create new things and dig to new rooms, and there are verbs attached to all of these. There are ssh interfaces so you can connect to playsh from other computers, and other folks can connect to your playsh instance from their own.

playsh is written in Python. The verbs in the game are also written in Python. There's a kernel, which is relatively small, and most of the game (including the sentence parser) exists as in-game verbs. In-game verbs have editable source, or if they're altered on disk they can be reloaded without rebooting the game. To allow this, the player can drop from the game environment into a Python interactive interpreter.

The Python interactive interpreter is a lower-level interface to playsh. Objects have a dictionary interface for their key-value properties, and methods appear to be verbs. Because playsh is social, the Python interpreter is also social. That is, two players can live in the same interpreter: One player can write a function, and the second player can both see the first player typing, and make use of that function. This means playsh can be a good teaching and learning environment. Of course, anything that can be done on your computer in Python can be done in a verb, so verbs can interact with desktop applications or work with serial interfaces.

How objects are represented in the playsh code is a novel feature. An object (whether it be an item, or a place, or a player) has two parts: properties and verbs. The properties are the underlying reality of the object--these are key-value parts like a list of object IDs named 'contents', which represents what is inside this object. When interacting with an object, all players share these properties. The verbs, on the other hand, are player specific. Each player maintains a list of special objects, called 'actualizers'. Actualizers are pattern-matching machines. When a player resolves an object, all the actualizers they have try to bind to the properties. If one recognises a particular pattern (say, it notices that there are two lists called 'exits' and 'entrances'), it wraps the properties in a collection of verbs. This is now a complete object.

Because the view of objects is subjective, different players can play different games, while using the same underlying reality. One player may see playsh as a geographic layout of rooms; another may see it as a card game where they play the 'north' card and the dealer puts a 'place' card on the table, and deals out more directional cards.

The final feature of playsh, and where this all comes together, is that properties may be loaded from a number of sources. Object IDs of the regular form load from files on disk; IDs that look like web addresses load from that particular website. The HTML (or XML) source-code is parsed, and actualizers bind to the patterns seen in the source and give it appropriate verbs. Thus an RSS feed manifests as a room with many doors, and the RSS items are written labels on the doors. An upcoming.org events feed is a room with a special verb that says what's on right now. bleb.org TV listings may manifest as a television item. And, with a little more work, you could have a walk-through version of your desktop calendar.

Verbs, to make use of web APIs and HTML scraping, can be written in-game, and then combined with one-another. Different players may experiment with different verbs, and then share the best ones. playsh is a shell to experiment, playfully and socially, with these kind of recombinant uses of the web.