Has this been done: IF as a "parasite" of regular compiler?

Hi all,

Since I still try to come to grips with writing IF, I guess quite naturally I find myself every now and then frustrated and run into dead ends with compilers, and begin to think to myself, “I could do this better!” (No, I’m not seriously in the stage of trying this.)

Then your mind begins to wander, and you start to think how you would go on about it. One problem is, that a decent IF compiler must have a more or less complete programming language “in its belly”. After all, what good is the IF, if you can’t perform at least some calculations, and if you don’t have functions, variable, blocks of code, etc.? That’s a lot of effort which only indirectly has to do with the IF problem at hand.

Then it dawned on me that perhaps one wouldn’t have to reinvent the wheel. After all, whatever language I used to write the IF compiler in, this compiler would have all the functionality already inside itself. So, whereas the current process is “Use language A to write your IF language compiler B, then use B to process a source file for your IF into a story file”, wouldn’t the next logical step be to reverse the roles? In other words, whoever writes a game with this system, simply writes a program in language A, includes the libraries with the actual IF functionality (parser, etc.), and then compiles it all together? (Of course, in this case there wouldn’t be a seperate IF compiler to produce a story file, and an interpreter to run it, but game source and If library would be bound together as a single executable.)

Of course, this would be tricky, because language A would have to be powerful enough to allow variable argument lists, etc. etc, but at the same time simple enough for the IF author to learn who has at the same time to invest in learning the library (the IF system proper) as well.

I’m just wondering, has anybody tried this? With what success?



There are some “IF as a Python library”, “IF as a Ruby library”, “IF as a Lisp library” etc projects out there. None of them have taken off in a noticeable way.

(Unless you count MDL as the original Zork implementation platform! But even that did not remain in common use. Infocom’s ZIL did not use MDL as the programming language of game code, only as the language of the compiler.)

The stumbling blocks, as I see it:

(a) You want some very basic constructs for creating objects, and when you try to offer this in a general programming language, you usually wind up needing a little too much boilerplate syntax.

(b) Saving state reliably in a general-purpose language sucks.

© Portability sucks. IF interpreters are polished these days and it’s hard to make Python measure up, especially when you get into web browsers, etc.

Another argument against this is possibly
(d) a separate interpreter creates a sandbox for the games to run in, while compiled executables could contain any kind of code really.

That said, I would love to see this happen.

I thought about doing a pure clientside web system, using coffeescript (which compiles to JavaScript). That partially solves some of the issues above, but may introduce performance issues instead.

Isn’t that the basic description of Zmachine and Glulx among others?

Probably the most successful have been Javascript games such as Aunts and Butlers (not that there are a lot of them) and I guess you could include games like Leadlight too. But in general they’re one-offs afaik.

Does z-machine create a sandbox: yes, of course, that was my point. Unlike native executables. (This all assumes the “sandbox” itself can be trusted).

Isn’t a web terp already a “pure clientside web IF”? well, yes, but the starting point for this thread was “why not use a standard programming language to create IF”.

And that’s another thing. If the game itself was written in JavaScript (or coffeescript) you’d be able to do anything you can do in a browser from within the game. Need a twitter feed in your game? Awful idea, but sure, check. Need jQuery animations? Processing.js graphics? Talk to a custom REST server side component? Check all that.

But this is just an idea. It may be a bad one. And anyway, not a trivial one to implement.

Edit: and wherever I say coffeescript you could substitute that for any other language that compiles to js, like dart and haxe.

You can use JavaScript in a game without writing the whole game in JavaScript - look at Quest (and maybe Vorple?)

I thought about that, but perhaps creative use of macros could alleviate this somewhat.

Chuckle, I agree. Serialising a game state must be a nightmare.

OTOH, since you would create an standalone executable with interpreter and story file bound together, there’d be no need for a seperate interpreter. You simply download the game as-is, no extras required, and the game should run on any platform the host language has compilers for.

Of course, multimedia support would be fairly hard to achieve.


JZEXE allowed bundling a zcode game with interpreter decades ago; I think ADRIFT 5 also has a “interpreter with bundled executable”.

Curveship is Python, right?

Curveship is in Python but I don’t remember how much Python logic goes into a Curveship game.

Here’s Cloak of Darkness for Curveship:

So yeah, this is Python. More info at http://curveship.com/index.html.

One solution to this problem is to write a clean* IF-supporting framework in C or C++, and then compile to javascript using Emscripten. Though of course writing IF in C wouldn’t be most people’s favorite pastime.

  • With “clean” I mean avoiding recursive event loops and longjmps, since that’s problematic in JS. This is why Tads at least can’t be compiled to javascript right now.

Pike seems to be an interesting candidate.

If I understand correctly, it was originally used as a MUD description language like MDL, but has developed a life of its own. At a first glance, it looks as though all there is to do is to add a little engine to evaluate the class structures written by the game author… hm.

Anybody having any experience with Pike?


I don’t think it’s too different from languages like C, Python, Javascript, etcetera. I think its ancestry is in the LP family of muds which were known for their flexible scripting capabilities (in 1995 :slight_smile: ). I haven’t followed its progress lately; I guess you’d have to make a case for why Pike instead of Javascript?

Hm. You have a point there. On my radar, JavaScript was a language for web applications mostly, but upon looking into it, it seems that’s a somewhat outdated cliché.

Thanks for the hint,


Considering that Qt just got ported to Javascript it’s definitely a bit of an outdated idea! :slight_smile:

badassjs.com/post/43158184752/qt … emscripten

Is “IF as a Ruby library” even a thing? Any pointers?

I dunno, I googled “ruby interactive fiction”.