Archive for the ‘IF’ Category
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.
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?
It comes up a couple of times that Earl Grey was criticized in IFComp reviews for not conforming to the IF community’s expectations — that it had ‘too much interactivity’ (not a quote of Parrish, but the interviewer) — but from what I remember of the reviews this wasn’t the main criticism at all, rather reviewers wanted more interactivity. They felt that the Earl Grey puzzles were unfairly arbitrary and obtuse, and didn’t explore the mechanics nearly enough. I’ll quote Victor Gijsbers at length (to make sure I include the good things he says, because I should add I did like Earl Grey a lot too):
This is a delightful idea, but its execution leaves a lot to be desired. There are simply too many words in the game that ought to be knockable, but aren’t, or that ought to be castable, but aren’t.
I can see how this would have been a pain to implement, but really, this game needs to be more open. We have in this magic system the perfect opportunity to reward player creativity and have multiple solutions to all puzzles, but instead, the authors have chosen to make the game very linear indeed. Only the things you must knock or cast or steep can be knocked, casted or steeped. Nothing else works.
The game, then, is not open enough, and is too difficult. Nevertheless, I enjoyed myself hugely, more so than with any other game in this competition so far. (Okay, I loved solving the card puzzle in The Grand Quest, but that was less because it was a brilliant puzzle than because my linear algebra skills were itching.) The writing was mostly very good. The scenes were evocative, if perhaps a tad too surreal. The implementation was very good as well. The side comments of the main character were a brilliant idea–the piece was much funnier for them, and also made more sense. In fact, most of the jokes actually worked.
But, most importantly, as far as the puzzles were solvable, they were great fun. This is interactive fiction doing one of the things that interactive fiction does best: using language in interesting new ways, doing things with it that could not be done in any other medium.
Of the eight competition games I have played so far, this is the first that might make it onto my list of “must play” games published in 2009. Not because it is perfect; it is not. But because it explores a very interesting puzzle concept in a highly competent and often enjoyable way.
Oh, and Rob and Adam? If you make a post-competition release which responds to more input and allows more solutions of the puzzles, this game might actually rise to the level of “great puzzle game”.
In any case, I definitely recommend it. A lot of other good interviews at Another Castle too.
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.
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?
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).
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:
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…
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).
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.
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.
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.
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.
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.
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.