Creating Interactive Fiction with Inform book (and howdy!)

Hey there! I’m a new user of Inform 7, and a friend of mine pointed me to these forums. I just signed up, and this is my initial post. Hope you are all well today! :smiley:

I’m planning on getting a copy of Aaron Reed’s book, “Creating Interactive Fiction with Inform 7,” and I am interested in the opinions of those who have read it. I am having a little trouble with the documentation included with Inform 7 (mainly when it comes to finding something specific I want to do), and am hoping the book has a structure that is more appropriate for my way of handling things. If anyone can comment a little on how the book is organized and so on, that would be really helpful. :slight_smile:

I also write graphical games, and am experienced with a few programming languages (C, C++, C#, Java, and JavaScript mostly). I’d like to know of any recommendations to help me transition from writing in plus signs and curly braces to Plain English. :wink: I know, I know, but once you get into the mindset of a programmer, unlearning (or at least managing) those habits is tough!

Looking forward to getting to know you, and sharing information and stories with the community here. :slight_smile:

I7 isn’t plain English. It just pretends to be. Pretence is an important part of the I7 project.

With your C++ background, I’d suggest you stick to the curly braces and learn I6 instead.

+1 to the above mate… Since you have a programming background, besides curiosity and the novelty of I7, you’d better try Inform 6 or TADS… :wink:

EDIT: And I too have Aaron’s book but not time to put on I7 yet… But if you want to take a look on I7 I think it’s worth it, but it doesn’t have the structure you ask, the “how to do this” kind… Besides Inform’s 7 original manual other ppl here have made their owns, take a look around or google to find some more links mate, cheers :slight_smile:

To put it in another way, programming in I7 is still programming, even though the syntax differs from other languages. Programming background does help and there’s no need to unlearn it. What requires more of a mindset change is that I7 is a rule-based language instead of declarative or object-oriented.

It’s often said that programmers should stay away from I7, but I haven’t found a real correlation between previous programming experience and ability to grasp I7. It’d be crazy to claim that pre-existing programming knowledge somehow prevents learning other paradigms. Some programmers use and like I7, some are more comfortable with a more traditional language; the same is equally true for people with no previous programming experience.

Amazon’s page for the book has the index and large chunks of content on display (click on the cover picture). From that you can probably get a good picture of how the book is organized.

This may or may not help, but it’s worth pointing out that the Recipe Book part of the documentation is the part that’s organized around accomplishing specific tasks you might want to do in a game. If you haven’t seen it, scroll to the bottom of the table of contents for the main docs, and click Inform Recipe Book.

plese notice Jacek is our resident troll and almost always is full of BS. I’m a programmer too but I found i7 a refreshing new approach to IF authoring. Next step in the evolution of the genre only if we get a smarter parser and better event narrator.

So, besides the Recipe Book Emily suggested, you could also take a look at Jim Aikin’s excellent Inform 7 Handbook:

musicwords.net/if/i7hb.htm

Actually, his comment that I7 only pretends to be English is straightforwardly true. I don’t know whether that means that C programmers should go for I6 instead.

I’m not a programmer myself, but the notion that programmers don’t like Inform 7 is clearly belied by the facts–there are plenty of programmers who are using and enjoying I7. There’s even a separate manual intended to help introduce programmers to the language:

plover.net/~pscion/Inform%20 … ammers.pdf

–Erik

I have a very basic programming background in C++ and VB, and I enjoy I7 very much. It’s got some . . . well, quirks, and I’ve found it takes time to figure out where those are likely to pop up. I think what coding background I had was helpful in that I had some expectation for how if statements and such were used, and a grasp of where infinite loops might pop up and other common problems. In other words - the programmer mindset will serve you well, because you can focus your energy on the actual language.

Creating Interactive Fiction didn’t really help me with the technical aspects of Inform, but I found it helpful seeing how someone else put together their story, and then playing the game and seeing how those came together. For more technical assistance, I found Jim Aikin’s book invaluable when I was starting out. I treat Creating Interactive Fiction as less a reference/learning manual than a travel journal - something to read for inspiration or insight, but not so much for programming directions. But then, I came to the book after having done a fair amount of I7. There’s certainly plenty of explicit I7 code in there, and I think following along would give you a good grasp of the basics.

The other thing I’ve found helpful, once you’ve read parts of your chosen manuals, is reading source code. Even stuff from older versions of Inform. Even stuff by novices. Even stuff that’s not perfectly written. Even stuff that’s above your current ability level. (It’s been so helpful that as far as I’m concerned, it should be standard practice.)

I’m surprised no-one’s mentioned Ron’s guide yet.

ifwiki.org/index.php/Inform_7_for_Programmers

Also there’s Jim Aikin’s great handbook, but in this case, “I7 for Programmers” seems more relevant.

And since Pudlo’s brought it up, you should be aware that there’s nothing you can do in I7 that you can’t do in I6, so you can use I6 if you like… but I7’s great innovations make trivial the implementation of things that have always been notoriously horrible to implement in I6. Just so you know.

Oh, so the “(-”/"-)" notation is just for pure nostalgia? But never mind. A more interesting question is which language is better at enforcing coding discipline. This is likely to be of some importance to someone whose expectations are based on C++. There are a number of reasons why I7 absolutely sucks at coding discipline, and I was kinda hoping you I7 guys and gals would be honest enough to educate the OP on at least some of them…

It’s true that things that were already trivial in I6 have been made even more trivial in I7. I’m not sure how that is a “great innovation” though. There are also some serious drawbacks. One of them is that I7 is so incredibly bloated, even a medium-sized game will not fit in the z-format. This means that by choosing to write your game in I7 you are condemning your opus to Glulx, an ugly and clunky VM that lacks support for most handheld devices, thereby cutting your audience in half.

Er, no, that notation is for when, for some reason, it’s necessary to delve into I6, which has absolutely no bearing on my original statement - that there is nothing withing Inform 7 that you couldn’t already do in Inform 6.

I admit, having never programmed in I6, that this is mostly hearsay. I often hear that things like spreading fire and smoke, and ropes, were nightmarish to implement in I6 (except, of course, for you, as you demonstrate in all your games involving buildings on fire and such). I also often hear that I7’s ability to create relations is one of its biggest advantages over I6.

I actually agree on this one, and have often wondered whether it might not be worth having a more condensed version of the standard rules, or some such - some way to elliminate overhead on games in which it’s simply unnecessary. Especially now that I’ve discovered the joys of mobile-phone IF.

But we should keep any of that to another thread, methinks.

The Programmer’s Guide for Inform 7 might be more up your alley. PDF link in my sig.

If you find it useful or confusing let me know. I’m working on polishing up this version still.

EDIT: oh, thanks Peter.
EDIT2: and Erik.

Hey everybody, thanks for all the tips – I didn’t think I’d end up starting a debate though. I guess I should know better by now, being a seasoned Web-forum user. :stuck_out_tongue:

I plan to stick with Inform 7. I know the syntax isn’t really “Plain English” per se, but is meant to sort of mimic it. It’s just learning the semantics and the “grammar” it uses seems a little weird in places. I’m thinking I can learn it, it’s just going to be like learning a traditional programming language again.

Thanks again, guys – I’m going to start checking out the resources you’ve posted. :slight_smile:

Well, my bad. The point is that this notation exists because there are things you can do in I6 which you can’t do in I7.

This is the combinatorial complexity argument, according to which I7 is vastly superior to I6 in regard to complex relations. The magic word here is “relations,” the absence of which supposedly cripples I6. Yet both Varicella and Savoir-Faire were written in I6, and both games are combinatorially complex in ways that no I7 game I know of has been able to emulate.

Oh, and one other tiny thing: I7 is under constant and rather leisurely development, meaning it won’t stabilise for at least a couple of years, meaning its very syntax is in a state of constant flux. Yeah, that’s right —> With Every New Build You Must Rewrite Your Entire Source Code. None of which you mentioned to the OP. Did it just slip your mind?

Or You Can Just Keep A Copy Of The Old Build On Your Hard Drive Until You’re Done With That Project.

If you want to say that, then say it without hijacking my own phrases. You made a big deal of English language on another thread - be consistent.

Which is, of course, another point entirely, relating only to authors, not to their tools. It also relates to a tendency for smaller games. I mean, why use matches when flint and metal did such a great job?

(note - I’m not implying that I6 is as unsophisticated as flint and metal. I’m implying that I7 is matches, in a matchbook, easy to carry, and you can light it easily)

EDIT - Also, I have not yet played Savoir-Faire and I don’t really like Varicella, but if you want complexity, you have Child’s Play, Blue Lacuna (and spare us your hatemongering, we already know you loathe Blue Lacuna). I have not played Damnatio Memoriae, but the reviews lead me to believe it shares the complexity, if not the length, of Savoir-Faire. Alabaster is certainly worthy of mention. Not to mention that trying to emulate Varicella is like trying to write an Invention. Bach already perfected them - what else can you add? Or like trying to write another Peleàs et Melisande. It’s just not possible, it’s the pinnacle of that particular current.

I would also venture to add that, if another Varicella were to come along, it might have a much more limited audience nowadays.

But then again, maybe Make it Good was that other Varicella, and it certainly had a broad audience.

But I digress horribly.

Curious that you shouldn’t mention the one point in which I agreed with you… at any rate, what you’re describing is the natural process of a lot of software. There was a concept, it was fleshed out, it got working, it was released to a certain public in order to gain feedback and improve it. Inform itself always went through many iterations. And I’m not sure it was ever necessary to Rewrite Your Entire Source Code With Every New Build - again, if you want to waste our time on the meaning of the word “switch”, you have to be precise. If it was, then it was only at the beginning, when the syntax was radically changing, but I would venture to say that you’d only have to seriously rewrite your entire code if you were using, say, v1.4 and suddenly started using v3.8. Mostly, there’s only little changes. Which is perfectly normal, as the syntax is being bettered as it’s being used, so as to better mirror what is required of it.

I tire of this, now. Pudlo, it’s quite all right not to like I7. It’s perfectly ok to point out, in a convenient discussion, its shortcomings. Being aggressively militant about it, in content and tone, is quite another thing.

Well, I’m used to having to adapt to change. When you’re programming in C++ (or even C#) and one of the libraries you use (for writing games, of course :wink: ) gets an update, it’s going to result in something getting rewritten about 90% of the time. For example, the fixed-function pipeline routines I used with OpenGL back in the day – they have been completely deprecated in more recent OpenGL specifications. So, that forced me to learn about the programmable pipeline, shader programs, and so on – which, now, I have come to appreciate.

Of course, I don’t think it will be anything quite as radical here with Inform. OpenGL and the like are industry standards – the world of forced upgrades. It seems as though people are happily using older builds of the Inform app, and their story files still work fine. So I suppose as far as backward-compatibility, things could be worse. :slight_smile:

I’m just going to relax and have fun. It’s not like I have anything substantial to complain about if a new Inform version breaks my code, since I can just grin and bear the code tweaks, or just continue to use the build I had already been using. :slight_smile:

Great attitude. FWIW, I have a very similar programming background to what you do (except I never learned C# and have spent a whole lot of time coding in LambdaMOO which is like a weakly-typed fusion of C++ and BASIC). I knew how to code in i6 fairly well, and have just recently got into i7. I share your problems with the official manual (and the recipe book doesn’t really fit my mental model, either, which is more abstract, I am more of a ‘give me the bare bones spec and skip the examples’ man), but I’ve found stretching myself into new conceptual programming territory enormously stimulating in a way that programming in i6 never was. Programming in i6 is like learning a specialised subset of C++. It isn’t going to be a serious challenge to anyone who knows OO, but you won’t learn anything new about programming. It’s much easier in i6 to get to the point where you feel you’ve got every aspect of the language nailed down. But worthwhile things are often harder than sticking to the status quo, and I’m finding i7 gives me a level of expressivity in my code that I never actually imagined could exist. Creative expressivity, I’m not just talking about what can be achieved, I’m talking about how it is achieved. What’s the value of fluidity? That’s a new perspective that I now have that I wouldn’t give up for mere convenience or the comfort of familiarity.

I’ve even found myself wondering lately what it would be like to program non-IF in the style of i7. Now that I have the sorts of structures i7 uses in my brain, I don’t think it would be that hard to adapt, much the way that once your brain has been object-oriented, you’re at least 50% of the way toward learning most OO language. I suppose what differentiates an old school programmer who will like i7 from one who will hate it, is whether you can take a step back from ALL the things you’ve learned about programming, and see that the same recurring structures that make it easy to pick up a new garden variety OO language are also locking you into a way of solving problems that is sometimes quite circuitous, and that compared to the way that you could just describe what should happen in pseudo-English, filtering all of your ideas through the standard circuitous hoops does tend to have a negative impact on creativity. This is something I might never have realised had I not given i7 a real chance.

Anyway, i7 compilers have gone through a couple of revisions since I started learning and nothing that I have coded has stopped working, so to some extent the naysayers may be more nursing old wounds at this point (and there is a dude who has dedicated his entire blog to naysaying i7, in a kind of amusingly cranky way — well, I find it amusing, anyway, only he’s dead serious).

Good luck and don’t forget to use this forum; it’s an amazing resource. Better than Google. 8)

Paul.