What to expect as an Inform 7 user when using Inform 6?

Authoring Inform 6
1

I have learned Inform 7 to the point where I’m somewhat comfortable with it. I don’t like it’s syntax, and I would like to be able to compile to z3 as a creative constraint. Switching to Inform 6 would solve those two drawbacks with Inform 7, but I’m sure it would come with other drawbacks. What would those be?

I understand

  • The syntax of Inform 6 is different – but I think of this as an improvement; and
  • Inform 6 does not have the amazing IDE that Inform 7 has.

What other things come to mind for those of you that have experience with both Inform 6 and Inform 7? What made you choose one over the other?

2 Likes
2

One of the big differences is that I6 is object based rather than I7’s rules. So if you have complex action responses that depend on multiple objects and/or rooms/NPCs/etc, then it will definitely be different, and possibly quite a bit more finicky.

5 Likes
3

It’s a very different language overall, so I’m afraid knowing I7 won’t be much help in learning. It’s object-oriented, has no rules or relations, doesn’t support inline string substitutions (no [one of] or such), and is focused mostly on routines attached to objects.

Still, knowing any programming language always helps in learning a new one, and the world model is very similar—light sources, player’s holdall, and things like that work identically.

4 Likes
4

Perhaps relevant: I’m a software developer by day so I’m not too concerned about the programming bit!

This seems like a big deal. How do you do this in Inform 6? (I suppose I could just look it up in the DM4 but I intend this thread to be useful to people who come here by google.)

3 Likes
5

Basically the way you’d do it in a non-IF-specific language: print the start of your string, use an if or switch statement for the random part, then print the end.

2 Likes
6

To just pick a random string from a set, you can:

print "You dance ", (string) random("wildly", "slowly", "happily"), " for a while.";

To emulate the Inform 7 functions, see Craverly-Heights_PunyInform/src/craverly-puny.inf at main · johanberntsson/Craverly-Heights_PunyInform · GitHub

5 Likes
7

I think you meant “Inform 6 does not have the amazing IDE that Inform 7 has.” and that is true. You need a good text editor that can be configured to do syntax colouring, auto-indenting, bracket matching etc. and custom commands to compile your code and stuff like that. I use Textpad, but I think most people use VScode nowadays.

I have my environment configured so that I can edit, compile, double-click on a compile error to jump to that line of code and so on. I can also extract the strings to do optimisation and abbreviations, run the game and open the DM4, all without ever leaving the editor. The whole process is very fast and efficient. Not counting the Inform 6 (or PunyInform) library, there is only one source code file and one executable (or story file) and that’s it. No bloat whatsoever, unlike Inform 7.

As others have said, Inform 6 is a truly object-oriented language. It is said to be a C-like language and that’s mostly true, but it does have some qwirks that take a bit of getting used to.

Your game world (or the world model) consists of objects. Each object has properties and attributes. Properties are your variables. These can be numbers, strings or routines. The routines are where all the interesting things happen. Attributes are Boolean values, mostly defined by the library.

Your objects are located in a containment hierarchy. A room does not have a parent, but it may contain one or more children, which are other objects. The other objects may initially be placed in a room, in other objects (in the case of containers), on other objects (in the case of supporters) or nowhere (called nothing in Inform 6). Non-room objects can be moved about within the game and floating objects can appear in multiple rooms.

In addition to the world model, you can add or extend the grammar and add action routines to add to those provided by the library.

All in all, I’d say Inform 6 has a steep learning curve (arguably nowhere near as steep as Inform 7), but once you understand the basics, it’s all pretty straight forward and you’ll be developing small games in weeks instead of months.

To answer your last question, why did I choose Inform 6 over Inform 7? I was using Inform 6 before Inform 7 was available and invested a lot of time and effort learning it. When Inform 7 came along, I just didn’t get it. I’ve since made several attempts to learn it and I still don’t get it. As it doesn’t have a reference manual, I spent hours and hours wading through the tutorial-like manual and examples trying to work out how to do simple things and would get frustrated.

It is said that Inform 6 appeals to those with a programming background and Inform 7 appeals to those with a non-programming background. As I fall in the former group, Inform 6 is quicker and easier to learn without all the verbosity and frustrations of Inform 7.

8 Likes
8

It’s not true, but people do say it.

12 Likes
9

Laconic as usual.

The goal of Inform 7’s syntax isn’t primarily to make things easier for non-programmers (although non-programmers often think it is, and by the time they realize their mistake, they’re halfway through their first game and might as well finish). Rather, Inform 7’s key insight is that IF consists largely of rules and relations, and natural-language grammar is a powerful and intuitive way to express these:

A thing can be creepy or innocent. A doll is usually creepy. After looking when any creepy doll is visible, say “You have a strange feeling of being watched.”

