feeds and rivers

I’ve started to poke at something that’s been on the back burner for too long.

I put out IFURLs (a weekly curation and summation of interactive fiction links) for about a year, and while I enjoyed the process I felt like I reached a natural limit doing everything by hand after a while, so I put it on hold. The new idea (well, it’s certainly not new at this point) was to build a tool that would make the process easier and invite collaboration from like minded folks. I thought that while I was at it I could add feeds from outside the strictly-defined parser IF community, since I did that anyway with the list by hand. Choice-based games, muds, electronic writing of every kind — what I wanted to make was a huge firehose of all that stuff and then develop the tool to make it easy to filter and sort that information for the reader, the ultimate goal always being to present a weekly select list of the most interesting links. So it’s not a planet site, and not an add-a-link Reddit or Hacker News clone; I’ve seen these kinds of sites described as rivers and that’s not a bad description.

I’ve taken the first step of putting about 30 feeds (some are planets as well) on a page.

I’m using Clojure, noir-async, and clj-rome to put it all together.

Clj-rome wraps the rome-fetcher RSS library, and that seems to present the first issue. You can see in the screenshot that some of the items include dates and some don’t. It appears that rome-fetcher isn’t parsing some of the RSS pubdates correctly. The Mudbytes feed items for example includes pubdates, but I don’t get them in the rome-fetcher parsed feed.

I remember 5 or so years ago when I swore I never would touch Java code. I seriously had a natural aversion to it from the first time I had half an idea of what it was all about. I guess Time is the great Trickster, isn’t it?

I’m not sure how to proceed with the pubdate issue. There was a somewhat related issue filed at the rome-fetcher Jira page, and I commented on that. In the worst case I can add my own date based on when I pull down the feed item, since it’s not that important that my date syncs precisely with the actual post date of whatever I’m grabbing.

A nice thing about Java is its layers of abstraction. It feels industrial and solid. Of course that’s also a downside; getting at a problem seems to require a lot more peeling back of layers, though I think (hope) some of this complexity is just a lack of familiarity.

going for Spring

writing interactive fiction without a programming language

Warning ahead for a rambling post.

The English-like syntax of Inform 7 gets a lot of flak, mostly from programmers who say something like how programming languages should express concepts in concise and symbolic ways due to the nature of programming itself.

However one of my favorite things about Inform is not really the English-like expressions of ‘The Kitchen is a room’ or stuff like that, but how you can create new phrases. For example, from the I7 docs:

To make (character – a person) lose (point value – a number) points in the eyes of (voter – a person): …

To use that phrase, in your code you’d write something like ‘make Biff lose 10 points in the eyes of Buffy‘. Now if you were to translate that to a more conventionally symbolic language like Python for example, it might look like biff.score_points(-10, ‘Buffy’). In other words it’s a more verbose expression of the function.

It’s not that I necessarily prefer one syntax over the other — but what the first does is let you create a mini-language for describing that procedure of the program. Of course, that’s exactly what the Python function does as well. But because the first example is not necessarily couched in the syntax of I7 itself, I think the possibilities become much, much greater and more powerful.

Exactly how, well I’m still a little fuzzy on that. I’ve read a little recently about domain-specific languages, in particular I found this article about language-oriented programming. It’s rather out there but worth perusing.

I think I’ve said this before, but in using Leo recently it’s made me think more about what a program really is. It’s rather obvious it’s not a syntax file. However it seems, primarily, that few people examine and write programs in something other than a syntax file.

Leo takes that next step with its outline; I guess other tools such as debuggers and code browsers do something similar.

A question I seem to be orbiting lately is the somewhat unique case of how IF combines code and prose. In that sense IF isn’t too unlike a structured markup language like HTML, only markup languages rarely contain process — well, unless you count things like JavaScript. Regardless, language-oriented programming feels like it offers something to interactive fiction development. I think the synchronicity of the two terms is not a surprise. Dave Cornelson made an interesting post with regard to domain-specific languages at Intfiction. I don’t really like his choice of platforms but the core idea is worthwhile.

