"It is a thousand times harder to make simple things
than complicated ones."
- Mikhail Kalashnikov
With so many existing IF authoring systems, anyone with the audacity to create yet another one really needs to justify that decision, particularly if it departs from the proven and widely accepted (at least within the IF community) usage of the Z-machine. Well, I'm a bit of a contrarian, and I've chosen to do just that. This essay describes why - in particular, it examines the fundamental choice of framework/library vs. specialized language. While I don't doubt that someone could create a better framework than JIFFEE, I do believe that any better system is quite likely to use this same basic approach. (Note that unlike the rest of this web site, this page does assume that the reader is an experienced programmer, as nobody else is likely to care about this material anyway.)
First a word about terminology, and the distinction between two approaches to providing "canned" functionality for someone writing in an existing standard programming language:
Now to the meat of the matter: is it better to create a customized language, i.e. one designed specifically for writing IF, or is it better to create a framework in an existing "standard" programming language? Let's look at a number of aspects of this choice.
This is the essence of the "specialized language" argument: We want a very low barrier to entry for beginners, and by designing a customized language we can create something that looks "almost just like English" and thus makes it very easy to get started. (Old farts in the audience may recall a very similar rationale regarding COBOL.)
While this argument sounds eminently reasonable, I've concluded that it is a false argument. When you look at it closely, even an "English-like" IF language is still really a computer language, it can still be formally described in BNF, and it's still probably parsed by a recursive descent or LR(1) parser. The bottom line is that the user is still going to have to learn some rigid syntax even if that syntax does bear a surface resemblance to natural language. (Again, think back to the experience with COBOL. If it were really as simple as writing in English, colleges wouldn't have offered semester-long courses in it.)
Actually, the real beginner isn't going to learn syntax at all; that's not how the typical human mind works. The beginning IF author is actually going to look at examples in the tutorial and imitate them, probably via cut-and-paste followed by some editing. When you're working this way, it really doesn't matter whether the syntax is:
DESCRIBE lobby AS You're standing in the lobby of the Opera House.or
traits.set("lobby", "long-desc", "You're standing in the lobby of the Opera House.");Either way, it's not really English, and either way, it will only take even the rankest beginner a few minutes to get the hang of whatever the syntax is.
Here a specialized language does have the edge. Using any conventional programming language interpreter or compiler will inevitably lead to error messages - especially about syntax errors - that have no discernible relationship to what the user is trying to do. It's probably possible to write lint-like preprocessors that would do a better job of reporting, but running them could be awkward. The best bet is probably to keep the framework so simple that only a very tiny subset of the full language is needed for beginner-level programs, thus keeping the number of likely errors to a correspondingly small set which the user can quickly learn to recognize.
Making it easy to write "Hello, world" is a noble goal, but no game worth playing (or writing!) is going to stay simple and declarative for very long. Almost immediately the author is going to want to add some variable behavior. You can use templates or forms or patterns or any kind of sugar-coated syntax you want, but the truth is that as soon as the first customized conditional logic appears, the IF author is now programming. The authoring system designer has to specify a well-defined, complete semantics for this conditional logic, and the IF author has to learn it in order to do anything interesting with the system.
You can try to design your own way of doing this, but we already have a way to specify conditionals that has been around for years and is well-proven. It's called an if-then-else statement. If you look at all the major mainstream programming languages (even including things like LISP and Smalltalk), you can't help but notice that at the semantic level they all use roughly the same structure. That's because it works - not just at the level of what the computer can do, but also at the level of how people can think about it.
If you try to use English (or any other natural language) to specify a conditional as unambiguously as an if-then-else statement, you will end up with something that looks like it was written by a paranoid obsessive-compulsive attorney.  This is no accident, since attorneys are paid to remove ambiguity just like programmers are, but they have the terrible disadvantage of being required to so so in English.
So whether you roll-your-own or use something standard, a game of any sophistication is going to require the specification of complex logic. You might as well use a standard way of doing it. Note that this need not increase the difficulty right at the very beginning of the learning curve, since total beginners really will be working at the "Hello, world" level. This also doesn't prevent a framework from providing a bunch of canned logic for common actions that can easily be invoked declaratively, e.g. facilities for picking up and moving objects. It just says that at some point, probably fairly soon, an IF author is going to outgrow the predefined facilities and will need to define some real logic, and it's important that the IF authoring system provide good facilities for doing so.
To really put this in proper perspective, take some code from a non-trivial program (even "Cloak of Darkness" will do) written in an existing IF language, show it to some non-IF friends, and ask them to explain what the code does. Even if they are programmers, I suspect they won't be able to produce a coherent and accurate description. (The same would not be true of a Java programmer looking at C++ code, or a Python coder reading Java - in those cases, although they will miss details of how iterators and scoping work, they'll at least be able to follow the basic flow of conditionals, loops, and subroutine calls.)
When we author IF, we obviously want our creations to run on as many different computers as possible. In the early days of IF this was a difficult challenge, and designing an intermediate virtual machine was a proven and practical technique to achieve portability. Even mainline languages like Pascal used this approach. This led to the Z-machine, and that worked well.
Once you get serious, you want to write serious games. Really serious games, that require serious computation, complex logic, and sophisticated implementation. Taking a language designed for newbies and extending it piecemeal to try to add power is a recipe for trouble, and even if you do manage to avoid inventing a spaghetti language it will still be a huge amount of work to implement and test, and at the end you'll have laid one more brick on the Tower of Babel of computing languages.
As they say, the proof is in the pudding, and without empirical evidence my opinion is just, well, opinion. The only way to find out for sure is to try it. Alas, since JIFFEE is quite new I don't have any solid evidence either way yet, but I am piloting it with real people (currently, non-programmer middle-school students) to see how they do with it. Time will tell.
JIFFEE and JIFFEEgames.com copyright © 2007-2010 by Michael S. Kenniston. All rights reserved. This page was last updated on 2010-01-01.