Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Explaining Inform 7

162 views
Skip to first unread message

Jeff Nyman

unread,
Jun 6, 2007, 11:41:55 PM6/6/07
to
In the thread "I7 Philosophical Distinctions" I had brought up some of the
conceptual difficulties some classes I was teaching had with Inform 7. I was
in danger of carrying that thread too far off topic, so I figured I'd post a
follow-up here for those interested.

** Conceptual Problems **

In the aforementioned thread, I mentioned some continual conceptual
problems. Was it just because of the NL-like syntax? As it turns out: no.
The key problem was largely the manual or, rather, the style of
presentation. Everyone agreed that the manual was a well laid out document
that looked very professional and tied into the IDE well. The problem was
that people were just struggling to use it. Mind, this isn't some thin
attempt at criticizing the manual in that I realize how hard it is to write
something like this. Very much so, in fact, since I've found myself
rewriting parts of the manual for the class. Here's an example of a
rewriting of some parts of Chapter 13 (Relations):

http://www.genuinetesting.com/LearnI7/relations.html

People responded very well to this revised version and those conceptual
difficulties were largely removed. I basically distilled some aspects of
each of the sections and cut down the examples, which people found way too
bloated and confusing to be useful.

I should note: this relations section of mine is unfinished. The parts that
are there need to be polished up and some stuff has to be added. Also, the
code sections are going to be color-coded to match the Inform 7 style of
coloring. So, phrase of the day: Work In Progress.

I should also remind that this was with my non-programmer writer group. I
haven't yet shown it to the programmer group. That latter group is sort of
my null hypothesis group. They've also had problems with how the manual
presents things but they've also been somewhat quicker to pick up on the
concepts than the non-programmer group, meaning that they've been more
willing to forgo the manual and experiment or rely largely on the recipe
book in lieu of a linear reading of the manual. They're also not concerned
about relating the ideas of Inform to traditional writing concepts.

* * * *

Now, here are a few notes from my observations regarding the idea of manual
presentation and the problems I've noticed, not just for myself but for the
vast majority of the people in the classes I'm teaching. I bring this up
because maybe it would help consider ways to present information, either in
the manual or perhaps as a supplement to it. I can summarize my findings
with two points, both interrelated.

** Manual Difficulties -- Presentation **

I'm finding a lot of things in terms of existing Inform 7 documentation
leave little tidbits out that would probably make certain things much easier
to understand. For example, something will be stated but there won't be any
indication of why what's being stated is relevant. The bigger hassle for me
usually isn't that such knowledge isn't in there; it's just that it's
dispersed in a sort of episodic and digressive way that I call the
"hop-skip."

What I mean is that I'm often told something will be covered "later in the
manual." So I might search to find when "later" it's covered. That then
leads to new questions when I read that section. The answers to those may
come in an earlier section, even though I haven't gotten to it yet. Or I
just skip going ahead for now but then I have to remember to come back and
understand the previous section in the light of my new knowledge.

In reality, the Inform manual wants me to (say) jump from A to D, then jump
back to B for a bit, which might lead me to jump to Y (which in turn might
suggest I briefly check out M), and then leap back to B so I can move on to
C.

*This* is what I found others having trouble with as well.

It's a very digressive style of writing and reading. I find it tends to work
well -- if you already know the material. If you don't, it's a lot of
"hop-skipping." You could argue that you don't need to hop-skip because the
later stuff isn't relevant yet. But, again, you don't know that unless you
already know it. (I can't know something is irrelevant if I don't know
what's relevant.) And if it's truly not relevant yet, why was it brought up
in the earlier section?

I'm finding many of the examples could have been crafted to not refer as
much to material you haven't seen yet. Granted, that would have made the
examples simpler and shorter but I'm not sure that's a bad thing. The issue
as I see it is the examples are doing double-duty in a way: showcasing
(some) part of the section they're in and often showing a wider example of
how to do some thing (only one part of which is covered in the section
they're in).

** Manual Difficulties -- Examples **

Sometimes I have to wade through an example, going through a bunch of filler
stuff, just to find the one bit that actually serves as an example for what
I'm looking for in that section. Other times, the examples as a whole seem
ill-fitting for the section they're serving or seem only peripherally
related because it was just the best place to stick the example. I think
part of this stems from what I mentioned above: that the examples do
double-duty: (1) they make up short, focused examples that highlight bits of
the section being described in the current section, (2) they serve as part
of a recipe book that is largely independent of the section being described
and provide longer, more defocused examples that highlight situational
things you might attempt.

Thus, one thing serves two very different purposes. I'm not saying that
can't be an effective way to do things, but I personally find it very
jarring to have to constantly figure out what parts are signal and what
parts are noise. (And the problem is that some examples invite you to come
back later after you've learned more, so now you have to realize that the
noise might become signal later on. So remember all those examples you
skipped over!)

The examples rarely follow-on from each other even though some examples
virtually beg the reader to try an obvious variation. I found people
preferred examples that iteratively built up over the course of explanation.
This is particularly the case when two examples, even in the same section,
can be wildly different (or at least seemingly so) in what they are showing
you. This has often given me the feeling that the examples are disconnected
(or connected only tenuously) to the section they are in. Other times,
however, they seem to be exactly what is needed to drive the points home. So
it's a bit uneven for me and I found others were having that problem as
well.

* * * *

So, um, yeah. That's about it for now. The experiment continues.

- Jeff


Emily Short

unread,
Jun 7, 2007, 1:06:17 AM6/7/07
to

Thanks for the feedback; this is useful to know. It's really excellent
that you've found a batch of, er, experimental subjects to test these
things out on.

In re. example organization, the situation is even a bit more
complicated than you guess. I was trying to a) demonstrate what the
reader can do now he has learned the technique of this section; b)
show how to do some common other things that he might have questions
about as a result; and, c) as you say, provide a recipe-book
demonstrating how to do many common moderate to challenging IF tasks.

The number of examples of type (b), which you probably regard as
pedagogically out of sequence, has actually grown since the beta
project started: people working on (say) chapter 3 tended to have
questions about how to do special parsing and name-printing for
objects that had unusual names. They got frustrated that they didn't
know where to get that information yet. So I added an example that
laid out the common work-arounds: it's not an expansion of anything in
the chapter and draws on ideas not presented until later, but it's
meant to help keep people from getting stuck because they have an
implementation idea that's sensibly related to the subject matter in
the chapter, but too challenging for what the manual has explained
thus far.

We originally did talk about having sustained examples that would grow
iteratively -- one per chapter, say, the way the charter boat example
grows through chapter 3. But we found that this was dull to write (and
thus almost certainly dull for the reader too); and also that the
organization of the manual didn't really lend itself very well to this
kind of treatment. A whole chapter-long growing example on tables? or
units? It's hard to envision that this would be interesting for long.