To get back to what a program is (forgetting the presumption of that statement for a moment) — an IF language that really was an IF-language creation language is another way of getting at that. If the IF author could specify how they create the work (and I mean really specify, not just within the specification of a syntax), is that another way of realizing the program?

A poet or a novelist is free to invent new constructs of language, new devices of storytelling or expression, in order to communicate the work. I guess an IF author does that by creating the process of the program — but is doing so within a defined syntax an unnecessary limitation?

A defined syntax obviously creates a framework an author can hang their hat on, and it makes it easier for authors to exchange examples and extensions to the core language. If every author created their own language for their work I can imagine any community collaboration could become difficult.

On the other hand it might turn out that certain mini-languages are more appropriate for some implementations than others. Does the barrier to entry become too high when, to write a work, you need to understand five or six mini-languages rather than just one syntax specification? Probably an IDE would obviate some of these difficulties…tools like the T3 Workbench or the I7 IDE do some of that already. But at the same time I’m not sure you’d want a very strictly defined IDE. Maybe something more like a Smalltalk environment? One with live code reloading…

Is it strange how these ideas keep turning in circles?

Playing text games on the web

Of course purists will say, ‘playing text games in the web browser’. Only in the last year or two have web clients for muds and interactive fiction really started to gain momentum. As far as I can tell there hasn’t been a single source that attempts to note them all in one place, so that’s what I’ll try to do here. I’ll treat IF and muds separately (though in many ways the use case isn’t that different).

Interactive Fiction:

Traditionally IF in the browser used java applets or java web start. Zplet and Zag are java interpreters for the z-machine and glulx, respectively, the former using applets and the latter web start. ZMPP is in this category as well.

While web start launches a new window, applets typically run within the browser window. For example, Jetty, a TADS 2 applet, looks like this:

But you also can style applets how you like within the page; for example, contrast the above with this game:

Over the last few years it seems like JavaScript has been superseding Java for many web applications, but JavaScript has been around for IF for a while.

That’s from Aunts and Butlers, a 2006 JavaScript IFComp game.

Of special note is that the IFDB offers plugins so that it’ll start a game automatically (using an interpreter on your local computer). In essence this is like using Java web start, but with a much greater variety of game formats available.

The IFDB is not only the IF site where you can play games; the IFwiki has a good list of sites with various web-based interpreters.

A lesser known z-machine/glulx interpreter is iffy. It’s a CGI application, so it needs a web host to run from (rather than running completely on the player’s computer).

To be honest, though, all of this is a lead up for the new generation of IF interpreters, the standard bearer of which is the z-machine’s Parchment.

The Parchment development site links to instructions on how an author can get their game running. Because Parchment uses the Google app engine, all the author needs to do is put their game file on a publically accessible computer somewhere. Of course, an author can download the Parchment package to their own host as well.

Parchment isn’t the only representative of this new breed of interpreters. Quixe is a work in progress to emulate Parchment for glulx games (not yet released). Leaflet was developed by Jay Is Games for playing IF at their site. Another Flash z-code interpreter is Flaxo.

Other interpreters in this class include ifrotz, written in Ruby and C:

:

As well as SilverGlulxe, a glulx interpreter in Silverlight:

Of special note here is Guncho, essentially a mud server written with Inform 7. As a mud server, you can connect to it with mud clients. Guncho hosts a java client on its homepage, and these work a lot like the applet and web start interpreters shown above.

Well, since I’m talking about mud servers, that’s our bridge to jump over to…

MUDS:

Web clients for muds got their start with the java applets and java web start clients just mentioned. Since many of these were made for specific games, and were an attempt in some way to compete with native clients (such as mushclient, Zmud, and so on), they often look a little fancier than comparable IF interpreters.

Also due to the server-based nature of muds, they more often have employed socket-based Flash clients for players;

That’s a souped up example of Fmud, available for free (but not open source) from the developer. Fmud is not the only Flash mud client out there, but it’s simply harder to track down these clients (compared to IF clients), and Fmud is probably the most feature complete and polished one you’ll find. Of note is Soiled, a haXe client (which compiles to Flash).

Similarly with the progression in IF from Java to JavaScript, lately there has been a progression in muds from Java and Flash toward JavaScript clients. The jMud client is mostly JavaScript with a Flash socket connection. MUDBrowser is a JavaScript based subscription service to play muds in a web browser.

There are also generic telnet clients such as anyterm that use AJAX. I even found a Firefox plugin to do a similar thing (though I couldn’t get that to work for muds very well — I think it was designed for BBSes).

The PHuDBase client is a very new php-based platform (which currently requires Google Chrome to try out).

This represents my current knowledge of what’s available; with a little more digging I know I can find more clients particular to specific muds, but I don’t think they progress beyond the examples shown here. Any other references are of course very welcome.

What can I take away from the survey? Personally I like that IF interpreters are moving toward open web standard frameworks such as JavaScript, HTML and CSS.

It’ll be interesting to see how muds approach this; by their nature muds are a little more ‘custom’ than IF games, so using platforms such as Java and Flash may make more sense, but as web services begin to integrate more and more, mobile devices proliferate, and JavaScript gets faster and easier to use, it may be the case that muds would do better going a similar route as IF. On the other hand Java and Flash are not going away anytime soon, and they do offer a richer set of options for mud client developers out of the box.

One topic I haven’t touched here is hypertext, web-based gamebooks and CYOA, boutique systems such as Twine and Twee, or the range of digital poetry and literature ‘playable’ in the browser. There obviously is a lot more to talk about when talking about ‘playing text games on the web’, and something I’d like to get to in future posts. I feel that all of these genres could learn something from the technology that each presents itself with.

Narrative Designers assembling

I came across http://narrativedesigners.net/, which is a newish forum/wiki/resource for people working in narrative design. Seems to be mostly people in the AAA industry, and perhaps those from art and academia as well. It’s always struck me that these folks work in something of a walled garden so it’s nice to see a public-facing community site take form.

What we talk about when we talk on RAIF

Amid a little Inform 7 drama lately on RAIF I started to wonder how much of the conversation there actually is taken up by Inform 7. For those among my vast readership not familiar with RAIF, it’s the Usenet group for talk about writing interactive fiction.

There seem to be hints that Inform 7 may create its own forum for discussion, so I also wondered about the effect on RAIF of moving I7 discussion somewhere else.

I just browsed through the last month of topics (basically December) and categorized them as follows: Inform 7, TADS, design talk, meta (talk about RAIF), interpreters, community (competitions and the like), calls for game testers, and the convenient other. The results:

According to Google Groups stats there were 784 posts in December 2009 (I’m guessing many of these are spam). Was December an anomalous month in terms of number of posts? In general, no. Here’s the table:

The high count in November may have been from IFComp.

As soon as I get my horde of winged monkeys to tabulate all of 2009, I’ll report back.

Anyway, it’s always been obvious that many of the RAIF posts were on I7, but I never realized just how much. It’s not really a huge percentage in terms of the whole newsgroup, but it dwarfs each other category individually.

I wish there were some more numbers available, like how many active posters there are…a man can only dream I guess.

