April 30, 2006
Announcing: Inform 7
After years of work and anticipation, Graham Nelson’s new interactive fiction development system, Inform 7, is out. The new system is in many ways more different from Inform 6 than OS 10 was from System 9: Code looks like natural language (like English prose, specifically), a new and well-crafted IDE from Andrew Hunter is provided, and numerous improvements to the language and world model have been incorporated. Games still compile to z-code, however, to run on the standard interpreters that run earlier Inform games.
Copious examples are provided in and alongside the manual, Writing with Inform. An excerpt, for example, from the source code to Emily Short’s Bronze, mentioned previously here on GTxA:
The warning sign is scenery in the Entrance Hall. The description of the warning sign is “You know the words by heart, having heard them first from your father, and then studied them yourself on many more recent occasions.” The printing of the sign is “Those who seek to leave the castle depart at peril of their lives and souls, unless another servant be provided in exchange, or a fixed term of absence be granted by their master.” Understand “old” or “familiar” as the sign.
Stephen Granade also offers an overview of Inform 7 on Brass Lantern.
April 30th, 2006 at 5:04 pm
SPAG (Society for the Promotion of Adventure Games) #44 is out today, too, and includes an interview with Graham Nelson and Emily Short.
April 30th, 2006 at 5:40 pm
What do we all think of the natural language source code? I, for one, am uncertain. I’ve been using Inform 6 in my Introduction to Computational Media course, and I’m not sure I’ll want to switch to the less “codish” code of 7.
The IDE is gorgeous though. And it does compile Inform 6.3, or at least it will after I get the library files in the right place
April 30th, 2006 at 5:47 pm
Ah, interesting! From Brass Lantern:
That’s not to say that I7 isn’t related to Inform 6. The I7 compiler converts its source code to Inform 6 source code, then lets the Inform 6 compiler turn the game into its final form. I7 is thus built on top of I6 in the same way that Rome rests on the bones of its past.
April 30th, 2006 at 6:28 pm
Looks great to me, on first blush. For ease of authoring, it makes sense to make a more abstract (e.g., higher-level) authoring layer on top of a more code-based layer, that compiles to the code-based layer, that then compiles to an executable. The higher-level layer may be less expressive, technically, than the code layer — that is, there may be functionality that requires coding, that can’t be expressed in the higher level authoring language. At the same time, the higher level language may experientially, for some, be more expressive, because it’s easier to use.
Congrats to Graham Nelson and all that contributed.
You didn’t mention, Nick, that Inform7 is released 10 years to the day later than Inform6! Neat.
April 30th, 2006 at 10:13 pm
Interesting, but I’m not convinced that it is really an improvement. A lot is claimed in terms of “readability” and “ease of writing”, but to me it just looks verbose. The “naturalness” strikes me as an illusion: the same precision of syntax is still as necessary as ever, only now it will be harder to spot mistakes because they look like correct english.
That said, it does look like the underlying mechanisms of the language (eg: declarative rules rather than procedures) are more natural ways of expressing the typical kinds of processes in authoring IF. And anything which makes IF coding less daunting more intuitive to non-programmers is a good thing in my book. It would be very interesting to see some rigorous empirical study into whether this language “works”.
May 1st, 2006 at 9:16 pm
As an ahem, non-programmer, I find this very intriguing, and I’ll frankly admit less intimidating than its predecessor. I also really love the idea of code that could be pleasantly readable to a nonprogrammer from a “codework” perspective. That is, I can imagine writing constrained prose in this form that would be designed both to be compiled and played and read separately in its own right. I understand why, on the level of efficiency, this might not be an improvement, but it’s a wonderul impulse on the part of the developers. Think I might give it a go.
May 1st, 2006 at 10:04 pm
Putting aside the natural language thing, how about that IDE? The testing features, transcript, and skein are all great innovations.
As for natural language vs programming code, you can still use Inform 6 in the IDE although I’m not sure how well that will work.
I’m not given to gushing but I reckon this is an exciting announcement.
May 6th, 2006 at 1:25 am
What gives me faith in the pseudo-natural language interface is the belief that the precision required by the compiler will come naturally with practice, and that writing the way the interpreter needs may prove to be as easy as adopting any other writing style. Much as how an IF player and an IF game meet somewhere in the middle with a little practice by the player and a little thoroughness by the game author, the Inform 7 compiler strives to understand as many sensible variations in syntax as it can, and the author strives to give the compiler the precise language it needs. (The author would not intentionally try to trip up the compiler with florid language.)
I do expect that, just as games can be frustrating to play because the author hasn’t coded certain alternatives that seem intuitive to the player, Inform 7 Beta may prove to have a few language hang-ups, but hopefully they will be minor and can be cleaned up during the beta period.
In fact, I’m more concerned with the elements if I7 that do not resemble natural language. At first glance, those seem to be more specific and code-like, and not amenable to a natural flow of writing.
I admit that learning to write natural language in a particular style, such as a style that would be acceptable to a compiler, requires a bit of skill. The cool part is that it’s a writing skill, not a programming skill, and I suspect many non-technical writers will be able to pick it up pretty easily.
May 6th, 2006 at 7:41 pm
Perhaps the most important difference in Inform 7 is that code samples are much easier for non-programmers to read.
While you still have to THINK like a programmer to write in Inform 7, I think this will be much easier for non-programmers to pick up.
I’m definitely switching to Inform 7 when I teach two new media classes this fall, and I’m even going to try it in a freshman comp course. We’ll see what happens.
The one-step installation of the IDE is reason enough to make the switch. I had to spend a whole day in the computer lab, just installing the various components of Inform 6, WinFrotz, and teaching my non-programmer students where to find their files after they were compiled. Even dragging and dropping a file icon to an exe icon caused a lot of stress for a significant number of students.
May 7th, 2006 at 7:35 am
Besides the psuedo-natural language aspects, the underlying structure of the language seems very interesting. It would be interesting to see how well it works with speech recognition. I wonder if they use the same parser for the authoring interface as for the experiencing interface.
May 7th, 2006 at 10:50 am
I agree with SR, Inform 7, as a non-programmer myself, looks a lot easier to use. I’ve always felt too intimidated to try writing IF. But once upon a time I felt the same way about blogging, and before that hypertext, and so on. Maybe this summer I will try this out.
May 7th, 2006 at 1:19 pm
I7 uses as its syntax a small subset of natural language, but it is not therefore a natural language parser. It is instead a NL(-esque) programming language. The difference between NLParsing and NLProgramming is important for appreciating what I7 (as an experiment) can teach us about system design.
NLParsing takes true natural language as its object, and tries to make some (imperfect) sense of it. NLProgramming, on the other hand, is not natural language but coded instruction, which the machine by definition understands perfectly, because the rules of the game are determined by the machine. The form of address is as entirely different as the objective.
In terms of pros and cons, the benefits all come with qualifiers, and there are some real problems. The syntax is novice friendly (no ugly curly braces, etc.), but it increases the learning curve by occluding the underlying model (which a conventional programming grammar would more directly reflect); also, it sets the temptation to step outside the strict grammar permitted by the machine (and step into NL proper), which is always frustrated of course. Simple examples are easier for a non-programmer to read (that is, it’s more-or-less self-commenting), but the programmer has to parse the code (just like the machine) to find the underlying structure, so in effect it’s considerably more difficult to read.
May 7th, 2006 at 2:08 pm
Yeah, that was my first reaction–that the language is very well-tailored to its target audience. Whenever I ask (not-very-technically-minded) designers what kind of script/language support they want, they always respond in terms of dropdowns and cute graphical features; typing words and the possibility of syntax errors scare them more than a little.
But playing IF trains you to deal with syntax errors, and that some sentences are parsable by the machine and some aren’t; if you’re accustomed to that (I think–am too much a programmer to really judge) Inform 7 should come pretty naturally. It’s not a language for just any old non-programmers.
May 8th, 2006 at 9:20 am
I don’t like Inform 7. According to the posts on raif, it seems the new language is as confusing as any other. It also is less readable, in my opinion, for the same reason that saying “the square root of n plus 5” is less readable than its mathematical representation. Abstractions were created for a reason. I guess Graham never thought about code blocks being understandable by themselves, while paragraphs have to be actually read to be understood. Not to mention the fact that creating a grammar full of special cases is absurd. How many times people have asked a question on raif just to be answered with a: Take a look at chapter 20.2. It’s explained there? But what can we expect of people who say things like this: “It is probably not a good idea to try to use ChooseObjects by hand.”, and twelve hours later complains about the lack of easy access to ChooseObjects?
My main complaint about the language is that it assumes people are dumb instead of assuming the system is crap. “Oh, so you say Inform is difficult? I’ll make it easy for you.” Inform was never difficult, it was just badly designed. It has many limitations that only have historical reasons. And Inform 7 has done nothing to change this. It reduced tremendously authors’ freedom by enforcing several conventions that are not easily changeable (that is, in case they’re changeable at all). It doesn’t deal with the layout of the game, etc. It was always made with English in mind, never treating other languages as equal, and, thus, making translations awfully complicated. Also, the NL-like syntax has no advantage for me and many others. English is not our natural language. And let’s not forget that it is a very special kind of English. We could call it Aristotelian English. The need for a logic makes it unnatural somehow, just like Spinoza’s works, for example. I could go on and on. But the idea is this: Inform is outdated and should be superseded. Three years have not been enough for Graham to come up with something new or really needed. I wouldn’t feel sad if there wasn’t an Inform 8.
I hope I’m wrong, but I’m quite sure that if we make a study a year from now on the games written with Inform 7, there will not be many of them written by new authors and the games won’t be considerably better or revolutionary. So what have we won? Nothing. What have we lost? Three years.
May 8th, 2006 at 4:10 pm
Steve’s distinguishing between NL parsing vs. NL programming is a good one — that, essentially, Inform7 is still a programming language, where the keywords and language grammar happen to (by design, of course) coincide with a limited subset of the English language.
This allows those not familiar with Inform to read and understand at least parts of an Inform7 program; it may even allow those not familiar with programming to understand parts of it. However, when programming new code, you’re still up against the rigid rules of what programming languages typically require. (And, as others have mentioned, without some of the organizational features of most programming languages, such as braces.)
What would be really interesting, but an order of magnitude or three more difficult, is to move digital fiction authoring towards NL parsing, which would also require AI-assisted programming. In such a system, you could describe your IF world in less rigid, natural language — still very descriptive, at times procedural, but including perhaps some sort of Q&A mode where the system would ask you lots of questions about what you want to happen, even discuss it with you. For sure, you’d be very much underspecifying what’s supposed to happen in the world; you’re essentially giving lots of high-level direction, sort of like a client describing to a service provider what they want built. Then the (very intelligent) system would work with that, and fill in all the blanks you left out. Then, you’d play with the system and start micromanaging this and that, tweaking and tuning it.
Sounds crazy, I know, but I see Inform7 being a baby step on that path…
May 8th, 2006 at 5:07 pm
Good discussion of alternate programming approaches here. I’ve been playing around with Inform 7 and am very impressed both with the IDE, and with the declarative language (irrespective of the English-like syntax).
I see the Inform 7 language as doing three distinct things:
1. Providing a declarative, rule-based authoring language for IF. This of course could have been done completely separately from using English-like syntax – it could have looked like Prolog, or CLIPS, or Cyc-like predicate calculus. Inform 7 makes the ontology of inform worlds explicit in its declarative language.
2. Employing heuristics to make small inferences beyond what is explicitly stated in the code. The Inform 7 manual gives the example of Mr. Darcy wears a top hat from which, during compilation, the system concludes that Darcy is a person, because inanimate objects do not normally wear clothes, and the top hat is clothing. But Inform 7 doesn’t figure out that Darcy is a man, because it doesn’t know about the social conventions implied by “Mr.” (or the wearing of top hats). Again, this could have been done completely separately from using Enlish-like syntax – if the programmer instead specified wears(“Mr. Darcy”, top-hat), the same inferences could have been made by the compiler. Andrew suggests cranking this inferential capacity way up, which is a cool suggestion, but, as he says, very hard (like common-sense-reasoning hard). The ontology used by the Inform 7 compiler is all about physical relationships between objects – even in this domain, extending the inferential capacity is challenging. And as the domain becomes broader, moving into social relationships, the compiler starts needing more and more background knowledge. But I like the suggestion of viewing Inform 7 as a baby step in this direction. Languages like ML do this for types, but Inform 7 is the first language I’ve seen that does this in an everyday domain.
3. Providing an English-like syntax on top of the declarative language. It would be interesting to see if a more syntactically formal declarative language were also available (which would still be much more abstract than Inform 6) if programmers would naturally migrate from the English-like syntax into the more formal one.
May 8th, 2006 at 5:56 pm
Riffing on property 2, which I’ve found interesting while playing with Inform, and riffing on Andrew’s comment, imagine a compiler that could do this:
Mary’s expensive locket is in the jewelry box. Mary sits near by.
run
Mary’s Bedroom
An expensive locket sits in a jewelry box on the vanity. Mary glances at you, surprised, as you enter the room.
Take locket
Mary jumps up in alarm crying “Thief, thief, give me back my locket”
Examine Mary
Eyes wide, Mary stares at you with a mixture of shock and anger.
(Here the compiler inferred that, all other things being equal, a woman’s jewelry box and jewelry are most likely in her bedroom, thus the location must be her bedroom. The compiler fills in furniture based on its background knowledge of bedrooms. Entering someone’s bedroom unannounced is likely to surprise the occupant, hence Mary’s reaction. Taking something that belongs to someone is likely to shock and upset them – the fact that Mary becomes upset when the player takes the locket, plus default background knowledge, in this case, really cliches, about reactions to an owned object being taken results in Mary’s reaction.)
Mary’s expensive locket is in the jewelry box. Mary languishes near by.
run
Mary’s Bedroom
An expensive locket sits in a jewelry box on the vanity. Mary sits slumped in a corner. She barely glances up at you as you enter the room.
Take locket
Mary stares at the ground, sighing. Finally, she slowly raises her eyes, staring deeply into your own. “Go ahead, take it. Everything else has gone wrong lately…”
(Fancy inferences being made from the use of the word languish being used in the source code.)
Use Victorian World
Mary’s expensive locket is in the jewelry box. Mary languishes near by.
run
Mary’s Bedroom
An expensive locket sits in a jewelry box on the vanity. Mary sits slumped in a corner. She barely glances up at you as you enter the room.
Say to Mary “Why are you sad?”
Mary stares at the ground, sighing deeply. Before she can answer, you realize with a shock that her thin waist, her pale almost greenish complexion and her large eyes can mean only one thing – consumption.
(A compiler that makes domain-specific inferences to move beyond the source will need a large amount of background knowledge. Different collections of background knowledge should be nameable and invokeable.)
Use Victorian World
Use Hard-boiled detective Style
Mary’s expensive locket is in the jewelry box. Mary languishes near by.
run
An expensive locket sits in a jewelry box on the vanity. Some dame sits slumped in the corner, barely acknowledging your entry. Typical.
Say to Mary “Why are you sad?”
She stares at you – you could go for a swim in the depths of those blue eyes. Before she can answer, your well-liquored brain, hammering like a steaming, clanking Difference Engine, puts the clues together – that thin waist, those hollow cheeks, can only mean one thing – she’s bought a one-way ticket to the sanitorium.
(Since the compiler is highly generative, style should also be nameable and invokeable. Of course, combining arbitrary styles and background knowledge can create challenging generation problems for the compiler.)
Use Victorian World
Mary’s expensive locket is in the jewelry box. Mary languishes near by.
run
Mary’s Bedroom
An expensive locket sits in a jewelry box on the vanity. Mary sits slumped in a corner. She barely glances up at you as you enter the room.
Say to Mary “Why are you sad?”
Mary stares at the ground, sighing deeply. Before she can answer, you realize with a shock that her thin waist, her pale almost greenish complexion and her large eyes can mean only one thing – consumption.
OVERRIDE: Mary is sad because of unrequited love.
UNDERSTOOD
Say to Mary “Why are you sad?”
Mary stares at the ground, sighing deeply. Tears welling from her eyes, she finally gasps out, “I wander the moors thinking of him, but he hardly knows I exist.”
OVERRIDE: Mary’s unrequited love lives in town and works with Charles Babbage.
UNDERSTOOD
Say to Mary “Why are you sad?”
Mary stares at the ground, sighing deeply. Tears welling from her eyes, she finally gasps out, “All he cares about are those, those, Engines, and that oh-so-clever Lady Lovelace.”
(The back-and-forth dialog with the compiler should happen while you run the world. Essentially the “compiler” plus runtime system are an online, incremental story generator whose underspecified initial conditions are given by the “program.” As the generator makes up new content in response to player interaction, the player/programmer can override decisions made by the generator, essentially modifying the initial conditions.)
May 8th, 2006 at 7:06 pm
I’m sorry, but I’m just not seeing this “underspecification” meme working w/r/t interactive storytelling. Characterization is the opposite of underspecification. Maybe you can underspecify in your storytelling if you’re Scorcese directing de Niro, but if you’re a programmer directing a computer, you have a snowball’s chance in hell to succeed, IMO.
May 9th, 2006 at 12:25 pm
I’ve only looked at this since saturday when I first heard of it. I liked the previous version 6, so I have been anxious to get my hands on version 7. I’m a programmer first of all, so the verbose approach of Inform 7 makes me a little nervous. The code does not seem so readable to me – in fact it is difficult to get a quick overview of it. Maybe some better colorcoding and more comments in the code would help a bit? That said, I like the IDE – it’s really good for testing games.
I prefer the old manual. The new manual is spread across too many pages, and it would be nice to have it all in a single PDF file.
May 10th, 2006 at 12:45 pm
Dirk, I think the example above is actually of story generation and play, rather than storytelling. I think it succeeds in outlining an interesting possible experience, one quite different from traditional storytelling.
May 11th, 2006 at 6:57 pm
I have to say that I’m less convinced than ever about both “interesting” and “possible”, Noah.
Let’s start with “possible”. Michael wrote:
I really doubt that a compiler which can make such inferences in FOL is technically feasible. My doubt is based on Algorithmic Information Theory and the fact that one would have to encode algorithmically very complex cultural notions to enable a machine to make the inferences about women and their jewelry that Michael imagines. Long story short, I simply don’t believe that the mathematical tools that one would need to encode, say, American culture in binary form can exist, because the culture to be encoded is continuous, not discrete, and because Gödel’s Incompleteness Theorem pwns us all (push me a little, and I’ll spew the sorid details ;-).
But let’s pretend I’m wrong, and Doug Lenat makes a comeback, beause all of a sudden, Cyc works, and Michael gets his compiler with common sense built in (“Choose from 8 exciting cultural backgrounds!”). Now, how interesting could stories generated by common sense possibly be?
How interesting could Mary be, an AI-generated character that is a common-sensical woman who keeps her jewelry in her bedroom, is shocked when someboy surprises her, and complains when somebody takes something from her? You think this is a character that could make a writer famous? You think anybody would care?
Nobody ever used common sense to create memorable characters. Any writer worth being called one wants her characters to be as uncommon as possible. Mary stores her jewels in the fridge, of course – keeps ’em fresh! Mary just sneers at you when you “surprise” her, and if you try to take anything that’s hers, she pulls a nasty little surprise of her own. The audience for a waif crying “Thief, thief, give me back my locket” is limited, I believe.
How do you think a common-sense-based compiler could generate an uncommon character?
A certain form of “specified underspecification” actually does work, but all you can do with it is compress redundancy, not information. The information you need to encode to generate a surprise in the spectator needs to be put in there by the author – the machine cannot “generate” it on its own. What you can generate is the irrelevant, boring, template-based stuff (Will Wright knows this, and leaves the story generation to the audience altogether). But whatever it is that makes people go “Whoa – that was fresh!“, I don’t believe it’s common sense.
May 12th, 2006 at 5:30 am
If anybody feels like exploring this AIT stuff more deeply, here‘s a page with what Gregory Chaitin dubs his “understandable papers” on Incompleteness.
June 4th, 2006 at 8:45 am
Fantastic site! Thanks for the contributions. I will be certain to try some of the hypertext software that you point to.
CB
June 12th, 2006 at 8:12 pm
I can see josemanuels point about inform. On one level you could look at it as a dumbing down of the language. But as a non-programmer I’ve been really intimidated by most programing languages. I’m sure I could ‘get’ it if through lots of tearfull nights and hair pulling but… Inform 7 appeals to me not just because of the natural language aspects but because I can see the logic of the program I’m writing. This is something that I haven’t really been able to experience. I was able to get a rudimentary ‘game’ up and running quite easily. That isn’t to say that I haven’t had any frustrations. It’s still its own language that often only makes sense in its own context. Trying to figure out exactly how to ‘ask’ for the results you want can be challenging. Thinking like a programmer in a literate way…
June 14th, 2006 at 7:00 pm
I don’t see it as a dumbing down of the language. I see it as a dumbing down of the user. My own ideal language for IF would be one that lets you write in the same way that you think about your game, not in the same language that you think about your game. Inform was never really well thought in that respect. My humble opinion is that it was always meant for designing puzzles, not for writing stories. Instead of being object-based or rule-based, a good IF language should be storytelling-based. But I know that these are just empty words. I have no real development system to back them up.
June 15th, 2006 at 6:39 am
You take it into an interesting direction, josemanuel. Is there any way in which you can describe how a “storytelling-based language” could work?
I approach the challenge of designing “a programming language that I can write stories with” from the other side; basically starting with the acknowledgement of the fact that all computation is necessarily rule-based.
If I want to enable a digital device to participate in an interactive storytelling process, its part of the interaction must be computable, so at least the automated part of the storytelling (that which I’m writing, contrasted with that which a system user writes) must be rule-based (the user input is expected to be a random string with a probability weight). Using the Turing machine abstraction (as we do when we use any Turing-complete programming language), we get infinite storage, but finite control. And since it’s not a normal TM we’re using, but the Interaction Machine variety of a TM, non-deterministic operation is guaranteed, anyway, so in the interest of getting my story’s message through, I want to preserve as much determinism as possible. Rules rule, AFAIC. Or even more pointedly: Rules are the only game in town.
In storytelling, there are a lot of rules used for teaching it to others. Aristotle’s “Poetics” can easily be seen as the source code from which one can compile a rule-base that describes a well-formed story. There are many other texts (by Syd Fields, Robert McKees, Frank Daniels, Linda Segers, &c.) that can be compiled into such rule-bases. Some of the rules of storytelling – e.g., the Rule of Threes – seem to represent “global” functions, as they appear in all of the different story models.
So I assume that the set of languages which are suitable (to any degree) for interactive storytelling is a subset of the set of all rule-based languages, which happens to include the set of all Turing-complete programming languages. That’s the set I’ve been studying, with the result that, technically, any computable story can be written using any Turing-complete PL, regardless of the story model that is to be implemented. The writers choice (or, the degree of suitability she assigns to any candidate language) seems very much to depend on the dataype(s) you employ for your implementation of “storytelling” – if you’re using a lot of numerical abstractions, you might want to work with Java or Python, because they handle numerical types well; if – like me – you’re mainly manipulating dynamically subtyped objects of the string type, you might choose a language which does that well, like awk, SNOBOL, AIML, whatever.
Now comes the most interesting – to me – question: What kind of functionality should a PL which is in some way optimized for storytelling – and which I therefore might prefer to other candidate PLs for writing interactive stories – provide to the writer? A global operator that implements the Rule of Threes seems to be a good candidate for a primitive in such a language – any suggestions for other global operations on story spaces? And how could, for example, a global RoT operator be designed in a way that is not implementation-specific to some story model or engine – any ideas?
June 15th, 2006 at 9:29 am
Ronald P. Loui, whose work on the “Dynamics of Rule Revision and Strategy Revision in Legislative Games” is of great interest to me currently – to which degree can “Legislative Games” be equated with “Interactive Stories”? – offers an article titled “Why GAWK for AI?”, in which he investigates the question of why almost all of the best work in his undergraduate AI programming classes results from the use of GAWK, Gnu’s version of the awk pattern scanning language, which is deemed “pre-historic” by most “serious” programmers.
June 15th, 2006 at 1:32 pm
Ok, you know how a screenplay is written, right? It has a precise format. This format could be thought of as a programming language syntax. The good thing about this format is that it is designed to help all the people involved in telling the story do their particular work. Screenplays are divided in sequences because that helps producers in the planning on the schedule, and descriptions are there to help mostly everybody in deciding how to light each scene (day/night, ext/int), what pieces of furniture to put where and how to put them, how the actors should be dressed, where in space/time will the action take place, etc.
Now. A script is not the film, but it makes it easy for a director to know exactly what will come out eventually on the big screen. In other words, the screenplay format is suitable for storytelling. But Inform (or any other IF language that I know of) is not. That is not to say that it isn’t a great work. It is. A lot of it is still usable; but in general it is an outdated work. (Always in my humble opinion.)
As for the particular aspects that need to be changed, I’ve stated them already too many times in too many places, public and private, so I’ll just refer you to any of my last raif posts.
June 15th, 2006 at 4:35 pm
Yes, a screenplay is a program that is run on a movie production machine – that’s well worth noting. But that movie production machine mainly relies on continuous processors – human talent -, which can “read between the lines”. Discrete machines can’t do that. Instructions for any virtual movie production machine would run much longer that 120 pages, and it’ll never have any talent, besides counting real fast.
The good thing about computers, though, is that they’re endlessly mutable, which goes especially for programming languages. My experience is that, if you’re an artist who finds that programming language X lacks the feature Y that would let you express Z algorithmically, complaining to the language’s designer(s) is terribly ineffective. It seems faster to just figure out for yourself how to extend that language, and just do this.
Anyway, thanks for the hint; I’ll have a look at the posts you mentioned, see if I can learn anything.
June 15th, 2006 at 5:54 pm
You’re right, but some ways of doing things are more efficient than others. It might be possible to do some of the things I’m always talking about with the Z-machine, but the point is to make them efficiently and as easily as possible. That’s why I put the screenplay example, because it is a clear and easy format–and easy syntax, you could say–but at the same time lets you do everything you could need or want.
Oh, let me help you with the posts, because I don’t sign them with my nick, but with my real name. The only really interesting thread is here:
http://groups.google.es/group/rec.games.int-fiction/browse_thread/thread/5ecf412dbb9386c4/9ee33b32eb2983f7?lnk=st.
Also, if after that you’re still interested in what I think, check out my Damnatio Memoriae review for SPAG here:
http://www.sparkynet.com/spag/backissues/SPAG44.
June 16th, 2006 at 6:05 am
I took an impression of the Z-machine, and not only does it look hackable, but it looks like it’s designed to be hacked. I wouldn’t worry about performance and ease-of-use issues at first; just get something working in any crude way, and then throw it to your community to chew on.
For instance, in the raif thread you linked, you suggest a “phrase translation” feature,which would map semantically equivalent phrases from different natural languages to one common ID. In effect, it looks to me like you want to create a domain of “extensional” values which represent equivalence, and map those to another domain of “intensional” values which represent equality. At least from the docs, it seems to me that this should be possible through employing the Z-machine’s substitution mechanism. Doing something like this is at least a good way to find out why things are as hard as they are, and knowing why always defeats the frustration for me. Plus everybody seems to find it more fun to discuss running code (or even code that fails to run for interesting reasons) than to discuss galloping ideas.
I’m not so optimistic about some of your other wishes regarding new tools, however. You wrote:
Like I said, there is a hard limit to the power potential of our digital tools, because there is a hard limit to the power of computation per se. Neither literature nor technology are equipped to computationally handle the non-determinism brought about by human-machine-interaction, especially interaction that involves natural language semantics. There’s no mathematical proof just yet, but there is much evidence that any natural language always will beat any formal language in terms of expressiveness, because the human “language machine” cannot be described in terms of a computable function.
Therefore, I feel that any “paradigmatic change” will not involve finding new mathematical primitives that somehow make computation more powerful. After 50 years of trying, and after establishing much common knowledge about the inevitable reasons for failure, AI research should just fess up and move on, IMHO. To me, all it’s about getting more creative with the small set of useful primitives that we have.
June 16th, 2006 at 7:34 am
Gosh, there even is a way to compile ANSI C to Z-machine assembler. I’d say you can’t really expect more powerful tools to pop up for you; you’ll need to aquire a more powerful mindset to use them.
June 16th, 2006 at 8:47 am
Excuse me for asking another question, but: Has anybody ever thought about writing an AIML interpreter in C and compiling it for the Z-machine, so that one could use AIML from inside Inform? Alternatively, if there were a way to compile from C++, one could use the RebeccaAIML C++ library. Would that be interesting?
June 16th, 2006 at 11:24 am
I didn’t suggest a “phrase translation”. I suggested a new IF development system consisting of three independent parts: a grammar creator, a compiler and an interpreter. The grammar creator (what you call “phrase translator”) would be used to create the language or languages that the game would understand. With an easy syntax, very much like HTML, you can tell the computer what kind of constructions it may accept as input from the player. The output of the grammar creator would be a header or library file (very much like the Inform library files) that you could include in the source code of your game, which itself would contain the dictionary words. The grammar creation part would be an optional step in the writing of the game, so you could use an already written grammar if you don’t want to bother creating a new one.
Why do I want this? Because it makes games translations as easy as possible. All you have to do to translate a game is translating the text of the game and changing the included grammar file. With the current tools, you have to touch a big part of the code. (Ask Nick. He did it once.) Another use for this is playing games with invented or artificial languages as input. You can play games that could at some point require of the player to give some C code as input, for example. Or maybe you want to write a Name of the Rose-kind of game with some puzzles in Latin. Or multilingual games, detective or spy stories about a PC that has to travel to several countries and communicate in several languages. The possibilities are immense. But, hey, if you think that writing a game in ANSI C (which is not an IF language) and then compiling it to Z-Machine assembler is easier, go ahead.
Oh, my mindset is powerful enough as it is. Thank you.
September 17th, 2006 at 10:13 pm
[…] -1287″> TADS 3’s emergence from beta follows fairly quickly upon the arrival of Inform 7. TADS 3 is a major achievement and a very capable development system, wh […]