towards popular Python interactive fiction (#1)

I’ve sort of touched on this topic in previous posts, but I’m trying to crystallize my thoughts here.

In my opinion there currently are three viable options for creating IF with Python: PAWS, PyF, or a custom system. An alternative form of IF can be made with Ren’Py, a visual novel system. Finally, there are two possibilities in the future: Curveship, and another I learned of recently, Prosemonger.

Two other ‘less possible’ possibilities are PUB, and any one of a number of Python mud engines (particularly those with Twisted, a lib originally built for mud IF).

But let’s talk about making a game, using Python, in prose-based, command-line IF (you know, what most people call, ‘IF”). That rules out Ren’Py, PUB (too old), and Python mud engines (too incomplete, or conversely, too complicated I think).

Curveship and Prosemonger are out too of course, as they’re not yet released. As an aside, while I’m eager to write with Curveship, from what I know I don’t think it will be much like IF as it’s played and written today. I think it will be more akin to an academic, generative narrative system, but only time will tell.

At this point a digression is in order (well, with me digressions always are in order, but I…OK, I won’t go there). When I say ‘towards popular Python IF’, what does that mean anyway? And why would you want to write IF with Python in the first place when there are at least five major IF systems that would fit the task very nicely — TADS 3, Inform 7, Inform 6, Hugo, and Adrift?

I’ll take the second question first. How does Python compare to these other systems?

First, let’s dispense with the VM argument — i.e., the relative portability of the Python VM versus the z-machine or anything else. In my opinion this won’t really matter in the future. Why? Because most mobiles, tablets, and so on will have capable web browsers. Therefore the portability of a VM won’t matter, so much as its ability to compile a game to something like a JavaScript source (here we may ask why someone is not writing a full-fledged JavaScript IF development system…and that would be a very good question!).

In this respect Python is in a good position. There are many parallel efforts right now to bring Python, or a Python to JavaScript bridge, to the browser.

These efforts attest to one big advantage of Python — its user base. There are many libraries that cover topics relevant to IF — language parsing, intelligent agents, knowledge models, and so on. Above and beyond that, there are numerous game and multimedia libraries available as well. All in all it’s a huge resource for an IF author.

At the same time, if you wanted to write IF using these libs, it’s a bit like making snowballs in an avalanche. What the IF systems do is make a domain-specific language available that puts you miles ahead of anyone trying to write their own parser and world model, or assemble one from third party libraries.

Python also has a couple of disadvantages in my opinion with respect to IF:

1. because Python isn’t an ‘IF language’, it doesn’t respect one important IF convention — the ability to make source code assignments and definitions without regard for their order in the source code file.

2. Python source code isn’t interested in the marriage of prose and code — I think this is a critical consideration when designing a structure in which to write IF.

Prosemonger and PyF, I think the two most viable ‘contemporary’ Python IF options (though Prosemonger isn’t yet released), both take a similar approach to the ‘IF writing structure’ — the world is declared in a structured markup, XML. This somewhat gets around the two disadvantages noted above, by setting up a universal structure — XML, and scripting — for the source code.

It’s a sensible approach, but as you may have guessed by now, I’m not sure it’s a good one. First of all, writing and editing XML creates a lot of friction.

A solution to that, of course, is a good XML editor, especially with a WYSIWYG authoring environment (I’m not sure anyone really advocates for hand-editing XML in the first place), but I wonder whether that really solves the problem? Regardless, in my own experience, I’ve always dispensed with visual editors and gone to the source code to get stuff done, and as a hobbyist it’s not like I’m really hardcore or anything.

Still, just from using Leo, I think structured source code is a good idea and I think as one ‘view’ of such a structure, a good visual editor could work. My take on this has changed from my original pawsy experiments — an attempt to write ‘prosey’ IF while including Python scripting. Such source code may not be necessary with the right editor.

The question is whether this editor is something that could be bolted on to an existing system (it doesn’t seem like such a tool is in the plans for PyF or Prosemonger). Furthermore this doesn’t really solve the first disadvantage above, that of source code assignment order. That’s really a problem that is asking for a compiler pre-parser (what most IF languages use I think), so now two tools are asked for, an editor and a pre-parser. It’s not like people haven’t made third-party tools like this for IF before (there’s at least one IF-specific code editor out there), but are the best tools made hand-in-hand with the system they’re used for?

I’ll punt on that question for a moment, because I don’t want to say that writing in XML is such a big downer that it obviates the advantage of the ‘Python universe’ of code. Writing an example game with PyF and incorporating Twython, for example, was really fun, and Python syntax itself is quite nice (opinions on this, of course, vary!).

Another major point in Python’s favor is it’s not weighed down by the multimedia or typographical constraints of the IF systems, all of which tend to roll their own solutions, rather than using common standards — for good reasons respective to each system, for sure, but it’s still something of a burden.

To go back to the first question, what does ‘towards popular Python IF’ mean? I didn’t say ‘making Python IF popular’, as I’m not really sure you could do that if you tried, but by popular I mean:

Easy to communicate for authors and players: Browser interpreters, sharing libs (i.e., extensions in IF parlance), sharing transcripts — on open, democratic platforms.

Easy to write: not in the sense of a visual editor, or filling out checkboxes instead of writing source code (which I emphatically don’t mean), but writing IF in a humane way, a people-centered way, without ignoring the essence of the work as a program.

So by popular, I mean, ‘for and of people’. Well, it’s a little ambiguous I admit, but suitable as a design goal nevertheless.

Where do I leave this, practically speaking? Taking PyF as a base is one starting point, and waiting to see what Prosemonger (and perhaps Curveship) is made of is another. I’ll try to get to some details of a structured source code IF editor in a future post.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: