Burn The Koran and Die Released
Burn The Koran and Die is a political satire which riffs on the (in)famous Pick up the Phone Booth and Die games. It’s short, sharp, and about 270k in size. Grab your very own copy here. Enjoy! 
I7 Request List
I’ve run out of points to spend on the I7 Feature Request site, so I’ve decided to make a public list of ideas until I get points back.
1) More ways to refer to parts of kinds. It would be nice to have some kind of notation to always be able to access a particular part of a kind, like using the dot(.) operator.
2) Allow more than two operands in a rule. Right now, you can’t say if (A) and (B) and (C), if that’s in a rule. Likewise, allow more than one operand between brackets in a Say command. Right now you cannot say “[if a and b]text[else if a or b]text2[end if]“.
3) For rules that apply to a kind, it’s not clear when you say something like this: Instead of attacking a bird — that bird is a kind. It would be better if kinds required a particular article, like any. That way you could always tell at a glance whether you were referring to a kind or a thing. E.g.
Instead of attacking any bird, say “But they are your brothers!”. [Bird is a kind.]
Instead of attacking the otter, say “After he helped you build the dam, surely not.” [Otter is something besides a kind.]
4) Constants. It’s dangerous to force the programmer to use variables where constants are intended because some other code could change those values. Why should I7 make creating games more difficult for the programmer?
5) Allow for variable word order. If I7 is supposed to be natural language, one of the features of NL is that word order is not strict. That is to say “Now the player is swimming.” and “The player is now swimming.” are equivalent in every way except for slight emphasis differences; the truth value they communicate is the same. However, I7 accepts the first but not the second. In fact, you could argue that “now” itself should be optional, because “The player is swimming.” means the same thing as “Now the player is swimming.”
I7: He Reached Too High
I’m reminded of the closing words of one of the classic film noir films: “He reached too high,” upon reading this I7 vision-cum-Brave-New-World statement:
It’s probably fair to say that we are more likely to accept suggestions if they follow the grain of Inform. There are well-established conventions used by all well-established conventional programming languages, but we don’t necessarily follow them. We’re not very interested in traditional computer-science syntax, and more interested in thinking about how natural language – and books, and newspapers – communicate.
I say the following as someone who has been interested in AI for a while, someone fascinated by linguistics, as an author, poet, programmer, and a thinker: the above is hubris. Computer languages exist because the first interaction en route to writing or game-creating, is between the creator and the computer, i.e., between a human being who uses language naturally and an unthinking, unfeeling, amalgam of silicon and steel. Until you can do a good job at modeling language itself, this initial conversation must necessarily be an compromised language, which means that it must be a language that the computer is better skilled at understanding. The short and witty moniker of such languages are “computer languages”.
What have the fields of translation and cultural studies in large taught us? That when languages butt up against one another, new languages develop, usually for the purposes of trade; these are called creoles, or even pidgins. Computer languages are man-machine pidgins that allow different creatures (man and machine) to converse intelligently. To treat the machine as though it were a human, in telling it complete and complex sentences could be attempted — but Inform 7 is not the tool. Such tools require neural networks, worldview information (either large databases or access to large databases), excellent parsers, and so forth. They must be dedicated to the task, and even then, they do not so well. Inform 7, which has its goal of being a tool to create interactive fiction, simply falls short, and painfully short in this task.
What happens when you attempt to interact with Inform 7? You at first treat it as a computer language, which does not work. It does not support the linguistic shortcuts, or the conventional pidgin notations of other languages; then you attempt to treat it as it says it should be treated — as a human. Yet, when you do that, you find that it has some severe limitations. There are many, but here are a few illustrative examples:
- Tabs make or break what the compiler understands. This is incredibly out of place for the realm of natural language, especially given that tabs are supposed to be a convenience for programmers, not a requirement; in terms of a natural language equivalent, they are pauses, and all human speakers can gracefully elide the pauses and yet understand the sentence.
- You cannot have more than two objects in a grammar line. You cannot say if A and B and C. In natural language, this restriction would redact many novels (especially those of Romantics) into confetti, to say nothing of what it would do to speech.
- You cannot use a verb with more than one object. You cannot say if reading a book or a newspaper. This too would decimate speaking and writing.
- You have no synonyms and the order of phrases is usually fixed. The beauty of natural language lies in its expressive power, which is a result of its synonyms and its flexibility in structure. It does no-one any good to whisper promises of natural language and then refuse to understand the speaker when he places an adverb last instead of first.
The concept that you, the programmer/author are speaking your game/work into existence (quite like God) quickly hits the brick wall of a limited implementation. The result is not a familiar programming language, where once you have learned the core concepts, you can apply them to other languages; nor is the result some peaceable conversation where you are writing to someone else, who understands what is being said, occasionally asking for clarification. The result is something like an argument with a child in Spanish, when you do not know Spanish.
Sadly, that sort of experience burned out an entire generation of AI researchers. All those who praised ELIZA or SHRDLU to the skies, who went gaga over Dragon Naturally Speaking, or fell prey to whatever glorious thing some robed and titled intellectual promised would revolutionize the world, are still locked out from the basics of the field: passing the Turing test. Inform7 falls into the same collection of yesteryear’s overhyped promises and failed revolutionary campaigns.
All it produces in the end is an odd, perhaps petulant, little language that is neither one thing nor the other. It pretends to understand you, but really mollycoddles you. It hides its woeful lack of power underneath a pleasing exterior. It forces you to use an amputated English, like that a traveler overseas, flipping frantically through a pocket translation dictionary. Worse, by failing to heed the lessons learned in previous man-machine communications (i.e. other programming languages), Inform7 fails in ways that others have already failed; as a result, its hubris leads straightaway to its mockery.
Inform7 does not deliver upon its grandiloquent vision, and it could never have hoped to. Indeed, thinking that it comes anywhere close insults both of its parents: programming language and natural language. For those who want to learn to program, Inform7 is not a helpful language, for few of its constructs can the new learner add to his or her mental toolkit. And for writers, having your own native tongue circumscribed in unexpected and irrational ways is so artificial as to incite rebellion, not complaisance. Writing embodies freedom and Inform7 embodies a bizarre kind of straitjacket where you are always discovering new ways in which your words do not work.
And in the movie, the man who reached for the stars in the circus, did so by scamming others, playing a dangerous game of deceit and threats; in the end, the only job left to him was circus geek, who ate live chickens in exchange for liquor and a pittance. He had pushed against the universe and found out that his method was doomed from inception; he burned the candle at both ends, and found that it tapered away rapidly, leaving a greater darkness than before it was lit.
He, like Inform7, had reached too high.
I7: Multiple Source Files on Mac OS X
There is a way to do this, thank God. It’s basically saved my project, New Cat. Here’s what I did.
Requirement: Inform7 installed, and a good source code editor. What follows assumes that you are using Smultron, but really, any editor that can execute UNIX commands will work. I’m on 10.5, but if you’re on Snow Leopard, check out Smultron’s successor, Fraise. I’d imagine it works the same way.
Step 1. Add Inform7 to the languages that Smultron recognizes. By default, Smultron doesn’t know about Inform7. No problem. Open up the application package in the Finder (control-click Smultron and choose Show Package Contents), and dive down into the directory: Contents > Resources. Double-click the Syntax Definitions.plist, which will open it in the Plist Editor (unless you’ve chosen another editor, of course). Once you’re in there, add an Inform7 entry that follows the same structure as an existing entry. Then save.
Step 2. Configure the syntax highlighting of Inform7. Go down into the Syntax Definitions folder. There, create a copy of an existing language plist (I used C), and name it Inform7. This name must match the name you used in the Syntax Definitions.plist. Then, double-click on that and customize it to fit Inform7.
Step 3. Set up your environment. This is wholly up to you, but it does assume three things:
- You have copied the ni compiler and the inform-6.31-biplatform compiler to this directory. This is optional, but I did it to keep down the length of the script.
- All your source files live in this directory.
- You’ve already created an inform project. In the end, this may not be necessary, but I’m going with the principle of “modify the least possible”. At any rate, you’ll still be able to edit in the IDE if you wish, and that might prove useful during the release phase.
Step 4. Set up Smultron to paste together your multiple source files and then call the Inform7 compiler. In Smultron, choose Tools > Handle Commands > Show Commands Window. Then, in any collection you want, add a new command, and name it something like “Paste I7 files and compile”. Select in the lower pane, and enter the following code:
#!/bin/sh
/bin/cat /users/zzz/Projects/Inform7/main.ni /users/zzz/Projects/Inform7/rooms.ni > newcat.inform/Source/story.ni
/users/zzz/Projects/Inform7/ni -rules /Applications/Inform.app/Contents/Resources/Inform7/Extensions -package /Users/zzz/Projects/Inform7/newcat.inform -extension=z8 -log
/users/zzz/Projects/Inform7/inform-6.31-biplatform -wv8s /users/zzz/Projects/Inform7/newcat.inform/Build/auto.inf /users/zzz/Projects/Inform7/newcat.inform/Build/output.z8
Note that the paths to the compilers vary depending on where you put them, as will the path to your source files. Also be sure to list all your source files IN ORDER on the third line prior to the greater than sign. The “newcat.inform” is the name of your project created in the IDE, so it, too will vary.
Inform7 Hates Programmers
Although I’ve talked about why Inform7 doesn’t work in several posts already, I think the summing statement is this: Inform7 confuses the role of player and author. That is, the player may want to read a book, or play a book (as some games are), but the author doesn’t necessarily write in that way. The I7 developers show an absolutely shocking ignorance of how writers and programmers work.
For instance, if you look at the documentation on Headings, you’re blaisely told that one long huge document is just as useful as several separate documents, split up according to programmer will.
This is a risible statement for ANY writer who has worked in MS Word. Those of you who have know that Word routinely corrupts, mangles, and does strange things with large documents. Even today, as of Word2007, I’ve found corrupted and strange styles (the Char Char issue, anyone). Because I deal with Word all the time, there’s no way I would buy into writing a large document in a single source file.
Not only that, but it’s dangerous from a data-loss perspective to put all your eggs in one basket. If you lose that one file, brother, you’ve lost it all. It’s much safer to split up your code or your chapters into multiple files. Computers are prone to faults; hard drives (even solid-state drives) are prone to failure; power loss can come at any time, and woe unto you if you have pets or children!
The sad thing is that even a cursory survey of programmers and writers would reveal this simple singularity: we don’t all write/code the same way. Thus, why would you design a language that presumes that? It’s madness, that I have to presume comes only from ignorance — either coding without knowing, or coding assuming that everyone is just like you.
Even worse, is that this assumption of a single source file, is based on an outmoded assumption of writing/coding. The designers of I7 are not familiar with technical writing AT ALL. I say this, in sorrow, not in some kind of victorious battle-cry. In technical writing, the days of long single-file source documents are over, and they have been over for nearly 10 years. I7 is 10 years behind the curve. Why is that?
In technical documentation, which by nature has to reach several different audiences, REUSE IS KING. You write with an eye to have that procedure reusable in the training material. You write that overview so that it can be included in other writers’ topics. This is made possible through an XML back end, and through some sort of user-friendly front-end. The documentation is then stored in XML and assembled according to how you publish. If you publish the XYZ book to PDF, then certain rules are applied a PDF document emerges. Programming faces similar challenges, which is why it makes sense to allow multiple source files; in fact, every other programming language allows multiple source files; I7 is alone on that score.
Further, hypocritically, the source code for Inform itself is in several source files. It certainly is not in one huge file. So why would the designers of this language presume that we were any different than they? We’re doing the SAME DANG THING.
Even further, there is nothing difficult about stitching together different source files at run-time. You could even force a manual refresh of the index, the skein, and so on. So there’s no real technical difficult in allowing this.
I just don’t understand the caprice, here. There’s no reason for it, except willful blindness.
The Fatal Flaw: No Multiple Source Files
Update: The restrictions on multiple source files are strictly a function of the IDE (which to be fair to Andrew Hunter, I don’t think that he purposed this restriction). Anyhow, there are ways to compile I7 code using the command-line tools, and really, they’re not all that bad. See this newer post here.
We don’t have an infinite amount of time to thoroughly investigate the tools that we use. We do the best that we can and then we go forward, in reason and in faith, to then create, using those tools. That there will be surprises should be no surprise. Yet, the fatal flaw somehow manages to surprise.
Never would I have thought that Inform7 would, by design, disallow multiple source files. Let me restate that: you must fit YOUR ENTIRE GAME into ONE SOURCE FILE. You cannot include files; extension solutions are hacky and frustrating; there is no outlet, and no hope.
I write like I program — that is, with a main or controlling master file, and then supporting files. This is especially critical in long projects, where you’ll need to remember the plot, the world, and have character sketches at the ready. Likewise, in programming, I have one main file and then multiple included files, for rooms, characters, the intro, and so forth. Just as I reach the point where I would naturally split up the project, I find out that I’m condemned to scroll up and down in some kind of programming topeth. This infuriates me.
Not only does Inform7 suffer from several implementation problems, the supplied documentation does not understand the audience, but by design, I7 has decided to either drastically reduce the size of games or punish with 40 lashes people who think a certain way. Why? There is no answer, except the stoic leer from those who punish people for using their tools.
I’ve pushed on, through bugs, through asinine language constructions, through IDE malfunctions that won’t be fixed, only to arrive at, at long last, a wasteland. This is the literary equivalent of the hero overcoming every obstacle to reach the enemy castle, only to find that as he arrives, the princess’ dead body is hurled over the parapet walls.
I guess I’ll have to port it now.
Inform 7 Bug Tracking Used For Personal Attacks
Needless to say, I was surprised and nonplussed, coming across this. So now, reporting an issue with the product becomes an invitation for attack? I held my tongue on the ticket itself, because that’s not the place for retaliation, only for a clear and calm discussion of the issue being reported. I did, however, inform Ron Newcomb that I was reporting him to the admins.
I have done so. Now we’ll see what they do. I’m not going to issue any prognostications at this point, because I don’t know who runs it, although I do see some names I know in the power structure. The TOS for those systems are pretty standard, and harassing/demeaning/personal attacks are usually forbidden.
So, that aside, it makes me wonder anew — what kind of people populate the IF world? Ron Newcomb apparently has so little control of himself that he uses a bug tracking forum to attack people. Bahahah. That’s a bit third-grade, isn’t it? How petulant. How immature. How sadly, dispiritingly, typical of the IF “community”. And no, I’m not being hypocritical. If I saw Emily Short post a bug report, why would I care? If I saw Zarf post a bug report, why would I care? The point of the bug tracker is to report bugs — that’s it. I don’t see why that’s hard to understand or live by.
This reminds me of some folks who inject politics into everything in an attempt to browbeat everyone around them into their way of thinking. The same subversion of forms is at work here, the same disrespect for the common areas of the community, the same childish arrogance and egotism.
It’s now upon the I7 bug tracker folks to do the right thing.
Select-a-Word Games
I was caught unawares in a very nasty surprise by the game Room 206; what I assumed was a broken game was in fact, one of the “new breed” of interactive fiction, if by “interactive” you mean the PC as a retarded monkey pointing to shapes on a wall and grunting out single-word commands.
My issue with these select-a-word games is that there is no interactivity involved. They are even less interactive than choose-your-own adventure stories, because even those books/games give you explicit options. I.e. a CYOA game might give you a menu of options, like so:
1. Attack the troll with the sword? Turn to page 10.
2. Attack the sword with a hair dryer (turned up to 11)? Turn to page 14.
3. Convince the troll that he is working against his own economic interests and teach him how to organize his community? Turn to page 17.
Those options may not cover the entire range of possibilities, but they give you a choice of several explicit actions. When you turn to page 10, you expect to get the result of choosing to attack the troll with the sword, not the results of the other two options, and you always get that, too. The CYOA presents an interface which the player can trust implicitly.
But when you’re faced with the below, what do you expect?
You stand on a cliff edge. The wind whips your long hair in your face, making you think about getting a hair band or at least a scrunchi. Your best friend’s diary lies in your hip pocket, and a bottle of bourbon lies at your feet.
No-one really knows what clicking or selecting or typing one of the seven magic words in the paragraph means or will do. There’s no way for the player to predict; as far as he or she knows, all of the words are instant death. In fact, that appeals to the twisted contrarian in me — making a game where each of the magic words leads shortly to death.
In GUI terms, select-a-word games are not stateful. The player can derive no realistic expectation of what will happen next, and because of this, he tends to advance with trepidation, saving every move, and greeting new choices with fear, rather than with confidence. The sad thing about this relatively new development is that we’ve trod this path before. The reason why we know about statefulness is because of human factors/man-machine interface knowledge, and that has bubbled upwards because of years of awful GUIs that required memorization of each and every screen in order to do things. Then, like now, statefulness was absent. The user did not want to explore except if he was feeling particularly lucky or had a penchant for self-abuse. To be certain, those GUIs did not sell their product well, and neither does the select-a-word interface sell its games very well; the select-a-word interface is yet another manipulative, hide-important-things-from the player design whose ancestors were the “killer” games of yesteryear. You might remember them: those games bragged about all the ways in which they could kill the player, purposefully obscured the obvious just for the sake of difficulty, and featured scads of “instant death” rooms, which required the player to save every turn just to safeguard progress. Generally, players hated those games and only tolerated them because there was nothing else to play.
So why return to abusing the player? I have always wondered why we have not pushed IF towards a more simulationist direction. It is not conceptually difficult to implement a neural net and have it learn from a player’s playing experiences; nor is it conceptually difficult to integrate a database of information common to the world of the game which could be accessed quickly using SQL; this is to say that while none of today’s authoring systems have the capacity to push IF to a more truly interactive mindset, the raw capability is here which was not in the ’90′s or the ’80′s.
Select-a-Word, like Twitter, is a step backwards, a retreat from the land of milk and honey back into the safe, painful, and known slavery of Egypt. Yet some will always choose limits and manacles over freedom and I suspect it is those sad souls who also favor this retrogressive approach to IF authoring.
I as a freedman, deplore this with every ounce of my strength.
Conversation as Strategy
Why doesn’t conversation in IF work? Mostly because the player means a specific thing when he or she types in something to say, and the parser, being a resource-constrained and programmed thing, usually doesn’t come close to doing what the player expects. One way around this is to institute a general “talk” command which lets the character half of the PC do the talking. This works fairly well, except when the player wants conversation to serve some particular end. That is, instead of just talking, the player wants to threaten, joke, and so forth. But wait, isn’t all conversation intentional? If we take the burden of creating the conversation off the player and put it on the character, while still granting control to the player, then we could get a bit closer to a truly interactive conversational system.
I’ve been thinking of doing exactly that, and it would be a setting wherein you’d do a lot of talking. Imagine being a high-school girl. You spend 99.99% of your day talking (or a little more) , so intentionality is extremely important. Thus, if you had a conversational menu for everyone you came in contact with, it’d look something like this:
A – Attack | B – Bye | C- Compliment | J – Joke | S- Small Talk | T – Threaten
You’d have your usual commands for doing physical things. An interaction might go something like this.
A-wing, by your locker
It’s early and you have fifteen minutes before homeroom. Cindy, the snooty upperclassman is here, fiddling with her locker. It’s right next to yours. You’ve tried to befriend her, but she treats you like a dog. If it wasn’t for her totally awesome younger brother Steve, you’d ignore her.
> G(reet).
“Hi Cindy, what’s up?”
She looks in your general direction and tosses her hair, pulling her locker open.
> A(ttack)
You don’t dare. She could start a rumor that would make your life suck for weeks, if not half the year.
> S(mall talk).
You talk about the basketball game, knowing that she’s dating the star forward, and how lame it was that they lost by four points.She turns to face you and says, “I know! They totally cheated! I hate Tatertot High!” By the time you get your books out of your lockers and shovel them into your backpacks, you feel like you might be able to ask her about the stuff that Steve is into.
There’s a tradeoff here, I know. You’re replacing the guessing game of the Say command and the scripted dialog of the Talk command with more verbs and more discrete answers. More discrete answers requires careful design of each conversation and better yet, multiple paths through each. This doesn’t really threaten a complexity explosion as even multiple paths through several conversations are a discrete number of paths. You could disallow certain responses based on your character’s mood and/or close off certain responses with stock responses depending on how the conversation is unfolding to help reduce the amount of work. Knowing the protagonist well would also help. Say the protagonist is Timmy the Geek. Timmy, for the sake of the game Timmy Vs. The Jocks, would never think of verbally threatening Bill, Steve, or Mike, at least until he learned that each of them were failing Algebra.
You could go overboard with this and end up in completely menu-driven system, which would steal away the mimesis of not relying on a menu system in the first place. That is to say, if the initial conversation menu gave way to another menu and then a third (if you allowed Q for ask question, and then descended to asking a question about someone, and then asking something particular about someone), then the seamless nature of interaction becomes artificial and calculated. You don’t want to err too much on the side of strategy as that pushes the whole nature of IF (somewhat artificial in that you have as much time as you want to choose your next move) completely into the camp of pure strategy. All this system does is add a touch of strategy, enough to increase realism and return intentionality to the focus of conversation.
Using Pointers in INFORM 7
I was told, briefly, by someone that INFORM really wasn’t for using pointer arithmetic, as though here (at the end) I was asking for something completely impossible. Yet nearly all programming languages allow for pointers and arithmetic pointer manipulation.
Guess what I found cruising through RGIF? Check out the post here. Basically, someone wants to set up a table of pointers in INFORM. Although this doesn’t involve pointer arithmetic, that’s the next logical step.
Well, how about that?
