Inform 7 Critique
steve....@gmail.com
ideas. Instead, people became very rhetorically aggressive. This was
part of the plan.
For example, Emily Short conjured the image of a "steel-cage-
deathmatch between T3 and I7." Then, without blushing, she decried
battle, using the image instead to mis-characterize her pretended
opposition. A cruel piece of rhetoric, that.
Sure, I felt personally insulted, but that's peanuts. The whole
community took a huge hit. After this, honest critique was
misconstrued as attack, and in effect, honest critique vanished.
Those who had been working on TADS-3 for several years (her
"opposition") were of course entirely uninterested in "steel-cage-
deathmatch." There was no opposition. We just wanted to find out about
what I7 was like, for the overall benefit of IF, and the mutual
improvement of development systems. We had been developing the
frontier IF system, entirely in the open, for many years.
I7 made RAIF a battleground. And in the face of such hostility, those
who had honest critical questions about I7 withdrew from the
discussion. The sad thing about it: this was the plan.
Why the aggressive rhetoric?
The whole NL thing made I7 seem really questionable. Graham Nelson
admitted that he expected people would be very upset and skeptical
about it. Emily Short has admitted that Bronze and Relics were
published in advance of the system in order to prove the competence of
the system, to an audience which would be surely suspicious. (People
would doubt that NL programming is capable of making full-blown IF.)
The I7 people were on the defensive, at the time of the big unveiling.
In other words, there was a lot of rhetorical aggression motivated by
fear of a shaky position. Unfortunately, the rhetorical tricks worked:
for the most part, a serious critique of I7 has not occurred.
I'm a big believer in the idea that honest critique is the highest
praise one can offer. I also believe that the suppression of I7
critique has done significant damage to the development and potential
of the genre.
--
To begin the discussion, let me just challenge a couple ideas about
I7's 'rule' orientation, and its significance:
-
"Rule" oriented?
I7 is largely Object Oriented: a lot of programming work involves
classes and subclasses of objects. Inheritance and extensibility (and
polymorphism) goes through it all.
Of course it is common to write a rule outside of an object
definition: "before putting a hat on a table" -- but for most
purposes, this is the same as inserting a piece of code in the
'hat.putOn' or 'table.notifyInsert' -- and in fact, you get a lot more
control if you have procedural oversight like this.
The counter-argument is that you lose something, when you specify
where the rule is located. But this is false, and gets into the 'Rule'
panacea....
-
The 'Rule' panacea
Jon Ingold recently observed that rule governance is unwelcome unless
the resolution is transparent. You can't just let those rules fight it
out inside a black box. You've got to have some way of officiating the
fight. You don't want the rules to tie-break one way, when you want
something else.
There's a false promise, that making rules means you don't need to
deal with priority, but basically that's the #1 problem in rule-based
systems: deciding which rule dominates in a certain circumstance.
Nate Cull once strongly insisted that I7 would advance AI. He implied
that I was being obstreperous, when I asked him why. (Does it make
parametrization easier? If so, howso?) He never gave actual
justification. Haven't heard from him since.
--
A few requests, towards keeping this a serious and useful discussion:
1) Please avoid fallacies, especially "red herring" fallacies.
( http://en.wikipedia.org/wiki/List_of_fallacies#Red_herring_fallacies
)
1a) Point it out, if you must, if someone is committing a fallacy, but
allow for some rhetorical emphasis, as befitting the full expression
of the idea. So, exaggeration (to express excitement) is perfectly
fine; personal attack (in hopes to derail a person's argument) is
obviously unacceptable. The difficult middle-ground here is personal
criticism (to express your unhappiness that a person has committed a
series of fallacies). This is acceptable, but again, please refrain
from personal attack.
1b) As a counterpoint, please avoid excessive rhetorical argument.
Communication is great; persuasion is tolerable; propaganda is unkind.
2) Please treat counterpoints with respect. Assume that everybody is
here because they want to communicate.
2a) Concession normally improves your own position. Plus, it's
ethically good to recognize the validity of another person's view.
2b) Try to understand all positions, and please do not exaggerate a
counter-position, to make it seem absurd.
( http://en.wikipedia.org/wiki/Straw_man )
3) Troll rehab. Of course, you can simply ignore posts which you think
are trolls. But definitely don't get all mad about it and argue.
Instead, appreciate whatever idea might be present in that post, and
try to develop it and incorporate it into the discussion.
James Cunningham
> In the time around I7's release, it was very difficult to talk about
> ideas. Instead, people became very rhetorically aggressive. This was
> part of the plan.
You know, I was just thinking to myself the other day -- Self! I said
-- do you know who Steve Breslin reminds me of? Charles Guiteau! What?
I asked myself. How does that work? No, no, I said; bear with me. Think
of the TADS 3 guys as the Oneida community and Graham Nelson as
President Garfield. Steve's been shooting "I am stalwart of stalwarts!"
for *years* now. In both cases it's one of those things where it's
tragic at the *time*, but after a while it's mostly comic.
Yeah. Steve Breslin is Charles Guiteau. I like it.
Best,
James
vaporware
> In the time around I7's release, it was very difficult to talk about
> ideas. Instead, people became very rhetorically aggressive. This was
> part of the plan.
Who was it that became aggressive? It was you, Steve. It hasn't been
that long; some of us still remember. Hell, you're still doing it.
If you want to foster an "honest critique" of I7, accusing its
developers and users of plotting to suppress your opinion is a pretty
poor way to start.
You raise a couple interesting questions about I7's design. They've
been discussed many times before, but perhaps they're worthy of being
discussed again. I, for one, however, have no interest in discussing
them with you after the paranoid screed you launched in the first half
of your post.
Honestly, leave out the history lesson next time. If people want to
know what kind of response you've received in the past, and why, they
can search the archives and see for themselves.
vw
jon.i...@gmail.com
> Jon Ingold recently observed that rule governance is unwelcome unless
> the resolution is transparent. You can't just let those rules fight it
> out inside a black box. You've got to have some way of officiating the
> fight. You don't want the rules to tie-break one way, when you want
> something else.
(to respond just to the bit with my name in)
Well, in fairness, the rules I was talking about are lines of code at
the I6 level; and the extension I was writing was purely to bring them
up to the level of I7 rules, precisely so that they would be
transparent (ie. listed in the rules Index, which is not the most
legible document but it's better than the NounDomain routine!) Also
they're more editable here.
jon
PaulDV
> I'm a big believer in the idea that honest critique is the highest
> praise one can offer. I also believe that the suppression of I7
> critique has done significant damage to the development and potential
> of the genre.
What's to critique, and why do you feel the need to provide one?
To me you either use I7 or you don't. If you find something about it
that you don't like and would like to discuss or propose a 'better'
way of providing that feature then, by all means, propose away.
The only critique that would be relevant would be one involving all IF
authoring systems but, as with anything involving personal preference,
the choice of system is largely subjective, thereby rendering any such
critique only as useful as your judgement of the person providing the
criticism.
I could not say whether I7 is better or worse than TADS3 for the
simple reason that I've never used TADS3. I came across Inform at a
time when I was looking, had a (very) brief look at a couple of
systems (well, maybe as far as downloading them and looking at the
help files) and plumped on Inform as is seemed best suited to my
programming background and it appeared to do everything that I wanted
it to. Have I made a mistake and chosen the wrong platform on which
to while away my hours? Possibly. Do I care? No I don't.
I recall being very excited when I7 was aunched, but I didn't do
anything with it then because at that time I did not have a lot of
spare time; I was not heavily into IF, merely dipping my toe in the
water every now and then; and what I did see of I7 was such a dramatic
change from what I was used to, I realised that it was going to take
me some time to adopt the paradigm shift I'd need to get productive
with it. I'm happy to say that, a couple of years down the line,
after a few short weeks, I'm now starting to get to grips with it and
find it a breath of fresh air.
So you can keep all of your petty arguing and pot-shots - I'm not
interested in who said what to whom - I will gladly participate in
this forum, both as a means to gain more knowledge and, hopefully,
impart some on the way. If you want to start a discussion on the
merits of rule-based systems please do, but surely you can do it
without opening the discussion with a tirade of inflamatory rhetoric?
That said, I'll admit that most of such discussions tend to go way
over my head, as you guys seem to be on a completely different plane
to me - and perhaps that's a good thing too, otherwise who would there
be to put together and maintain (for free, I might add!) such
wonderful tools?
Regards,
Paul.
pfshec...@gmail.com
> In the time around I7's release blah blah blah
Cry some moooooooore. </heavyweaponsguy>
Has someone made IF out of Team Fortress 2 yet? Man, I would play the
crap out of that.
ChicagoDave
Hey Steve....I think this is some odd attempt at a conciliatory
jesture on your part and I give you credit for that.
The problem some of us have is that your "conflict resolution"
techniques could use a little work. Usually, when someone senses
discord on a team, they will try to start a dialogue with "I think we
can all agree that I've been a bit hard you guys and I want to rectify
that. I'd like to start over and have a better conversation about some
of the issues with Inform 7."
Then you might explain, without any _hint_ of "you know better" and
get down to the salient points.
The second someone's ego rears its head in a meeting, people tend to
withdraw or fight. They rarely will adopt a posture of open
communication.
I think a good book to read is here:
http://www.amazon.com/Emotional-Intelligence-Matter-More-Than/dp/0553375067
This is a pretty standard book in the computer consulting world since
our main job is to increase the effectiveness of client
communications. It makes the client happy and the resulting work more
closely reflect the needs and wants of the client.
But it just helps you understand what to say and what not to say and
that _how_ you interact with people _directly_ impacts the resulting
communications.
You can be the smartest person in a room, but if you can't get people
on your side that's simply not going to matter. Teams are more often
than not successfully led by people with strong soft skills more than
flat brain power. Experience plays a big factor, but again, you can't
use a hammer...you have to engage people.
Of course you can always disagree....but then we're not going to make
much progress.
David C.
mikegentry
> On Oct 5, 12:02 am, steve.bres...@gmail.com wrote:
>
> Hey Steve....I think this is some odd attempt at a conciliatory
> jesture on your part and I give you credit for that.
The only thing that still surprises me about Steve is how much credit
(and that is little enough) some people are still willing to extend
him. Take a look at the thread in which Emily made her "cage match"
comment, take a look at the context of that comment and how people
actually responded to it, and then take a look at Steve's own comments
in that thread. The "concilatory gesture" is transparently
disingenuous. Although I'll be damned if I can figure out why he felt
the need to unpack all this again now. Something to do with the
competition, maybe?
Jim Aikin
> The "concilatory gesture" is transparently
> disingenuous. Although I'll be damned if I can figure out why he felt
> the need to unpack all this again now. Something to do with the
> competition, maybe?
You may have put your finger on it. As a T3 author, I admit to feeling
a little ostracized by the fact that this year's T3 games are
outnumbered more than 10 to 1 by Inform games (though that count
includes at least one I6 game, and possibly several).
Neither of the T3 entries was written by Steve, of course. He could
have altered the percentages materially by entering a game.
I'm not enough of a computer science geek to be able to discuss
whether OOP or rules-based languages are better in the abstract. I
suspect that question would have to be parsed into, "Better for
what?", "Better for whom?", and, "Is the language currently under
discussion an ideal examplar of either A or B, or are we perhaps
responding to deficiencies that are specific to this particular
language (which is still being developed) rather than to the power and/
or shortcomings of the underlying concepts themselves?"
I've tried to learn I7 about three times now, and I keep going back to
T3. My feeling at present (it may change next week) is that this has
very little to do with the nature of the language itself -- though I7
seems to require more typing and seems to invite the author to indulge
in a kind of disorganization that other languages would not allow.
My discomfort has more to do, I think, with the state of the
documentation. It seems to me (others may disagree) that the I7 manual
and recipe book are a very good tutorial for beginners, but not a very
good reference manual for the experienced programmer. In particular, I
sometimes find that I want to put my finger quickly on a type of
customized code with which I'm already familiar, and I may have the
very devil of a time finding the information I need.
If I were learning I7 as my first programming language, this might not
be an issue: By the time I got to doing complicated stuff, I would
have been through the manual about five times, and my own memory would
nudge me about where to look.
Confusion can also arise because the I7 compiler is finicky about
syntax in ways that are not at all obvious to the novice; given two
code phrases that appear entirely equivalent to the author, one may
work and the other not (but with no complaint from the compiler). This
is not a desirable state of affairs, but it could probably be
addressed with more robust compiler warnings -- the I7 equivalent of
"You said = in line 909. Did you mean ==?"
Dennis Jerz and I have discussed creating an ifwiki that would
function as a growing ref manual for I7. I sent him a longish set of
notes for one chapter (before I decided to bounce back to T3 yet
again). Haven't heard from him on that, but I'm sure he has other
commitments.
--Jim Aikin
Kevin Murphy
> My discomfort has more to do, I think, with the state of the
> documentation. It seems to me (others may disagree) that the I7 manual
> and recipe book are a very good tutorial for beginners, but not a very
> good reference manual for the experienced programmer. In particular, I
> sometimes find that I want to put my finger quickly on a type of
> customized code with which I'm already familiar, and I may have the
> very devil of a time finding the information I need.
I had the same problem. As someone who already knows how to program, my
instinct when learning a new language is to jump in and try to build
something, referring to the documentation as required.
The Inform 7 manual forcefully resists this approach. It's an excellent
tutorial, but it's not structured for easy reference.
The Cookbook seems like it would be helpful here, but in practice the
examples are too specific. A more general-purpose reference manual would
be a useful addition, or even just a comprehensive index of terms,
rather than examples.
Why do I feel like I just volunteered for something? :)
steve....@gmail.com
say a couple things that one would naturally read as such. Sorry, I
was very clumsy in discussing the origin of the problem. The intro was
already far too long, so I'll just apologize without parsing words.
Honestly, I think the cruel rhetoric began as a natural defensive
maneuver, mostly unconscious and probably entirely unplanned. I don't
think much thought was given to the damage that people were doing to
the discussion. Conspiracy implies some secret strategy or so, which
was not in place. I think I explained the emotional states pretty
clearly already, so I won't go into this further either. The point was
that this was damaging to the development of the genre.
As for my own part in the heated rhetoric, I have several times
admitted that I have erred. I admit that I have even escalated on
occasion, where I felt particularly strongly. It was all honestly
motivated, though. ("Honestly" in the sense that people who behave
boldly feel very strongly about their positions and the urgency of the
situation. But I do not confuse this with "responsibly.")
It's probably worth mentioning that I have, in all cases, received far
worse than I have dealt. (Not that I'm complaining! -- I'm just
relativizing.) Not to be clever about it, but you could read the
responses to the current thread, and you'll see immediately what I
mean; even your own response is much more aggressive and unsympathetic
than anything I've written recently.
Well, maybe we'll still disagree. That's really fine! You still have
my respect! I just wanted to indicate that the breakdown has been an
obstacle for discussion, and hopefully we can look forward to getting
over it, now two and a half years later.
@ChicagoDave: I was trying to point out, as above, how important it is
for those vocal few people who are obsessed with the soap opera of
RAIF to get past the personalities and talk about the issues. But of
course you're right, I should be even more diplomatic. I like the way
you put it, actually" "I think we can all agree that I've been a bit
hard you guys and I want to rectify that. I'd like to start over and
have a better conversation about some of the issues with Inform 7."
Consider it said! You have shown greater skill than I!
On the other side, I'm the only one (thus far) to make such
concessions, so you might consider me (relatively speaking) more
genuinely diplomatic than my detractors. I recall a certain poem which
argued my dissatisfaction with I7 was not due to the points I
elaborated, but on the (accusation?) that I am unhappy with the size
of my penis. So the lesson in diplomacy -- as much as I appreciate it
-- seems nevertheless one-sided and self-serving.
PaulDV wrote:
> What's to critique, and why do you feel the need to provide one?
It's not a need, but a desire to contribute, but really I don't want
to get into the personal stuff. If you really want my personal bio,
and why I like to think about system design, maybe we can discuss this
in another context.
As for what's to critique, I mentioned some of that already. There
will be more to come. Please let me know if you have any questions
about the critique! :)
Please understand that "critique" is never meant in a bad way: I just
mean "evaluate and thoughtfully analyze" -- never "to find fault with,
and point out the faults of."
> If you want to start a discussion on the
> merits of rule-based systems please do, but surely you can do it
> without opening the discussion with a tirade of inflamatory rhetoric?
Yes, well it sounds like you're mischaracterizing the opening,
probably not intentionally. It was not the best, as noted, but I'm
trying. :)
--
I figured there would be some personal backlash, but hopefully this
can grow into a discussion of ideas, not personalities.
Peter Pears
> Jim Aikin wrote:
> > My discomfort has more to do, I think, with the state of the
> > documentation. It seems to me (others may disagree) that the I7 manual
> > and recipe book are a very good tutorial for beginners, but not a very
> > good reference manual for the experienced programmer. In particular, I
> > sometimes find that I want to put my finger quickly on a type of
> > customized code with which I'm already familiar, and I may have the
> > very devil of a time finding the information I need.
>
> I had the same problem. As someone who already knows how to program, my
> instinct when learning a new language is to jump in and try to build
> something, referring to the documentation as required.
Jumping in - I had the exact same issue. I didn't come from full-blown
knowledge and mastery of a programming language, but I had gotten very
used to writing scripts in AGS - AGS uses, I'm told, a variant of C++,
or maybe it's C, and at any rate I was regularly churning out stuff
like
int counter=10;
function repeatedly_execute() {
if (player.Room==3 && cRoger.Room==5) {
while (counter>10):
lblTimer.IntToString(counter);
counter--;
}
...but I found it relatively easy to switch to I7. Once I realized I
had to make the switch. I was willing to make the mentail switch
necessary - maybe if I wasn't, I would have gone to T3 as well.
Jon
> Please understand that "critique" is never meant in a bad way: I just
> mean "evaluate and thoughtfully analyze" -- never "to find fault with,
> and point out the faults of."
Liar.
mikegentry
>
> I've tried to learn I7 about three times now, and I keep going back to
> T3. My feeling at present (it may change next week) is that this has
> very little to do with the nature of the language itself -- though I7
> seems to require more typing and seems to invite the author to indulge
> in a kind of disorganization that other languages would not allow.
>
> My discomfort has more to do, I think, with the state of the
> documentation. It seems to me (others may disagree) that the I7 manual
> and recipe book are a very good tutorial for beginners, but not a very
> good reference manual for the experienced programmer. In particular, I
> sometimes find that I want to put my finger quickly on a type of
> customized code with which I'm already familiar, and I may have the
> very devil of a time finding the information I need.
>
> If I were learning I7 as my first programming language, this might not
> be an issue: By the time I got to doing complicated stuff, I would
> have been through the manual about five times, and my own memory would
> nudge me about where to look.
>
> Confusion can also arise because the I7 compiler is finicky about
> syntax in ways that are not at all obvious to the novice; given two
> code phrases that appear entirely equivalent to the author, one may
> work and the other not (but with no complaint from the compiler). This
> is not a desirable state of affairs, but it could probably be
> addressed with more robust compiler warnings -- the I7 equivalent of
> "You said = in line 909. Did you mean ==?"
And *this* is what a cogent and constructive critique of Inform 7
actually looks like, people.
James Jolley
Agreed. Interestingly though Jim, coming from a programming background
didn't seem to make a difference for me. I find I7 quite a welcome
change and got into it quickly enough. Yes, the syntax can be a pain
sometimes but the phrasebook and the actions pages are good places to
fix mistakes in syntax.
--
Best
-James-
mikegentry
Purely anecdotally, the only significant programming background I have
is with Inform 6, and I took to I7 instantly.
It took me a while to realize how much of the "reference" part of the
documentation is actually in the index tab. (Interestingly, this means
you *have* to jump in and try to build something before you can get
access to it.) This is not something that is explicitly discussed in
the documentation. The action tab breaks down every action in the game
into its individual rules and grammar, and lays out the implementation
philosophy behind most of the actions; the kinds tab contains a
breakdown of the default properties for every kind, and a quick-
reference for kinds of value and what you can do with them; the
phrasebook contains a syntax reference for every phrase (or function
call, or whatever you want to call them) in the language, etc.
Now, I'm not suggesting that knowing this will magically make the
documentation make more sense. It's still a very different way to
organize things. But once I realized that the index tab was in many
ways an *extension* of the documentation, a lot of little light bulbs
started coming on in my head.
John W Kennedy
> On Oct 5, 6:02 am, steve.bres...@gmail.com wrote:
>> I'm a big believer in the idea that honest critique is the highest
>> praise one can offer. I also believe that the suppression of I7
>> critique has done significant damage to the development and potential
>> of the genre.
>
> What's to critique, and why do you feel the need to provide one?
Because he's a psychotic with an imagined personal grudge against Graham
Nelson that it would be too silly to explain. Don't bother answering him
rationally; you're only wasting your time. PLONK him (most of us have
already) and move on.
--
John W. Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the
throne of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"
Mike Tarbert
>
> It took me a while to realize how much of the "reference" part of the
> documentation is actually in the index tab. (Interestingly, this means
> you *have* to jump in and try to build something before you can get
> access to it.) This is not something that is explicitly discussed in
> the documentation.
> ...[O]nce I realized that the index tab was in many
> ways an *extension* of the documentation, a lot of little light bulbs
> started coming on in my head.
I couldn't agree more. Realizing the value of the index tab as a
powerful reference tool was definitely a "light bulb" moment for me as
well. I still compile my work after only the first few lines of code so
that I'll have access to it. You're also right about the documentation,
Mike. Although a quick search reveals that the index is mentioned quite
a bit, it's usually in an off - hand "this can be found in the actions
tab of the index" sort of way. Indeed, the first mention of the index
(in ch 1.6) has this to say: "The Index is only an optional convenience,
but becomes more and more helpful as the fiction grows larger." It
should probably changed to read something like, "The Index is your
indispensable friend. In fact, if you've programmed IF before and/or
plan on skipping around in this documentation, stop reading now, create
a minimal one - room game (i.e. 'The Lab is a room.'), hit compile and
check it out."
Skinny Mike
Jeff Nyman
news:48eb248f$0$17069$6e1e...@read.cnntp.org...
>> mikegentry wrote:
>> ...[O]nce I realized that the index tab was in many
>> ways an *extension* of the documentation, a lot of little light bulbs
>> started coming on in my head.
>
> I couldn't agree more. Realizing the value of the index tab as a powerful
> reference tool was definitely a "light bulb" moment for me as well.
Yes, I've found this as well when I've taught Inform. In fact, in a version
of the "Rules" portion of the manual that I started to rewrite
(http://www.genuinetesting.com/LearnI7/rules.html), I do make specific
reference to checking the Index after a couple of actions. I repeat this a
few times so the reader gets the idea of *how* to check the Index and, more
importantly, *when* to check the Index.
In fact, for my class, I actually had to rewrite significant portions of the
manual and one of the main things I did in each case was focus on using the
Index, usually by setting up a small example and then iterating through the
example, using the Index as a continued reference. (Reinforcing the use of
the Index is probably a focus the manual should take as I've found it
shortens the learning curve, and this is the case whether I was dealing with
programmers or non-programmers.)
- Jeff
jon.i...@gmail.com
> I couldn't agree more. Realizing the value of the index tab as a
> powerful reference tool was definitely a "light bulb" moment for me as
> well.
Indeed - and in longer works I find that one of the biggest
impediments is that the Index panes become quite cluttered, especially
the "rules" tab, which is hard to navigate and find things in - but
almost always solves your problems! The curious thing is it's a bit
like writing two pieces of code for one game - one the content of the
rules, and the next the order of them.
I'd really like to be able to reorder my rules directly from the Index
panel by some kind of drag and drop!
jon
Jim Aikin
> I couldn't agree more. Realizing the value of the index tab as a
> powerful reference tool was definitely a "light bulb" moment for me as
> well. I still compile my work after only the first few lines of code so
> that I'll have access to it.
I'd love to see a complete set of instructions on how to use the Index
tab. The point at which I most recently bailed on I7 was when I
searched for a library rule in the Index > Rules, and it wasn't there.
Specifically, I was fiddling around with the idea of implementing a
rope. I had an object called a rope, and had attempted to create code
that would allow me to tie it to something, but when I ran the game,
'tie rope to pump' got the reply "You would achieve nothing by this."
So I turned on 'rules' and learned that I had run afoul of the 'block
tying' rule.
I went straight to Index > Rules and searched for the string "block
tying" -- and it wasn't there! So how the heck was I supposed to use
the Index to learn what rule I need to override? I don't believe I
would want to simply say, "The block tying rule is not listed in any
rulebook," because that would get rid of its generally useful
functionality, if the player tries 'tie turnip to barn' or something.
What I wanted to do was, first, learn exactly where that rule is in
the relevant rulebook, and second, learn how to override it in
specific cases.
The Index did not seem to be set up to help with this. But maybe
that's just because I didn't know how to use it.
BTW, I know there's an Example that implements a rope, but it's mainly
about how to drag things from one room to another with a long rope,
which wasn't what I needed. And in any event, I don't believe that
Example even mentions the block tying rule, as "block tying" is not
found anywhere in the manual either.
--Jim Aikin
PaulDV
> I went straight to Index > Rules and searched for the string "block
> tying" -- and it wasn't there! So how the heck was I supposed to use
> the Index to learn what rule I need to override?
I understand where you're coming from and a guide would be good, but
what you're looking for IS there, you were simply looking in the wrong
place.
Someone please correct me if I'm wrong, but it seems to me that the
Rules tab only shows rules which have been changed or added to in some
way.
If you'd gone to the Actions tab and looked up 'tying' you would have
found 'Tying it to'. Click on the magnifying glass next to the action
and it shows you the rulebooks and rules associated with that action.
It's only thanks to Emily pointing this out to me that I 'discovered'
the fact that the Index tab is probably your best friend in I7.
Regards,
Paul.
Mike Tarbert
> On Oct 7, 5:07 pm, Jim Aikin <midigur...@gmail.com> wrote:
>> I went straight to Index > Rules and searched for the string "block
>> tying" -- and it wasn't there! So how the heck was I supposed to use
>> the Index to learn what rule I need to override?
>> --Jim Aikin
>
>
> Rules tab only shows rules which have been changed or added to in some
> way.
>
Well, not really. The rules tab shows rules which are not tied to
specific actions, including but not limited to: every turn rules,
procedural rules, rules governing activities (before printing the name
of, etc.). It also includes the three rulebooks which govern actions,
but are not tied to a specific action, namely Before, Instead, and After.
The Actions tab deals with the rules tied to specific actions, including
their individual Check, Carry out, and Report rules, as well as any
Before, Instead, or After rules which directly affect that action. (That
is, if you were to add an "Instead of examining the cat..." rule, it
could be found by consulting either the Rules tab (under Instead of
rules) or the Actions tab (by clicking on the examining action). Note
also, that this new rule added by the source would have an arrow next to
it which, when clicked, moves the cursor to the source window,
highlighting the relevant code (in windows at least).
> If you'd gone to the Actions tab and looked up 'tying' you would have
> found 'Tying it to'. Click on the magnifying glass next to the action
> and it shows you the rulebooks and rules associated with that action.
>
Yeah, the actions at the top part of the page are categorized ("Actions
which move the actor", etc.), but if you scroll down past that, there is
also an alphabetized list of commands recognized by the parser. In this
case, under ""tie [something] to [something]", you are directed to the
"tying it to action" with a clickable magnifying glass icon, which leads
you to the same page as the above.
Skinny Mike
Mike Tarbert
>
> I'd love to see a complete set of instructions on how to use the Index
> tab.
An aside of sorts:
When I first started working with I7, I remember finding out pretty
early on that there were some significant differences between the Mac
and the Windows IDEs and that the Linux version didn't have one at all.
I have no way of knowing, but I suspect that this is at least part of
the reason that certain IDE - specific tools (such as the index) were
initially -- and remain -- under - documented. Although I think the Win
and Mac versions are much closer to identical now, I don't know what the
Gnome interface (Linux) is like. I therefore don't know how these
differences might affect the documentation. Maybe an OS - specific guide
- book... wait, I don't want to volunteer for anything.
Which reminds me -- thank you, David Kinder! Your work has made I7 even
more impressive than it would have been on its own. (I'm sure the non -
windows folks would say the same to Andrew and Philip.)
Skinny Mike
mikegentry
The rules tab lists all the rules in the game except those tied to
beginning and ending scenes (which are in the scenes tab), and the
check, carry out, and report rules for specific actions (which are
under the actions tab). The block tying rule is a check rule for the
tying it to action, so you'll find it under the actions tab.
> What I wanted to do was, first, learn exactly where that rule is in
> the relevant rulebook, and second, learn how to override it in
> specific cases.
I think this is where the discrepancy between how you want to read the
documentation, and how the documentation "wants" to be read, really
shows. The documentation won't tell you exactly where a particular
rule is. But reading through it like a tutorial gives you a general
understanding of how rulebooks are constructed and how the actions
work, so that you would know how to override any rule's behavior for
most of the things you want to do.
Your approach to the rope-tying problem makes total sense from your
perspective, but from my perspective it immediately struck me as,
well, ass-backwards (I don't mean that as a slam... I can absolutely
see where you're coming from, I'm just trying to illustrate the
difference in perspectives). Just reading up through Chapter 7 gives
you enough information to know that in most cases you don't really
*need* to know exactly where the rule is -- you'd know that you can
change the behavior of any action for a specific case with an instead
rule: "Instead of tying the rope to the post: [put code here]."
The Advanced Actions section (Chapter 12) provides more detailed
information about how actions work. So if you wanted to get more
complicated, like if you wanted to create a more generalized set of
rules for tying things to other things, you would read through that
chapter. That chapter gives you a breakdown of how and when all the
rulebooks are checked for an action (Before --> visibility and
touchability --> Instead --> Check --> Carry out --> After -->
Report), how to create new actions and set up the grammar for them.
And then the Rules chapter (Ch. 18) tells you how to write new rules,
how to make sure they fire in the order you want them to, how to
unlist rules (e.g, "The block tying rule is not listed in any
rulebook") so you can replace them with your own versions, etc.
I don't mean to suggest that your approach is wrong. But the
information is in there. It's definitely set up like a tutorial rather
than a reference, and that's pretty frustrating if what you want is a
reference. Maybe it helps to not think of it as a tutorial for
beginning *programmers* (which you obviously are not), but rather (or
additionally) a tutorial for *newcomers to I7*. Because most of what
it teaches isn't just "this is how an if-then statement works," but
rather about how the standard rules and the world model of I7 work,
and how best to approach the most common sorts of IF-related tasks
you're likely to want to implement.
ChicagoDave
> And *this* is what a cogent and constructive critique of Inform 7
I take complete credit. :)
David C.
David Kinder
> Which reminds me -- thank you, David Kinder! Your work has made I7 even
> more impressive than it would have been on its own.
:-)
David
steve....@gmail.com
> As a T3 author, I admit to feeling
> a little ostracized by the fact that this year's T3 games are
> outnumbered more than 10 to 1 by Inform games (though that count
> includes at least one I6 game, and possibly several).
It's just that the whole genre is suffering a new low. Just look at
the quality of the entries. (I haven't played them all, and some may
be excellent works! (No, I haven't played yours Jim, and I do hope the
best for you!))
As predicted, making IF programming more superficially appealing to
people who are turned off by braces and symbolism -- this is not going
to increase the quality of IF, but really just make it even more
mediocre. "If you're scared of programming, and can't tell Inglish
from programming, then Inform is for you!" Basically that's flat-out
selecting for morons.
> Neither of the T3 entries was written by Steve, of course. He could
> have altered the percentages materially by entering a game.
Not interested. In case you haven't noticed, my main interest is
advancing the genre on a procedural and theoretical level. I don't
think "more text" helps very much.
> I'm not enough of a computer science geek to be able to discuss
> whether OOP or rules-based languages are better in the abstract. I
> suspect that question would have to be parsed into, "Better for
> what?", "Better for whom?", and, "Is the language currently under
> discussion an ideal examplar of either A or B, or are we perhaps
> responding to deficiencies that are specific to this particular
> language (which is still being developed) rather than to the power and/
> or shortcomings of the underlying concepts themselves?"
Correct. Nobody argues any more whether OOP or rule-based languages
are "better." (There is always a rule-oriented expert in any CS
department, but they're always on the defensive when it comes to
programming: yes it's possible to program, but....) It's very well
known what the strengths and weaknesses are, in the abstract. What
remains is a discussion of functionality, their applicability to
specific cases.
Technically, Inform 7 is not rule-based; it's a hybrid. This is
interesting! Well worthy of elaboration. Unfortunately, requests for
elaboration were perceived as "steel-cage-deathmatch" challenges. This
was partly defensive, but mostly due to the fatal investment in
insisting that Inglish=English. In other words, it was impossible to
talk straight about programming regimes, if you're pretending to be
doing Natural Language Parsing.
> My discomfort has more to do, I think, with the state of the
> documentation.
Yes, I agree entirely. If it were presented as a programming language,
instead of an NLP, then more than likely, I'd be a believer. (Not a
regular user, of course -- TADS-3 is still 10 times more powerful,
once you've traversed the learning curve.) I read Nyman's rewriting of
chapter 18 of the Writing with Inform manual, and I was 100% satisfied
with this explanation of the writing tool.
> It seems to me (others may disagree) that the I7 manual
> and recipe book are a very good tutorial for beginners, but not a very
> good reference manual for the experienced programmer.
Again, yes, exactly. It's not really a "tutorial for beginners," if at
the end of the tutorial you're essentially stuck, because programming
has not been explained as such. You can walk down the path as directed
by the manual, but once you're ready to go out on your own, you
stumble off the path, into the swamp.
vaporware
[...]
> Technically, Inform 7 is not rule-based; it's a hybrid. This is
> interesting! Well worthy of elaboration. Unfortunately, requests for
> elaboration were perceived as "steel-cage-deathmatch" challenges. This
> was partly defensive, but mostly due to the fatal investment in
> insisting that Inglish=English. In other words, it was impossible to
> talk straight about programming regimes, if you're pretending to be
> doing Natural Language Parsing.
2.15. Does Inform really understand English?
No. No computer does, and Inform does not even try to read the whole
wide range of text: it is a practical tool for a particular purpose,
and it deals only with certain forms of sentence useful to that
purpose. Inform source text may look like "natural language", the
language we find natural among ourselves, but in the end it is a
computer programming language.
vw
Jim Aikin
> 2.15. Does Inform really understand English?
>
> No. No computer does, and Inform does not even try to read the whole
> wide range of text: it is a practical tool for a particular purpose,
> and it deals only with certain forms of sentence useful to that
> purpose. Inform source text may look like "natural language", the
> language we find natural among ourselves, but in the end it is a
> computer programming language.
This passage is honest, and it is unarguable. But since I seem (rather
against my own better judgment, I might add) to be taking Steve's side
in this discussion, or at least acknowledging that his position may be
worth discussing further, I took a jaunt over to Graham Nelson's
original white paper on the subject. At the beginning of the paper,
Nelson sets forth what I would call an ambitious agenda. Inform 7
began, he tells us, as:
"...a practical test of the following hypothesis: that the natural
language in which to write interactive fiction is natural language....
[T]he Inform 7 project aims to replace such syntax with natural
language...."
He also says this:
"...a 'natural' system for IF is one in which ... the source text
reads like a narrative."
These quotes seem, at least by implication, to run counter to the
quote from the manual. Or rather, the quote from the manual seems to
be an implicit acknowledgment that I7 does not in fact do what the
white paper asserts is desirable.
One might, I suppose, take the position that natural language
programming would indeed be a wonderful thing, but that Inform 7 is
not (at present, anyway) a very good example of natural language
programming. The manual gives, in 2.15, one realistic example of how
I7 falls short:
"Inform understands 'something which is carried by the player' but not
(at present, anyway) 'something which the player carries' even though
both are perfectly good English."
But following this passage, rather than provide a thorough explanation
of the many other forms of natural language that I7 doesn't understand
(an explanation that I, for one, would certainly like to read), the
manual turns to a "philosophical" observation (which amounts to an
admission that the compiler generally doesn't know what words mean
unless we give it some hefty clues) and advises the aspiring author to
avoid absurd ambiguities. And that's the end of the discussion of the
limits of I7 as a "natural language" system.
I can see how this approach might get Steve's dander up. The
attractive aspects I7 are being set forth with enthusiasm, yet its not
infrequent failure to live up to the hype is being, if not brushed
under the rug, at least greeted with a silent shrug.
Personally, I don't find this offensive. Graham Nelson is human, after
all, and it's very human to give greater weight to the sterling
qualities of a viewpoint for which one is an advocate than to the
occasional irritating reminders that one's viewpoint is not, after
all, unassailable. We should not expect anyone to be immune to this
tendency, and I feel no need to rant about it.
Five hundred years from now, if there are still computers (and if
there are still people), we may indeed have true natural language
programming. It may be possible to sit down in front of a computer and
say, "Write me a program that will correlate X and Y with A and B,"
and have the computer do the job, prompting the "programmer" with
intelligent questions only as needed. We're not there yet, not by a
long way. (I7 compiler error messages are a baby-step in the right
direction, but on the whole they seem not much more cogent or sensible
than most compiler messages.)
I'm only a layman, not a computer science expert. But it seems to me
that in Inform 7 we have a extremely useful and suggestive rough
sketch (indeed, an extremely rough sketch) of how a natural-language-
based programming system might someday look and operate. Far from
being disappointed with it, or feeling cheated, or feeling that it's
being misrepresented, or asserting that it has run off the rails
somehow, I would like to see it developed much, much further!
For instance, many of the grammatical constructions that at present
flabbergast the I7 compiler are perfectly clear to native speakers of
English. It's only a matter of time (and budget, I suppose ... oh,
wait, this is all unpaid volunteer work!) before the compiler is
brought up to a higher level in its ability to deal with constructions
like "something which the player carries."
We can imagine further refinements. Consider the example from 2.15,
"Mr.Darcy carries a top hat." I'm sure it wouldn't be difficult
(someday, given a big enough budget...) to give the compiler a large
list of common terms that an author may want to use in building a
world. We can list a hundred garments (hat, shirt, shoes, boots, etc.)
and instruct the compiler that, by default, things that are named with
these words can be worn. We can give the compiler a table of body
parts, so that it knows a hat will usually be worn on the head and
shoes on the feet (of which there are usually two). Thus "put my hat
on my feet" will be understood as an absurd input, and will generate
an appropriate in-game error message. We can provide a list of common
animals, furniture, and so on.
On the other hand, at that point the author has to be cautioned that
when implementing a brake shoe, it's necessary to tell the compiler
"The brake shoe is not a shoe." So there's a tradeoff: The more
cultural baggage the compiler "knows" about, the more care the author
will need to exercise in handling exceptions and special cases. In
general, I7 seems to take a hands-off, less-is-more attitude. The
library is kept rather small. This leaves the author less likely to
run afoul of the brake shoe problem, but forces the author to specify
more of the basic aspects of the world model.
TADS 3 has a very large library. In T3, you can make something a Bed,
a Chair, or a Candle, and by golly the compiler knows what these
objects are capable of. There are advantages and disadvantages on both
sides; this is a bit like the argument about whether MacOS, Windows,
or Linux is superior. In the end, it's a matter of taste.
Based on my own very limited experience with I7, I think maybe the
number one thing I'd like to see developed further (or fundamentally
changed) would be the method for setting out the routes between rooms.
The present system runs into serious difficulties the minute I want to
name a room "South of the Hut" or "In the Crypt", or at least that's
the impression that I have at the moment. One is forced to back up
into a syntax that more closely resembles resembles traditional
programming:
Hut-south-side is west of hut-front. The printed name of Hut-south-
side is "South of the Hut."
A better system might look like this:
South of the Hut is a room. In Front of the Hut is a room. The route
from South of the Hut to In Front of the Hut is west-east.
Here, the keyword "route" removes all ambiguity.
Rather than get into a wrangle about natural language programming in
the abstract, I think it might be more useful to focus on specific
places like this where I7's ability to grok natural language could be
materially enhanced.
But then, what do I know? I'm just a cello player.
--Jim Aikin
Peter Pears
It looks as though we're going in circles. One person says "It's not
natural language, it's a programming language." The other says "But it
looks like natural language, and if it behaved like one it would be
better." And another says "But it says, itself, it's not really
English, it's just another programming language." And another says
"But it set out to be..." and so on. Great points are being made, but
we're still going around in circles.
I don't find it in the least problematic that in its concept I7 wanted
to be fully natural language and in practice it's not. What's wrong
with that? Without that ambition, we'd never even have arrived at the
halfway-natural language we have today. Someday there may be natural
language, and sure, it'll be easier to write, maybe then one wouldn't
need the manual at all. But those are technological advancements, not
theoretical, not conceptual. The concept is to make it full-blown
natural language. It hasn't got there yet, and it is very clear in
saying that it hasn't gotten there yet. Any more on this issue is
rather like flogging a dead horse (one which isn't dead, just resting
after the first race and getting ready for the second).
The biggest problem seems to be that some people are too much of
purists to look at I7 without going "It's advertising natural
language, but it's not natural language! BLASPHEMER!". Those people -
lighten up. :P
>It's just that the whole genre is suffering a new low. Just look at
>the quality of the entries. (I haven't played them all, and some may
>be excellent works! (No, I haven't played yours Jim, and I do hope the
>best for you!))
>
>As predicted, making IF programming more superficially appealing to
>people who are turned off by braces and symbolism -- this is not going
>to increase the quality of IF, but really just make it even more
>mediocre. "If you're scared of programming, and can't tell Inglish
>from programming, then Inform is for you!" Basically that's flat-out
>selecting for morons.
So the alternative is "No, keep it hard, that way we keep morons
out!".
And you were talking about elitism the other thread. Tsk, tsk.
Take a look at AGS. See the CRAP games that abound there. And see the
quality of some OTHER games. There's brilliant games made with AGS.
There's commercial games made with AGS. And see the first games of the
authors of the very GOOD games. Heck, see Bestowers of Eternity, the
grandaddy of Dave GIlbert's Blackwell Legacy.
AGS is an extremely easy graphic adventure authoring tool, and it has
received exactly the sort of complaint you are making. My response to
you and people like you is, not everyone find it easy to program, and
an easy tool doesn't mean only morons will use it, it means more
people will use it. "More people" include writers who don't know much
about programming and feel daunted by it. It also includes morons, but
it also includes morons who one day will churn out great quality
games, after their first experiments.
Also, as far as I can see in all Tads and all Inform 6 games, not
being immediately acessible is not a guarantee of not being crap
games. There will always be crap games.
Hey, maybe the teenage Andrew Plotkin should have been stopped from
making Inhuman! That shounds good, doesn't it? One less ho-hum game in
the world! Except that then we wouldn't have Spider and Web, Shade,
Delightful Wallpaper, Hunter in Darkness, and so on and so forth...
>Again, yes, exactly. It's not really a "tutorial for beginners," if at
>the end of the tutorial you're essentially stuck, because programming
>has not been explained as such. You can walk down the path as directed
>by the manual, but once you're ready to go out on your own, you
>stumble off the path, into the swamp.
This sort of approach usually comes from the mindset of people who
just read the manual through, not bothering with trying things out.
The whole mindset boggles me. It's a programming language. It doesn't
provide a tutorial, but there's lots of examples. It's right next to
the source code. You are heavily encouraged, by the format of the
thing alone, to write in and try stuff as you go along! To get
acquainted with the language as you read the manual! If you don't do
this, of course you'll be stuck by the end. And there's a higher
learning curve than it seems.
The manual is a path indeed, but if you stray off the path you'll find
another path, the beginnings of a path, which you can yourself
continue. And it's not a swamp, it's a well-lit forest, with a ranger
house on RAIF ready to provide help.
The manual does a good job at inspiring you to try stuff out and then
explaining stuff to you. If you don't muck about while you're still
reading the manual, now.... no wonder you don't get very far.
***************
[takes Defensor of I7 cloak off]
***************
Funny, I didn't mean to be so fervemt about this, but some of the
things said here tickled me a bit. And I got to thinking *why*.
You know, maybe using I7 or another tool is just a mindset. A
preference. Some would never consider using Tads 3. Some would never
consider using Inform 7. And we're gleefuly telling each other why we
prefer one or the other (in this case, telling each other what is and
isn't wrong with I7), but in the end who is trying to convince who?
Despite Steve's elitist claim, godd games will still come along.
Despite all the theory on whether a rules system is really the best,
some of us have been working with it long enough to be know it and
even love it (I do both). There's less of a rational motive to pick
one, and more of a "how suitable is it for ME" issue. I love it. It is
a further diferentiation between the systems, one so radical is allows
one to *easily* choose which one is best for him, never worrying
"Wonder if I should have chosen that othe tool, maybe it had -feature
list- ..."
Theory is theory, right, and thought is thought. But peoples is
peoples. Criticizing I7 when it was a concept made sense, but now you
might as well criticize a hammer - it's a tool. It's there. People use
it. What's the point in wondering about it? Unless you want to make it
better, of course, but it doesn't strike me as though you do, Steve.
It strikes me as though you want to rewrite it all. That was at the
concept stage. We're way past that, and everyone's using the hammer.
Except for the people who aren't, of course, because maybe they prefer
using screws rather than nails. Peoples is peoples.
Pete Chown
> Correct. Nobody argues any more whether OOP or rule-based languages are
> "better."
It's true that you don't see Prolog being used for everyday projects.
However, some object-oriented libraries implement something that looks
rule-based to me. Swing is a good example. When you use
addActionListener to attach an event handler to a button, aren't you
adding a rule? You could imagine writing something similar in pseudo-
Inform: "When the player clicks the button..."
Pete
steve....@gmail.com
> 2.15. Does Inform really understand English?
>
Yes, there's the fine print, but it's a false concession. I imagine
that Graham inserted this only with great reluctance, and only because
omitting this concession would have further emphasized the incoherence
of his project.
At the same time, he was arguing on RAIF that Inglish is in fact
English (it's a subset (which is true); it's basically readable by a
complete novice (not always, but whatever); that it's machine
instruction "does not obviate its naturality," etc.), and I7
understands that, so... QED. Jim already pointed out the relevant bits
of the whitepaper, so you should be getting the idea here.
Not that I have any objection to incoherent arguments in principle.
The point was simply that the manual would have been much improved, if
Graham weren't talking out both sides of his mouth, and took a
practical approach, actually treating I7 as a programming language.
Chewbacca
> Jim Aikin wrote:
>
>> As a T3 author, I admit to feeling
>> a little ostracized by the fact that this year's T3 games are
>> outnumbered more than 10 to 1 by Inform games (though that count
>> includes at least one I6 game, and possibly several).
>
> It's just that the whole genre is suffering a new low. Just look at
> the quality of the entries. (I haven't played them all, and some may
> be excellent works! (No, I haven't played yours Jim, and I do hope the
> best for you!))
>
> As predicted, making IF programming more superficially appealing to
> people who are turned off by braces and symbolism -- this is not going
> to increase the quality of IF, but really just make it even more
> mediocre. "If you're scared of programming, and can't tell Inglish
> from programming, then Inform is for you!" Basically that's flat-out
> selecting for morons.
Do you feel that T3 games are less mediocre? Would you care to name any
titles? You know, for actual comparison, so we know what you're talking
about. Speaking of which, how would you classify _The Battle of Walcot Keep_
on your mediocrity scale?
>> Neither of the T3 entries was written by Steve, of course. He could
>> have altered the percentages materially by entering a game.
>
> Not interested. In case you haven't noticed, my main interest is
> advancing the genre on a procedural and theoretical level. I don't
> think "more text" helps very much.
That's such a waste. With your sharp wit and masterful prose I think you'd
make a great IF writer. Perhaps this is the time to switch seats and grab
the wheel, seeing how the vehicle for your "procedural and theoretical"
advancement of the medium (read: T3) is slowly atrophying. Could this, in
fact, be where the shoe pinches? The slow death of T3 and the victory of I7?
Pete Chown
> He [Graham Nelson] also says this:
>
> "...a 'natural' system for IF is one in which ... the source text reads
> like a narrative."
This makes a certain sense, I suppose. You play IF by typing pseudo-
English, so why shouldn't you write one the same way?
> Five hundred years from now, if there are still computers (and if there
> are still people), we may indeed have true natural language programming.
> It may be possible to sit down in front of a computer and say, "Write me
> a program that will correlate X and Y with A and B," and have the
> computer do the job, prompting the "programmer" with intelligent
> questions only as needed.
In this context it's interesting to think about SQL. Obviously it
doesn't aim to be natural language. At the same time, you tell the
computer what you want, rather than how to get there. Once the query
planner knows what you want, it works out how to get there, and "writes
the program".
One of the things you realise is that specifying the program formally is
nearly as hard as writing it. Writing SQL is a bit easier than writing
code that uses indexes directly, but there isn't a huge difference. At
the same time, anyone who has worked in IT has horror stories where
specifications are misunderstood, and the resulting product doesn't do
what is required.
As a result, I think natural language programming may not be as good as
it appears on the face of it. You will still need someone to write
unambiguous specifications, which sounds very like "programming". You
might also find that these specifications are nearly as long as they
would be when expressed in computer language, as happens with SQL, so you
haven't saved very much.
Pete
Jim Aikin
> vaporware wrote:
> > 2.15. Does Inform really understand English?
>
> > No. [...]
>
> Yes, there's the fine print, but it's a false concession. I imagine
> that Graham inserted this only with great reluctance, and only because
> omitting this concession would have further emphasized the incoherence
> of his project.
Sorry, Steve -- trying to read Graham's mind puts you firmly back in
the "ad hominem" column. The discussion so far in this thread has been
fairly sensible, on all sides. I, for one, would appreciate it if you
would steer clear of this kind of rhetoric. It really doesn't help.
--JA
steve....@gmail.com
> On Oct 9, 3:50 am, steve.bres...@gmail.com wrote:
>
> > vaporware wrote:
> > > 2.15. Does Inform really understand English?
>
> > > No. [...]
>
> > Yes, there's the fine print, but it's a false concession. I imagine
> > that Graham inserted this only with great reluctance, and only because
> > omitting this concession would have further emphasized the incoherence
> > of his project.
>
> Sorry, Steve -- trying to read Graham's mind puts you firmly back in
> the "ad hominem" column.
Not really. An "ad hominem" is where you replace reasoned argument
with personal attack. I'm not offering personal attack as evidence.
(Indeed, this wasn't a personal attack anyway, but whatever.)
If I had argued how the I7 manual is less than ideal, and in evidence
I argued that Graham is mentally conflicted about what he's trying to
accomplish, that would be "ad hominem." (It's a very silly example,
but again, whatever.) I'm not saying that sort of thing at all.
We have a pretty clear and entirely separate argument, that the I7
manual (and the IDE) is less than ideal, in that it does not treat I7
as a programming language, relegates the overt programmy stuff to the
index and de-emphasizes it. Ok, so that's noted... now what?
Well, I'd say we can ask why it turned out like that. There was this
NL goal, expressed in the whitepaper and on RAIF. If the author were
really intent on presenting I7 as NL, this would explain the problem
with the manual. vaporware makes the intelligent point, that, well,
this can't be true, because it says right there in black and white
that I7 isn't an NLP. Basically, my response is, yes, there's that
concession, so to be more precise, the manual is self-conflicted. It's
pretty clear that Graham was aiming for NL as an ideal, fell short (of
course), but still wanted to push towards NL as much as rhetoric and
logic would allow. In so doing, I believe he damaged the system
(resulting in the problems we established before the 'why' even came
up).
I can see the reluctance to speculate on someone's intentions. Maybe
we should identify the problems and stop there, without thinking about
the underlying source of the problems. On the other hand, maybe the
speculation helps prevent their repetition. But in any case, this is
not argument "ad hominem," and I certainly apologize if I sometimes
get a little irritated about the whole thing, and it ends up coming
across like a personal attack.
stealth...@gmail.com
> Well, I'd say we can ask why it turned out like that. There was this
> NL goal, expressed in the whitepaper and on RAIF. If the author were
> really intent on presenting I7 as NL, this would explain the problem
> with the manual. vaporware makes the intelligent point, that, well,
> this can't be true, because it says right there in black and white
> that I7 isn't an NLP. Basically, my response is, yes, there's that
> concession, so to be more precise, the manual is self-conflicted. It's
> pretty clear that Graham was aiming for NL as an ideal, fell short (of
> course), but still wanted to push towards NL as much as rhetoric and
> logic would allow. In so doing, I believe he damaged the system
> (resulting in the problems we established before the 'why' even came
> up).
I don't think that's clear at all. I've no experience with TADS, so I
can't judge that system (and precious little with Inform either - I've
only been playing with it for a few months) but the design goal of
Inform 7 seems very clear to me - to try to make the language with
which the writer/programmer communicates with the computer as close as
possible to the language with which the computer communicates with the
player. This also has the secondary effect (intentional, I'm sure) of
making the source code read like prose, which I think makes it easier
to conceptualise the work in terms of the story being written and make
it easier for non-programmers to program in it. It also makes the code
vastly more maintainable and thus more fun to work with (I spend all
day at work looking through perl scripts trying to find the place
where someone's typed .* instead of *. in some string of
incomprehensible gibberish full of @s and \s - the last thing I want
to do is do that in my spare time).
Of necessity, to do those things, especially the first two, the
language used has to be a subset of natural language, but that doesn't
mean the aim of I7 was ever to be a natural language parser. Rather,
it's aiming at *implementing those features of natural language which
make it suitable for IF-writing*.
I think it's actually a rather remarkable achievement,
But then, I also don't think the manual is 'less than ideal'. It's not
K&R, or the Camel book, but it's not trying to be. It's not primarily
aimed at teaching people the nitty-gritty of the language before
anything else, but at teaching them what they need to know as they go
along.
I would suggest that if something is both the most popular system in
use *and* a system that has been used to create works of undoubted
quality, anything that looks like a 'fundamental flaw' is probably
just a difference in preference, and if you have disagreements with
the fundamental, basic design decisions then it's probably more
productive to concentrate on those platforms that *are* to your taste
than to keep posting about why they're 'wrong'...
steve....@gmail.com
> > It's
> > pretty clear that Graham was aiming for NL as an ideal, fell short (of
> > course), but still wanted to push towards NL as much as rhetoric and
> > logic would allow. In so doing, I believe he damaged the system
> > (resulting in the problems we established before the 'why' even came
> > up).
>
> I don't think that's clear at all.
Ah, if you mean his goal, then you should read the whitepaper; if you
mean his rhetorical efforts, then you can read the RAIF archives. From
these, it is indeed clear.
> [T]he design goal of
> Inform 7 seems very clear to me - to try to make the language with
> which the writer/programmer communicates with the computer as close as
> possible to the language with which the computer communicates with the
> player. This also has the secondary effect (intentional, I'm sure) of
> making the source code read like prose, which I think makes it easier
> to conceptualise the work in terms of the story being written and make
> it easier for non-programmers to program in it.
If that were the justification, then of course I would not be arguing
that the design was ideologically driven, and as a consequence failed
on certain practical issues.
I would limit myself to arguing the value of formal symbolism, to make
the technical meaning/effect of a piece of code perfectly clear.
You make a good point, however, in that writing in mock-English code
might make it easier to conceptualize the work in terms of story. I
think the harder part is conceptualizing it in terms of algorithmic
procedure, so mock-English is not a fun programming system for me. :)
> But then, I also don't think the manual is 'less than ideal'.
> [...] It's not primarily
> aimed at teaching people the nitty-gritty of the language before
> anything else, but at teaching them what they need to know as they go
> along.
My experience reading it was a fall into increasing confusion. If it
exposed the language as a programming language, then I would have had
a much easier time. But others have written in more detail on this
subject, upthread.
> I would suggest that if something is both the most popular system in
> use *and* a system that has been used to create works of undoubted
> quality, anything that looks like a 'fundamental flaw' is probably
> just a difference in preference[.]
I'm afraid I can't agree with a single point in that thought. I have
doubts that I7 is the most popular system in use; certainly I7 has
produced passable works, but nothing compared to more important and
robust works created in I6 (Varicella, Savoir Faire, Spider and Web)
or TADS-3 (Elysium, RtDD).
I didn't say 'fundamental flaw,' and I didn't deny 'difference in
preference.'
If you want my explanation of why those who prefer I7 do so, I'd say
that the main alternative (TADS-3) seems too complicated to bother
with. This 'seeming' has to do with the fact that TADS-3 uses a
symbolic formalism which takes a couple days or so to get used to (if
you're a complete novice), and the TADS-3 library is huge and
intricate. TADS-3 is pitched/optimized for advanced users. (That I7 is
pitched for novices may be a fatal flaw, if it means that advanced
users are hobbled. -- But that was not the argument.)
> [I]f you have disagreements with
> the fundamental, basic design decisions then it's probably more
> productive to concentrate on those platforms that *are* to your taste
> than to keep posting about why they're 'wrong'...
I'm not posting about why I7 is 'wrong,' sorry.
Adam Thornton
<steve....@gmail.com> wrote:
>If you want my explanation of why those who prefer I7 do so, I'd say
>that the main alternative (TADS-3) seems too complicated to bother
>with. This 'seeming' has to do with the fact that TADS-3 uses a
>symbolic formalism which takes a couple days or so to get used to (if
>you're a complete novice), and the TADS-3 library is huge and
>intricate. TADS-3 is pitched/optimized for advanced users. (That I7 is
>pitched for novices may be a fatal flaw, if it means that advanced
>users are hobbled. -- But that was not the argument.)
There is some truth to this.
The symbolic formalism is not an issue for me. I was reasonably
competent in TADS-2, I wrote I6 just fine, and I can express myself with
varying degrees of fluency in probably a dozen other computer
languages. TADS-2 is less grotty than Inform 6, certainly, and T3 isn't
significantly different in terms of syntax.
The staggering complexity of the library is a much bigger stumbling
block. I very much appreciate Eric Eve's work in making it digestable
(and Marnie Parker's additional Quick Tour documentation), but the fact
remains that I could just start writing in I7 in a way I couldn't in T3.
(The plotter-drawn class-inheritance diagram from the T2 documentation,
btw, is gorgeous; honestly, that diagram alone was probably worth every
bit of the $50 I paid for TADS (yes, I was one of the first purchasers
of TADS-2, pretty much immediately after it came out (late 1992, IIRC);
I used TADS v1 too, but not very much), which was a lot of money for me
at the time--money I have never regretted spending). These days....it
looks much less elegant (http://www.flaminglunchbox.net/tads3/tads3.pdf)
but I have no doubt it's hugely more functional.
I don't think that I7 itself hobbles advanced users overmuch. The main
hobbling I've noticed is the hobbling I've done to myself. By that I
mean, I started coding something one way, and it sort of worked, and I
kept going, and by the time I realized that I really hadn't done it the
best way for the effect I wanted (and here I'm specifically thinking of
the conversation system in my WIP) it seemed like an immense amount of
effort to go back, rip it out, and do it right. So I didn't. And what
I've ended up with is kludgey and gross. I don't know how evident its
shortcomings are to the *player* rather than the author, though. My
playtesters have not seemed to mind or notice much, at least once I add
the conversational topics they want.
This might have been avoided in T3 only because I would have been forced
to sit down and do the design properly in the first place, rather than
just jumping in and beginning to write, snatching examples from the
manual as I went. Whether this would have been any faster than doing it
right in I7 is debatable. It certainly would have been slower than
doing it *wrong* in I7, but I might have liked the results better.
Adam
stealth...@gmail.com
> stealthmunch...@gmail.com wrote:
> > > It's
> > > pretty clear that Graham was aiming for NL as an ideal, fell short (of
> > > course), but still wanted to push towards NL as much as rhetoric and
> > > logic would allow. In so doing, I believe he damaged the system
> > > (resulting in the problems we established before the 'why' even came
> > > up).
>
> > I don't think that's clear at all.
>
> Ah, if you mean his goal, then you should read the whitepaper; if you
> mean his rhetorical efforts, then you can read the RAIF archives. From
> these, it is indeed clear.
I have read the white paper - several times. It contains phrases like:
" Inform does not aspire to recognise anything like the whole sweep
of natural language,
and in a few cases usefulness has been allowed to trump linguistic
fidelity: in particular, it
does not attempt to reject all un-natural language. But on the whole
Inform tries to avoid
eccentricity."
See also footnote 9. Pretty much the whole thing, in fact, is a
demonstration of how I7 is *not* 'natural language' in the sense that
it mimics exactly an actual natural language. I think the use of
'natural language' in that paper is possibly slightly ambiguous - what
I took away from the paper is that I7 is not 'natural language' but
*is* what we might call 'naturalistic language' in that it can be read
and comprehended straight away.
> > [T]he design goal of
> > Inform 7 seems very clear to me - to try to make the language with
> > which the writer/programmer communicates with the computer as close as
> > possible to the language with which the computer communicates with the
> > player. This also has the secondary effect (intentional, I'm sure) of
> > making the source code read like prose, which I think makes it easier
> > to conceptualise the work in terms of the story being written and make
> > it easier for non-programmers to program in it.
>
> If that were the justification, then of course I would not be arguing
> that the design was ideologically driven, and as a consequence failed
> on certain practical issues.
Those are the justifications that Mr Nelson lays out in the paper you
refer to yourself...
> I would limit myself to arguing the value of formal symbolism, to make
> the technical meaning/effect of a piece of code perfectly clear.
And then we get to what is essentially the old high/low-level
programming language debate. "REAL programmers directly manipulate
the positions of individual electrons on the hard disk." It's a
position I have a lot of sympathy for most of the time, having used
one too many Python apps that bloat to half a gig of memory because of
poor memory management, but I view the creation of IF as being more of
an artistic than a technical act, and I think in general artistic
tools should have as simple an interface as possible...
(I also admit that I may well be talking complete drivel, having
produced precisely 0 complete pieces of IF in my life so far...)
> You make a good point, however, in that writing in mock-English code
> might make it easier to conceptualize the work in terms of story. I
> think the harder part is conceptualizing it in terms of algorithmic
> procedure, so mock-English is not a fun programming system for me. :)
Fair enough. Horses for courses and all that. In my case I find the
story the hard part...
> If you want my explanation of why those who prefer I7 do so, I'd say
> that the main alternative (TADS-3) seems too complicated to bother
> with. This 'seeming' has to do with the fact that TADS-3 uses a
> symbolic formalism which takes a couple days or so to get used to (if
> you're a complete novice), and the TADS-3 library is huge and
> intricate. TADS-3 is pitched/optimized for advanced users. (That I7 is
> pitched for novices may be a fatal flaw, if it means that advanced
> users are hobbled. -- But that was not the argument.)
That's certainly possible - probable even - as one reason for people
choosing it. It doesn't, though, explain those people who have moved
over to I7 from other languages...
It also doesn't explain my own case - I've only very recently become
interested in IF (other than playing a few games when I was very young
and always having loved the Infocom Hitch-Hikers game) and that
interest is in large part because I read about I7 and was fascinated
by it *as a language*. I've only since started playing (and enjoying)
those games that people seem to consider classics. I find the language
itself fascinating and the design decisions aesthetically and
intellectually pleasing in a way I don't with most other languages.
James Jolley
> If you want my explanation of why those who prefer I7 do so, I'd say
> that the main alternative (TADS-3) seems too complicated to bother
> with. This 'seeming' has to do with the fact that TADS-3 uses a
> symbolic formalism which takes a couple days or so to get used to (if
> you're a complete novice), and the TADS-3 library is huge and
> intricate. TADS-3 is pitched/optimized for advanced users. (That I7 is
> pitched for novices may be a fatal flaw, if it means that advanced
> users are hobbled. -- But that was not the argument.)
>
> If this was the case entirely, why does Emily bother using it? After
> all, she started out with I6 and certainly understands that system. I
> don't suppose she'd ever bother using I6 again though.
Jacek Pudlo, Esq.
"Adam Thornton" <ad...@fsf.net> skrev i meddelandet
news:ert4s5-...@quicksilver.fsf.net...
> In article
> <43c0ec23-51f9-4723...@y29g2000hsf.googlegroups.com>,
> <steve....@gmail.com> wrote:
>>If you want my explanation of why those who prefer I7 do so, I'd say
>>that the main alternative (TADS-3) seems too complicated to bother
>>with. This 'seeming' has to do with the fact that TADS-3 uses a
>>symbolic formalism which takes a couple days or so to get used to (if
>>you're a complete novice), and the TADS-3 library is huge and
>>intricate. TADS-3 is pitched/optimized for advanced users. (That I7 is
>>pitched for novices may be a fatal flaw, if it means that advanced
>>users are hobbled. -- But that was not the argument.)
>
> There is some truth to this.
>
> The symbolic formalism is not an issue for me. I was reasonably
> competent in TADS-2, I wrote I6 just fine, and I can express myself with
> varying degrees of fluency in probably a dozen other computer
> languages. TADS-2 is less grotty than Inform 6, certainly, and T3 isn't
> significantly different in terms of syntax.
This is ultimately what's wrong with this community. We should be discussing
Pynchon's sublime prose, Updike's transcendentalism, Delillo's gift for
terse, hilarious dialogue. We should be discussing poetics, not the
aesthetics of computer language syntax. We should sound like tedious
academicians, not like tedious 'puter geeks.
Let's totally rewire this thread. How does Harold Bloom's idea of literary
influence apply to IF? I want you *all* to take a trip to your campus or
local library, borrow _The Anxiety of Influence_, read it, and come back
here with ideas how it applies to IF.
Okay, here's a hint: it doesn't. But why? In answering the question we'll
understand more about IF than by arguing how TADS-2 is "less grotty" than
Inform 6.
steve....@gmail.com
> Let's totally rewire this thread. How does Harold Bloom's idea of literary
> influence apply to IF? I want you *all* to take a trip to your campus or
> local library, borrow _The Anxiety of Influence_, read it, and come back
> here with ideas how it applies to IF.
>
> Okay, here's a hint: it doesn't. But why?
Extraordinarily lame. If you were in a seminar, and you interrupted
and said: "Let's totally rewire this discussion. How does Harold
Bloom's idea of literary influence [better known as misprision] apply
to the discussion? Um... Well, actually come to think of it, it
doesn't. But maybe I can dig myself out of a hole by asking *why* it
doesn't have any bearing!"
Everyone would stare at you like you were the dumbest person they ever
met, and they'd be right.
N.B.:
Fact is, I7's design is overburdened by anxiety over influence. This
does not explain why NL presentation is so thoroughgoing, why NL is
placed above practical considerations.
But it certainly explains why I7 makes such a radical break with the
programming paradigm expressed by TADS-2 and I6, which TADS-3 more-or-
less perfects: it had to do something else under the circumstances. It
also explains the constant semi-quasi-ironical pretension levels, the
bad faith, the cavalier-yet-imperial treatment of other texts.
Jacek Pudlo, Esq.
<steve....@gmail.com> skrev i meddelandet
news:90a894dd-2d5b-4490...@2g2000hsn.googlegroups.com...
> Jacek Pudlo wrote:
>> Let's totally rewire this thread. How does Harold Bloom's idea of
>> literary
>> influence apply to IF? I want you *all* to take a trip to your campus or
>> local library, borrow _The Anxiety of Influence_, read it, and come back
>> here with ideas how it applies to IF.
>>
>> Okay, here's a hint: it doesn't. But why?
>
> Extraordinarily lame. If you were in a seminar, and you interrupted
> and said: "Let's totally rewire this discussion. How does Harold
> Bloom's idea of literary influence [better known as misprision]
Misprision, better known as clinamen, is only one of the six revisionary
ratios of Bloom's theory of literary influence. Yours is a common mistake --
a metonymic substitution of the whole for its part -- but I do hope you're
more careful in your seminars.
> apply
> to the discussion? Um... Well, actually come to think of it, it
> doesn't. But maybe I can dig myself out of a hole by asking *why* it
> doesn't have any bearing!"
It doesn't apply because of the simple fact that IF lacks the equivalent of
what Bloom calls "strong poets." If IF is indeed a separate medium with a
separate canon, what would its centre be? _Zork_? It's certainly one of the
most influential games, but the idea that IF authors are struggling under
the anxiety of _Zork's_ influence is rather silly. Are there other
candidates? _Galatea_? _Anchorhead_? _Photopia_? Even the best IF games are
so narratively vacuous and artistically crude there is nothing there to
misread, purge, or complete, to mention some of the revisionary ratios,
which I'm sure you're familiar with. So realising that Bloom's theory of
influence doesn't apply to IF *does* give us some insight into the medium.
Namely the dismal realisation of its crudity.
> Everyone would stare at you like you were the dumbest person they ever
> met, and they'd be right.
To be honest, Steve, I'm surprised that an English teacher in a provincial
college has *any* understanding of Bloom's theory, even if that
understanding is shallow and distorted. And I do admire your passion, though
I feel it's somewhat misguided.
Adam Thornton
Jacek Pudlo, Esq. <jacek.jacek@jacek> wrote:
>This is ultimately what's wrong with this community. We should be discussing
>Pynchon's sublime prose, Updike's transcendentalism, Delillo's gift for
>terse, hilarious dialogue. We should be discussing poetics, not the
>aesthetics of computer language syntax. We should sound like tedious
>academicians, not like tedious 'puter geeks.
Why? Why must we be tedious at all?
I already *did* my time in the academy. If I must choose, I'd actually rather
sound like an engineering geek than a humanities geek.
Of course, maybe that *is* what's wrong with the community. That is:
there are some *very hard indeed* computing problems that would make IF
better if they were solved. Most of them are damn near equivalent to
having actual AI, and it's vanishingly unlikely that the solutions are
going to come out of the IF world.
Other than that, there's really nothing that *algorithmically* hard
about IF. At this point, the major systems are plenty good enough to
model geography, objects, basic object interactions, et cetera, ad
nauseum. My WIP is very large, and contains lots of fairly clever
stuff from a programming perspective, but it doesn't do anything even
remotely *hard*.
If the game has an amusing and/or appropriate response to whatever he
types, why should the player care whether it's done with a detailed
simulation of the game-world's physics, with
behind-the-scenes-stagecraft, or by little elves inside his computer
screen? He shouldn't, is my answer.
On the other hand, good or bad writing is something the player *will*
encounter. At the very least, a game's prose should be competent and
acceptably-crafted: the prose should at a minimum not distract from the
story the author's trying to tell. That shouldn't be a very high bar.
The perennial appearance of games whose authors don't understand the
distinction between "your" and "you're," however, sadly suggests that it
is.
>Let's totally rewire this thread. How does Harold Bloom's idea of literary
>influence apply to IF? I want you *all* to take a trip to your campus or
>local library, borrow _The Anxiety of Influence_, read it, and come back
>here with ideas how it applies to IF.
>
>Okay, here's a hint: it doesn't. But why? In answering the question we'll
>understand more about IF than by arguing how TADS-2 is "less grotty" than
>Inform 6.
I haven't read Bloom in almost 15 years. I recall thinking he was far
too credulous about the utility of Freud in understanding
categorization, and (I'm pretty sure we were given _A Map Of Misreading_
alongside _The Anxiety of Influence_) the Kabbalah stuff just baffled
me. (Looking at Wikipedia to refresh my memory, I do find it intriguing
that I basically agree with him in terms of modern novelists, although I
must confess that I am not that impressed with Philip Roth. I agree
wholeheartedly with his recommendations of Pynchon, McCarthy, and
Crowley. I need to read more DeLillo; not sure why I haven't. I also
need to re-read Hart Crane, carefully this time, since Chip Delany also
adores him.)
Cognitive science has a lot to say about how we *create* IF, but maybe
less than we'd hope about how to play (read?) it. I find Lakoff's work
on categorization fascinating and provocative, but I'm not sure, in the
end, it has much bearing on creation of IF rather than on creation of
tools to create IF.
The closest analogue, *I* think, is "game designer"--but that's a
vocation that is, as far as I know, largely lacking a coherent
theoretical framework. It's possible that I'm just out of touch with
what that framework is (my rather dismissive survey of what I thought
the state of the art circa 2001 to be can be found in the Holodeck scene
of _SMTUC_).
I'd really *like* to read a historical survey of game design...but I
don't know that any such thing exists (no, not just computer game
design; I guess a historical survey of, what's the academic term now,
ludics? is what I'm looking for). Does it? IF isn't just fiction,
which is one of the strange things about it. The things that make a
good IF writer aren't the things that make a good writer, or the things
that make a good computer programmer. The things that make a good IF
writer are, I believe, a lot closer to the things that make a good game
designer. I don't really know where to take that belief from there,
though.
Adam
Adam Thornton
<steve....@gmail.com> wrote:
>Extraordinarily lame. If you were in a seminar, and you interrupted
>and said: "Let's totally rewire this discussion. How does Harold
>Bloom's idea of literary influence [better known as misprision] apply
>to the discussion? Um... Well, actually come to think of it, it
>doesn't. But maybe I can dig myself out of a hole by asking *why* it
>doesn't have any bearing!"
>
>Everyone would stare at you like you were the dumbest person they ever
>met, and they'd be right.
Or as if you were a Vice-Presidential candidate.
Except that, come to think of it, she wouldn't *state* she was radically
changing the subject, she'd just do it.
Also, I seem to be putting that Vice-Presidential candidate up as a
counter-example to "dumbest person ever," so, well, er, actually, never
mind.
Adam
Jacek Pudlo, Esq.
> In article <pLKdncOIyKxXQGzV...@giganews.com>,
> Jacek Pudlo, Esq. <jacek.jacek@jacek> wrote:
>>This is ultimately what's wrong with this community. We should be
>>discussing
>>Pynchon's sublime prose, Updike's transcendentalism, Delillo's gift for
>>terse, hilarious dialogue. We should be discussing poetics, not the
>>aesthetics of computer language syntax. We should sound like tedious
>>academicians, not like tedious 'puter geeks.
>
> Why? Why must we be tedious at all?
If we must be tedious at all, let us be tedious about something that
matters. If I must be a pedant, I'd much rather be a pedant on Pynchon than
TADS.
> I already *did* my time in the academy. If I must choose, I'd actually
> rather
> sound like an engineering geek than a humanities geek.
I once spent an entire evening in the company of a retired electrical
engineer who lectured me, uncolicitedly, on the intricacies of the
combustion engine. I sincerely hope you're just being contrarian, Adam.
> Of course, maybe that *is* what's wrong with the community. That is:
> there are some *very hard indeed* computing problems that would make IF
> better if they were solved. Most of them are damn near equivalent to
> having actual AI, and it's vanishingly unlikely that the solutions are
> going to come out of the IF world.
You see, I don't think better AI will solve anything. But neither do you.
> Other than that, there's really nothing that *algorithmically* hard
> about IF. At this point, the major systems are plenty good enough to
> model geography, objects, basic object interactions, et cetera, ad
> nauseum. My WIP is very large, and contains lots of fairly clever
> stuff from a programming perspective, but it doesn't do anything even
> remotely *hard*.
>
> If the game has an amusing and/or appropriate response to whatever he
> types, why should the player care whether it's done with a detailed
> simulation of the game-world's physics, with
> behind-the-scenes-stagecraft, or by little elves inside his computer
> screen? He shouldn't, is my answer.
[Jacek nods his head in silent agreement.]
> On the other hand, good or bad writing is something the player *will*
> encounter. At the very least, a game's prose should be competent and
> acceptably-crafted: the prose should at a minimum not distract from the
> story the author's trying to tell. That shouldn't be a very high bar.
> The perennial appearance of games whose authors don't understand the
> distinction between "your" and "you're," however, sadly suggests that it
> is.
Here's another difference between IF and static fiction: There are no
editors in IF. For all we know, Thomas Pynchon may have problems with "your"
and "you're." Only it's not really a problem, not for Pynchon, because
Pynchon has paid professionals who scour his texts for the tiniest errors.
This is something that reflects on the fact that IF is a cottage industry,
not necessarily on the quality of the authors. But it is one of those things
that reviewers tend to focus on, mainly because it's simpler to analyse
grammar than narrative structure or prose style. It's *so* much easier to
poke fun at George W. Bush's malapropisms than to cogently critisise his
policies.
>>Let's totally rewire this thread. How does Harold Bloom's idea of literary
>>influence apply to IF? I want you *all* to take a trip to your campus or
>>local library, borrow _The Anxiety of Influence_, read it, and come back
>>here with ideas how it applies to IF.
>>
>>Okay, here's a hint: it doesn't. But why? In answering the question we'll
>>understand more about IF than by arguing how TADS-2 is "less grotty" than
>>Inform 6.
>
> I haven't read Bloom in almost 15 years. I recall thinking he was far
> too credulous about the utility of Freud in understanding
> categorization, and (I'm pretty sure we were given _A Map Of Misreading_
> alongside _The Anxiety of Influence_) the Kabbalah stuff just baffled
> me. (Looking at Wikipedia to refresh my memory, I do find it intriguing
> that I basically agree with him in terms of modern novelists, although I
> must confess that I am not that impressed with Philip Roth. I agree
> wholeheartedly with his recommendations of Pynchon, McCarthy, and
> Crowley. I need to read more DeLillo; not sure why I haven't. I also
> need to re-read Hart Crane, carefully this time, since Chip Delany also
> adores him.)
I you haven't already, try _The Human Stain_. It's not as highly touted as
_American Postoral_, but much better. I'd recommend anything by DeLillo,
except for the stuff he's published under an assumed name and, sadly, his
latest novel, which was a huge disappointment.
Speaking of Bloom, I think IF would gain from a canon discussion. Instead of
discussing how future games will gain from future technology, instead of wet
dreams about non-existent titles, we should focus on games that do exist and
try to explain why some are better than others. Even if Bloom's revisionary
ratios are rather unproductive when applied to current IF, some kind of
canonical hierarchy -- or a discussion about one -- could be fruitful. You
know how Bloom is constantly bitching about his "School of Resentment"? How
it is the "death of art"? It strikes me now that current works of IF are not
even cogent enough to be resentful. The problem is not that IF lacks a
Tolstoy. What is more embarrassing by far is that IF lacks a Jamaica Kincaid
and a Maya Angelou.
> Cognitive science has a lot to say about how we *create* IF, but maybe
> less than we'd hope about how to play (read?) it. I find Lakoff's work
> on categorization fascinating and provocative, but I'm not sure, in the
> end, it has much bearing on creation of IF rather than on creation of
> tools to create IF.
>
> The closest analogue, *I* think, is "game designer"--but that's a
> vocation that is, as far as I know, largely lacking a coherent
> theoretical framework. It's possible that I'm just out of touch with
> what that framework is (my rather dismissive survey of what I thought
> the state of the art circa 2001 to be can be found in the Holodeck scene
> of _SMTUC_).
>
> I'd really *like* to read a historical survey of game design...but I
> don't know that any such thing exists (no, not just computer game
> design; I guess a historical survey of, what's the academic term now,
> ludics? is what I'm looking for). Does it? IF isn't just fiction,
> which is one of the strange things about it. The things that make a
> good IF writer aren't the things that make a good writer, or the things
> that make a good computer programmer. The things that make a good IF
> writer are, I believe, a lot closer to the things that make a good game
> designer. I don't really know where to take that belief from there,
> though.
I vehemently disagree. I see IF as primarily textual and narrative, and thus
a lot closer to literature than to gaming. There is a game component, but
it's secondary at best and primary at worst, by which I mean that
simulationist IF efforts tend to suck dead rats through a very narrow straw.
Adam Thornton
Jacek Pudlo, Esq. <jacek.jacek@jacek> wrote:
>If I must be a pedant, I'd much rather be a pedant on Pynchon than
>TADS.
Well, I'd rather be a pedant on Pynchon than on damn near anything else,
but....
>> I already *did* my time in the academy. If I must choose, I'd actually
>> rather
>> sound like an engineering geek than a humanities geek.
>
>I once spent an entire evening in the company of a retired electrical
>engineer who lectured me, uncolicitedly, on the intricacies of the
>combustion engine. I sincerely hope you're just being contrarian, Adam.
I can see how that would produce colic.
However, I'm not entirely being contrarian. At least engineers are
usually talking about *something*. This differentiates them from many
scholars in the humanities, who argue at length about *nothing* that
anyone outside their specialties can understand.
The _Social Text_ hoax was very mean-spirited, but it did have an
essential point. The fascinating thing is that it could, very likely,
be perpetrated in high-energy physics these days. But I digress.
That said, when talking to engineers, I only rarely have the
barely-controllable urge to grab my crotch and say "I got something you
can put under erasure RIGHT HERE, BABY!"
>> Of course, maybe that *is* what's wrong with the community. That is:
>> there are some *very hard indeed* computing problems that would make IF
>> better if they were solved. Most of them are damn near equivalent to
>> having actual AI, and it's vanishingly unlikely that the solutions are
>> going to come out of the IF world.
>
>You see, I don't think better AI will solve anything. But neither do you.
Well, *really* better AI would solve *everything*. It will probably be
in the form of a rather Final Solution, though, so I'm not too excited
about the prospect of immanentizing that particular eschaton.
>Here's another difference between IF and static fiction: There are no
>editors in IF. For all we know, Thomas Pynchon may have problems with "your"
>and "you're." Only it's not really a problem, not for Pynchon, because
>Pynchon has paid professionals who scour his texts for the tiniest
>errors.
Say "major authors in general" and I'll agree with you. Little Tommy P,
maybe not so much. Seriously: "wooden blanket" ? Well, that's a lovely
circumlocution for "coffin," but do I have any confidence it's not a
typo for "woolen" ? I do not. Sleep, and let the train go by.
Being Pynchon's copyeditor would be very nearly as hard as being Gene
Wolfe's copyeditor. Not a job I'd want.
>This is something that reflects on the fact that IF is a cottage industry,
>not necessarily on the quality of the authors. But it is one of those things
>that reviewers tend to focus on, mainly because it's simpler to analyse
>grammar than narrative structure or prose style. It's *so* much easier to
>poke fun at George W. Bush's malapropisms than to cogently critisise his
>policies.
Yes, but....
If the grammar and spelling are atrocious, it makes it much harder to
focus on the ideas and story. I am among the few defenders of Rybread
Celsius. Beneath the incoherent awfulness beat a heart of lambent
surrealism, but it was hard, hard, hard to find.
>I you haven't already, try _The Human Stain_. It's not as highly touted as
>_American Postoral_, but much better. I'd recommend anything by DeLillo,
>except for the stuff he's published under an assumed name and, sadly, his
>latest novel, which was a huge disappointment.
Really, I've only read _Portnoy's Complaint_. I'll give _The Human
Stain_ a try.
>Speaking of Bloom, I think IF would gain from a canon discussion. Instead of
>discussing how future games will gain from future technology, instead of wet
>dreams about non-existent titles, we should focus on games that do exist and
>try to explain why some are better than others. Even if Bloom's revisionary
>ratios are rather unproductive when applied to current IF, some kind of
>canonical hierarchy -- or a discussion about one -- could be fruitful. You
>know how Bloom is constantly bitching about his "School of Resentment"? How
>it is the "death of art"? It strikes me now that current works of IF are not
>even cogent enough to be resentful. The problem is not that IF lacks a
>Tolstoy. What is more embarrassing by far is that IF lacks a Jamaica Kincaid
>and a Maya Angelou.
I don't know if I agree from you about "instead of," but, yes, I think
there is a lot to gain from close readings of various games, and then
vibrant discussion thereof. The closest thing we have to a canon,
though, is probably something like "the dozen or so really good Infocom
games, plus another two-dozen-or-so interesting-and-or-innovative modern
games." The problem there, of course, is that everyone's two dozen
modern games will be different, and, well, I'm not sure that "canon" is
quite the right word. There are a number of games that are deeply
flawed but fascinating from structural or narratalogical standpoints, as
well as some that aren't actually groundbreaking in any way, but are
very well-crafted exemplars of their forms.
I'd like to see a discussion of _Curses_ (well, *you* know my obsession
with "The Waste Land", so that shouldn't be a surprise), or _Anchorhead_
(damn near as good a Lovecraft pastiche as exists in static fiction,
which is saying something: lots of people try Lovecraft pastiche, but it
usually doesn't work. There really *was* something to Lovecraftian
cosmic horror that _Anchorhead_ nails, and most people, no matter how many
times they use "rugose" and "squamous", can't do). But I'd also like to
see _Aisle_ dissected, or _Rematch_--both of them very slight, but
structurally fascinating. Or indeed the underappreciated _So Far_,
which I characterized once, somewhat snarkily, as "miss, near."
_Varicella_ and _Lock and Key_ are two takes on the learn-by-dying
puzzler, and I think a side-by-side comparison of the two would be
fascinating. _Metamorphoses_ is another very interesting experiment, in
my book. But then, I also have a fascination with Early Modern alchemy:
a fascinating and quite rational attempt to deduce things about the deep
structure of the world, whose only real fault was that its axioms turned
out to be completely wrong.
>> The closest analogue, *I* think, is "game designer"--but that's a
>> vocation that is, as far as I know, largely lacking a coherent
>> theoretical framework. It's possible that I'm just out of touch with
>> what that framework is (my rather dismissive survey of what I thought
>> the state of the art circa 2001 to be can be found in the Holodeck scene
>> of _SMTUC_).
>I vehemently disagree. I see IF as primarily textual and narrative, and thus
>a lot closer to literature than to gaming. There is a game component, but
>it's secondary at best and primary at worst, by which I mean that
>simulationist IF efforts tend to suck dead rats through a very narrow straw.
And here we do indeed disagree. Simulationism is *not* gamism.
Which is to say: I agree that simulationist efforts are probably a silly
waste of time if you're writing a text game. If you're doing that, then
a medium in which the physics is more apparent (like the FPS) makes much
more sense (that said, I am a huge fan of inappropriate technologies.
The text-based side-scroller in that C.E. Forman game, for instance, was
a glorious failure, as was the IF version of the first level of _Doom_).
But there are plenty of excellent non-simulationist games.
However: if we're not writing games ("games" might be the wrong term,
but I don't have a better one yet) then what's the point of the "I" in
IF? If you want to write neat experimental short fiction, great:
McSweeny's is absolutely worth reading, and if you can get published in
it, bully for you.
I think the game component *must* be central. Certainly, at *least* as
central as the writing, since if it isn't, why not just write stories,
in which case you don't have to worry about player agency screwing up
your plot and characterization?
For me, writing IF is very similar to doing (pen-and-paper) RPG module
design. (I suppose "module" is one of those terms that went out of
favor with AD&D v1; "scenario" is perhaps more the Done Thing these
days) That is to say, there's an overarching story arc you'd like to
preserve, and the job at hand is to write a set of contingency plans so
that, whatever the players do, they get a satisfying story, but feel
they had the ability to affect the outcome in a meaningful way.
This is easier in tabletop gaming, of course, because you don't need to
fake the storyteller. The storyteller (when not actually just Space
Moose in a blonde wig) can actually think on his or her feet to
accomodate player requests. This is where IF becomes like writing a
module: you yourself don't get to be at the table, so you have to think
out at least the most likely player directions, and write instructions
to cover those contingencies.
I've recently been reading the recent RPG _Spirit of the Century_, which
is largely about the joys of the pickup game--a highly-improvised game
that, basically, does the Aristotelean thing from the _Poetics_ and has
plot dialectically emerge from character. Having read _SotC_, I am
*almost* willing to believe that this is indeed a model for more than
classical tragedies. However, the game itself is designed around the
tropes of the 1930s pulp novel, and I'm not at all convinced that pulp
is, really, a significant departure from the straitjacketing formalism
of the classical tragedy. _Both_ those genres are largely defined by
heroic characters sucked into awful but wholly predictable actions
because of their inherent character flaws. Yes, it makes a compelling
story, but I still maintain it's not the only kind of worthwhile story
(this is the essence of my beef with Chris Crawford as well).
I don't disagree with you that better writing will make better IF.
However, I disagree that this is *principally* what is needed for better
IF. The "I" is at least as important as the "F".
Adam
Emily Short
> But I'd also like to
> see _Aisle_ dissected, or _Rematch_--both of them very slight, but
> structurally fascinating.
Have you taken a look at Jeremy Douglass' dissertation? (
http://jeremydouglass.com/dissertation.html ) He offers a close
reading of Rematch; it's worth a look.
Pete Chown
> I once spent an entire evening in the company of a retired electrical
> engineer who lectured me, uncolicitedly, on the intricacies of the
> combustion engine. I sincerely hope you're just being contrarian, Adam.
I don't know what uncolicitedly means. Nor does my dictionary, and there
are no matches for it in Google. Did you make the word up? ;-)
> It
> strikes me now that current works of IF are not even cogent enough to be
> resentful. The problem is not that IF lacks a Tolstoy. What is more
> embarrassing by far is that IF lacks a Jamaica Kincaid and a Maya
> Angelou.
Why do you want to study IF if you have such a low opinion of it?
Pete
Adam Thornton
Thanks. I hadn't.
Downloading now.
Adam
S. John Ross
> The sad thing about it: this was the plan.
And not just a recent plan, either. The Trilateral Commission has been
cooking it up for years, now, based on inscriptions held in a secret
Masonic temple in Germany on the orders of Adam Weisshaupt. It would
have been put into motion earlier, had not key elements of I7
technology vanished in the raid on the Martian relics used to power
the emergency generator at the Pentagon. It took five Skull & Bones
members to perform the necessary rituals to re-conjure the items, and
a deal with the Space Dolphins that our children and grandchildren
will pay for, dearly, at the Time of Reckoning.
But by then I figure we'll be on I8, so, meh.
steve....@gmail.com
> > The sad thing about it: this was the plan.
>
> And not just a recent plan, either. The Trilateral Commission has been
Heh, yes I seemed to imply a conspiracy, but in fact I meant to say
something quite contrary: of course Emily did not intend to create
that which she described as a "steel-cage deathmatch." The fact that
she did so (at least, in the minds of many I7 true-believers) was more-
or-less accidental, and I'm sure counter to her better judgment.
"The plan" was extremely limited in scope, and very poorly thought out
indeed. It was a program of nasty rhetoric, aimed generally against
any criticism (legitimate, illegitimate, friendly, hostile, academic,
pedestrian, etc.); "base defensiveness" is probably the best
expression for it, although the rhetorical shinnanagins were highly
sophisticated.
There was a plan implied by mislabeling honest criticism a
"deathmatch," but that plan was largely unintentional, just as it was
ignorant and counter-productive. The lesson of behaving unethically is
that you can't then control the result. Emily meant to squirm out of
criticism, but I'm sure she did not really intend to polarize the
community and inspire hatred. (Well, perhaps she did, for a moment,
but again, it wasn't a well-thought-out plan.)
Adam C.
> Heh, yes I seemed to imply a conspiracy, but in fact I meant to say
> something quite contrary
and yet there was a masterplan
> "The plan" was extremely limited in scope, and very poorly thought out
> indeed.
indeed, and yet
> the rhetorical shinnanagins were highly sophisticated.
there was no conspiracy, but
> There was a plan implied by mislabeling honest criticism a
> "deathmatch," but that plan was largely unintentional,
which, accidentally, is an oxymoron
> The lesson of behaving unethically is that you can't then control the
> result.
That's a thought whose triteness is matched by its sententiousness.
> Emily meant to squirm out of criticism,
And you know Emily's unspoken intentions exactly how?
> but I'm sure she did not really intend to polarize the
> community and inspire hatred. (Well, perhaps she did, for a moment,
> but again, it wasn't a well-thought-out plan.)
You have a mental itch. Please scratch it somewhere else.