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.

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.

Python game devs agglomerating

I found a neat little site for game development in Python, PyedPyers. Apparently it’s been around for more than a year (and this is the first time I’ve heard of it). The neat thing about it is it has some additional resources besides just a forum, such as a spot to host projects. It’s rather small at the moment and very quiet, but perhaps with a core group of some active people there some interesting stuff could happen. Check it out!

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.

pyglet and livecoding (#1)

Recently I started reading about livecoding. I was aware of it in the context of music performance, but in regard to games it might be more accurate to call it code reloading or simply interactive programming, but of course ‘livecoding’ is more catchy. Regardless of what you call it, it’s a lot of fun, and if you like programming as an iterative process as I do, it’s just fantastic.

A few years ago there were a few articles about livecoding and Python, which you can track down through this post by Richard Tew. He’s the author of the livecoding module which I’ve started to use with pyglet.

The basic idea is that you can modify a game’s code as the game is running; this isn’t any different than what you can do with many game development frameworks and some mud servers (mush softcode allows this, for example, and I believe LPMud has this as well), but the livecoding module lets you do it simply with your text editor of choice. Some IF language development environments like the Inform 7 IDE and TAD 3’s Workbench have a similar function with their skein and replay features, but livecoding is much more immediate and in the flow of the game itself.

The livecoding module achieves this by managing which files are to be tracked for changes, and then executing a file’s contents over again when you change it. As the programmer you need to structure your program so that you’re cognizant of what is in the global scope, as executing that code again will clash with the previous version (for example, you don’t want to re-execute a file that instantiates the pyglet window, unless you delete that window from the global scope). You also want to manage how instances of a class know about changes to their class; the module won’t automatically update old instances, but you can reassign the class to the instance to get the new changes (this at least is what I’m doing currently — I’m still learning how this works).

Here’s a simple example — get the livecoding module and put it in a new directory. Then create a code directory within that new directory. In my code directory I put two files, an initialization.py and a classes.py. Here’s initialization:

import pyglet

window = pyglet.window.Window(width=640, height=480, visible=True, caption='livecoding')

Remember that the important thing is to separate things in the global scope from the things you’ll change, to avoid clashes with the running game when you change things. Now in classes.py I put this:

import pyglet

class Hero(pyglet.sprite.Sprite):
    def __init__(self):
        pattern = pyglet.image.SolidColorImagePattern(color=(255, 255, 255, 255))
        solid = pattern.create_image(200, 100)
        image = solid.get_texture()
        super(Hero, self).__init__(solid)

    def set_pos(self):
        self.x = 400
        self.y = 200

In the main directory you’ll have a script to run the game, which I just called run.py.

import pyglet

from livecoding import reloader
cr = reloader.CodeReloader()
cr.AddDirectory("server", "code")

import server

hero = server.Hero()

@server.window.event
def on_draw():
    hero.__class__ = server.Hero
    hero.set_pos()
    server.window.clear()
    hero.draw()

if __name__ == '__main__':
    pyglet.app.run()

The reloader keeps track of changes to any file in the code directory (of course, you can call the code directory anything you want). This replaces the normal Python import statement for those files. It’s similar in a way to pyglet’s method of managing data files.

You see that the game creates the hero object, and in this hackish example I reset the class of the hero on every frame. That’s to account for the possibility of changes to the Hero class (in classes.py). What you do then is execute run.py, and while the pyglet window is sitting there, change the set_pos method of Hero in classes.py. Then mouse over the pyglet window or alt-tab to it, and see the changes!

In a less trivial example you could move the class reset to an update function called on a pyglet timer. That then opens up, fairly transparently, making changes to the game process and data as you’re playing the game.

The only sticking point so far is managing the structure of the program to avoid any weird errors in the global scope. Also from reading some of those other posts I linked above it seems like I might run into more problems with things like animation as I go forward — but we’ll see what happens!

New Python roguelike tutorial at Roguebasin

Springing from a discussion at the libtcod forums, Jotaf is spearheading a complete roguelike tutorial hosted at the Roguebasin wiki. It’s shaping up nicely!

code name: Waddington (#2)

Maiden Desmodus’ new client

And it’s pretty:

I think they just need to make the text area a little bigger, and probably enable hideable toolbars and status bars. Definitely raises the bar for anyone serious about an enjoyable mud client experience.

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