Depending on your taste, this is either a stroke of genius or liable to give you a stroke. If you really get it and make the effort to do things the way Inform 7 wants you to do them, it’s an incredibly powerful tool; but the moment you start falling back on traditional procedural paradigms, your code starts irrevocably disintegrating into a morass of hackery.

(Graham Nelson’s original white paper on the design of Inform 7 is still fascinating reading.)

6 Likes
10

Emily Short’s Some Observations on Using Inform 7 makes some of the same points in a shorter form (and perhaps a more direct comparison with Inform 6? been a while since I read it).

4 Likes
11

Both I6 and I7 try to be as declarative as possible. That is, they hope that there is enough procedural code in the library to do almost everything you need, and that most of your tasks are best served by filling out a database with entries for rooms, objects, verbs, etc. Most of the game engine is about the conditional display of text, so you should be able to use standard effects.

So you’ll learn the syntax for doing this in I6 and I7, but you’ll also learn ways in both languages to say “Nope, hangon: when this combination of conditions occurs, I have a complicated procedure for determining the result.” You’ll need to look into the implementation details of the standard behaviours in the library, and see if there’s a hook there you can attach your code to, or if you need to write a whole new library module to add in.

It happens in both languages, but the syntax of I6 initially makes you feel the impedance mismatch of these two approaches. Your declarative I6 code looks like data structures being filled in with attributes and properties and event handler rules. When behaviours are only a little more than simple text output, you often put little anonymous functions in place of the bare text strings. By the time you’re putting loops or if/else blocks in, it kind of looks natural to be there.

You will find that there’s an isomorphism between a lot of the I7 active phrases and I6 methods. You’ll find yourself missing the powerful rules-based engine, but you’ll also find yourself thinking “Oh! That whole Instead of fooing the bar, construct in I7 is just compiling to something like bar with before: [; Foo: ….

I’m helping a group of rotating CS grad students with a long-running PunyInform (which is I6-based) project, and one of the things I regularly find myself doing is to say “You didn’t need to write all that code: if you’d linked these two verbs together, it would have behaved almost exactly like what you wanted. You can then catch the rest of the behaviours with a short hook on these objects or rooms.” Then a 500-line patch becomes 12 lines. I do my best to cite the DM4 and the PunyInform documentation and source code, but these systems are unlike the standard libraries in almost any other coding environment.

Oh but one thing you will absolutely miss is the I7 square brackets in strings trick. I often wish I had the ability to mark text as “I just know the player will try to interact with this” while writing. I will say that the PunyInform “cheap scenery” extension is a great tool for managing this.

6 Likes
12

Of course, general statements like this aren’t ever 100% true; but there’s some truth to this for some people. For example, Inform 6 appeals to me, having a programming background, more than I7, which I admire more as a technical achievement than as a tool in my arsenal.

2 Likes
13

There are extensions which do similar things in I6. orPrint comes to mind because… its mine, but you can do stuff like:

orPrint("I just $i;know$n $the:actor will try to interact with this");

or less concisely:

orPrint("I just $italics;know$normal $the:actor will try to interact with this");

Producing something like:

I just know the thief will try to interact with this

2 Likes
14

Sorry, I possibly wasn’t clear: I didn’t mean inline text markup for printed styles, but rather marking text as required object names.

That is, in I7 I can say the description of a room is “Large [optical cables] line the walls of this corridor, and an [air circulation fan] spins lazily in the [ceiling].” If I fail to create objects for optical cables, air circulation fan, or ceiling, the compiler will spit out an error. This lets me just type out as I go, and mark phrases as nouns the parser needs to recognise.

In PunyInform, I instead find myself writing a room description, then beneath it immediately adding cheap_scenery. I have to re-scan over the description text, and make sure I catch as many good pairs of words and occasionally some likely verbs I’d need to support.

7 Likes
15

Ah! My mistake.

2 Likes
16

Though in that case, you could have "Large ", (name) optical_cables, " line the walls", right?

1 Like
17

You could! But that’s probably less useful for cheap_scenery, which is the common use case in Puny.

2 Likes
18

I generally use a TODO comment line just above the room definition, e.g.

[TODO: oven, fridge, sink]
the kitchen is a room. "a bare kitchen, with the bare equipment, oven, fridge and sink".

of course, when implemented, the object is removed from the TODO comment… and yes, this is the organisational trick which allowed me to do the implementation feat of the 46-component portrait :wink:

Best regards from Italy,
dott. Piergiorgio.

1 Like
19

Yeah, it’s just really handy to be able to force a compiler error on undescribed nouns. Easily my favourite feature of I7!

3 Likes
20

I disagree. I love the focus on rules and relations, but I would much, much rather write them in a Prolog style syntax than a highly restricted subset of English!

4 Likes