Some people have suggested that it would be nice to have a tutorial
game that grew gradually more complex, but I think it would have to
structure that complexity differently from the way the manual is
structured. (For that matter, I believe someone started writing such a
thing, but that it didn't get very far.) In any case, that seems like
a teaching resource that might stand alongside the manual rather than
be incorporated into it.

The other consideration -- the reason why some of the examples for a
given section do wildly different things -- is that I was trying to
demonstrate the often wide-ranging effects of certain techniques.
"After reading a command" comes to mind particularly, because there
are so many different kinds of possibility that open up as a result;
the same applies throughout the rulebook chapters. So in that sense,
some of the examples were concocted to answer the reader who asked,
"okay, what is *that* good for?" This becomes more and more true in
the later chapters covering rulebooks and activities, where the manual
is introducing things that may on the surface seem quite abstract;
we're no longer working on (say) implementing a really good door, but
instead on Stuff You Can Do With A Procedural Rule.

We did hope that the star rankings would give people some idea of
which examples could profitably be used just as illustrations of the
current section and which should be regarded as more challenging.
Three-star or four-star examples are often better used as recipes than
as demonstrations of the simple principles in a given section. Do you
find, in practice, that you and your students read them anyway before
they're ready? or that the one- and two-star examples are still too
hard/noisy? Or...?

Brian Slesinsky

unread,
Jun 7, 2007, 3:59:12 AM6/7/07
to
On Jun 6, 10:06 pm, Emily Short <emsh...@mindspring.com> wrote:

> Some people have suggested that it would be nice to have a tutorial
> game that grew gradually more complex, but I think it would have to
> structure that complexity differently from the way the manual is
> structured. (For that matter, I believe someone started writing such a
> thing, but that it didn't get very far.) In any case, that seems like
> a teaching resource that might stand alongside the manual rather than
> be incorporated into it.

Hmm. One way to put a spotlight on the relevant portion of an example
would be to have "before" and "after" versions showing how to add a
feature. The changes might be highlighted, or the two versions could
be shown side by side.

Also, sometimes taking an example from a previous chapter and adding
something to it would be a nice way to tie different concepts
together, returning to a previous theme and at the same time building
on a game that the reader might have already studied.

- Brian

Jeff Nyman

unread,
Jun 7, 2007, 7:59:14 AM6/7/07
to
"Emily Short" <ems...@mindspring.com> wrote in message
news:1181192777.9...@k79g2000hse.googlegroups.com...

> The number of examples of type (b), which you probably regard as
> pedagogically out of sequence, has actually grown since the beta
> project started: people working on (say) chapter 3 tended to have
> questions about how to do special parsing and name-printing for
> objects that had unusual names. They got frustrated that they didn't
> know where to get that information yet.

And that's an excellent point and goes to what I was thinking regarding the
different audiences. People asking about special parsing and name-printing
might be those that are more familar with IF conventions or ways to do
things in IF. (Perhaps.) So someone who's not necessarily a programmer or
not familar as much with IF, might not think to ask of those things right at
chapter 3. But a programmer-type, particularly one who is familiar with IF,
would think of such things.

None of my groups include programmers who are also familiar with IF because
that's sort of what the people on this newsgroup serve as, to a large
extent.

> We originally did talk about having sustained examples that would grow
> iteratively -- one per chapter, say, the way the charter boat example
> grows through chapter 3. But we found that this was dull to write (and
> thus almost certainly dull for the reader too);

Interestingly, I found the opposite from the reader point of view. That
said, the iteratively growing examples need to be short, as I found. For
example, the Rope and the Orient Express examples that I used from the
manual only had two iterations of development. I actually took off quite a
bit of the functionality of the Rope example because all of that wasn't
necessary for the person to think about relations. However, if the person
wanted a way to think about how to realistically use a rope in a game, the
example as a whole would be great.

> organization of the manual didn't really lend itself very well to this
> kind of treatment. A whole chapter-long growing example on tables? or
> units? It's hard to envision that this would be interesting for long.

I agree. I think I've found people wouldn't like this either. But multiple
short examples that do just a few things that iteratively build the idea
seem to work well. Granted, I have a ways to go here so I'm trying to be
somewhat provisional in my conclusions. I mainly found that people were
happy with fewer examples and more content *if* the content was explained
well and the fewer examples were immediately seen as relevant.

For example, I found that people responded better to one big "section" for
relations, rather than a bunch of little sections. They preferred content
they could flow through in one sitting. The nature of clicking from section
to section seemed to break the flow of learning. People also responded well
when I cut the examples from 10 to 5. They didn't respond well when I cut
from 5 to 2.

One suggestion I've had from numerous people is to perhaps have an "end of
chapter" example that is larger than all the shorter examples and ties all
the concepts together. Some people have suggested that I just use one
iterative example throughout the chapter and then the final, mega-example is
a "mini-game" of sorts. Others felt that the use of varied examples was
effective, but also felt a larger "wrap-up" type example at the end might be
warranted, whether or not it used material from the same examples throughout
the chapter.

> Some people have suggested that it would be nice to have a tutorial
> game that grew gradually more complex, but I think it would have to
> structure that complexity differently from the way the manual is
> structured.

That's interesting. I thought people would prefer this as well at first. I
didn't suggest it, but through a series of questions designed to elicit what
people might like, I wanted to see if people would be interested. A full
tutorial game had never come up, however. The only thing that I found might
work was when I suggested that perhaps a full game could accompany the
manual that did use bits and pieces from the examples. The game would be
liberally commented and would include references to the chapters (or
sections) that were used at that point in the game. But people didn't want
to see this game built up as part of the manual. I got the impression they
would rather just have a game that is tied directly to the manual that can
be looked at separate from reading the manual directly.

> thing, but that it didn't get very far.) In any case, that seems like
> a teaching resource that might stand alongside the manual rather than
> be incorporated into it.

That's exactly what I found as well.

> The other consideration -- the reason why some of the examples for a
> given section do wildly different things -- is that I was trying to
> demonstrate the often wide-ranging effects of certain techniques.
> "After reading a command" comes to mind particularly, because there
> are so many different kinds of possibility that open up as a result;
> the same applies throughout the rulebook chapters.

Exactly! I can completely see how this would happen. So much can happen with
Inform once you learn a certain technique, that I can easily see how it
becomes hard to organize the material. I kept running into that at various
points myself. I found keeping the examples short helped to keep me focused.
Of course, keeping the short means I remove a lot which means their use in
the recipe book comes constrained.

I actually found, similar to the idea of a tutorial game, that people would
like the idea of a recipe book, but not necessarily one that's so tied to
the examples in the section. In other words, the recipe book, like the
tutorial game, is almost an adjunct to the manual rather than incorporated
so much into it. It's not so much that people said those exact words, but
I'm basing that conclusion off of the comments I did, which I laid out in
the first post.

> So in that sense,
> some of the examples were concocted to answer the reader who asked,
> "okay, what is *that* good for?"

Yes! This is exactly the issue I brought up in the "I7 Philosophical
Questions" thread. People were having conceptual difficulties with relations
and when I finally distilled what their problem with them was, it was
basically: "yeah, that seems good, but what am I going to do with it?" In
other words, they could see the concept as a concept, but not how they might
generalize that and then actively employ it.

Now, interestingly, here's where I found the examples didn't always help
people. The reason I distilled was that they couldn't always separate the
signal to noise ratio in the example. The Rope example from Chapter 13 is a
good example. People saw how clever the usage of a rope could be. But was
all of that necessary to learn relations? That was the question I was asked.
So the Web example I show, breaks the Rope example (currently) into two
examples. Each shows a bit about the rope and the output from the game. All
the stuff that you see removed is the stuff that people found they could do
without .... at least for considering relations. When considering how to
build a realistic rope, however, they loved it.

> Three-star or four-star examples are often better used as recipes than
> as demonstrations of the simple principles in a given section. Do you
> find, in practice, that you and your students read them anyway before
> they're ready? or that the one- and two-star examples are still too
> hard/noisy? Or...?

I find people, at least in the main, do read them anyway, even with
knowledge of the stars, because they figure that if it's placed there, it
has to be for a reason. It's kind of like placing a sign somewhere that says
"Don't Read This." It's impossible to adhere to that instruction. People's
thinking with the examples is that they must be relevant somehow. Also,
people don't want to track what examples they did and did not utilize on
their first pass-through only to go back later and re-visit them. In other
words, they weren't sure if they'd remember to go back and check that
particular example.

And sometimes people found that the examples (of whatever star value)
contained a bit of explanation that wasn't in the main text. That bit of
explanation actually helped them, even when the example didn't. Once people
found out that this could happen, they realized they "had to" read the
examples because they weren't sure if other little tidbits were lurking.

So the approach I started taking was building up examples iteratively with
the class and seeing at what point everyone felt that the relevant lesson of
the chapter/section had been learned. When that point was reached, I
actually found a relatively common stopping point for many of the examples
in terms of their length or in terms of their density. I then found that if
I wanted to make a larger example that (a) included the relevant material I
was covering *and* (b) covered a general topic more thoroughly (such as the
Rope example), I should probably have the chapter reference a "mini-game" or
"larger example" as part of a *separate* recipe book. (Something like: "See
the Recipe Book 'Attached' for more examples of how to more thoroughly use a
rope when the attached relation and stuck to verb are used.")

- Jeff


Jeff Nyman

unread,
Jun 8, 2007, 3:55:51 PM6/8/07
to
A bit of an update for those who were awaiting developments with
anticipation that was bordering on breathless.

When I (finally!) distilled the issues, it came down to some relatively
simple points once I kept in mind this was a group of writers who wanted to
learn Inform. (Or, rather, I should say: writers who were intrigued with the
idea of text-based interactive fiction and saw Inform 7 as a viable route to
accomodating their current skill-set and allowing them to presnet their work
in an intriguingly different format.) Quoting from Les Edgerton, an
established writer:

"Many, if not most, writers are never taught how to begin stories or even
how to structure stories
at all. Many writing classes focus on writing *exercises*. Parts of
writing. Chicken nuggets instead
of the full roasted bird. A unit on how to write descriptions, for
instance. Another on how to
create character. Or, one on effective dialogue. And so on. But very
little is actually taught as to
*how* stories are put together." [emphasis mine, of course]

"Writing education, by and large, consists of far too many exercises. The
teacher gives us a unit on
description, then one on something called characterization, etc. We learn
pieces. This approach, in
and of itself, isn't necessarily a terrible thing, but what is perhaps
terrible is that many times the teacher
neglects to show her students the big picture. The story itself. How it's
shaped. It's not just throwing a
bunch of pieces together. It's much more complicated than that."

It was appreciated, by the group, that what was being written here was both
a game and a story but what everyone felt was missing was the overall idea
of "craftsmanship" for *how* to construct an Inform game/story and *why* to
do things one way rather than another.

So, the point here: the episodic nature of the manual is what gave some of
the issues and the reason, which is what I was trying to get to, is because
they see that kind of learning as bad for people who actually want to craft
narrative and story structure. They base that informed opinion on the fact
that this way of doing things is similar to how writing is currently taught
in many places.

Here's what I've come to as a working hypothesis that I have to put to form.

= = = = = = = = = = = = = = = = = = = = = =

* Don't treat the subject matter episodically, i.e., one chapter on actions,
one chapter on descriptions, one chapter on relations. Rather, combine those
elements into one. That leads to the next point...

* Have fewer, but larger chapters. BUT ---- those chapters cover a range of
topics related to actions, descriptions, relations or whatever. HOWEVER ----
each chapter gets progressively more difficult in terms of what it presents.

[Aside on this point: I can see how this might help writers know where the
true "IF specific" stuff starts. People can get off the train at the points
where they feel they have enough to use Inform for what they want. So my
teaching group with children has an earlier stopping point than my writers.
My writers, in turn, usually have an earlier stopping point than my
programmers.]

* Have one example that caps off each chapter. That example is a mini-game
that is progressively built from each chapter. So by the end of the manual,
you have a full working mini-game of sorts.

* Within each chapter, smaller examples -- very small, very focused -- can
be used to showcase things outside of the main (mini-game) example.

* Present the examples in different tense and viewpoint. THIS WAS A BIG ONE.
All of the writers, without exception, didn't like the second person at all.
They were, for lack of a better term, surprised that the idea of tense and
point of view was not built-in, but rather part of an extension.
(Unfortunately, it's an extension that no longer works with the current
Inform 7 build, which didn't help matters until I went back to 4S08.) This
got into lots of implementation discussions that I was trying to avoid to a
certain extent.

[Aside on that last point: That makes sense since the vast majority of
novels and stories are not written in the second person. This second person
POV issue has long been a problem for me as well with text-based IF that
tries to be as "artistic" as novels, stories, screenplays. So I was happy to
hear other writers agree with me on this. I should also note that this was
an area where TADS 3 won very high marks based on the perceived ease in
terms of dealing with tense and viewpoint.]

= = = = = = = = = = = = = = = = = = = = = =

I also presented this working hypothesis to the programmer group (who,
remember, are not writers). They didn't have the same issues in terms of
story structure and narrative. This is because they look at Inform 7 more as
a game producing system than a story producing system. They did, however,
agree with the general ideas of the presentation as "possibly" being more
helpful to learning. Regarding what I said before about the writers (not
enough on the "craftsmanship" for *how* to construct an Inform game/story
and *why* to do things one way rather than another), the programmers only
felt that more of the latter part (the "why") was needed and should be
presented with either less examples or shorter examples.

So, perhaps not terribly surprisingly, my programmer-non-writers and my
writer-non-programmers converged on largely the same desire, but for
different reasons.

One thing I hasten to remind: these programmers are, without exception,
programmers who have *not* programmed any text-based interactive fiction. So
I wouldn't say that these conclusions would translate to programmers who
*have* used systems like Inform, TADS, Hugo, etc., to write games. This may
be why, to some extent, the conceptual difficulties I've found haven't been
brought up as much on this newsgroup.

- Jeff


Andrew Plotkin

unread,
Jun 8, 2007, 5:45:10 PM6/8/07
to
Here, Jeff Nyman <jeff...@gmail.com> wrote:
>
> * Present the examples in different tense and viewpoint. THIS WAS A BIG ONE.
> All of the writers, without exception, didn't like the second person at all.
> They were, for lack of a better term, surprised that the idea of tense and
> point of view was not built-in, but rather part of an extension.
> (Unfortunately, it's an extension that no longer works with the current
> Inform 7 build, which didn't help matters until I went back to 4S08.) This
> got into lots of implementation discussions that I was trying to avoid to a
> certain extent.

I would be very hesitant to teach any IF programming (for any
language) in anything other than the IF-standard second-person-
present.

First, because I would want to teach it in conjunction with lots of
the existing IF canon. (If the students weren't already familiar with
that.) And the canon is, really, second-person and exceptions. I think
IF is still in a state where second-person is one of those rules which
you should only break after you know how to keep it.

Yes, writers from a non-IF background will have internalized the
opposite rule. ("Only use second-person after you know how, when, and
why to write in first/third.") But this difference is something to
learn, not ignore.

Second... I have a faint but abiding suspicion that while the IF
*toolsets* support first/third/past IF, it will somehow clash with the
underlying structures. Or they'll make less sense; you'll wind up
designing in second-person anyway, and then translating.

This is not a suspicion which is supported in any way by evidence.
It's a hunch. I will be interested to see how it comes out.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Making a saint out of Reagan is sad. Making an idol out of Nixon ("If the
President does it then it's legal") is contemptible.

Jeff Nyman

unread,
Jun 8, 2007, 6:30:33 PM6/8/07
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:f4cil6$cj8$1...@reader2.panix.com...

> I would be very hesitant to teach any IF programming (for any
> language) in anything other than the IF-standard second-person-
> present.

I was hesitant at first, too. But in both groups, they had not really been
exposed to a lot (or even any) of interactive fiction of the textual
variety. They found no issues with going into first or third person.

My personal belief is that second person is a relic that does hold up more
interesting styles of narrative and story structure in text-based
interactive fiction, just as it would if all conventional novels were
written only in second person. As you state, I should also state: I can't
really back this up with evidence right now. That means I could be totally
and one hundred percent wrong. That said, part of how I learn new IF systems
is by rewriting existing games. When doing so, I *always* change the tense
and point of view and this is part of what I base that conclusion on. (Of
course, I have yet to release any game+story of my own, so my viewpoint is
probably largely irrelevant.)

A good example of how people didn't like the second person was when we
"dissected" the text of "The Hitchhiker's Guide to the Galaxy", both from
the Infocom game and the actual book. That said, this was a free discussion
and not actually part of the "crafting a game+story" but it actually gave me
a good idea of how people were looking at it.

> Second... I have a faint but abiding suspicion that while the IF
> *toolsets* support first/third/past IF, it will somehow clash with the
> underlying structures. Or they'll make less sense; you'll wind up
> designing in second-person anyway, and then translating.

I worried about this, too. So far I haven't seen that, except when the
extensions or the libraries for the languages miss something and make it
hard to get *out* of second person in some limited case. But, beyond that, I
found people much more readily accepting of writing game dialogue and
description in first or third person. Now, interestingly, the
programmer-non-writers preferred third person; the writer-non-programmers
preferred first person. That was the case for the writers even if they
traditionally eschewed first person for novels. The writers also greatly
enjoyed the ability to change point of view mid-game. (This was something
the programmers had no desire to do.)

- Jeff


Graham Nelson

unread,
Jun 8, 2007, 7:43:17 PM6/8/07
to
Thanks for this, and for your other interesting conclusions. Perhaps
it would stimulate further discussion if I say a little bit about what
we're trying for (which may not be what we actually accomplish, of
course). The aims of the current documentation are:

(a) To make it possible to write small games early and often.

(b) To present each major conceptual topic in a single chapter, so
that, for instance, reading through the Understanding chapter doesn't
take too long and gives a good picture of everything I7 can do with
parsing of text. We divide the Actions material into two, and also the
descriptions material (so that, in effect, noun phrases are covered
long before verb phrases), but by and large we stuck to this. The
chapters, in turn, are arranged so that at any point the user can stop
and put together techniques so far. There's really only one ordering
which allows this. One alternative would have been to spend three or
four chapters laying out the basic grammars and only then start gluing
rooms together: the DM4 does this, but beginners didn't like it.

The cutting up of the chapters - which are actually quite short texts
- into sections probably does make them look somehow longer and more
formidable. But again, this is really something forced on us by the
need to make the text work for in-application use on screen. In a
printed copy, the section headings won't be very intrusive, and the
text will flow more easily.

Just as most major topics occur in single chapters, most minor topics
occur in single sections. This is intentional too - the sections are
the cross-referencing points for links from the Index pages. There
needs to be a clear-cut destination for, say, "say".

(c) To describe I7 but not IF. The DM4 was a sort of hybrid book, half
about Inform, half about the canon of IF and its traditions and
history. Here, we tried not to get into questions of what "good" IF
might be, or even what has been done in the past. This was partly to
make a fresh start, but also just to make the text shorter, especially
as it was intended for screen use.

I tend to agree with Zarf that teaching the writing of IF is probably
best accompanied by some material on classic IF - getting people to
play, I don't know, Zork II and Floatpoint, or some other combination
of old and new, and giving them an idea of what people have tried
before. So from that point of view the I7 manual isn't a good teaching
resource, or rather, it isn't good as the only teaching resource.
(Though it runs only up to 2000, chapter 8 of the DM4 is still
available online for those who want to read it; we link to it from the
I7 website.) But in any case, a guide to I7 is always going to contain
too much material to be used unedited as a teaching resource: I think
it's inevitable that in a series of talks on IF, one would have to
strip down the chapters and refer people to full details elsewhere.

Finally, it's perhaps worth noting that what one thinks of as
important to do first, and what to leave until later, is a matter of
personal outlook. I7 wants people to discover descriptions and rules
early on, and to use relations and verbs. This is why chapter 6, on
descriptions, precedes a lot of fairly basic stuff: similarly, chapter
13, Relations, precedes material on tables and parsing. If the book
were arranged so that traditional core IF features came first, and I7
exotica last, these chapters might be right at the back. We didn't
want to do it that way because we have our own views on what I7 does
well rather than badly. But others would disagree.

I haven't mentioned the examples yet, because that opens other issues.
It's interesting that people consider these to be "inside" the text,
rather than some kind of appendix or supplement. We haven't yet
printed a paper copy of the documentation, but when we do, we were
thinking of making it two volumes - the main text, and the recipe book
- rather than including examples "inline", so to speak. Emily has
already noted that many examples are where they are, and demonstrate
what they do, following requests from users. I'd like to point out,
too, that the examples really have four aims:

(a) Actually to exemplify I7 semantics put to use.

(b) To produce creditably finished-quality transcripts and
interactivity. (Just as photographs of dishes in recipe books always
show them to best advantage, and recipes tend to include garnishes and
other ingredients not strictly necessary.)

(c) To produce a varied and fairly systematic corpus of tests for I7.
(Each build is mechanically checked against about 750 works of IF, to
see if it can make them such that they still play correctly: more than
300 of these tests are from the examples. But it means they have to be
complete little games, with scripts of commands.)

(d) To provide I7's equivalent to a standard library of code. Some IF
design systems provide code for, say, ropes or ladders as class
definitions which slot into the existing hierarchy of classes - an
approach like that of the standard libraries for C or C++. I7 instead
provides implementations for many different interesting behaviours in
the form of examples: the idea is to play around, cut out the active
parts and paste them into new works, and alter as one likes. A lot of
I7's syntax is intended to make it possible to "transplant" source
text like this.

Emily has already talked about the pitfalls of the "single game
gradually written" form of multi-example. We went back and forth on
this. Part of the reason we didn't really go down this route, I think,
was also that it's much more fun to have a great variety of settings
and writing styles in the examples. It suggests that IF can be a lot
of things. In so far as there are some surprises, well, that's to the
good, really. Some examples are longer: but we do signal that. And
they can all be quickly pasted into the source panel and tried out -
and then browsed via their indexes, etc. I suspect that trying to read
the examples as text would become a little sterile: the best way to
see them is always to compile them, type "test me", watch what
happens, and then look to see how it was done.

It's hard to write tutorial material for a system still evolving, of
course. And as you say, there are many different constituencies of
users to think about. It may well be that we haven't got the balance
right. (What do people think about the chapter summary sections, I
wonder?)

Emily Short

unread,
Jun 8, 2007, 8:21:11 PM6/8/07
to
On Jun 8, 5:30 pm, "Jeff Nyman" <jeffny...@gmail.com> wrote:
> "Andrew Plotkin" <erkyr...@eblong.com> wrote in message

>
> news:f4cil6$cj8$1...@reader2.panix.com...
>
> > I would be very hesitant to teach any IF programming (for any
> > language) in anything other than the IF-standard second-person-
> > present.
>
> I was hesitant at first, too. But in both groups, they had not really been
> exposed to a lot (or even any) of interactive fiction of the textual
> variety.

This is an interesting point. The more you say about what this group
needs, the more I think it would have to be an entirely different
document from the regular manual. Defining "good IF craftsmanship" is
something that we deliberately avoided, as Graham says. At a couple of
points I do sermonize a bit about things like how to write an action
to minimize guess-the-verb effects, and we talk here and there about
which I7 constructs are best to use under what circumstances; this
kind of explanation was often requested even by veteran programmers. I
think that's all useful, and the manual may yet pick up more of it. I
still have some chapter summaries left to write.

But that's all small-scale stuff. When it comes to larger issues, I
tried *not* to impose my ideas of good IF design too heavily on the
parts of the manual I wrote. For one thing, this is open to debate,
and I imagine a number of people here would disagree with (and perhaps
find obnoxious) the more prescriptive things I might be tempted to
say. For another, I very much wanted to encourage authors to
experiment, which is why the examples are so diverse in style: they're
meant to hint at the possibility of writing many different kinds of
IF, with many kinds of interactive focus.

Still, I wasn't envisioning a target audience with *no* prior
experience playing IF. I can see how the manual might be quite
confusing to such authors. There might be room in the world for a
document that started from scratch by explaining what IF is and
introducing various conventions and design methodologies. I wonder,
though:

1) whether it would be better for such a guide to be language-
agnostic, so that it could be used as an introduction regardless of
whether the author wanted to go on to use I7 or TADS 3 or one of the
older languages; and

2) whether (on the other hand) it's reasonable to try to teach people
to write in a form of which they've experienced no examples. I
wouldn't expect someone to write a good short story if he had never
read one before, no matter how carefully the teacher introduced
concepts of plot, pacing, characterization, dialogue, and so on.

You could say that it's desirable to attract authors who don't come in
with a lot of preconceptions about IF, to see what they will write and
whether it advances the state of the field; but if that is what we
want, a kind of clean-slate experiment, then surely an extensive
manual about IF techniques and conventions would undermine the
experiment just as much as exposure to a few canonical works. (Maybe
more so: playing a bunch of IF demonstrates that people do lots of
different things, and do sometimes successfully ignore conventional
wisdom -- just take one of zarf's award-winning maze puzzles. Reading
a book that summarizes the conventional wisdom would seem to be a more
restrictive introduction to the whole problem.)

Anyway, so far you're convincing me more that very novice users need a
different manual entirely (or some supplementary documents to the main
text), rather than that it is possible to edit the existing manual to
serve them while still remaining functional for its current users.

steve....@gmail.com

unread,
Jun 8, 2007, 9:00:55 PM6/8/07
to
Suuggestion for the I7 manual: treat the syntax as syntax. Hello, it's
a computer language.

Oh, and lose the phony-sophisticated Voltaire reference. Dropping in
"Oh, I know X about Voltaire" for no apparent reason does not make you
look smart. Well, maybe it impressed Oxford students, but please:
spare the rest of us.

ChicagoDave

unread,
Jun 8, 2007, 9:44:54 PM6/8/07
to

I think I'll side with "impressed Oxford students" over you any day.

David C.

Emily Boegheim

unread,
Jun 9, 2007, 5:46:17 AM6/9/07
to
Emily Short <ems...@mindspring.com> wrote in
news:1181348471.6...@p77g2000hsh.googlegroups.com:

> Anyway, so far you're convincing me more that very novice users need a
> different manual entirely (or some supplementary documents to the main
> text), rather than that it is possible to edit the existing manual to
> serve them while still remaining functional for its current users.

I agree. I feel the problem with the I7 documentation is that it's trying
to be too many things to too many people. It just doesn't seem reasonable
to expect one document to be a tutorial, a reference manual, a recipe
book, and so on. It would make more sense - to me, at least - to have two
separate documents: one just a tutorial and the other a reference manual.

Of course the work on I7 is all voluntary and two separate documents
would mean more time to be put in. And I7 is still developing, and so
difficult to document. But I think the documentation would be clearer and
easier to use, both for novices and more experienced users, if it were
structured this way.

Emily

Jeff Nyman

unread,
Jun 9, 2007, 6:47:12 AM6/9/07
to
"Graham Nelson" <gra...@gnelson.demon.co.uk> wrote in message:

> (b) To present each major conceptual topic in a single chapter, so
> that, for instance, reading through the Understanding chapter doesn't
> take too long and gives a good picture of everything I7 can do with
> parsing of text.

This I can definitely understand. But I often found that, say, giving "a
good picture of everything I7 can do with parsing of text" still often
requires understanding other things. Now, by itself, that may not be a
problem because presumably somebody read those parts already. However, that
same situation often crops up early in the manual too (such as where
numerous examples say that you'll see something "later" or that parts are
"borrowed" from later chapters).

So, in other words, I'm finding something opposite to what you found: people
seem not to like one major conceptual topic per chapter, *at least* when
it's not possible to totally isolate that one conceptual topic (since it
needs bits from other conceptual topics to be fully understandable).

Clearly, though, this may be because of the audiences I have chosen to work
with.

> (c) To describe I7 but not IF. The DM4 was a sort of hybrid book, half
> about Inform, half about the canon of IF and its traditions and
> history. Here, we tried not to get into questions of what "good" IF

> might be...

Right -- and here I should clarify, because I probably was being misleading.
People I talk with don't necessarily want something like "The Craft of
Adventure." What they want is how using relations will help them with story
structure. What they want is how certain types of actions can be used to
help pacing of a story. In other words, they want to learn how the
*specifics* of Inform 7 can be used to implement the various aspects of the
craft of good writing. Put another way, they want to see how the craft of
writing can be translated to the craft of writing text-based interactive
fiction. BUT -- they don't want a treatise on how to write characters or how
to write good descriptions or even how and when to include puzzles. They
just want to see more of a mapping between what Inform provides, in terms of
constructs, and what makes up a story.

Now, I'll be the first to admit, I had some problems nailing people down on
this. But, remember, they're approaching it as writers first. They see
Inform 7 as a way to put what they normally do (write stories) in a
different format and yet that different format can't sacrifice those
elements that make a good story, meaning a way to pace the narrative; a way
to modify the narrative in a way that keeps the reader (player) engaged; a
way to deal with internal monologue and external dialogue; etc.

> I tend to agree with Zarf that teaching the writing of IF is probably
> best accompanied by some material on classic IF - getting people to
> play, I don't know, Zork II and Floatpoint, or some other combination
> of old and new, and giving them an idea of what people have tried
> before.

Agreed. And this we did do. I picked some examples that I particularly liked
or that had an effect on me. I didn't so much go with "classics" of the
genre, but I did take early examples of text-based interactive fiction as
well. My goal was really to show games that had placed emphasis on
characters, games that had placed emphasis on intricate plots, games that
had placed emphasis on unique ways of telling the tale, etc.

> So from that point of view the I7 manual isn't a good teaching
> resource, or rather, it isn't good as the only teaching resource.
> (Though it runs only up to 2000, chapter 8 of the DM4 is still
> available online for those who want to read it; we link to it from the
> I7 website.) But in any case, a guide to I7 is always going to contain
> too much material to be used unedited as a teaching resource: I think
> it's inevitable that in a series of talks on IF, one would have to
> strip down the chapters and refer people to full details elsewhere.

I agree, to a certain extent. Part of the classes I'm teaching actually
weren't really about the manual. They were about the use of Inform in
diffrent contexts (and, by extension, the efficacy of text-based interactive
fiction in those different contexts). Relative to Inform, part of this was,
of course, focused on the use of the natural language to see if that
provided people with a different aspect of approaching something they may
not have otherwise approached. (The answer to that, I've found, is yes; the
natural language aspect does help.)

However -- right now the manual is really the only resource we had. So
that's what we started with. But I will admit that part of this was also a
calculated move on my part in that I had suspected that the manual might
have some "problems." (Note the quotes, please!) What made me come to that
provisional conclusion was, in part, the number of times Emily has to say,
on these newsgroups, "Oh, that's covered in example xxx." Or, "We talk about
this in section x.x." It happens enough (and has happened to me) that I had
to wonder: are all these people just not reading the manual? Or are we not
finding what we want? Or are we finding it but not realizing we did?

I should also note that these classes of mine are a bit looser than a rigid,
academic class. This is especially so when you consider that I'm still
learning Inform 7 myself. So this was a lot of "let's learn together." I was
also hoping this would help me return some viewpoints to the community here
because then I would not be colored by too much familiarity with Inform such
that I couldn't see the problems my classes were having.

> (b) To produce creditably finished-quality transcripts and
> interactivity. (Just as photographs of dishes in recipe books always
> show them to best advantage, and recipes tend to include garnishes and
> other ingredients not strictly necessary.)

I can see this and I certainly agree with it. What I found people responded
to better, however, was having shorter, more focused examples that made the
output easier to read and made the example itself easier to distill in terms
of the point that should be learned. I do agree with what you say regarding
the recipe books, but you'll notice that this same logic doesn't usually
apply in programming books (at least in the early phases). The same also
doesn't usually apply in books that teach you writing by including snippets
of texts.

Also, going with what I said before, what I found people liked were chapters
that didn't focus on just one conceptual topic. So, by that logic, if more
elements were included in the chapter, then the more you can include in an
example. (However, this is where people felt the iterative examples helped:
an example that builds up.)

> (c) To produce a varied and fairly systematic corpus of tests for I7.
> (Each build is mechanically checked against about 750 works of IF, to
> see if it can make them such that they still play correctly: more than
> 300 of these tests are from the examples. But it means they have to be
> complete little games, with scripts of commands.)

I can see the purpose of this. But it's sort of conflating the needs of the
ultimate reader with the needs of having code-based unit tests. All I mean
here is that while the goal of having tests is good, having even part of
that goal be to incorporate those tests into the manual might drive the
creation of certain examples that don't necessarily edify the user.

> approach like that of the standard libraries for C or C++. I7 instead
> provides implementations for many different interesting behaviours in
> the form of examples: the idea is to play around, cut out the active
> parts and paste them into new works, and alter as one likes

This I can understand as well. But I found that people didn't like that
aspect. For example, the rope example ("Otranto") from chapter 13 was found
to be way too confusing for that chapter. What people indicated they would
like is a "full rope example" that is part of a separate "recipe book." That
way, if they want a rope and care about implementing a realistic one, they
can look it up if and when they need it, rather than having to "cut out the
active parts" while learning. It was that very act of having to distill what
was *needed* from an example and what was just "filler" serving some other
purpose that seemed to cause the greatest annoyance, at least among the
people I'm working and learning with. (I have to admit it was part of my
stumbling block with Inform 7 as well.)

> Emily has already talked about the pitfalls of the "single game
> gradually written" form of multi-example. We went back and forth on
> this. Part of the reason we didn't really go down this route, I think,
> was also that it's much more fun to have a great variety of settings
> and writing styles in the examples.

And interestingly this is exactly what I found threw people off. Too many
different things going on that it made it hard to internalize the lesson of
the example, because you always had to figure out the details of *this*
particular example. When I built examples iteratively, people spent time on
just the first example getting used to the basics of what the example was
going to be about. (What rooms, what NPCs, etc.) Then the subsequent
examples built off of that and allowed people to focus directly on what I
needed them to.

But, as you and Emily have indicated, this all may be the result of me
working with audiences that are very different (at least largely so) from
the audience here on the newsgroup.

> In so far as there are some surprises, well, that's to the
> good, really. Some examples are longer: but we do signal that. And
> they can all be quickly pasted into the source panel and tried out -
> and then browsed via their indexes, etc.

Agreed -- but I found people didn't often want to do this. They didn't want
to browse the index to have to learn. They also very rarely wanted to paste
the examples. They wanted to type them out. Just as with any programming
language, typing something (rather than copy-pasting) is often a better
route to learning, even for stuff you've already seen before. The repetition
of typing in even familiar material starts to build up the connections you
need to understand everything as a whole. (Clearly there's some personal
opinion in there.) Even in writing classes, students aren't encouraged to
paste text. They're encouraged to type out text, particularly in what
they're trying to learn (i.e., dialogue).

Keep in mind here that with the shorter examples I was using (which didn't
use elaborate room descriptions where they weren't needed), the typing was
kept to a minimum. With some of the examples in the Inform 7 corpus, clearly
typing everything would be a large exercise in frustration. But that, to me,
was highlighting the need for shorter examples rather than a copy-paste
functionality.

> I suspect that trying to read
> the examples as text would become a little sterile: the best way to
> see them is always to compile them, type "test me", watch what
> happens, and then look to see how it was done.

Right. Now, if you see the examples I provided with my Web page on the
"re-written chapter 13", you'll notice I often include the output from a
"test me" along with information about what someone should notice about the
output. I found this worked well with both my programmers (who are used to
this kind of thing from traditional programming resources) and my writers
(who preferred seeing short example with short output).

> It's hard to write tutorial material for a system still evolving, of
> course. And as you say, there are many different constituencies of
> users to think about. It may well be that we haven't got the balance
> right. (What do people think about the chapter summary sections, I
> wonder?)

Regarding the summary, if you see that link I provided in the first post,
you'll notice that I actually incorporated some of the summary stuff into
the main text. So, with the groups I deal with, they *do* like the summary
material but they often wish they had read it first because, in some cases,
bits of the summary would have made the preceding a bit more understandable.
So what I did is just incorporate bits from all of the chapter (13, in my
example) and put them into a linear whole.

This kind of thing removed the most common complaint which was that the
material seemed to episodic. People, I found, were willing to pay for a bit
more upfront description if they knew they were going to get an example that
made it clear how the upfront description of the material could be put to
use. So, in other words, people liked the summary material, but would have
preferred it to be placed within the main text at relevant points to provide
a more cohesive (less episodic) learning experience.

- Jeff


Mike

unread,
Jun 9, 2007, 7:31:22 AM6/9/07
to
> Regarding the summary, if you see that link I provided in the first post,
> you'll notice that I actually incorporated some of the summary stuff into
> the main text. So, with the groups I deal with, they *do* like the summary
> material but they often wish they had read it first because, in some cases,
> bits of the summary would have made the preceding a bit more understandable.
> So what I did is just incorporate bits from all of the chapter (13, in my
> example) and put them into a linear whole.
>
> This kind of thing removed the most common complaint which was that the
> material seemed to episodic. People, I found, were willing to pay for a bit
> more upfront description if they knew they were going to get an example that
> made it clear how the upfront description of the material could be put to
> use. So, in other words, people liked the summary material, but would have
> preferred it to be placed within the main text at relevant points to provide
> a more cohesive (less episodic) learning experience.
>
> - Jeff

Jeff makes a good point here. Although I have no experience of
teaching or writing IF manuals, a large part of my job is to write
training materials for lawyers. One of the things that they always
want is an upfront summary of what the training material teaches with
links to the sections where the summary points are explained in more
detail. As the author, this helps me as well. It means that I can
begin to layer the training materials and direct those who have less
knowledge to the basics and those who have more knowledge to the more
complex aspects of a transaction or point of law. I do not how easy
it would be to apply this to the I7 documentation. I have found that
it is possible to go back to something I have written and apply the
summary later but sometimes it means that you need to reorder the
material.

Jeff Nyman

unread,
Jun 9, 2007, 10:31:34 AM6/9/07
to
"Emily Short" <ems...@mindspring.com> wrote in message
news:1181348471.6...@p77g2000hsh.googlegroups.com...

> 1) whether it would be better for such a guide to be language-
> agnostic, so that it could be used as an introduction regardless of
> whether the author wanted to go on to use I7 or TADS 3 or one of the
> older languages

That could be. Now, one of the things I've seen that clearly interests
people with no IF programming experience is the fact that Inform 7 uses the
natural language constructs. (I know what a hot topic that is for people; I
was skeptical myself. But I've come to realize that people -- children and
adult alike -- really respond to it.)

So, to that end, I think the language-agnostic aspect of this would hurt
Inform 7 specifically because such people are interested in doing these
things *with* Inform 7. Certainly some elements could be moderately
language-agnostic, at least in terms of the overall details. (Just as some
programming books on, say, C++ or Java, do include aspects that could be
considered language-agnostic.) But the implementation, of course, would be
how to do these things in the constructs that Inform 7 makes available.

> 2) whether (on the other hand) it's reasonable to try to teach people
> to write in a form of which they've experienced no examples. I
> wouldn't expect someone to write a good short story if he had never
> read one before, no matter how carefully the teacher introduced
> concepts of plot, pacing, characterization, dialogue, and so on.

Agreed. To be sure, the groups I'm dealing with were exposed to the
*concept* of text-based interactive fiction, but not the *programming* of
it. For example, all of them had "heard of" so-called 'text adventures' and
others had played some in their past. Many others knew of 'Choose Your Own
Adventure' books which, in their minds, is just a difference in kind. We
also looked at various games. As I mentioned in another post, one good
example was "The Hitchhiker's Guide to the Galaxy" which had the benefit of
being a book and a game in the text-based IF format. We also looked at
"Amnesia" (story by Thomas Disch) and "Mindwheel" (story by Robert Pinsky).

What got people interested (moreso the writers) is how this format could be
used to present a different form of storytelling. That then naturally leads
to the question of what elements of storytelling transfer over. For example,
do you have to sacrifice anything? (Going from book to film, for example,
you usually do. So what are the sacrifices in terms of going from book to
text-based game?) The writers were excited by the idea of increased
interactivity. One of the writers for example wanted to see a rendition of
Clive Barker's "The Hellbound Heart" (more popular to some as the
"Hellraiser" movie) done in the form of text-based interactive fiction.
Another thought that Greg Egan's "Permutation City" would be an interesting
translations.

These kinds of things writers excited about the idea of a new medium for
plying their trade. I think it would be a good area for Inform 7 to increase
its entry into. I've found that such writers, even if not wanting to create
games, see an ability to use Inform as a prototyping tool. Others saw it as
a relatively unique way to present screenplay ideas.

As I said in another post, my programmers were not so much interested in the
storytelling aspect, per se, at least as it relates to strict novel or short
story writing practices. HOWEVER -- they *were* interested in the nature of
game programming and how the story could be effectively told via the game.
So, for example, a game programmer interested in a style of game like "The
Longest Journey" or even something like "Syberia" could see elements of how
to think about constructing a game, even if their focus wasn't so much on
story-telling per se. One thing that I did find interesting is that some of
the programmers did see a tool like Inform 7 as being a prototyping tool
even for graphical games. It's sort of gave them the impression of an
interactive storyboard for the game. We explored this a little bit by
considering how we'd take a game like "The Dig" (story by Alan Dean Foster),
done as a graphics-based adventure game, and prototype the opening scenes in
Inform 7.

One group I've sort of ignored in these posts is that group with the
children. A couple of reasons. That one is not being done in a formal
setting at all. It's a bunch of parents and their kids who have agreed to
get together to see what they think about the use of something like Inform 7
for teaching their children the ideas of story-telling. A few of these
parents are teachers (one at a grade school, the other at a high school) and
they have shown great interest in the concepts of Inform 7. The reason I
bring this up is because, here again, is an audience that might be something
to consider when presenting how to talk about the ideas behind Inform 7.

> Anyway, so far you're convincing me more that very novice users need a
> different manual entirely (or some supplementary documents to the main
> text), rather than that it is possible to edit the existing manual to
> serve them while still remaining functional for its current users.

If I've done that, then I feel I've at least made a positive contribution
(and hopefully not an annoying one). I do believe what you're saying here is
accurate but I also fully realize the challenges involved. I'm currently
embarking on that "working hypothesis" I presented to the class regarding a
possible structure of a manual. So as I get that in place and see how people
respond to it, I can report back on those findings as well.

- Jeff


José Manuel García-Patos

unread,
Jun 9, 2007, 1:28:48 PM6/9/07
to

> Emily has already talked about the pitfalls of the "single game
> gradually written" form of multi-example. We went back and forth on
> this. Part of the reason we didn't really go down this route, I think,
> was also that it's much more fun to have a great variety of settings
> and writing styles in the examples. It suggests that IF can be a lot
> of things.

The best tutorial for I6 (for InformATE, actually) that I ever read was
one where a single game was constructed step by step while the basics of
Inform were explained as they appeared. That tutorial, unfortunately,
was incomplete, and maybe that was the reason why I found some parts of I6
difficult to learn. If you need a greater variety of settings, styles, or
whatever, you can always change the example game slightly, as in "you can
do that, but you could have also done this", or "you can do it this way or
that other." After all, I7's documentation is hypertext, so you can make
branches, and jump back and forth between several issues. Things will
always be kept in order because everything would appear when the user
would encounter it in real IF writing. I would put code samples,
and then links to the technique(s) employed in it, in case we were not in
that particular chapter. In a way, writing documentation like that could
be like writing IF non-fiction.

Besides that, one could use that example game as a template for his own.
In that case, the approach would be doubly useful.

All The Best.
José Manuel García-Patos
Madrid

Andrew Plotkin

unread,
Jun 9, 2007, 2:21:23 PM6/9/07
to
Here, Jeff Nyman <jeff...@gmail.com> wrote:
> "Emily Short" <ems...@mindspring.com> wrote in message
> news:1181348471.6...@p77g2000hsh.googlegroups.com...
>
> > There might be room in the world for a
> > document that started from scratch by explaining what IF is and
> > introducing various conventions and design methodologies.
> > [...]

> > 1) whether it would be better for such a guide to be language-
> > agnostic, so that it could be used as an introduction regardless of
> > whether the author wanted to go on to use I7 or TADS 3 or one of the
> > older languages
>
> That could be. Now, one of the things I've seen that clearly interests
> people with no IF programming experience is the fact that Inform 7 uses the
> natural language constructs. (I know what a hot topic that is for people; I
> was skeptical myself. But I've come to realize that people -- children and
> adult alike -- really respond to it.)
>
> So, to that end, I think the language-agnostic aspect of this would hurt
> Inform 7 specifically because such people are interested in doing these
> things *with* Inform 7.

You were talking about a particular (hypothetical) document in this
thread: a document about techniques of IF craftmanship, what makes
pacing work, how to introduce characters and make them interact.

I have occasionally thought about that document too, but I wasn't
imagining it as a tutorial. I was inspired by Scott McCloud's
_Understanding Comics_, which is a detailed travelogue of the elements
of comics and cartoons. It's (in my opinion) intended to give readers
a better and more educated eye for what goes into comics, so that they
can understand more of what's going on, and appreciate it at a
conscious level.

(You might say that if a comic book can't convey its message to a lay
audience, then it's a failure, and so accompanying it with an
educational text is only underscoring the failure. But I love learning
about process and technique; it gives me a richer view of the work,
even work which I already liked.)

Now, _Understanding Comics_ isn't a how-to document. It *is* aimed, to
some extent, at journeyman comic artists. But it doesn't try to teach
you the craft; it tries to give you a sense of where the craft can go,
which gives you the chance to explore those roads (which you might
otherwise have overlooked.) And, to beat the metaphor entirely flat,
it plants a lot of flags around the landscape; landmarks of interest.

So that's one model of an IF document. That wouldn't be particularly
technology-oriented; it would mention the major platforms, but it
wouldn't go into much source code.

The other model is what you seem to be talking about: "IF from the
ground up, and how to go about it (in I7)". That would have to be
platform-specific, because a huge percentage of it would be source
code.

But I think that *this* model, even though it's I7-specific, would not
focus on I7 constructs as its organizing principle. You wouldn't have
a section on relations, and how to use them. You'd have a topic, say
"representing the internal state of characters", and relations would
naturally come up as a tool for doing that.

You then reach a methodological fork. You can say that the document is
intended for I7 newbies, so it has to teach relations before it can
use them. So you integrate a lesson on relations the first time they
come up.

Or, you can say that this is not an I7 manual at all. The first time
relations come up, you refer the reader to the appropriate section of
the I7 reference manual. Except then you have to write an I7 reference
manual, because -- as we've been discussing -- the current I7 manual
is not that.

(The nice thing about the latter form is that you could re-use a lot
of it for a different platform: "IF from the ground up, and how to go
about it (in T3)" You'd be rewriting a lot of the *body* of the work,
but the table of contents would be unchanged, and the discussion of
the topics would be mostly the same.)

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're patriotic.

Emily Short

unread,
Jun 9, 2007, 2:54:57 PM6/9/07
to
On Jun 9, 5:47 am, "Jeff Nyman" <jeffny...@gmail.com> wrote:
> "Graham Nelson" <gra...@gnelson.demon.co.uk> wrote in message:
> > (c) To describe I7 but not IF. The DM4 was a sort of hybrid book, half
> > about Inform, half about the canon of IF and its traditions and
> > history. Here, we tried not to get into questions of what "good" IF
> > might be...
>
> Right -- and here I should clarify, because I probably was being misleading.
> People I talk with don't necessarily want something like "The Craft of
> Adventure." What they want is how using relations will help them with story
> structure. What they want is how certain types of actions can be used to
> help pacing of a story. In other words, they want to learn how the
> *specifics* of Inform 7 can be used to implement the various aspects of the
> craft of good writing. Put another way, they want to see how the craft of
> writing can be translated to the craft of writing text-based interactive
> fiction.

Oof, I have no idea where I'd even start with something like that: it
feels to me a little like saying "please discuss how a chisel can be
used to produce a well-proportioned statue." The chisel isn't useless,
but it's not where the proportion comes from.

It sounds to me as though what your writers are missing is a sense of
what interaction can do for a narrative. Having heard of interactive
fiction, or having a vague sense that choose-your-own-adventure novels
are similar, isn't really a sufficient basis for understanding what IF
adds to (and takes away from) non-interactive fiction.

A better understanding of this would partly answer questions like "how
is this story going to have to differ from the story in a novel?", and
would also provide more context for understanding what Inform's tools
are for -- namely, making the *interaction* better. But if I were
going to discuss this topic, I would have to start more abstractly;
not with the constructs of Inform code (which are useful at a lower
level) but with ideas like exploration, choice, role-playing, and
complicity. I'm not sure whether it would ever get to a point where I
could draw in relations, e.g. -- they're useful in a range of ways,
but that usefulness has to do with the programming model, and the way
in which the model relates to the story-telling is going to vary from
piece to piece, depending on how the author designed it.

Jeff Nyman

unread,
Jun 9, 2007, 4:43:07 PM6/9/07
to
"Emily Short" <ems...@mindspring.com> wrote in message
news:1181415297....@k79g2000hse.googlegroups.com...

> It sounds to me as though what your writers are missing is a sense of
> what interaction can do for a narrative. Having heard of interactive
> fiction, or having a vague sense that choose-your-own-adventure novels
> are similar, isn't really a sufficient basis for understanding what IF
> adds to (and takes away from) non-interactive fiction.

That's a very good point and one that I believe is very true. That said, I'm
not convinced that text-based interactive fiction has been approached as
much from a writing standpoint. (The persistence of second-person --
something that is virtually absent from printed novels and even many other
game formats -- is one possible example of that.) Based on my studies of
narrative structure (and some of the debates on this newsgroup), I'm not
convinced most practitioners of writing text-based interactive fiction truly
understand what IF adds to and takes away from other forms of fiction, such
as printed novels. Granted, that's an incredibly sweeping statement and I
know that, like all generalizations, it's easy to find examples that would
seem to disprove it. But I believe that this observation is true over the
wide scheme of text-based interactive fiction, not only as it is practiced
now, but as it was in the past as well.

So, to be honest, I think there is a lot of value in the "stranger value"
aspect to text-based IF because I think certain forms of thinking have
dominated it for quite some time. I don't mean this in some sort of "Cabal"
sense. I mean this as a sort of collective inertia that has sprung from how
such games were originally crafted. (As another example, you can look at how
much has changed even with writing conventional fiction; it used to be that
backstory and setup were part of the novel, relegating the inciting incident
well into the story. That trend, I believe, stopped a lot of good
story-telling structures, and, to be sure, we see the change that has
occured since that time: the inciting incident is now where many novels
actually start.)

On a similar note, and relating to the notion you brought up regarding the
idea of "please discuss how a chisel can be
used to produce a well-proportioned statue", I've taken game programming
courses, for example, and one thing most of the good ones *don't* start out
with is actually programming a game. They start with what makes a good game;
and how you can use the abilities of graphics and sound to create a good
game. They talk about how a story can be presented in the form of a game.
But then they start immediately showing how the *specifics* of the game
engine (or language) you are using can be used to create those elements.
While it may be true that the game engine ("chisel") can't put in the
proportion, it can often dictate to what extent the proportion can take.

> A better understanding of this would partly answer questions like "how
> is this story going to have to differ from the story in a novel?", and
> would also provide more context for understanding what Inform's tools
> are for -- namely, making the *interaction* better. But if I were
> going to discuss this topic, I would have to start more abstractly;
> not with the constructs of Inform code (which are useful at a lower
> level) but with ideas like exploration, choice, role-playing, and
> complicity.

Well ... okay, I see your point. Let me see if I can answer to it, at least
in terms of where my thinking started off and where it was going.

One of the things most writers noticed about text-based interactive fiction
was that characters were often given the short end of the stick. As most
writing courses teach you, readers care most about characters. (Game
programming courses teach you this as well, when they talk about crafting
interesting characters to populate a game world.) Good writing courses teach
you that readers remember images and actions best. They also talk about the
nature of scenes and the pacing within scenes that puts you, as the author,
more in control of the story. Now, with interaction of the sort that
text-based IF offers, the model of interaction is different and the notion
of author control is modified in some ways. The contention, however, is that
what makes a good story a good story has not changed. Since the arbiter of
the interaction part is the game engine (in this case, Inform 7) relating
those interaction parts to what makes a story good seems right on target.
Or, at least, that was how my thinking went. And I'll be the first to admit
that the first classes with the writers were incredibly bumpy, as you can
imagine with a lot of floundering around (on all of our parts).

> I'm not sure whether it would ever get to a point where I
> could draw in relations, e.g. -- they're useful in a range of ways,
> but that usefulness has to do with the programming model, and the way
> in which the model relates to the story-telling is going to vary from
> piece to piece, depending on how the author designed it.

Exactly! That's what most writing courses teach you as well. There is
technique but how that technique is used and how effective it is will differ
from author to author (which is where talent comes in) and from the nature
of the work itself, which may be more or less amenable to certain techniques
given such things as tone, narrative structure, etc.

What's interesting to me is that I originally agreed with you. I didn't
really see the efficacy of relations so I didn't cover them as much. Once I
did, however, the writers pounced on the idea. They really liked it. That's
in fact what led to the "re-written" chapter 13, because everyone wanted to
explore the notion of relations more. It was here that just about all of the
writers in my class found that they could start to bridge the idea of what
makes a story good and the constructs of Inform. Most of the rest they just
saw as creating a game. When I got to relations, they started to see writing
a story, with a game being just one part of it.

So ... what's perhaps interesting is that I'm coming to vastly different
conclusions than yourself and, it sounds like, Andrew (maybe) and Graham.
Since you all have been actively practicing this for more years than myself,
I take that seriously because it does call into question not just my methods
but perhaps my conclusions. So I'm not sure at this point.

- Jeff


Jeff Nyman

unread,
Jun 9, 2007, 5:00:01 PM6/9/07
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:f4er33$c8l$1...@reader2.panix.com...

> You were talking about a particular (hypothetical) document in this
> thread: a document about techniques of IF craftmanship, what makes
> pacing work, how to introduce characters and make them interact.

Yes, but one caveat. I was talking about a document "about techniques of IF
craftmanship *as applied with Inform 7*." Keep in mind that Inform 7 is
specifically being targeted because it's a tool that others (non-programmers
and writers) have taken a more keen interest in than other similar tools,
partly because Inform 7's presentation and structure gives them the idea
that they can do something with it that those other systems cannot. People
aren't so much interested in learning "IF craftmanship" in a vacuum because
my contention, along with some of the writers, is that such craftmanship
might be in need of a change if the idea is broadening out the appeal of
text-based interactive fiction.

> But I love learning
> about process and technique; it gives me a richer view of the work,
> even work which I already liked.

Absolutely agreed. I'm the same way.

> Now, _Understanding Comics_ isn't a how-to document. It *is* aimed, to
> some extent, at journeyman comic artists. But it doesn't try to teach
> you the craft; it tries to give you a sense of where the craft can go,
> which gives you the chance to explore those roads (which you might
> otherwise have overlooked.)

Understood. Now, I could see a similar thing about "Understanding Short
Stories" or "Understanding Storytelling." But, unlike comics and unlike
short stories or novels, text-based interactive fiction offers a different
level of interaction than those formats because it's a type of game. So, do
you think the following statement is true: a hypothetical "Understanding
Games" *would* probably teach you some of the craft where "Understanding
Comics" would not.

> The other model is what you seem to be talking about: "IF from the
> ground up, and how to go about it (in I7)". That would have to be
> platform-specific, because a huge percentage of it would be source
> code.

Or: consider this. There's a book I really enjoyed called "Lights! Camera!
Fiction! A Movie Lover's Guide to Writing a Novel" by ALfie Thompson. That
book doesn't talk about novels or movies "from the ground up." What it does
is talk about translating from one medium to another but while keeping the
basics of what makes a compelling story very much in mind. So I see
something like "A Story [Novel] Writer's Guide to Writing Text-Based
Interactive Fiction." It's not so much "IF from the ground up" (although
parts of that would bubble up during the discussions). Rather, it's how to
use a specific system that allows you to translate from one medium to the
other.

> But I think that *this* model, even though it's I7-specific, would not
> focus on I7 constructs as its organizing principle. You wouldn't have
> a section on relations, and how to use them. You'd have a topic, say
> "representing the internal state of characters", and relations would
> naturally come up as a tool for doing that.

Right! Exactly! That "naturally come up" part is what I'm talking about.
Rather than have a manual broken up by conceptual topics (Relations,
Actions, Advanced Actions) you'd have a conceptual chapter based on what
storytellers (and game writers) do: i.e., represent characters. Within that
chapter you'd talk about the means by which that can be achieved with Inform
7. (After all, they're reading about Inform 7; they're going to try this in
Inform 7; you're trying to convince them Inform 7 is a good tool for doing
so; --- you can't really separate the implementation too much from the ideas
because then it becomes too theoretical, which would be the kiss of death
for some people.)

> (The nice thing about the latter form is that you could re-use a lot
> of it for a different platform: "IF from the ground up, and how to go
> about it (in T3)" You'd be rewriting a lot of the *body* of the work,
> but the table of contents would be unchanged, and the discussion of
> the topics would be mostly the same.)

This kind of reminds me (at least in concept) of the "Thinking in
{Language}" books, like "Thinking in C++", "Thinking in Ruby", "Thinking in
Java", "Thinking in Python", etc. Those books are released under a license
that allows people to literally take the entire book, but change the details
so that it matches a given language. Conceptual chapters about programming
are often left in as-is, with the exception of modifications of a few
examples.

That could be interesting, I agree, and probably is a route that might be
beneficial for text-based interactive fiction practitioners and perhaps even
help those people who get stuck in analysis mode, trying to choose which
tool they should use. That said, not all tools are necessarily viewed the
same. For example, parents didn't get as excited about seeing TADS 3 or Hugo
code as they did with Inform 7 code because they didn't see it as useful or
as "fun" for kids. Writers didn't see TADS 3 or Hugo matching how they
thought about storytelling, whereas they did find that with Inform 7.

So a large part of what I'm looking at here is what (I thought) some of the
goals of Inform 7 were: to widen out the possible appeal of text-based
interactive fiction and to introduce it to a wider audience. This wider
audience may not care as much about how many other tools there are because,
to them, Inform 7's unique structure and presentation is what makes it their
choice.

- Jeff


Emily Short

unread,
Jun 9, 2007, 5:48:33 PM6/9/07
to

Jeff Nyman wrote:
> So, to be honest, I think there is a lot of value in the "stranger value"
> aspect to text-based IF because I think certain forms of thinking have
> dominated it for quite some time.

Sure -- but if you're coming to it from that perspective, there is
also some risk entailed if you hand these strangers a how-to-craft IF
book that (pretty much necessarily) is full of ideas originating in
this community.

> On a similar note, and relating to the notion you brought up regarding the
> idea of "please discuss how a chisel can be
> used to produce a well-proportioned statue", I've taken game programming
> courses, for example, and one thing most of the good ones *don't* start out
> with is actually programming a game. They start with what makes a good game;
> and how you can use the abilities of graphics and sound to create a good
> game. They talk about how a story can be presented in the form of a game.
> But then they start immediately showing how the *specifics* of the game
> engine (or language) you are using can be used to create those elements.
> While it may be true that the game engine ("chisel") can't put in the
> proportion, it can often dictate to what extent the proportion can take.

Right, sure -- but you probably don't find yourself looking at things
like "how to use arrays in your game" or "variables and their role in
characterization". There's some point at which the code elements are
too basic to be grounded this way.

> What's interesting to me is that I originally agreed with you. I didn't
> really see the efficacy of relations so I didn't cover them as much. Once I
> did, however, the writers pounced on the idea. They really liked it. That's
> in fact what led to the "re-written" chapter 13, because everyone wanted to
> explore the notion of relations more. It was here that just about all of the
> writers in my class found that they could start to bridge the idea of what
> makes a story good and the constructs of Inform. Most of the rest they just
> saw as creating a game. When I got to relations, they started to see writing
> a story, with a game being just one part of it.

Hm. Well, I can certainly imagine that from an encounter with
relations, they might start thinking about things like "what do I want
to represent in this game? What am I modeling? If I'm keeping track of
things like who-knows-what-about-whom, what kind of storytelling does
that allow me to do?" And, indeed, the fact that Inform 7 tracks
things this way does encourage me to do that kind of thinking when I'm
designing a new project. So this doesn't entirely surprise me, though
I wouldn't mind hearing more about what they latched on to
particularly, and why.

Jeff Nyman

unread,
Jun 9, 2007, 6:12:19 PM6/9/07
to
"Emily Short" <ems...@mindspring.com> wrote in message
news:1181425713....@k79g2000hse.googlegroups.com...

> I wouldn't mind hearing more about what they latched on to
> particularly, and why.

I'll start further collating these thoughts and post them here. It also had
a lot to do with scenes. People liked the idea of certain relations being
operative during given scenes, at least from a player point of view.

> Sure -- but if you're coming to it from that perspective, there is
> also some risk entailed if you hand these strangers a how-to-craft IF
> book that (pretty much necessarily) is full of ideas originating in
> this community.

Agreed. That said, I haven't seen to many "how-to-craft IF" materials, even
from this community. I have seen "how to use this particular system"
materials and "the nature of IF" materials, but I haven't seen much that
actually talks about the craft of text-based interactive fiction as a
story-telling medium (and how that medium can adopt practices from other,
related media).

> Right, sure -- but you probably don't find yourself looking at things
> like "how to use arrays in your game" or "variables and their role in
> characterization". There's some point at which the code elements are
> too basic to be grounded this way.

Well, sorta. To give you an idea, people were interested in variable so some
our simple forrays were like this:

<code>
When play begins:
let the current state be 2;
say "[the current state + 10]".
</code>

The above helped people learn what a variable was like and how it could be
represented since even the least programmatically-inclined among them could
understand what a variable was and how it was used. We also did stuff like
this:

<code>
A room can be marked or unmarked.

When play begins:
let the current state be 2;
say "[the current state + 2]".

Every turn when the turn count is even:
if location is unmarked, let the current state be 1;
otherwise let current state be 0;
repeat with area running through marked rooms
begin;
now every room which is adjacent to the area is marked;
end repeat.

To decide whether the turn count is even:
if the remainder after dividing the turn count by 2 is 0, yes;
no.
</code>

What people didn't want to see too much of was something like this:

<code>
Rule for printing a parser error when the parser error is not a verb I
recognise: say "Sorry, I don't know how to [verb word]."
To say verb word: (- PrintWordAt(verb_wordnum); -).
Include
(-
[ PrintWordAt n arr len;
arr = WordAddress(n);
len = WordLength(n);
for (n=0:n<len:n++)
print (char) (arr->n);
];
-).
</code>

So, you're right: these aren't examples that were showing anything about how
to craft a game. On the other hand, when you learn how to compose a sentence
(correct grammar), that's often separate from writing a novel since you can
use those same rules of grammar when composing a letter to a friend. But you
still learn them, even in the wider context of what you really want: writing
a good novel. So my writers did recognize the need to learn some of the
programmatic underpinnings.

People also liked to break down examples into specific permutations of
things that could be tried. What follows below are two examples of that in
action. The first example is just a "how to use tables" (without too much
about when or why you might want to) adapted from "Reliques." The second
example concerns a simple permutation of how containers and supporters can
work (including lit things that can be placed in containers). The point here
is just to show that we did get into just some "programmatic-only" type
stuff so that everyone could understand the basics.

= = = EXAMPLE: TABLES = = =

Table of Enchantments
Spell Nature Cost Duration
memorize arcana 1 a number
detect trap defensive 3 --
mend healing 2 --
magic missile offensive 1 --

When play begins:
say "The number of rows in the Table of Enchantments is [the number of rows
in the Table of Enchantments].[paragraph break]";
say "The third spell in the Table of Enchantments is '[spell in row 3 of the
Table of Enchantments]'.[paragraph break]";
say "The nature of the memorize spell is [the nature corresponding to a
spell of memorize in the Table of Enchantments].[paragraph break]";
say "The nature of the mend spell is [the nature corresponding to a spell of
mend in the Table of Enchantments].[paragraph break]";
say "[if there is a nature corresponding to a spell of detect trap in the
Table of Enchantments]There is a nature for detect trap.[end if][line
break]";
change (the nature corresponding to an spell of memorize in the Table of
Enchantments) to defensive;
say "The nature of the memorize spell is [the nature corresponding to a
spell of memorize in the Table of Enchantments].[paragraph break]";
[** A way to repeat through the table. **]
repeat with number
running from 1 to the number of rows in the Table of Enchantments
begin;
say "The nature of the [spell in row number of the Table of Enchantments]
spell is [nature in row number of the Table of Enchantments].";
end repeat;
say "[line break]";
[** A way to repeat without spelling out the "in row number" part. **]
repeat with number
running from 1 to the number of rows in the Table of Enchantments
begin;
choose row number in the Table of Enchantments;
say "The nature of the [spell entry] is [nature entry].";
end repeat;
say "[line break]";
[** A way to repeat without loop variables. **]
repeat through the Table of Enchantments begin;
say "The nature of the [spell entry] is [nature entry].";
end repeat;
say "[line break]";
[** A way to do the above but in reverse order. **]
repeat through the Table of Enchantments in reverse order begin;
say "The nature of the [spell entry] is [nature entry].";
end repeat;
say "[line break]";
[** A way to do the above but with ordering by column. **]
repeat through the Table of Enchantments in cost order begin;
say "The nature of the [spell entry] is [nature entry], with cost [cost
entry].";
end repeat.

= = = = = = = = = = = = = = = = =


= = = EXAMPLE: CONTAINERS = = =

The Study is a room.

The Living Room is a room. The Living Room is east of the Study. The Living
Room is dark.

The Bathroom is a room. The Bathroom is north of the Living Room.