code name: Waddington (#2)

Leo and pyf: literate IF development? (interactive fiction in Python #2)

Originally when I started the IF with Python series I thought I would methodically go through each Python IF lib, write a small game, compare and contrast, and so on. I still plan to do that. But as might be expected, I’ve just gone down a rabbit hole, so I’d like to see where it leads.

On a TIGSource thread maybe a month ago I heard of the programming tool Leo, which is a ‘literate editor with outlines’. By literate it means it’s a tool for literate programming (LP).

I’ve always been interested in LP, but now I suspect it was for the wrong reasons — or at least for reasons that aren’t really fundamental to literate programming. I’d checked out PyLit a bit, and my experiment with Pawsy was in a similar vein of trying to find out how to weave IF’s prose with its code in a pleasing way. I was attracted to LP because it seeemd like ‘prose, with code’. Since I like prose, I thought, hey, this might be for me.

But I had some free time today, so I finally opened up the Leo zip I downloaded a few weeks ago. Now I’m not so sure that LP is about ‘prose with code’ — at least with Leo, LP seems to say instead that a program is not just a set of code instructions, and not just a commented explanation of itself, or that thing combined — but a program is a structure that operates on multiple levels, and restricting yourself to one view of that structure, or to one way of investigating, exploring, and manipulating that structure, is an extremely limiting way to work.

I know I’m not being that coherent, as I’ve been working with Leo for less than a day. Maybe some examples will help. Here’s a screen of Leo with a pyf IF project:

Here are some closeups — first, the top left pane, the outline view.

The right hand pane is simply a log window — the bottom pane is the code view:

The @others keyword there is a Leo directive that says, ‘insert here all nodes below this one in the outline’.

So what you can do here is create the world model structure of your game, and in the top level, organize these nodes into your program structure. Already I find that this makes for much more readable code.

In the outline view you’ll see node names (headlines) that begin with @thin. This is one way of telling Leo to write that node to an external file; when Leo writes the file it expands all @others type directives, so basically you end up with a file that assembles all the code in your nodes into a single game file ready to run.

My workflow, then, involves creating the Leo outline, and then running from within SciTE the assembled program. In an ideal world I’d be able to do this directly from within Leo; Leo stores its outline files in a .leo directory, so I guess it’s possible to run the Leo outline from the project directory instead, in order to have easy access to any modules that I’m importing into the game but are not available to the whole system from site-packages (like the pyf module, for example).

So far this may not seem much different from an IDE with class/function browsing, or an editor with multiple levels of code folding. However there are some important differences.

First of all you can put anything you want in a Leo outline — you can mix Python code, xml, html, plain text, etcetera, and choose what goes into the assembled file that is the actual game source. In this way a single outline can hold many disparate components you’re using for your game, but still produce the working game code as you need it.

Second, you can do more with the outline structure than you might expect. You can clone nodes in Leo, such that a single chunk of code or text can exist at multiple points in the outline hierarchy. When you change the node at one of these points, all of its clone nodes change as well.

In other words you have multiple views of the same piece of data. When I first read about that I immediately thought this would be a great way to write IF conversation. Of course I have no idea if that will work in practice, but imagine writing an IF conversation as an outline, where you can easily reuse quips as necessary. Compare that to a flat view of conversation, as you’d find in any IF source. The question is whether the additional overhead of the outline is a net plus over a conventional layout, but intuitively it seems like this could really work.

Anyway, the real test will be to write a non-trivial game in pyf using Leo, so that’s my next step. I have to say I’ve never been this excited about a programming tool though. Most of the IDEs I’ve checked out are not that inspiring; this feels completely different.

code name: Waddington

Writing interactive fiction in Python (#1)

Newsgroups: comp.lang.python
From: Neil Cerutti
Date: Mon, 13 Aug 2007 13:37:26 GMT
Local: Mon, Aug 13 2007 5:37 am
Subject: Re: Adventure-Engines in Python

[….]

As far as I know, no full game was ever written in PAWS. Once you try it, you’ll possibly see why no interactive fiction system distributed as a library for a general-purpose language has ever caught on. Every system that’s enjoyed even moderate success has been a language+library implementation.

—
Neil Cerutti

This is my jumping off point for an exploration of writing IF with Python.

Every so often on RAIF someone will make a comment about why people “don’t just use the power of a general programming language” instead of bothering with boutique languages like Inform and Tads. I think it’s clear that IF languages solve a problem probably unique to writing iF — how to weave prose and code — not to mention that their years of development have resulted in very strong libraries that make writing IF much easier.

Nevertheless, as someone who enjoys IF, and programming with Python, I want to look at this more closely. More after the cut.