Coding is a Text Adventure

Wired News is running a story about a new approach to crossover working and gaming turning your coding into a MUD-style adventure. Playsh is a "narrative-driven 'object navigation' client, operating primarily on the semantic level, casting your hacking environment as a high-level, shell-based, social prototyping laboratory, a playground for recombinant network toys." Great, now they are combining two of the most horrible addictions in my life.

Comments

Re:Sounds familiar

[Rei]

I agree; this is just so perfect. Some of my most fond coding memories were coding for an lp mud. The ability to "see" every object that you have, and at the same time to be able to, say, call functions on the body of the person that you're talking to, was just so much fun. I loved to patch myself to impersonate a message board or hide inside other objects. And don't get me started on "coding wars", when someone creates an object to dest you, you create a counter for the dester, they work around the counter, you come up with a convoluted counter-counter, etc.

From a practical standpoint, it makes a lot of coding intuitive and makes "plugins" nearly automatic. For example, objects can look at what is in their "environment" (i.e., what is holding them). If you have an object that calls "insert_foobar()" on every object sitting inside a message board object when someone tries to foobar the board, if you were to take it out of the message board and stick it in a player's inventory, it would try and foobar their inventory when someone foobars the player.

The fact that you can simply pick up and move objects around makes visualizing your tasks so simple. You can even have fun with how people interact with your objects; if you want an object that will perform some actions on someone's player object, for example, you could make it be a bread that they eat. You could have an object that displays information be a firework that you light and launch into the sky. The possibilities are endless.

How about a simple shell?

[kisrael]

I always thought it would be interesting to attach a Infocom/Inform like parser to a File Explorer / DOS shell type thing, so you could type stuff like
> move all files from c:\wherever\ and below that end with .jpg to c:\backup\, preserving the directory structure

That shouldn't be too hard, actually, we have systems that can speak Turing-able English so long as you restrict the subject domain...and once you had that, it should be trivial-ish to get the right speech recongnition component in place, if you wanted to go that route...

Slightly OT...

[DarthChris]

FTFA:

"Imagine using a bank where you move transparently between the automated and human-assisted interface because they occur in the same mode," says Webb. "The human can show you how to use the ATM, which is over at the side of the room".

And the phishers can watch as you enter your PIN...

Bad design...

[__aaclcg7560]

I had a being in a castle with a vampire text adventure for the Commodore Vic-20 when I was a kid. It was so frustrating because I would get to a special door, I would type BREAK DOOR, and the computer would respond WITH YOUR HANDS? Since the instruction manual said that my commands must be a verb and a action word, typing YES never occured to me.

In fact, I would read years later in "Hackers" by Steven Levy that the original Adventure text game would put the player in the similar position and that typing YES was the answer. I was kicking myself for not doing the obvious. Was this bad game design or was I being too literal in following the instruction manual?

Re:Bad design...

[Anonymous Coward]

I had that with the text-based Star Trek adventure. I tried every "open communicator" "use communicator" "contact ship" I could think of.. and the answer hit me one day.. it was "Kirk to Enterprise"

A Cow Says "MOO!"

[TexVex]

MOOs were like chat rooms, except the members of the community could create new objects by programming them into the virtual world in a dedicated programming language, shaping the game as it went along.

MOO is interesting for a lot of reasons. It merges the concept of an object in the programming sense with the concept of an object in the game world sense, and it merges the concept of a method call with a game action.

For example, you might instantiate a class, and the object created then becomes an in-game object that you can manipulate like any other. It inherits its data and behaviors from its parent. But, that object is also a class that you can extend, and others can be instantiated from it.

In MOO, when you type a command, the game engine matches your command against "verbs" (methods ) found on the object representing you in the game world. The first word of the line you typed becomes the command to match, with the rest of the words being parameters. (You can also specify that verbs not be matchable, only allowing them to be called from within code). It's possible to have verbs that work either as commands or are callable from within other verbs.

If you want to add a new command to yourself, you just add the verb and program it. If it's something to be shared, you copy it to an appropriate ancestor, then delete your own copy; you and everyone else inheriting from that ancestor gains the command. (There's security in place; if you're an administrator you can do anything but if not then you need the cooperation of the owner of that ancestor object or an administrator.)

Ultimately, a MOO is just a scripting language and virtual machine, with a network interface and some security features to allow collaboration without granting all programmers full read or write access to each others' code and data. Implementation of the player / room / carryable object paradigm is done in the scripting language, not the engine itself. It's flexible enough to write Web servers in, and pretty damn fast for a language where everything is late-bound and weakly typed.

Interestingly, while most MOOs used internal mail and public forums, and would send email for various purposes (coded right in the scripting language), and many of them listened for HTTP connections and translated part (or all) of the game world into HTML, none of the efforts to create large MOO networks (a la IRC) ever got very far.

Re:A Cow Says "MOO!"

[nuzak]

Funny thing about MOO's command/method equivalence, I always considered it one of the weakest features. One of the very first things we did elseMOO was decouple the command interpreter from methods. We pretty quickly got a pattern matcher with arbitrary predicates (not just "any" or "this") and any static strings you wanted, not just hardwired prepositions (regexes were also doable). Programming the method the command was linked with became easier, because the command matcher would take care of resolving objects and generating appropriate errors -- no more $command_utils:object_match_failed.

As for networks: it was never all that big a community in the first place, so it coldn't have made a terribly big network. Many MOOs and other MUDs treasure their isolation, and don't want to be agglomerated into a network in the first place. MOOnet actually got quite a few nodes, with some decent topology management, but cores just weren't designed to handle remoting, so everything felt glued on. Heck, there's *still* problems with seamless distribution in today's virtual worlds. EVE Online manages it, but most MMORPG's have punted and just stick with shards and instances within shards.

Re:Usability and Games: 17 Excellent References

[webword]

Usability and Games: 17 Excellent References Direct link to source article.../