[An open container that you can't get in but you can see in.]
A container called the bucket is in the Study.

[A lit thing in the bucket. Since the bucket is open, this should light up a
room.]
The glowing water is in the bucket. It is lit. The indefinite article of the
water is "some".

[A closed container that you can't get in and can't see in.]
A container called the cardboard box is in the Study. It is closed. It is
openable.

[An item inside the cardboard box. Since the box is closed, you shouldn't be
able to see it.]
A toy monkey is in the cardboard box.

[A lit thing in the cardboard box. Since the cardboard box is closed, this
shouldn't light up a room.]
A flashlight is in the cardboard box. It is lit.

[A closed container that you can't get in but you can see in.]
A container called the glass bottle is in the Study. It is closed. It is
transparent.

[A lit thing in the glass bottle. The bottle is closed, but since it's
transparent it should light up a room.]
A firefly is in the glass bottle. It is lit.

[A container you can get in and that you can't see out of.]
[To test that enterable containers act the same as non-enterable, place any
item in here and close the container. You shouldn't see it from outside.]
A container called the wooden create is in the Study. It is closed. It is
openable. It is enterable.

[A container you can get in and that you can see out of.]
[To test that enterable containers act the same as non-enterable, place any
item in here and close the container. You should see it from outside.]
A container called the glass box is in the Study. It is closed. It is
openable. It is enterable. It is transparent.

[A container that that can be locked or unlocked. It shouldn't be locked to
begin with. It starts open.]
A container called the rolltop desk is in the Living Room. It is lockable.
It is openable. It is closed.

[A container that can be locked or unlocked. It starts as being locked.]
A container called the drawer is part of the desk. It is locked. It is
openable. It is closed.

[A container that is lockable and locked, but doesn't require a key; instead
you have to turn a latch.]
A container called the hamper is in the Bathroom. It is lockable. It is
openable. It is closed. It is locked.
A latch is part of the hamper.

[A container that is scenery that has objects in it. This object will have
other non-scenery objects in it. The important thing to note is that the
object will not be listed as part of the room even with the other objects
because it is scenery.]
A container called the bath tub is in the Bathroom. It is scenery.
A rubber duck is in the bath tub.

[A supporter that is scenery that has objects on it. This object will have
other non-scenery objects on it. The important thing to note is that the
object will be listed as part of the room because of those objects. However,
if the objects are removed, this object will not be listed as part of the
room.]
A supporter called the table is in the Living Room. It is scenery.
A teddy bear is on the table.

[A container that is a vehicle. This should be portable.]
A vehicle called the toy wagon is in the Living Room. It is portable.

[A container that is a vehicle. It is pushable between rooms. Note that it
doesn't have to be portable.]
A vehicle called the shopping cart is in the Living Room. It is pushable
between rooms.

= = = = = = = = = = = = = = = = =

- Jeff


Emily Short

unread,
Jun 9, 2007, 9:09:17 PM6/9/07
to
Jeff Nyman wrote:
> "Andrew Plotkin" <erky...@eblong.com> wrote in message
> news:f4er33$c8l$1...@reader2.panix.com...

> > But I think that *this* model, even though it's I7-specific, would not


> > focus on I7 constructs as its organizing principle. You wouldn't have
> > a section on relations, and how to use them. You'd have a topic, say
> > "representing the internal state of characters", and relations would
> > naturally come up as a tool for doing that.
>
> Right! Exactly! That "naturally come up" part is what I'm talking about.
> Rather than have a manual broken up by conceptual topics (Relations,
> Actions, Advanced Actions) you'd have a conceptual chapter based on what
> storytellers (and game writers) do: i.e., represent characters. Within that
> chapter you'd talk about the means by which that can be achieved with Inform
> 7. (After all, they're reading about Inform 7; they're going to try this in
> Inform 7; you're trying to convince them Inform 7 is a good tool for doing
> so; --- you can't really separate the implementation too much from the ideas
> because then it becomes too theoretical, which would be the kiss of death
> for some people.)

Now this is something that I can begin to imagine the shape of. Off
the top of my head, I'm imagining things like:

-- Setting
-- Place as a reflection of its history and purpose in the story
-- The gun over the mantlepiece rule more important than ever,
since you
must physically supply any objects that are going to be
critical in
the action
-- Creating rooms and objects
-- Varying descriptions of rooms
-- Using embedded [] elements in say phrases and descriptions
-- Using "writing a paragraph about", etc., to control the way
objects are
described
-- Some discussion of whether it's necessary to report
everything
present in a room; drawing the player's attention to one
thing or
another. (see Nothing More, Nothing Less)
-- Designing a map
-- Techniques in map design for creating a coherent geography,
etc.
-- Backdrops to create scenery visible from multiple places
-- Interactive parts of a setting
-- Machinery, e.g., that reveals something about what the area
is used for
-- Devices, on/off switches, settings and so on; creating
mechanisms

-- Atmosphere -- making areas seem alive and setting a mood (see
Anchorhead)
-- Every turn rules
-- Evoking sounds, smells, etc. in a given location
-- Making crowds seem active
-- Giving even quiet non-player characters something to do
-- Using tables or text variations extension to produce
randomized text
-- Time
-- Creating a schedule of background events
-- weather and time of day
-- shops opening & closing, etc.

-- Exposition -- letting the player discover material without info-
dumping
-- Writing a good introduction
-- When play begins: ... rule
-- Hinting, drawing the player's attention in the right directions
-- In-game sources of information
-- Books, computers, consultable devices
-- Other characters (though postpone detailed discussion of
conversation)

-- Plot
-- Planning scene structure
-- Using the scene mechanism
-- Moving the player from place to place
-- Changing rooms and moving objects around between one scene
and the next
-- Using time out of sequence
-- Flashbacks (see All Hope Abandon)
-- Temporally non-linear narrative (see Photopia)
-- Linear vs. branching narrative
-- Using the scene mechanism to handle choice alternatives by
the player
-- Presenting choices clearly; omitting irrelevant choices
-- (Probably would need more philosophical discussion here
about when
and why we want to let the player control the course of
the plot --
not because there's a single right answer but because this
is
something the author of any branching game ought to think
about
long and hard)
-- Conveying the shape of the narrative
-- Foreshadowing
-- In descriptions and events, much as in static fiction
-- In action, by teaching the player commands and techniques
that are
going to become important later
-- Teaching complicated new actions in small steps
-- Giving simple initial challenges to the player
-- Creating actions that work in a consistent way
throughout the IF
-- Designing a new action
-- Designing a model to support it
-- Tracking and signalling progress through the story
-- Score and alternatives to scoring
-- Using the status bar (make analogy to page numbers, if
writers are
resistant to having one)
-- Concept of "plot progress" or triggers -- what the player
knows or
has done so far, or important things that have happened,
relative
to what still remains to happen
-- Writing endings
-- Single and multiple endings
-- Function of multiple endings
-- "when play ends" rules

-- Pacing
-- Pacing individual scenes
-- Actions as they affect perceived pace for the player
-- Types of action (see Attack of the Yeti Robot Zombies)
-- Low-suspense commands like LOOK vs. more dramatic
actions
-- Density of dramatic behavior --> perceived intensity of
scene
-- Overview of the standard library actions and which
produce
dramatic results; using the ACTIONS index
-- Quantity and quality of feedback
-- Replies different from the standard library response
-- Giving enough response to an action that a player
remains
interested but not so much that he feels he has no
control over
events
-- The use of cut-scenes
-- Printing large quantities of text in Inform 7
-- High-suspense scenes (combat, physical danger, etc)
-- Every turn rules that keep events rolling (see Heroine's
Mantle)
-- Timed puzzle scenarios
-- Providing lots of clues about what to do next so that the
player
doesn't trip in these scenarios: if we want a scene that
plays like
an action scene or swash or something, the player should
spend
minimal time thinking about what to type next
-- Trapped/set-length scenes (being locked in a cell, on a
journey, etc)
-- Pacing when the player is faced with a single problem to
solve
-- Focus, controlled frustration
-- Opportunity to convey information, esp. if the player
is unable
to leave while he hears/sees an event
-- Legitimate ways to trap the player
-- Preventing actions during a scene
-- Writing sensible refusals while the scene progresses
-- Maintaining interest while working on the single problem
-- Designing puzzles with feedback for partial solutions
-- Atmospheric techniques to maintain local color
-- Internal monologue, development of character reaction
to
situation (see also Viewpoint and Viewpoint character)
-- Scenes with a minimal length where player cannot finish in
less
than N turns
-- Exploratory scenes
-- Leaving hints and guidance to move the player along
-- Exploration with a specific goal in mind, giving shape to
a sequence
-- Descriptions and reactions that reflect what player
already knows
-- Tracking what player has seen (perhaps introduce
Epistemology
extension and/or examples demonstrating this)
-- Conversation scenes
-- Switching control between the player and the non-player
character
-- (probably would leave the particulars of this until
later, since
it's complicated to implement and depends on your
conversation
model)
-- Ending scenes with a hook
-- Making the final action of a scene important (and
something that
feeds into the later parts of the game)
-- Pacing narrative as a whole
-- Using puzzles to control the player's access to plot
-- Geographical puzzles
-- Locked doors, vehicles, light source puzzles
-- Locks and keys, vehicles, light
-- Designing a map with pacing in mind
-- Research puzzles
-- Making sure the player has learned background before
moving on
-- Tie back to "in-game sources of information" above,
perhaps

-- Viewpoint and the Viewpoint Character
-- Characterization
-- Physical description
-- Describing the viewpoint character
-- Giving the viewpoint character appropriate clothes
-- Selecting what to model depending on the focus of the
piece,
since not every character needs a full set of clothes,
but this
is sometimes appropriate to have for some characters
-- Abilities
-- Giving viewpoint character appropriate tools and props;
communicating what the character is and can do from
the outset
-- Action refusal messages: what the character won't do reveals
who he is
(see Rameses)
-- Using extensions or rules to change the default library
messages
-- Room descriptions and character attitude (see Common Ground)
-- Allowing the player to role-play and explore the character
-- Custom actions reflecting character-appropriate behavior
(see Tale of the Kissing Bandit)
-- Creating simple new actions
-- Cluing character-appropriate commands in the text
-- Setting goals for the viewpoint character
-- Problems in forcing viewpoint character into one emotional
state or
another
-- Leaving goals partly open, including some element of
choice (not
a required feature of a work of IF, but again worth
thinking about)
-- Using internal monologue
-- Modeling character's attitude and discoveries;
Epistemology
extension again, and other ways of keeping track of what
the player
knows or feels
-- Triggering internal thoughts automatically
-- Using every turn rules or otherwise tracking the
player's plot
progress
-- Triggering thoughts as a response to player actions
-- Writing special response/instead rules for special
situations
-- Allowing the player to explore mental state
interactively
-- Implementing commands involving thought
-- THINK
-- REMEMBER
-- Allowing the player to express mental state for the
character
-- Implementing common gestures (even if they don't
much affect
the surrounding world)
-- KICK, SMILE, FROWN, SHOUT, ETC.
-- Making sure these behave appropriately around
other
characters -- sometimes these may be more trouble
than
they're worth
-- Changing the viewpoint character
-- "change the player to..." stuff (see Being Andrew Plotkin)
-- Changing room descriptions etc. accordingly (also covered
above)
-- Voice
-- Using the extensions for first/third person (see Fallacy of
Dawn)

-- Other Characters
-- Reactive characters who respond to/notice what the player does
-- "in the presence of" and related rules
-- Characterization in absentia
-- Physical artifacts, memories, etc., giving clues about
characters
-- Conversation
-- Basic action stuff on conversation
-- Choosing a conversation model for your work
-- How to use ask/tell
-- How to substitute in TALK TO
-- How to use conversation menus, and standard extensions for
that
-- Writing good conversation output
-- Presenting gesture and attitude of the character
-- "Talking Head Avoidance"
-- Involving the surroundings in the conversation
-- Using actions to let the character do minor actions
while talking
-- Using scenes to structure conversation
-- More advanced topics in conversation systems
-- Possibly introduce some of the extensions available
-- Tracking character attitudes dynamically
-- Variables and relations for attitudes between
characters
-- Using the model to affect output -- this is going to
change a
lot depending on what the model *is*; I could write a
longer
outline here, but I've already written about
conversation
at brain-destroying length over at

http://emshort.wordpress.com/writing-if/my-articles/conversation/
-- Automated character behavior
-- Advanced actions
-- Tracking character knowledge
-- Goal-seeking (but talk about how this is likely to affect the
author's
control over the story; design appropriately)

I don't know -- is this at all close to what you imagine? From my
perspective, it's got some weird flaws and gaps. This is possibly
because it's a quick brainstorm and I haven't put a lot of time into
organizing it or filling in the holes. But some of the weird things
are inherent, I think: because it's not really interested in the
gaming perspective, it relegates puzzles to a relatively small corner
as a pacing device (which, from the point of view of narrative, they
usually are).

Also, by assuming that we want to teach by analogy with conventional
fiction, I leave out the most important lesson (IMO) about IF design:
you have to start by figuring out what the player is going to do.

-- Interaction Rule 1: First answer the question, WHAT DOES THE PLAYER
DO?
-- Exploration
-- Choice
-- Complicity
-- Role-playing
-- Resolving Challenges (mostly puzzles in IF)

and

-- Interaction Rule 2: Build your model around what the player does
-- Creating actions that are relevant to the structure as a whole
-- Building the model that supports those actions

So I guess I can see an introduction that does take a perspective from
the view of a fiction writer, but I still think that it would need a
few sections specifically about interaction, even if that formed no
part of the writers' existing backgrounds.

ChicagoDave

unread,
Jun 9, 2007, 11:55:01 PM6/9/07
to
On Jun 9, 5:12 pm, "Jeff Nyman" <jeffny...@gmail.com> wrote:
> "Emily Short" <emsh...@mindspring.com> wrote in message

I'm interested in this subject as well, but from a publisher's
perspective.

I think a guide called "Writing to the Interactive Fiction Medium" is
what you're looking for and I'd like to see this developed somehow.

But I agree with Emily that such a guide wouldn't contain much if
anything about programming IF.

The guide would probably have to blend game design skills, the various
lists we've developed of Do's and Don'ts, Bob Bate's Puzzle white
paper, and then taking traditional writing aspects and mapping them to
IF. To do this, you'd probably have to have an entire game designed
for IF on paper and then take that final design and back port it to
the guide's intentions.

Since Textfyre will be doing all of its games in design format first,
it's possible that we could help develop such a guide. I'd wait until
we've perfected our design processes, but after a half dozen games, I
think we definitely could develop such a guide.

David C.

ChicagoDave

unread,
Jun 10, 2007, 12:00:47 AM6/10/07
to
On Jun 9, 5:12 pm, "Jeff Nyman" <jeffny...@gmail.com> wrote:
> Agreed. That said, I haven't seen to many "how-to-craft IF" materials, even
> from this community. I have seen "how to use this particular system"
> materials and "the nature of IF" materials, but I haven't seen much that
> actually talks about the craft of text-based interactive fiction as a
> story-telling medium (and how that medium can adopt practices from other,
> related media).
>

I'm interested in this subject as well, but from a publisher's

Rioshin an'Harthen

unread,
Jun 10, 2007, 5:16:30 AM6/10/07
to
"Emily Short" <ems...@mindspring.com> kirjoitti viestissä
news:1181437757....@q66g2000hsg.googlegroups.com...

[snip brainstormed structure]

Now, this (snipped out) structure is looking like something I'd actually
like to
read.

I'm wondering how many times I've read through the I7 manual, and there's
still parts of it that I'm wondering *how and when* to use, like the
relations
mentioned in this thread earlier. The manual occasionally feels too
abstract,
even with the examples; it just doesn't give a coherent picture of when
something can be useful.

Something structured along the lines of Emily's brainstormed structure might
be able to step over that gap, and actually enable me to be able to create
something other than extensions...

However, as Emily noted, puzzles are left as almost a side remark in that
structure. Maybe - I don't know if this idea is that good or not - split the
pacing chapter into two, one describing the general pacing of a work of
IF, the other consentrating on pacing using puzzles.

Similarly, if something feels like it needs a bit more attention, bring it
out
of the chapter it is in and create a new chapter of it; and if something
feels
like it shouldn't have a chapter of its own, then combine it with a suitable
chapter. Structures, especially just brainstormed ones, are prone to evolve,
possibly beyond recognition. :)

(If I haven't made it clear yet: I hope someone would write this; someone
who knows enough of I7 to be able to describe the parts used, and most
importantly, why they've chosen to use just that feature in this particular
place.)

Jeff Nyman

unread,
Jun 10, 2007, 6:46:51 AM6/10/07
to
"Emily Short" <ems...@mindspring.com> wrote in message
news:1181437757....@q66g2000hsg.googlegroups.com...

> I don't know -- is this at all close to what you imagine?

I think what you put there is definitely the closest I've seen to where this
has all been leading me. I really like it.

> organizing it or filling in the holes. But some of the weird things
> are inherent, I think: because it's not really interested in the
> gaming perspective, it relegates puzzles to a relatively small corner
> as a pacing device (which, from the point of view of narrative, they
> usually are).

Understood. Part of that is probably translating from one medium to another.

Written narrative differs from film, of course, in that a writer can get
into more aspects of a given experience than the movie can. So, as just one
example, you can be taken further into the minds of characters and balance
that with action. An author can let people share in memories and the
consciousness of characters. These images, unlike in film, are seen only in
the mind so that means readers have to participate in a different way than
film viewers. Both are participating (thus both media require interaction)
but hte level of participation (interaction) is different.

The point here is that we have yet another level of participation with
text-based interaction fiction. This one focuses more on the interaction
possibilities that surround the story. So, going to your point about the
puzzles, perhaps that's not a bad thing as a pacing device in the sense that
the puzzles become something a little more subtle than they were or,
perhaps, more character-focused than they were or, perhaps, more focused on
being a connecting element of the story structure and the narrative than
they were. I'm thinking off-the-cuff here a bit.

> Also, by assuming that we want to teach by analogy with conventional
> fiction, I leave out the most important lesson (IMO) about IF design:
> you have to start by figuring out what the player is going to do.

I would agree. Writing fiction is often predicated on providing the reader
with an experience that is superior to the experiences they would encounter
in everday life. (That's from Sol Stein.) Part of that involves figuring out
exactly what the protagonist is going to do, at least ultimately. More
practically, most fiction involves coming up with an inciting incident that
drives a surface problem. The actions taken by the protagonist (and the
actions are part of a scene) lead to another surface problem and so on. All
of these, of course, lead to gradual development of the story-worthy
problem. The focus here is on crafting a situation and then creating a
character that is "worthy" of dealing with that situation.

Now, in text-based IF this conflation of the player-character with the
player is what I think has stopped up people from thinking in terms of
fiction and thinking in terms of characters-in-situation, except in the
simplest of ways, because it's predicated upon the notion that the
player-character is the player. You don't really craft a protagonist worthy
of the situation because, ultimately, you need the player to be the one who
is worthy of that situation and you don't know who they are! As any good
writing class tells you, you have to know your protagonist inside and out.

Even many other game formats do not have to deal with this. First-person
shooters are, of course, first person. (And cut scenes are usually third
person.) Graphical games have ofted referred to the player character in the
third person like Space Quest ("Roger Wilco"), Police Quest ("Sonny Bonds"),
Kings Quest ("King Graham"), the Monkey Island series ("Guybrush
Threepwood"), The Longest Journey ("April Ryan"). Text-based IF is largely
alone in its use of second-person.

> So I guess I can see an introduction that does take a perspective from
> the view of a fiction writer, but I still think that it would need a
> few sections specifically about interaction, even if that formed no
> part of the writers' existing backgrounds.

I agree. And, ultimately here, perhaps the goal isn't just the idea of
writing Inform 7 from the perspective of an author of fiction. Rather, it's
using the practices of fiction (those that make it a viable format that
people enjoy) and translating those over to a system like Inform 7 that also
produces works of fiction. A lot of writers don't like guides that take you
from writing screenplays to writing novels, but they agree that certain ways
of thinking and doing can be translated. The "thinking and doing" refers to
those parts of crafting a *story.* Likewise, from writing novels to creating
films. It's not just a conversion but, again, there are elements that do
carry over and that can guide thinking. Those elements and that thinking
refer to those parts of, again, crafting a *story.*

I see something similar to that for text-based interactive fiction. It's not
so much that you say "Okay, here's a novelist would do it. And here's how
you translate that into Inform." Rather, it's distilling the ideas of what
it means to write effective fiction and then using those ideas to inform (no
pun intended) your work in text-based interactive fiction. That's what
really started me on this path. Since Inform does say its a "tool for
writers intrigued by computing, and computer programmers intrigued by
writing" I decided to take it at face value and put that claim to the test
and trying to find what tradeoffs need to be made to accomodate both groups,
who are very different.

The result is what you're seeing in this conversation.

- Jeff


Jeff Nyman

unread,
Jun 10, 2007, 6:56:25 AM6/10/07
to
"ChicagoDave" <david.c...@gmail.com> wrote in message:

> I think a guide called "Writing to the Interactive Fiction Medium" is
> what you're looking for and I'd like to see this developed somehow.

Something like that, yes.

> But I agree with Emily that such a guide wouldn't contain much if
> anything about programming IF.

In general, I disagree with the notion that it wouldn't contain much about
programming. In fact, as I've tried to show, the implementation can't be
separated from the medium. In fact, I've found that when trying to be too
abstract, people don't like it. When I focus just on the programmatic,
people don't like it. When I blend the two, people start to get it.

However, the blending has to be done with a conscious goal of speaking to
different groups and realize that you can't just treat it like "writing a
game" or "writing a story." You have to treat it like "writing a story in
the format of a game."

> The guide would probably have to blend game design skills, the various
> lists we've developed of Do's and Don'ts, Bob Bate's Puzzle white
> paper, and then taking traditional writing aspects and mapping them to
> IF. To do this, you'd probably have to have an entire game designed
> for IF on paper and then take that final design and back port it to
> the guide's intentions.

Yeah, that's kind of what I had to do. In my class, I realized that people
were constantly wanting to focus on mysteries because they could relate to
that. So I took "Murder on the Orient Express" (from the Inform guide) and
"Accuse" (a GPL game written by David Wheeler in Inform 7) and then
mixed-and-matched bits of those, along with putting in bits from other
examples in the Inform manual.

This started to serve as the template game that would expound on a few
subjects.

> Since Textfyre will be doing all of its games in design format first,
> it's possible that we could help develop such a guide. I'd wait until
> we've perfected our design processes, but after a half dozen games, I
> think we definitely could develop such a guide.

I (along with others, I'm sure) would definitely be interested to hear about
your design process and the experiences you find with Textfyre. Those
experiences can no doubt translate into writing up an effective guide based
on those real experiences. In fact, that's often one thing I think is
lacking in the text-based IF community, which is experiential data based on
design. You can learn a lot about how movies were made by watching the
commentary on a DVD. You can also learn a lot about how novels were written
by reading author notes for that novel. With some games, you can read or
listen about how games were developed and why they were developed the way
they were. (This usually comes as "extras" on a game CD or DVD.)

I think that kind of thing could benefit people coming to text-based
interactive fiction.

Further, in writing you often learn a lot just by reading the works of
others. Here's an area where Inform 7's use of natural language for source
text, and its built in means of distributing that text in a readable manner,
can be more helpful than most other languages. Here you have a way to allow
others to read the source of a story and to learn the craft not just by
learning technique (i.e., a writing course) but by reading the source (i.e.,
reading stories). This is yet another way that Inform 7 could, I believe,
start to reach some of the goals that have been aspired to for it, based on
statements made in this newsgroup and statements made in the manual.

- Jeff


ChicagoDave

unread,
Jun 10, 2007, 9:24:41 AM6/10/07
to
On Jun 10, 5:56 am, "Jeff Nyman" <jeffny...@gmail.com> wrote:
> I (along with others, I'm sure) would definitely be interested to hear about
> your design process and the experiences you find with Textfyre.

Although I believe our design template is platform agnostic, we have
developed a tendency to use Inform 7 logic in the details. We have to
go through the programming phase (beginning shortly) and after that we
should have a much clearer picture on how the nuts and bolts interact
with the narrative design.

I'm assuming that there will be changes to our template based on the
Inform 7 programming. But after that, we should have the structure of
what you're looking for. It might not be a bad idea to share the
template at that point (after signing an NDA) and we could partner on
developing a guide.

I'd want to develop a new design that can be shared openly and is not
a product of Textfyre, and besides, we'd want to develop a game that
has a range of specific uses within Inform 7.

So in the meantime, that might be a task on your end (or someone
helping you). Develop a game that uses the basic elements of Inform 7
and then possibly have a second and third revision of the same game
that adds more and more Inform 7 complexity.

David C.

Jeff Nyman

unread,
Jun 10, 2007, 9:24:54 AM6/10/07
to
"Emily Short" <ems...@mindspring.com> wrote in message
news:1181437757....@q66g2000hsg.googlegroups.com...

> Also, by assuming that we want to teach by analogy with conventional
> fiction, I leave out the most important lesson (IMO) about IF design:
> you have to start by figuring out what the player is going to do.

As I think on this "what the player is going to do" idea a bit more, I find
I can liken it to writing fiction but also putting it into the context of a
game.

Consider that one of the things they teach you in good writing or in good
screenplay is simply this: each part of the story is there for a purpose
that serves the story as a whole.

The nice thing about this is that it provides gating criteria, if you will,
for what to include and exclude. Meaning, it forces you, as an author, to
think more about what you are writing. This criteria also helps consider
what you can (and perhaps should) amplify in your story/game and what you
can (and perhaps should) compress. (Things like geography and time, for
example.) The key question that comes out of this is not "what is the player
going to do" necessarily but this:

How does this scene [that the player is in] matter to the story?

The nice thing about writing is that you can meld action and thought. These
combine to form images and it's all done with words. What this does is give
you a lot of ways to come in close to a character or an event. You can cut
across time and space much more easily. (See "The Time Traveler's Wife" by
Audrey Niffenegger, for one good example.) You can combine summary (the
scenic) and the scene. (See "Old Man's War" by John Scalzi, for one good
example.) You can stop to have characters reflect. Obviously all of this is
just saying that action and thought become the images and the author forces
the reader to construct these images in their mind. (Here is where film can
just present things to the viewer and is not as subtle of a medium in some
ways, even though interesting things can be done with it.)

Now, the question of the interaction level comes up.

In a scene, characters (and that includes the player character) must do
things. (Scene is about action, after all.) So characters act and react. All
those actions and reactions [should] add up meaningfully such that "how does
this matter to the story" starts to conflate with "what is the player going
to do." The player is going to do things that are meaningful to the story;
however, the broader interaction means the author has to consider how
various things the player can do can draw meaning (stay true to the story)
while providing satisfaction by letting the level of interaction allow the
player to more richly experience the story. (Just as readers can often more
richly experience a written novel than a film based on that novel.)

I think if text-based interactive fiction starts to get into this territory,
and starts to encourage its authors to do so, it will be ready for the "next
level" (as I've heard some people refer to it on this newsgroup). It will, I
believe, be something of an evolution in the way that text-based IF is
practiced and, perhaps, experienced.

A bit of a side note here: I grant that none of this is particular to Inform
7 necessarily. However, the ability to convince people of what is possible
and how to express themselves can matter quite a bit, which is where this
does (perhaps) get into some of what Inform 7 specifically provides. So part
of what I'm also looking at here is what sort of interface does seem to work
to convince people to write in the format of text-based IF. That's another
discussion that's come up a bit on this newsgroup, regarding how tightly an
IDE should be integrated and the efficacy of natural language constructs and
rule-based structures.

So, I guess the point here is, far from being just an academic exercise,
I've been looking at this community for awhile, watching what it debates
about (both in terms of crafting text-based IF and in the tools used to do
so) and I think there is wider scope to what we're talking about here, which
perhaps feeds back into Andrew's and Dave's ideas about types of manual
geared to text-based IF *qua* medium, rather than as Inform 7 IF or TADS 3
IF.

- Jeff


Emily Short

unread,
Jun 10, 2007, 9:37:28 PM6/10/07
to
On Jun 10, 5:46 am, "Jeff Nyman" <jeffny...@gmail.com> wrote:
> "Emily Short" <emsh...@mindspring.com> wrote in message

>
> news:1181437757....@q66g2000hsg.googlegroups.com...
>
> > I don't know -- is this at all close to what you imagine?
>
> I think what you put there is definitely the closest I've seen to where this
> has all been leading me. I really like it.

Thanks. I had some more thoughts about this -- and I was annoyed at
how hard to read the format was on Usenet (my own fault, but it's ugly
enough that it's hard for me to follow, so I imagine it must be worse
for other people). I've worked it over a bit more and posted it here:

http://emshort.wordpress.com/2007/06/11/inform-7-for-the-fiction-author/

There's still a lot missing from the outline, but maybe it's in better
shape to use for discussion.

Blank

unread,
Jun 11, 2007, 6:25:51 AM6/11/07
to
Brian Slesinsky wrote:
> On Jun 6, 10:06 pm, Emily Short <emsh...@mindspring.com> wrote:
>
>> Some people have suggested that it would be nice to have a tutorial
>> game that grew gradually more complex, but I think it would have to
>> structure that complexity differently from the way the manual is
>> structured. (For that matter, I believe someone started writing such a
>> thing, but that it didn't get very far.) In any case, that seems like
>> a teaching resource that might stand alongside the manual rather than
>> be incorporated into it.
>
> Hmm. One way to put a spotlight on the relevant portion of an example
> would be to have "before" and "after" versions showing how to add a
> feature. The changes might be highlighted, or the two versions could
> be shown side by side.
>
> Also, sometimes taking an example from a previous chapter and adding
> something to it would be a nice way to tie different concepts
> together, returning to a previous theme and at the same time building
> on a game that the reader might have already studied.
>
> - Brian
>

The downside with having several different things all explained using
the same example is that they can kind of blend together. I find this
can be a problem for me, because I know I've seen such-and-such
discussed, but can't remember exactly where.

For example, when I was learning I6, I never could remember where the
exact grammar for examining arrays is demonstrated (and still can't).
But I do remember that it's in the example with the birds and the highly
suspect calculation of flight distance by consideration of wingspan and
worms_eaten. So I would just search for 'magpie' and voila!

(I'm glad, by the way, to see that I7 is maintaining the tradition of
covert wackiness - a boon for people like myself cursed with flypaper
memory. I'm still enjoying "Frankly my dear, I don't have a camera."
though I've yet to use it as a search term.)

--jz

0 new messages