Inform 7; TADS 3 -- Survey says ...
Jeff Nyman
describe here is just one group that's working with one person (me), all of
whom have tried to keep some stranger value to textual IF. In short: nothing
I say should necessarily be used to draw conclusions outside of the limited
context in which it's presented. I know everyone already knows that but
sometimes the language wars erupt among even the most benign of
circumstances.
The original plan for the next class (which gets underway 14 April) was to
write a story in both Inform 7 and TADS 3. The thinking was that we could do
a bit of a comparative study between the two.
However, as the days got closer to starting here, I started to get a little
nervous about this approach. I felt we would spend too much time focusing on
the mechanics of the languages, learning how to do one thing well in one
language and then translating that to another language. Given the
differences in the language, you wouldn't just want to a direct translation,
though. Rather, you'd want to use the strengths of the language to do the
technique well *for that language.* I just worried we'd get too distracted
by that.
My group agrees. And I should mention, at this point, that this group is
composed *only* of most of the writers from the first group. The strict game
players/writers are not in this round.
So, it came down to choosing a language, which was the challenge I put to my
class.
There was a fun debate on this and the consensus was that, in some ways,
people wanted to stick with Inform 7 because they saw it as at least trying
to promote a more storytelling approach to textual IF .... BUT .... they
also indicated that TADS 3 seemed the most viable choice. Interestingly,
even though not actively *promoting* a storytelling approach, it was felt to
be more amenable to it.
The reason I even bring this up is that in looking at past threads, I can
see there's been debates here and there regarding which system is "better"
or which system is more in line with the phrase "so easy my [grandmother |
idiot brother | drunk friend | etc] could use it" or what system is "more
effective" because it uses X instead of Y (with the implied "only a moron
would want Y" usually lurking in the background).
So I thought it might be interesting to hear the rationale of a group that,
in many ways, approached their viewpoint differently than perhaps many
people here.
:: General Rationale ::
As far as rationale: everyone just found it easier to conceptualize stories
around objects. They felt that Inform 7 was a viable choice in a lot of
ways, but that the conceptualizations were ultimately focused on rules,
which was a harder mechanism by which to create narrative because it kept
you focused on the implementation model rather than on the actual objects.
Here they weren't talking about the Before, Instead, After rules but rather
then notion of "rule for writing a paragraph about" or having constructs
like "rule for deciding the concealed possessions of containers" and things
along that nature.
How I related this to my own software development background is simply that
software is a codification of a huge set of behaviors. So you have a
structure in place that basically reduces to: if *this* occurs, then *that*
should happen. Of course people can fairly easily visualize individual
behaviors, but people have a lot more difficulty visualizing large numbers
of sequential and alternative behaviors. So the system of reasoning by which
these are laid out becomes pretty important. (More on the "system of
reasoning" later.)
: Messages, Properties -- On Objects :
As one example, without exception, everyone in my group liked having a
series of "messages" they could plug into, such as:
notWithIntangibleMsg
notImportantMsg
cannotTakeMsg
cannotMoveMsg
They liked how these were "wrapped up" (encapsulated, for those of us in the
know) in specific objects that they could relate to as story objects.
Everyone also liked the simple to read binary values for various properties
on objects:
isAmbient
noLongerHere
Or text values on consistently structured properties:
roomFirstDesc
initSpecialDesc
What everyone doesn't end up liking are constructs like this:
After printing the name of a container while looking: omit contents in
listing.
Instead they would rather have something like this ...
isListedInContents
... and have that property on a defined object or a defined class with a
simple "yes"/"no" (true/false) value. Note that this wasn't just a reaction
to a "natural language approach" but rather a reaction against having a
structure that forced them to place the behaviors outside the thing doing
the behaving. (So far my group is basically just rehashing the arguments
that probably led to object-oriented programming in the first place.)
: So, no rules? :
With the exception of scenes and relations, it was found that the rules
structure in Inform 7 was too cumbersome to allow thinking of a story (as
opposed to a game, with some story around it). A good example was setting up
something like this:
"The freezing solid rules have outcomes stop action processing (failure),
continue action processing (success), and no decision (no outcome -
default)."
Everyone could see the power of that kind of ability but it just got too
distracting from the story itself. Interestingly, though, even though TADS 3
requires various code constructs to handle things like this, I found that
these were accepted better because all of the code was similar. What I think
I traced this to was simply that, from a conceptual standpoint, people
weren't jumping from a sort of "natural-ish" natural language to a more
"code-ish" natural language. It was a consistency of style that seemed to
help. (This goes to the notion of the "readability" of the source; more on
that below.)
: The World Model :
A major element that everyone likes with TADS 3 (and that they think will
make the upcoming class easier) is the extensive world model along with the
idea of multiple inheritance. They saw a lot more plotting possibilities
when you could treat objects (and that definitely includes characters) as
composites of various entities, allowing for a world that responds more
dynamically to various elements that must happen as part of the plot. The
idea of mix-in classes was also readily accepted by the group as allowing
them to be a bit more dynamic. A major plus that my group liked was the
templates. They like the idea of being able to craft templated structures
for types of objects and have the source itself look very uniform. (This
gets into that "readability" thing again.)
Some of this also has to do with how easy everyone seems to perceive it to
be to modify just about any aspect of the "system" by which they pretty much
mean the library. It's not certain how much or how little this will matter
but the ability to massively alter parts of the library, on demand through
simple modification, was seen as a selling point since we're not sure what
may need to be done to accomodate a more narrative style with plot
management aspects.
Everyone cares quite a bit regarding how much or how little you can deal
with what they came to understand as "disambiguation" and the extent to
which you can delve into every aspect of the back-end library to achieve
various narrative effects by changing how and when the system itself
responds to various actions, whether implicit or explicit.
So, after some questioning, what it came down to was the writers felt the
object-based library with an object-oriented language plus the extensive
world model in the ADV3 library would serve as a better "writer's toolkit"
that would let them focus on writing their story rather than on what they
called "ancillary" elements (like sorting rules into rulebooks or things of
that nature). They also felt that TADS 3 offered a better way to extend that
"writer's toolkit" in relatively easy ways.
--- Interlude Start ---
Something to understand: this group isn't concerned with a lot of things
that might make someone steeped in textual IF choose Inform. They don't
really care about portability. The audience they are mainly looking at is
the aggregate book reading public, which means their focus is mainly on
Windows and Mac users. (That's not to say Linux/Unix users don't read books,
of course! Rather, just to say, that the audience they are targeting is
probably much more likely to have Windows or Macs.) Secondary to that,
however, was something I mentioned as a result of the first go-around: they
weren't very concerned about "flashy" features. They didn't care about nifty
text effects. So even if the focus is on various interpreters on various
platforms, the focus they want is on the words and the story: not on the
interpreter itself nor on the effects the interpreter is capable of
displaying. That means as long as the interpreter (whether on Windows, Mac,
Linux, whatever) could display the story text, they didn't really care about
anything else, which meant that Inform's portability to various platforms
along with most of the features, didn't matter as much. Even if TADS is
ported as "text-only" they were pretty much okay with that
This being the case, there was some concern that perhaps TADS couldn't even
be ported all that well. I saw a discussion here about the Amazon Kindle and
this came up among my group, as writers are very interested in this
technology although they feel the Kindle would have some way to go to make
it easy to interactively read a textual IF story, rather than passively read
a static fiction story. Given their increasing programming knowledge, they
would be less concerned if they saw a TADS interpreter in Python or Java or
something along those lines. But, on the whole, no one really saw a focus on
solely Mac or Windows being anything that would significantly impact the
intended audience as long as the story itself could be "played" on those
systems.
Further, this group doesn't have any sort of nostalgic link with textual IF
history. They don't care that Inform uses something called a "Z-machine"
that some company called "Infocom" once used a variation of. (They often
found the Z-machine "cumbersome" -- their words -- anyway and weren't too
thrilled with the works of "Infocom", at least in terms of story. So for
them, these most definitely weren't selling points anyway.) What they care
about is how the textual IF system allows them to conceptualize a story and
then put that story to form, with a particular emphasis on the ability and
relative ease to conditionalize text without making the text in the source
massively difficult to read
--- Interlude End ---
: Readability and Context :
That last point in my interlude speaks to the "readability" I kept bringing
up.
Perhaps not surprisingly, everyone found Inform 7 was nice with it's natural
language -- but they found that the use of tables, of various rules all over
the place, and the use of convoluted [if]...[otherwise]...[end if]
structures in strings of text made source that was ultimately very difficult
to read. They weren't interested so much in others (writers, players,
readers) reading their code; rather, they looked at the source code as
successive series of drafts that they need to be able to easily parse over.
Now keep in mind: these people *aren't* programmers. But they still find it
much easier to look over and conceptualize their TADS 3 source rather than
their Inform 7 source. At first I was a bit surprised but I suppose this
isn't all that surprising -- or at least revelatory -- in the "how humans
cogitate" department because it's actually very much in line with a lot of
research into how people categorize objects, people, and actions via
ontological templates. Those ontological templates have had a massive effect
on how we, as a species, have evolved, particularly in terms of how we have
developed a "storytelling" ability.
Separation of knowledge of the story from implementation of the story is
being seen as very important; more than I apparently realized. In other
words, if the writer/author knowledge is "transcribed" in such a fashion so
as to closely mimic the implementation (which the natural language is felt
to do) then the focus is more on writing source than on writing a story. In
other words, TADS 3, it is felt, (or, rather, a "traditional" programming
structure), forces people to think about the story more --- and here's the
key point --- when you really start to get into the plotting and narrative
elements. It's felt that Inform 7 does a much better job of starting you off
and allowing you to freethought ideas and prototype concepts. But when it
comes down to the brass tacks, TADS 3 has carried the day.
Also, everyone sees the source text as their "domain knowledge" in terms of
their story. The domain knowledge should, in a very real sense, become a
system of reasoning. (I mentioned that earlier.) Where the interactivity is
seen to come in is when the system allows the answering of this question at
various points: "At this point, in this process, given this information,
what action(s) should be taken?"
Now, you'd probably think that a rules-based approach would be somewhat
amenable to that very thing. However, after a lot of conversations, I'm
realizing that everyone is implicitly rephrasing that question as such: "At
this point, in this process, given this information, what action(s) should
be taken **and what objects should handle these actions**?"
:: Some Final Notes ::
I think one other thing is important to note here:
My group *does not* think that Inform 7 is not capable of allowing authors
to write story-driven textual IF.
My group *does not* think that TADS 3 is inherently better at allowing
authors to write story-driven textual IF.
My group *does not* think that natural language programming is necessarily a
bad thing, nor do they think object-oriented is the answer to life, the
universe, and just about everything.
What it really boiled down to was the conceptual focus on writing that they
felt could be achieved with one system or another.
This matches a little of my thinking wherein I did not want to get into some
point-by-point comparison of the languages and how to implement
such-and-such in both or how difficult or easy that was perceived to be. So
the point here is that this decision was not reached via worship of one
language just because of its pedigree; nor was the decision reached as a
back-reaction against the perceived worship of one language. The decision
was not tainted by aspects of textual IF's history.
If I had to boil the decision down to an operational question that everyone
had to ask, I think it came down to this:
"As a writer, who wants to write a story that happens to have interactive
elements to it -- which system do I feel will most comfortably allow me to
do that and provide for the necessary open-ended experimentation, with the
fewest limitations, that this will ultimately entail?"
So I hope my caveat at the beginning takes on better context now, rather
than sounding like a desparate plea to not start a language war. The
situation we have here is...
(1) a particular group of 'popular fiction' writers, ...
(2) who want to approach textual IF with a story-writing mindset as primary,
...
(3) who feel the techniques and practices of writing static fiction could be
applied to textual IF, ...
(4) who feel that a vast potential -- and largely untapped -- audience
exists for such works, and ..
(5) who do not have any substantive past history with textual IF, either in
terms of playing it or writing it.
Just by the nature of that targeted grouping and set of motivations, I felt
the conclusions were at least worth mentioning while admitting that they
are, in the grand scheme of things, not necessarily indicative of anything.
- Jeff
Andrew Plotkin
> However, after a lot of conversations, I'm
> realizing that everyone is implicitly rephrasing that question as such: "At
> this point, in this process, given this information, what action(s) should
> be taken **and what objects should handle these actions**?"
But never "which verbs should handle these actions"?
This is where I see something going genuinely strange in these
discussions. While dispatch-by-object (or select-by-object, however
you want to think about it) is the common case in IF design, I don't
think it's *so* overwhelmingly common that dispatch-by-verb would
never even comes up as a concept. And in a group of non-programmers,
I'd think that dispatch-by-object would be the *less* intuitive
approach. You'd have to explain it by analogy: *rather than*
associating the action code with the verb, you associate it with the
object that it's acting on.
So why am I wrong?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Making a saint out of Reagan is sad. Making an idol out of Nixon ("If the
President does it then it's legal") is contemptible.
Andrew Plotkin
Here, Jeff Nyman <jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
>
> What everyone doesn't end up liking are constructs like this:
>
> After printing the name of a container while looking: omit contents in
> listing.
>
> Instead they would rather have something like this ...
>
> isListedInContents
>
> ... and have that property on a defined object or a defined class with a
> simple "yes"/"no" (true/false) value.
Imagine that I6 was extended to support divided object declarations:
Object thing
with description "Shiny.",
listed_in_contents true;
could also be written
Object thing
with description "Shiny.";
! ...lots of unrelated code...
Object thing
with listed_in_contents true;
(This would be pretty simple to define as a language change, although
actually putting it into the current I6 compiler would be a vast
headache.)
Do you think this would "infect" I6 with the aspect of I7 that your
students disliked?
(Experiment could be phrased in terms of T3, but I6 is what I'm
familiar with.)
Jeff Nyman
news:fs97b6$6m7$2...@reader2.panix.com...
>
> But never "which verbs should handle these actions"?
The verbs are wrapped up in the action with the object, I guess.
In other words, the conceptualizing seems to be like this:
Object-In-My-Story
Player can try to take it.
Player can attach things to it.
Player can try to eat it.
So it's not that the verb never comes up; rather, it just is conceptualized
in terms of the object being dealt with.
Where I found people really dealt with this better is when you consider
actions like PUT HAT IN BOX and then conceputalizing how the HAT or the BOX
might want to deal with that PUT action. Or ATTACH ROPE TO JOE, for example,
where, again, people could imagine how JOE (the object) would react to being
attached to (and having the code in place accordingly) or how ROPE (the
object, again) would handle being told to attach to something. This was even
the case with sensory events, such as when something could be "seen but only
dimly" or something like that.
This was even moreso the case when we got into conversational topics or the
way a plotting tool would handle how conversations or actions were then used
to further the plot.
So ...
> You'd have to explain it by analogy: *rather than*
> associating the action code with the verb, you associate it with the
> object that it's acting on.
People seem to respond better to your latter situation there (associate it
with the object that it's acting on) rather than a situation where you think
in terms of code-with-verb. I don't necessarily pretend to understand all of
the reasons for this, although I do plan on working through this more.
> So why am I wrong?
I'm not sure you're wrong about anything. I don't so much think there's a
"right" necessarily. I'm just basing this on what I'm being told and what
I've observed. That's also why I was somewhat careful to delineate the
nature of the selection process here (in terms of the people involved)
because it very well may be presenting a skewed vision. ("Skewed" here
relative to the "mainstream" textual IF community, without any thought that
one view or the other is "right" or "wrong.")
- Jeff
Mike Roberts
> Here, Jeff Nyman <jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
>
>> However, after a lot of conversations, I'm
>> realizing that everyone is implicitly rephrasing that question as such:
>> "At
>> this point, in this process, given this information, what action(s)
>> should
>> be taken **and what objects should handle these actions**?"
>
> But never "which verbs should handle these actions"?
>
> This is where I see something going genuinely strange in these
> discussions. While dispatch-by-object (or select-by-object, however
> you want to think about it) is the common case in IF design, I don't
> think it's *so* overwhelmingly common that dispatch-by-verb would
> never even comes up as a concept. And in a group of non-programmers,
> I'd think that dispatch-by-object would be the *less* intuitive
> approach.
I don't know; I think dispatch-by-object has a certain intuitiveness that
comes out of the structure of the writing process - simply in that the
physical objects are what you mainly concern yourself with when you're
writing a game. You (mostly) don't write verbs/actions, since most of them
are pre-defined. So if you're looking for a place to put a handler for an
action/object intersection, the thing that's closest at hand is the object.
Granted, the I7 approach removes "looking for a place" as an actual language
requirement, but I can imagine some people might still prefer a degree of
proximity anyway, just for the sake of tidiness. If you're going to group
the code with the object, it probably feels most natural to cast it in terms
relative to the object.
Also, I'm not sure that the OOP conceit of action-on-object is really so
foreign to the uninitiated. Most people seem to get the idea pretty quickly
when it's explained - in fact, most people just need a couple of examples to
pick up on it. I think the big reason OOP has been relatively successful
(as a general programming tool) is that it's a pretty good fit to the way
people naturally think, at least some of the time. Heaven knows it's not a
good fit to the real world - the macroscopic world is fuzzy-edged and
endlessly divisible and re-combinable, and that's to say nothing of the
*really* weird business when you divide things finely enough. (Which is
why, I think, OOP has always been an imperfect tool for IF.)
--Mike Roberts
Jeff Nyman
> As a separate question -- a thought experiment, but maybe useful:
>
So basically it's like partial classes in C# or something? In other words, I
can break up the declaration of my object (or, really, class) over multiple
places in my source. Is that what you're basically saying?
I'm missing the point of your example here, I think. By way of example,
here's what I see people respond well to (pseudo-code-ish):
Class Container
contentsListed = true;
Then (for a specific object):
Object Bucket class Container
contentsListed = false
describeContents() { ... some logic ... }
;
So everything is wrapped up in the object but, more importantly, visibly so.
It's the visible structure of the source that seems to matter. I say that
because a language can have something like that behind the scenes (thus
being object-based) but not programmatically used in that fashion (thus not
strictly object-oriented).
Incidentally, I found my students had issues very similar to programmers
I've met who had issues when they used something like Ink
(http://wiki.type-z.org/index.php?n=Projects.Ink).
> Do you think this would "infect" I6 with the aspect of I7 that your
> students disliked?
I don't think so, but to be honest, I'm not sure because it seems you're
suggesting to break up the class into two distinct sections (sort of like
the partial classes I mentioned). Whereas what I'm finding people prefer is
a class that contains all of its logic in one place. Then objects can have
their own logic, of course, but everything that can happen to or be done
with that object has code that is placed in the object itself.
- Jeff
Khelwood
<jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
> "Andrew Plotkin" <erkyr...@eblong.com> wrote in message
I think the I6 model was pretty close to what I would expect
intuitively -- standard behaviour is attached to actions, not to
objects, but exceptional behaviour is attached to objects. The
behaviour "move a thing from inventory to location" of "Drop" is built
into DropSub because that's what drop means. Whereas a ming vase
shattering when dropped is a quirk of a particular object, so it is
attached to the ming vase object.
But then in I7 you attached such things to neither, but to a slightly
nebulous thing called a rulebook.
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>This is where I see something going genuinely strange in these
>discussions. While dispatch-by-object (or select-by-object, however
>you want to think about it) is the common case in IF design, I don't
>think it's *so* overwhelmingly common that dispatch-by-verb would
>never even comes up as a concept. And in a group of non-programmers,
>I'd think that dispatch-by-object would be the *less* intuitive
>approach. You'd have to explain it by analogy: *rather than*
>associating the action code with the verb, you associate it with the
>object that it's acting on.
>
>So why am I wrong?
Intuition says to me that it's because you create new objects one or two
orders of magnitude more frequently than you create new verbs. Your
verb repertoire is much more limited in general than your object
repertoire: viz. the Marine Corps' motto, "if you can't eat it or screw
it, piss on it." Perhaps some day I shall write _Stiffy Makane: Semper
Fi_, in which those are the only three verbs available. With synonyms,
of course. I'm not a cruel man.
Adam
puzzler
achieve "professional" quality games.
Nevertheless, I can't imagine recommending it for non-programmers. It
is *very* difficult. It seems like it's going to be straightforward,
because so much behavior is encapsulated in the existing library
classes. But then, something doesn't work the way you expect it to,
or you want to alter some default message, or... and before you know
it, you have to read through and understand library source code to
figure out what's going on. You really have to be a programmer to do
that. The TADS library is well-designed, but it definitely has its
share of quirks. And of course, you need to know a certain amount of
programming to write any action code, because everything is expressed
with a programming syntax.
But good luck, and let us know how your next class goes! I follow
your reports with interest.
--Mark
greg
> So why am I wrong?
A tree of objects is easy to visualise and provides a
fairly obvious place to put most of the pieces of code
one might want to write.
It also compartmentalises things in a way that makes
it easier to reason about the way the various parts
will interact.
Humans deal with complexity best when it can be
organised into some kind of hierarchy. Objects
encapsulating methods provide an organisational
structure, whereas an amorphous collection of rules
doesn't.
The encapsulation breaks down sometimes, such as
when an action depends equally on two or more objects.
But that doesn't happen all the time -- very often
plain single-dispatch is all you need. Yet I7
forces you to use rule-based dispatch all the time.
While a rule-based system may be a valid technical
solution to the problem, it doesn't provide any
organisational principle that helps you reason about
the system. So from a human-factors viewpoint, it's
a poor solution.
People absorb new ideas better when they're presented
in concrete rather than abstract terms. So I don't
think we should be surprised that a group of non-
programmers found Tads, with a clear structure to
visualise, easy to latch onto, but when faced with
I7's nebulosity, felt themselves all at sea.
--
Greg
Jim Aikin
> I firmly believe that TADS3 is the tool of choice to most easily
> achieve "professional" quality games.
>
> Nevertheless, I can't imagine recommending it for non-programmers. It
> is *very* difficult. It seems like it's going to be straightforward,
> because so much behavior is encapsulated in the existing library
> classes. But then, something doesn't work the way you expect it to,
> or you want to alter some default message, or... and before you know
> it, you have to read through and understand library source code to
> figure out what's going on.
I'm inclined to agree. I also agree (with greg) that object orientation
seems to fit the way I think. I like TADS a lot, and I7's rules-based
approach doesn't appeal to me. But the first time I tried to learn T3 I
was baffled by the extensive use of macros and templates. OTOH, I
already knew how to write simple programs in C++, so this additional
level of syntax seemed like just a bunch more stuff to learn, and it
wasn't clear to me (as a hobbyist programmer) what was going on. For a
complete non-programmer, macros and templates might make it easier to
get started.
On balance, Jeff's experience tilts me a bit in the direction of
recommending TADS to non-programmers, which I might not have done
previously. The initial learning curve is steeper than with I7, no
question (at least, for people like me, who are too impatient to work
their way through the Getting Started Guide and the Tour Guide!), but
once you get over the hump, I suspect that non-programmers might find
TADS just as manageable as I7, and more intuitive in the long run.
--JA
Kevin Forchione
news:Q7WdnSFSPb53snXa...@comcast.com...
> "Andrew Plotkin" <erky...@eblong.com> wrote in message
> news:fs97b6$6m7$2...@reader2.panix.com...
>>
>> But never "which verbs should handle these actions"?
>
> The verbs are wrapped up in the action with the object, I guess.
I suspect this has to do with our predelection toward perceiving object
states. In a sense, an action is the delta representing the change between
one entitiy state and another.
But it may have much to do with our own psychological conditioning. Some
cultures observe and place importance on the foreground of a picture, others
take in the background with equal importance.
In a sense, the verb, the action, is a description of the change of state
(even "wait" which appears to take "no" action produces a change of state
("time passes...") or at very least produces a comic response ("wait 0"
"time doesn't pass")
--Kevin
eric...@hmc.ox.ac.uk
> On balance, Jeff's experience tilts me a bit in the direction of
> recommending TADS to non-programmers, which I might not have done
> previously. The initial learning curve is steeper than with I7, no
> question (at least, for people like me, who are too impatient to work
> their way through the Getting Started Guide and the Tour Guide!),
Since I suspect you're probably not alone in feeling that way about
Getting Started in TADS 3 and the Tour Guide, I've been working on an
alternative introductory manual, "Learning TADS 3", which takes a
rather different approach. If you're interested you can check it out
at:
http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm
Jeff may also find it of interest to his group, if they're going to be
working with TADS 3.
Bear in mind, though, (a) that this is still a draft (though Mark
Engleberg has been doing a great job of pointing out typos and other
errors to me, and the ones he's caught have now been corrected) and
(b) that it's targeted at a future release (3.0.16) of TADS 3.
-- Eric
eric...@hmc.ox.ac.uk
> Nevertheless, I can't imagine recommending it for non-programmers. It
> is *very* difficult.
I suppose that depends on what you mean by "non-programmers". If you
mean people who are unwilling to become proficient in using a
programming syntax, then what you say is of course true, but it's not
so obviously true for people who are willing to learn (everyone has to
start somewhere). But of course TADS 3 is going to be considerably
easier to learn from scratch for someone who is already familiar with
a similar programming language.
> It seems like it's going to be straightforward,
> because so much behavior is encapsulated in the existing library
> classes. But then, something doesn't work the way you expect it to,
> or you want to alter some default message, or... and before you know
> it, you have to read through and understand library source code to
> figure out what's going on. You really have to be a programmer to do
> that. The TADS library is well-designed, but it definitely has its
> share of quirks.
That's all very true, with the caveat above about what "be a
programmer" means. Provided it means no more than "be comfortable with
the syntax of the TADS 3 language (which people with prior programming
experience are more likely to be faster)" then I'd agree. It certainly
is the case that once you want to do something non-standard then
you're going to have to figure out some part of the library source
code, and that's often not a trivial task (but for the beginner it's
likely to be untrivial just as much through lack of familiarity with
the structure of the library source as through trouble understanding
TADS 3 code per se).
It's another question whether doing something non-standard is easier
or harder in TADS 3 than in any other IF system of comparable power.
To change the behaviour of the TADS 3 library you do indeed have to
figure out what method or property to override on which class, but
then to change the behaviour of the I7 library (say) you may have to
figure out which rule to replace in which rulebook, and which of these
is easier will depend in part on what exactly it is you're trying to
do. Either way what you're doing requires programming expertise of
some sort or another, although I accept your point that having prior
coding experience with a conventional programming language is going to
make TADS 3 seem a bit less difficult.
That said, I wonder if the principle difficulty for TADS 3 beginners
is really the need to read and write program code or whether it's more
the sheer size and complexity of the library, which is likely to seem
utterly daunting at first. Or to make a complementary point, it's
often easy enough to do what you want to do in TADS 3 once you know
how; the difficulty (especially but not only for beginners) is to work
out how. One way to help with this is to identify common tasks that
people are having difficulty with them and write them up as articles
in the Technical Manual - of course this can't help with everything,
since inventive game authors will always want to attempt something
unusual, but it can certainly help cut down on the difficulty
experienced with some of the more common tasks (customizing various
messages, for example).
> And of course, you need to know a certain amount of
> programming to write any action code, because everything is expressed
> with a programming syntax.
That's true, of course, but then I wonder if it isn't equally true of
any comparable IF system. In TADS 3 you have to write action code in
dobjFor() and iobjFor() blocks on the objects concerned; in I7 (say)
you have to write it in the appropriate rules; I7 has a different
programming syntax from TADS 3, but it still has a programming syntax.
One may think that TADS 3's syntax would look scarier to people
without prior programming experience, but I don't actually have any
hard evidence one way or the other, and Jeff's experience with his
group may suggest otherwise.
That said, while Jeff's post makes it clear enough why his group take
the view they do, and their reasoning all makes perfectly good sense
to me, his findings are probably not what I would have instinctively
predicted, which perhaps suggests we share not dissimilar instincts
about how people without prior programming experience are likely to
react to TADS 3; but maybe Jeff''s findings suggest that our instincts
are misleading?
-- Eric
Jeff Nyman
"puzzler" <mark.en...@gmail.com> wrote in message
news:28c409ce-25a8-41fc...@c19g2000prf.googlegroups.com...
> Nevertheless, I can't imagine recommending it for non-programmers. It
> is *very* difficult.
My only caution with statements like these is that they assume something is
difficult for everyone to the same level. Any programming language can be
difficult for non-programmers just as any new spoken language can be
difficult for people who have never spoken it before and are trying to learn
it. By this logic, a non-programmer could never learn a programming language
because they can all be considered difficult, particularly if you're a
non-programmer.
That, of course, is being simplistic, I realize, because there are some
languages that can be considered to have a bit of a lower barrier to entry.
Good examples might be Ruby compared to Java or Visual Basic compared to
C++. Or TADS 3 compared to Inform 7. So both languages were perceived as
difficult in their own ways, but it also came down to a perceived level of
what was ultimately possible or allowed with the language, wherein TADS 3
was seen to offer more possibilities, even if those possibilities were not
used initially.
I should also add that I was not so much "recommending" this for my group;
rather, they more recommended it for me. We had looked at both TADS 3 and
Inform 7 before so this was coming from some knowledge of what each IF
system entailed. Further, I should add that a large part of the basis for
this choice was the perceived difficulty of Inform 7 as compared to that of
TADS 3 when it came down to conceptualizing how everything in the code was
working together. So, in this particular case, the "very difficult" was
applied to Inform, not to TADS -- even though recognizing that TADS
certainly has its fair share of complexity.
> classes. But then, something doesn't work the way you expect it to,
> or you want to alter some default message, or... and before you know
> it, you have to read through and understand library source code to
> figure out what's going on. You really have to be a programmer to do
> that.
That's true, but the same applies to any programming language, including
Inform 7. (Maybe not so much in terms of reading library source code with
Inform 7, but perhaps in terms of reading extensions or reading through the
Index to find out what wording you can use to phrase things or what rulebook
you have to insert a rule into.)
> The TADS library is well-designed, but it definitely has its
> share of quirks. And of course, you need to know a certain amount of
> programming to write any action code, because everything is expressed
> with a programming syntax.
Very true. One of the things that also served as the basis for the decision
is that "everything is expressed with a programming syntax" was more
*consistent* with TADS 3. I can't emphasize that enough because it came up
from just about everyone in my group. What I mean is that once they learned
the syntax, it could be consistently applied. One issue people had was
jumping from the "natural-ish" natural languge to the "code-ish" natural
language, such as when handling blocks or having to construct things as
tables, or the potential "fear" of having to jump into I6 code. With TADS,
everything is in the same syntax. Note, however, that this wasn't seen as a
"bad thing" of Inform 7 necessarily; it was just seen as an element that was
impeding our focus.
- Jeff
Jeff Nyman
news:a7a96086-aac4-4864...@s19g2000prg.googlegroups.com...
> But then in I7 you attached such things to neither, but to a slightly
> nebulous thing called a rulebook.
Yes, this was consistently a problem people had in terms of conceptualizing
what they were doing and what was happening to what things and when was it
happening.
This was never seen as insurmountable but it just wasn't found to be
effective for building up a story-driven game. It wasn't even seen as all
that useful for a non-story-driven game, at least over and above other
methods.
We did experiment a little bit with the rules.t extension in TADS (which has
since become a rulebook library) so we could do a little experimenting with
the idea in TADS and it was found there were certain very limited conditions
where a "rulebook" could make sense but, even then, we often found other
ways we could do the exact same thing without worrying about rulebooks
simply by putting logic on objects.
The only time that latter aspect fell down (and where rules were found to be
useful) is when you had a condition that you wanted to apply globally, not
just for an object. Even then, we didn't need to worry about rulebooks;
rather, we just create a specific rule as a type of object. However we also
found we could use a Story object that had a 'fuse' or 'daemon' on it that
still allowed everyone to conceptualize via some abstract object. People
were perfectly happy with abstract objects that existed to encapsulate story
elements rather than actions against a physical object.
- Jeff
Jeff Nyman
points, so I'll just indicate where they matched what I've observed...
"greg" <gr...@cosc.canterbury.ac.nz> wrote in message
news:64rf0cF...@mid.individual.net...
> Humans deal with complexity best when it can be
> organised into some kind of hierarchy. Objects
> encapsulating methods provide an organisational
> structure, whereas an amorphous collection of rules
> doesn't.
This was the major problem everyone I dealt with had. People do, as a
general rule, like to see an organizational structure that can be taken in
at a glance. Further, a conceptually referencable structure is often
important, which often means simply knowing where things are. When you have
objects, and if you apply a consistent dynamic to how you utilize those
objects, you can "know" where you would have put code to handle a certain
action. Even if you don't, the organizing principle virtually ensures that
there's only one or two places you could have reasonably done this.
> While a rule-based system may be a valid technical
> solution to the problem, it doesn't provide any
> organisational principle that helps you reason about
> the system. So from a human-factors viewpoint, it's
> a poor solution.
Yes. This is exactly speaking to the "system of reasoning" I mentioned
before and this does tie into our own brain development, starting when we
are toddlers. While we do utilize a series of rules-of-thumb generalizations
(that you could call "rules") we in fact conceptualize in relation to
objects around us and on how actions on an object will have effects.
"I push this ball, it goes away from me. But I push this ball and it stays
in place and when I kick it my foot hurts." In this case, the latter ball
may be bowling ball. We don't create rules for the class of balls. Rather,
we realize the world is made up of different kinds of balls and various
similar actions can be taken, but they have very different effects. We then
start to apply the organizational principle that allows us to categorize our
actions (verbs) on objects of certain kinds. Sometimes people assume this
means we are "rule-based" in our thinking but, in fact, we really aren't.
None of that, of course, necessarily says whether a given object-oriented or
rules-based structure is more or less effective in a programming situation,
but considering that the programming arena we are dealing with here is
speaking to story-telling to some extent and that speaks very much to how we
view the world and break it down. Writers, of course, are not sitting their
thinking "object-oriented" any more than they are thinking "rule-oriented."
But what I'm finding is that when people conceptualize stories as textual
IF, they do better when they can conceptualize as sets of objects that can
have actions applied to them and then report what happened to them when that
action was applied.
- Jeff
Jeff Nyman
news:gNidne_8E71JrHXa...@comcast.com...
> people naturally think, at least some of the time. Heaven knows it's not
> a good fit to the real world - the macroscopic world is fuzzy-edged and
> endlessly divisible and re-combinable, and that's to say nothing of the
> *really* weird business when you divide things finely enough.
That's true --- but now consider fiction. Fiction is not fuzzy-edged and
endlessly divisible, at least as a general rule. The author has a specific
structure to the world they are creating and characters act in certain ways
and expectations are set up. Too many violations of those expectations
actually cause reader upset.
So while OOP doesn't model the real world in all of its complexity, it's not
meant to, just as fiction is not meant to. Both serve as approximations of
reality that are good enough for a certain situation. I think that's
ultimately what my group responded to and, as you indicate, I think this is
why OOP has been successful as a general approach to programming.
> (Which is why, I think, OOP has always been an imperfect tool for IF.)
The only thing I can say is that I don't know that I would want an approach
(OOP, rules-based, or whatever) that truly tried to present all the "fuzzy"
aspects of the real world; that truly allowed all the complexity of the real
world. Part of why I read fiction is to have a constrained world; part of
why I play games is to have a constrained world. If I want all the
complexity and fuzziness of the real world, I can just turn off my computer
and go outside and deal with real people.
So is it an "imperfect tool"? Yes, I would agree, just as any such approach
or concept is imperfect for modeling the real world to every level of
detail. But that imperfect nature is what I think also makes it effective,
and not just with textual IF. What I think often matters is the organizing
principle that a given approach follows or allows, that in turn allows
people to model a domain of knowledge and thus utilizing a more-or-less
effective system of reasoning about that domain of knowledge. Here I'm
abstracting a bit from the story-telling aspect that my class was focused on
and conflating it with the other part of my career, which is teaching
testing and software development to IT professionals.
- Jeff
Jeff Nyman
news:f62d1fea-5ec2-472a...@h11g2000prf.googlegroups.com...
> Jeff may also find it of interest to his group, if they're going to be
> working with TADS 3.
In fact, I had come across this as part of the mailing list and had shown
this to the group as a way to help make their decisions, one way or the
other. One thing they also really liked where the examples provided. Another
aspect that helped was the source to "Mrs. Pepper's Nasty Secret." A lot of
potential was seen in TADS 3 just based on looking at the source code for
that game itself.
So thanks for providing these materials. They are extremely helpful to
getting people up to speed with TADS 3 and the combined set of manuals
(Getting Started, Tour Guide, Learning) as well as the library reference
provide a great set of materials at different levels that allow someone like
me to modulate the learning process.
- Jeff
Jeff Nyman
news:ec5b699d-bdcf-49ed...@e6g2000prf.googlegroups.com...
> To change the behaviour of the TADS 3 library you do indeed have to
> figure out what method or property to override on which class, but
And just to add some experiential data to this, I can say even my group was
perfectly comfortable with the idea of using the modify aspect to a class
and putting certain behaviors in place. Further the ability to have easily
referenceable properties applied to objects made conceptualizing a lot
easier for them.
> That said, I wonder if the principle difficulty for TADS 3 beginners
> is really the need to read and write program code or whether it's more
> the sheer size and complexity of the library, which is likely to seem
> utterly daunting at first.
More experiential data: with my group, it wasn't seen as daunting at all.
Certainly it was recognized there was a lot and it would take time to figure
out what to use when. The complexity was not lost on anyone. But that sheer
size actually lended comfort to the extensive nature of what was available.
Coupled with the perceived ease of modifying, this was seen as a huge plus.
> One may think that TADS 3's syntax would look scarier to people
> without prior programming experience, but I don't actually have any
> hard evidence one way or the other, and Jeff's experience with his
> group may suggest otherwise.
I don't think I'd be mis-stating things to say that people found TADS 3
daunting at first glance. But TADS 3 (the libary) was found as manageable
because it was broken into concepual "chunks." Once you knew what a
TravelConnector was, you could traverse "down" and conceptualize a Room.
Alternatively, you could take a Room and traverse "up" and conceptualize a
TravelConnector. Then properties were considered as the bark along this
tree, so to speak, which made it very easy for people to determine exactly
how something would operate.
That's not to say that issues were run into where it wasn't immediately
clear how to apply a given effect. But one thing I did find is that people
were able to generalize better once the solution was found. In other words,
they were more likely to be able to come up with their own solution later
when a similar problem presented itself. This often wasn't the case with
Inform 7 because it might be utilizing different aspects of the same
rulebook or another rulebook entirely, which my group found defocused them
and stopped up their efforts.
- Jeff
Andrew Plotkin
> Andrew Plotkin wrote:
>
> > So why am I wrong?
>
> A tree of objects is easy to visualise and provides a
> fairly obvious place to put most of the pieces of code
> one might want to write.
>
> It also compartmentalises things in a way that makes
> it easier to reason about the way the various parts
> will interact.
>
> Humans deal with complexity best when it can be
> organised into some kind of hierarchy. Objects
> encapsulating methods provide an organisational
> structure, whereas an amorphous collection of rules
> doesn't.
I wasn't asking why object dispatch is more intuitive than rule
dispatch. I was asking why object dispatch is more intuitive than
*verb* dispatch. In other words, verbs could be OO objects too
(although in I6 they aren't). How come nobody goes there?
Once I understand this, I will be in a position to make a rule-based
system more comprehensible. :)
(I know why *programmers* built OO IF around objects!)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
It's a nice distinction to tell American soldiers (and Iraqis) to die in
Iraq for the sake of democracy (ignoring the question of whether it's
*working*) and then whine that "The Constitution is not a suicide pact."
Jeff Nyman
> I wasn't asking why object dispatch is more intuitive than rule
> dispatch. I was asking why object dispatch is more intuitive than
> *verb* dispatch. In other words, verbs could be OO objects too
> (although in I6 they aren't). How come nobody goes there?
I'm not sure they don't go there necessarily, but they tend to conceptualize
around the objects.
For example, at the simplest level, you might ask people to realize that you
have methods for verbs that act on one object (or perhaps on two objects, in
a multi-object command). So I might have this (pseudo-code-ish):
----------------------------------------------------------------------
AttackVerb
verb = "Attack"
action() { ... logic for this verb ... }
----------------------------------------------------------------------
So here the verb AttackVerb is, in fact, a type of object. (Maybe it's
derived from the class Verb or something.) Then I might have a given class
of objects that respond to this verb:
----------------------------------------------------------------------
Class AllThings
doAttack() { ... logic for how AllThings respond to attack verb ... }
----------------------------------------------------------------------
Then I have a specific thing that I happen to want to respond differently to
this verb:
----------------------------------------------------------------------
Object MySpecificThing
doAttack() { ... specific logic for how MySpecificThing responds to
attack verb ... }
----------------------------------------------------------------------
Here MySpecificThing would of course be derived from AllThings. This is what
I find people respond very well to because they conceptualize in a way that
verbs (methods) manipulate nouns (objects). But the objects determine what
happens when the method is applied or, put another way, the noun
contextualizes and situates the verb.
Broadening this out a bit, I can say that in the programming world, I've
only found on emphasis on the verbs when you're dealing with a "service" of
some sort. So people think in terms of objects that have state (even if they
don't word it that way) and services that don't have a state. In that case,
the "action" (verb) *is* the service. In fact in SOA circles you find people
who talk about organizing their components around the verbs (the actions)
that the service has to provide.
Yet many others argue that while what the service ultimately *does* may be
an action (and thus a verb), the service *itself* can be considered an
object. And that can be called and dealt with by other objects, which
effectively means you still end up with people conceptualizing the verb as
part of the object. That's been my experience, at least.
- Jeff
Ron Newcomb
> TADS just as manageable as I7, and more intuitive in the long run.
(That "more intuitive in the long run" strikes me as an oxymoron.)
I've 3 short things to add to this thread.
1) Just because something is more intuitive than another doesn't mean
it'll also be more efficient to use, easier to modify, more powerful,
etc. And those latter things take more experience to measure
accurately.
2) There's sometimes a holy war in programming language design about
punctuation vs keywords. Some people like the conciseness of a
punctuation-heavy language and some like more English words in the
language. Both say their preference is easier to type. It seems
largely a preference thing.
3) Tads 3 is more mature than Inform 7, so I'm seeing an apples-to-
oranges comparison. Give I7 another year or three. It's growing from
the bottom-up, whereas T3 was designed top-down.
-R
Ron Newcomb
> dispatch. I was asking why object dispatch is more intuitive than
> *verb* dispatch. In other words, verbs could be OO objects too
> (although in I6 they aren't). How come nobody goes there?
When infants first learn language, why do they learn nouns
first? ::shrug::
Jeff Nyman
"Ron Newcomb" <psc...@yahoo.com> wrote in message
news:dcb1fc89-b123-44e8...@d4g2000prg.googlegroups.com...
> When infants first learn language, why do they learn nouns
> first? ::shrug::
It's actually a really deep and interesting question or, at least, leads to
a deep understanding of ourselves. There are many good studies on this very
thing. One is "24-Month-Old Infants' Interpretations of Novel Verbs and
Nouns in Dynamic Scenes."
A good book on this is "What's Going On In There? How the Brain and Mind
Develop in the First Five Years of Life" by Lise Eliot. Another is "How
Babies Talk: The Magic and Mystery of Language in the First Three Years of
Life." by Robert Golinkoff and Kathy Hirsh-Pasek.
Why I even bring this up is because these books touch tangentially on that
very human aspect of storytelling; of how we view the world and construct
stories from it. That, in turn, leads to information about how do the same
things as we grow older and, further, why we like to read stories of certain
forms and what we look for in stories.
So, in its own strange way, all this ties back to why I started on this path
in the first place since textual IF can, in one sense, be said to be telling
a story, assuming it's not just an "abuse" or a set of situations that are
hung together by puzzles rather than plot.
- Jeff
Jeff Nyman
> 3) Tads 3 is more mature than Inform 7, so I'm seeing an apples-to-
> oranges comparison. Give I7 another year or three. It's growing from
> the bottom-up, whereas T3 was designed top-down.
Here I would disagree -- but perhaps only a bit. Not with the "mature"
aspect, since that's somewhat the case but I don't think it's "apples to
oranges" except in the sense that *anything* can be said to be that. C can
be said to be the apple to Ruby's orange. SilkTest can be said to the orange
to WinRunner's apple. What ties them together are the fact that they are
programming languages. The fact that Ruby is much younger, as just one
example, than C does not mean it's an "apples to oranges" comparison when
you look at how to do things in the same language anymore than it's "apples
to oranges" to allow the study of filmmaking to inform the study of writing
static fiction.
That's not to say there are not differences but, rather, it's to avoid the
negative implication that you can't compare the one to the other, which the
phrase "apples to oranges" tends to conjure up. After all, people *do*
compare them. It's how they make choices. Inform 7 will never be as "mature"
as TADS 3 if all you do is measure by date of release. (Your older brother
is always your older brother, unless you get really tricky with fast rockets
and relativity.) But Inform 7, I would argue, is mature in its presentation
of approach: it's use of rules is established and well attested to. Further,
the system has been used to produce quite a few games.
The issues we are dealing with now spoke more to the operating assumptions
and principles that underlie the textual IF systems themselves: the
presentation of approach. What I actually like about Inform 7 and TADS 3 is
that they are almost *philosophically* different in terms of the approach
they promote and the style they allow. The programming language allows the
philosophy to be translated into action and that's ultimately where the
decisions are made. Inform 7 can change a lot as it grows as TADS 3 could
but how they are now suggests the philosophy they will tend to follow.
That still allows a vast area of change, of course, but if the change is
significant enough, you're almost talking about a new language anyway. For
example, I6 and I7 are quite different beasts. There's clearly the start of
a philosophical difference between then -- but there's the interesting
counterpart to this, which is that I7 ultimately becomes I6 at some level.
But, still, I think the philosophy is different enough that you can
practically treat them as separate languages. And so you can use that as a
basis for deciding whether to stick with Inform 6 rather than going to
Inform 7, even though Inform 6 is clearly more "mature."
So hopefully this doesn't seem like I'm dismissing your point. Rather, I've
just never been a subscriber to the "maturity" argument unless of the two
things being compared, one simply isn't "done enough" to make effective
comparison possible. If comparison is possible, then "maturity" may play
some part in the decision, but I don't think it's always the major aspect
that sometimes it's treated as.
Caveat: part of this also extends to my career, in another context, where I
often have to deal with perceptions of "maturity" for organization and
process based on the Capability Maturity Model and the assumptions that
often follow when comparing practices from one group or company to another;
the phrase "apples to oranges" often comes up in this context quite a bit as
well and while there's some truth to it, in its negative sense, there's also
benefit in realizing that: yes, one is an apple, one is an orange. So which
do you prefer? The very fact that they're different is the whole point: it's
what makes for the basis of a decision.
- Jeff
Kevin Forchione
news:PsqdnT8NVuGRmXTa...@comcast.com...
> That's not to say that issues were run into where it wasn't immediately
> clear how to apply a given effect. But one thing I did find is that people
> were able to generalize better once the solution was found. In other
> words, they were more likely to be able to come up with their own solution
> later when a similar problem presented itself. This often wasn't the case
> with Inform 7 because it might be utilizing different aspects of the same
> rulebook or another rulebook entirely, which my group found defocused them
> and stopped up their efforts.
I think the community has benefitted tremendously from these observations. I
do hope they are collected, perhaps on a webpage, so that future
development/developers may benefit from them overall.
--Kevin
Jeff Nyman
news:kFaGj.77677$497....@newsfe14.phx...
> I think the community has benefitted tremendously from these observations.
> I do hope they are collected, perhaps on a webpage, so that future
> development/developers may benefit from them overall.
Speaking solely for myself, that's definitely one of my plans. What I'm
currently doing is going through the various threads here and distilling
people's ideas and thoughts and examples.
Then, with this next class, the plan is to write up a document that
basically explains how we approached the idea of telling a story with, in
this case, TADS 3. That part is the "thinking about story" aspect. Then I'll
write up the process whereby we translated those ideas to the programming
language. Along the way, I plan on documenting our false starts or where we
had to revise (both code and story) in order to accomodate the textual IF
format.
My current plan is to sort of intersperse the "writing a story" parts with
the "coding a story" parts. I then want to have footnotes or endnotes or
something that will incorporate the ideas from some of the recent threads as
well as the observations of all participants in the class.
It's a two-pronged effort (which gives me two times to screw it up, I
suppose): (1) show how people mostly new to the conventions of textual IF
approach the medium; (2) show how people attempt to incorporate
practices/techniques of static fiction writing to textual IF.
At the very least, I hope this kind of (admittedly limited) experiential
data can at least serve as a way for people who *are* already familiar with
textual IF to think about it in a different context or at least with (or
from) a fresh set of eyes and minds.
- Jeff
Ron Newcomb
Well, I meant I7 is beta, with a feature set and documentation in
flux. T3 is done, no nails sticking out to snag clothing. But OK.
Kevin Forchione
"Jeff Nyman" <jeffnyman__@__NOSPAM__gmail.com> wrote in message
> We did experiment a little bit with the rules.t extension in TADS (which
> has since become a rulebook library) so we could do a little experimenting
> with the idea in TADS and it was found there were certain very limited
> conditions where a "rulebook" could make sense but, even then, we often
> found other ways we could do the exact same thing without worrying about
> rulebooks simply by putting logic on objects.
Having continued my own exploration with Tads 3 rulebooks, I came to similar
conclusions. Expanding the library extension to encompass more and more of
the library actions, it became more difficult to conceptualize how to
organize the rulebooks, and how to allow an author to customize and extend
the process.
Interestingly, the *chief* attraction for me of the Tads 3 rulebooks
extension was the consistency of the structure. Each rule/rulebook having
the same interface and limited control flow.
I recently abandonned my project of incorporating more and more of the
library in rules/rulebooks, in favor of exploring a list processing
mechanism written in Tads. The syntax of this "language" being lisp-like.
> The only time that latter aspect fell down (and where rules were found to
> be useful) is when you had a condition that you wanted to apply globally,
> not just for an object. Even then, we didn't need to worry about
> rulebooks; rather, we just create a specific rule as a type of object.
> However we also found we could use a Story object that had a 'fuse' or
> 'daemon' on it that still allowed everyone to conceptualize via some
> abstract object. People were perfectly happy with abstract objects that
> existed to encapsulate story elements rather than actions against a
> physical object.
Hmmm. At one time I was working on a project called storyguide that did
something like this. It's been some time ago, but the library extension is
at http://ifiction.lysseus.com/downloads/storyguide.zip, if you're
interested. It might bear looking into again.
--Kevin
Jeff Nyman
> Hmmm. At one time I was working on a project called storyguide that did
> something like this. It's been some time ago, but the library extension is
> at http://ifiction.lysseus.com/downloads/storyguide.zip, if you're
> interested. It might bear looking into again.
That, in fact, is exactly what we were looking at. In fact, we'll probably
look at that again this time around. Also, on 15 December 2006, I had put up
a small post entitled "TADS 3 : Using Rules and StoryGuide Together" that
detailed a little of how I used it; that thinking eventually was
incorporated into my first class.
- Jeff
Kevin Forchione
> So is it an "imperfect tool"? Yes, I would agree, just as any such
> approach or concept is imperfect for modeling the real world to every
> level of detail. But that imperfect nature is what I think also makes it
> effective, and not just with textual IF. What I think often matters is the
> organizing principle that a given approach follows or allows, that in turn
> allows people to model a domain of knowledge and thus utilizing a
> more-or-less effective system of reasoning about that domain of knowledge.
> Here I'm abstracting a bit from the story-telling aspect that my class was
> focused on and conflating it with the other part of my career, which is
> teaching testing and software development to IT professionals.
The iterative development and "maintenance" aspects of interactive fiction
development aren't trivial in this respect. An approach that facilitates
both aspects is perhaps *more* important than the ease of initial
implementation. In my own experience, the "quick and dirty" initial
implementation often results in an untenable long-term solution.
--Kevin
Nikos Chantziaras
>> once you get over the hump, I suspect that non-programmers might find
>> TADS just as manageable as I7, and more intuitive in the long run.
>
> (That "more intuitive in the long run" strikes me as an oxymoron.)
>
> I've 3 short things to add to this thread.
>
> 1) Just because something is more intuitive than another doesn't mean
> it'll also be more efficient to use, easier to modify, more powerful,
> etc.
You have to keep in mind that "powerful" means different things to
different people, and therefore no system can be "more powerful" overall
compared to some other system.
> 2) There's sometimes a holy war in programming language design about
> punctuation vs keywords. Some people like the conciseness of a
> punctuation-heavy language and some like more English words in the
> language. Both say their preference is easier to type. It seems
> largely a preference thing.
But it doesn't look like the main difference between I7 and T3 is how
many English words are in each language's vocabulary. The real
difference is in the expressions you form with its syntax. I7 reminds
me of my first Pascal programs when I was 12 years old: an awful lot of
"if-then-else" blocks. Well, OK, I guess that's the "rule based"
approach to programming, and it seems to make it easier to beginners to
dive in, but after a few months it becomes too limiting, tiresome,
repetitive and boring.
> 3) Tads 3 is more mature than Inform 7, so I'm seeing an apples-to-
> oranges comparison. Give I7 another year or three. It's growing from
> the bottom-up, whereas T3 was designed top-down.
Though there are advantages to both approaches, I'm not really sure that
I7 was designed bottom-up and T3 top-down. Or whether is actually
matters to the user; it's an internal implementation detail.
Jeff Nyman
> The iterative development and "maintenance" aspects of interactive fiction
> development aren't trivial in this respect. An approach that facilitates
> both aspects is perhaps *more* important than the ease of initial
> implementation. In my own experience, the "quick and dirty" initial
> implementation often results in an untenable long-term solution.
I would completely agree. This is definitely a part of what drove the
consideration.
Initial implementation was often felt to be much easier with Inform 7. You
could have a couple of rooms and a few things in them in the span of just a
few seconds, with very little apparent structural code or framework needed.
The same could be argued with TADS 3, to an extent, but certainly there's a
little more cognitive friction with having to put in versionInfo and
gameMain objects and then put in an initialPlayerChar property and so on.
Plus you need those #include directives. So, at a glance, the initial setup
for Inform 7 seems very simple and, in fact, is very simple.
So, going with the two points I had said, Inform 7 allows pretty easy
modeling of the domain of knowledge (meaning, the story or game you are
creating). You can, at a glance, very easily tell the stucture of a game or
story if the only elements in the source text are declarations of rooms and
objects in those rooms. To wit:
---------------------------------------------
The Foyer is a room.
The Hallway is a room. It is north of the Foyer.
The Kitchen is a room. It is north of the Hallway.
The Living Room is a room. It is east of the Hallway.
A supporter called the couch is in the Living Room.
---------------------------------------------
But, that said, this isn't all that much different in TADS 3, or at least so
I would argue:
---------------------------------------------
foyer : Room 'Foyer'
north = hallway
;
hallway : Room 'Hallway'
south = foyer
north = kitchen
east = livingRoom
;
kitchen : Room 'Kitchen'
south = hallway
;
livingRoom : Room 'Living Room'
west = hallway
;
couch : Platform 'couch' 'couch' @livingRoom;
---------------------------------------------
Here you could argue that Inform 7 allows this to be more concise but, on
the other hand, this is the easy stuff anyway. Once you know the conventions
of the language, the initial implementation isn't really that hard in either
language. When you get into the complexities is when the languages start to
appeal to different people, depending on their focus.
The second point was the ability to utilize an effective system of reasoning
about that domain of knowledge, which speaks very much to the nature of the
code and how easy it is to update and/or maintain that code as things change
in your story or game and part of that is how easy you find it to read your
own code and update it as need be. For example, one thing we talked about
was conditionalizing text and, as you can imagine, authors would
periodically decide to change this text lots of times. Here's an Inform
7-ish way to do it:
---------------------------------------------
say "[if this condition]Here's some text[otherwise]Here's some different
text.[end if] Here's some text that should pretty much appear no matter
what.[if this other condition]Some text[one of]this[or]that[or]the other
thing[end if]."
---------------------------------------------
So to parse this out requires you to separate out those conditional
elements. This is as opposed to a TADS-ish way to do it:
---------------------------------------------
desc()
{
if (this condition)
"Here's some text. ";
else
"Here's some different text. ";
"Here's some text that should pretty much appear no matter what. ";
if (this condition)
"Some text <<rand('this', 'that', 'the other thing')>>. ";
}
---------------------------------------------
While that is definitely more code-ish looking and spaced out, I found that
even this group of non-programmers much preferred that because, at a glance
they could tell what was being said under what conditions. They didn't have
to spend time parsing out their conditionalized text: the structure imposed
it. Even constructs like this (which is a modified bit of text from 'Return
to Ditch Day'):
---------------------------------------------
north : NoTravelMessage
{
"You were five stories up. A better route down was the elevator. <<
lexicalParent.northQuip++ ? '' : '(Although given the state of the elevators
at the plant, it was only a marginally better route down.)'>> "
}
---------------------------------------------
One of my authors thought to do this and then just added a 'northQuip = 0'
property to the PowerPlantHallRoom class from the game. Notice how easy this
was for a putative non-programmer. So the point here is speaking to not only
the ease of setup for certain things (like a NoTravelMessage object in this
case) but the ease of seeing how to go back and make a little change.
That same author attempting that in Inform 7 wasn't really sure of the best
way to do this. They wanted to try a rule like "Instead of going north..."
but the problem was that the room in question didn't have a path to the
north, which just meant the player got the message "You can't go that way."
So then he tried "Instead of going nowhere ..." but that wasn't quite what
was needed because that would apply to every direction and not just north --
and north was the only text this was meant to show for. Then they realized
they could make a "Fake Room" to the north. But then, as they saw it, they
needed two rules:
---------------------------------------------
Instead of going north from the Hallway for the first time, say "You were
five stories up. A better route down was the elevator. (Although given the
state of the elevators at the plant, it was only a marginally better route
down.)"
Instead of going north from the Hallway, say "You were five stories up. A
better route down was the elevator."
---------------------------------------------
Now, mind, there might be better ways to do this but the point is I'm
showing you how one particular person conceived it and where they got stuck.
Also, I should note, of course that the person didn't know TADS 3's
"lexicalParent" intuitively. But once they described what they wanted to do,
they initially tried "northQuip++" since it was defined on the object. But
it was defined on the hallway object, not the north object.
So when asking why it wasn't working, it was suggested that 'north' was the
object in this case, and 'north' did not have the northQuip property. How do
I tell it to use the parent object? Just use lexicalParent to indicate the
parent object of 'north'. Intuitive, no. But once you got it, it stuck. From
that time on, this particular author was able to know when to use
lexicalParent and when not.
- Jeff
Andrew Plotkin
> "Andrew Plotkin" <erky...@eblong.com> wrote in message
> > As a separate question -- a thought experiment, but maybe useful:
> >
> > Imagine that I6 was extended to support divided object declarations:
>
> So basically it's like partial classes in C# or something? In other words, I
> can break up the declaration of my object (or, really, class) over multiple
> places in my source. Is that what you're basically saying?
>
> I'm missing the point of your example here, I think. By way of example,
> here's what I see people respond well to (pseudo-code-ish):
>
> Class Container
> contentsListed = true;
>
> Then (for a specific object):
>
> Object Bucket class Container
> contentsListed = false
> describeContents() { ... some logic ... }
> ;
Right. This is a division of logic (contentsListed is defined in two
places) which people seem to respond well to. But I'm interested in
what other kinds of code arrangement are intuitive.
My example is artificial -- although not completely, because I7 *does*
let you define tables in exactly this divided way. (So that part of
the table can be defined in an extension, and the rest in your game
code.)
> Whereas what I'm finding people prefer is a class that contains all
> of its logic in one place. Then objects can have their own logic, of
> course, but everything that can happen to or be done with that
> object has code that is placed in the object itself.
My other thought is that many of I7's parts *follow* an OO model. All
the object-based activities, for example. The semantics of "rule for
printing the name of OBJECT", "rule for printing the name of KIND" are
exactly the semantics of a class method. This is one of the things
that attracted me to the idea in the first place.
And it still feels like that to me -- "well, I'll just use a method
here". The activity rulebook is a separate first-class programming
construct, but then methods in Python are separate first-class
programming constructs, and that doesn't bother people.
This discussion implies that I should go back to the "rule-based
properties" posts that I was making in late 2006. There I was thinking
about a terse, programmer-y, mathy model for expressing a rule model
-- and one of the benefits was that you *could* express your
collection of object-dispatched value rules in a way analogous to an
OO object.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a
warrant, it's for one reason: they don't feel like it. Not because of
the Fourth Amendment.
Michael Martin
wrote:
> I don't think I'd be mis-stating things to say that people found TADS 3
> daunting at first glance. But TADS 3 (the libary) was found as manageable
> because it was broken into concepual "chunks." Once you knew what a
> TravelConnector was, you could traverse "down" and conceptualize a Room.
> Alternatively, you could take a Room and traverse "up" and conceptualize a
> TravelConnector. Then properties were considered as the bark along this
> tree, so to speak, which made it very easy for people to determine exactly
> how something would operate.
In my own experience with TADS 3, I found that I was unable to
properly lay out a map until I had learned the difference between all
20-odd subclasses of RoomConnector - most modifications I wanted were
actually already there, and I needed to make sure I wasn't using the
wrong one. Using the wrong class (Say, a FakeRoomConnector instead of
a NoTravelMessage) means that you get surprised by a reply (in this
case a status-line cue that the player can go a direction you don't
want him to), and the rich world model means that there are more
fiddly bits for you to have neglected to specify (so you might end up
having an interacting have a character move from one room to another
while remaining seated).
I've tried three times now to do projects in TADS 3, and in all of
them I've had to sourcedive the library every single time I wanted to
make a change that wasn't essentially just a custom refusal message.
Even with the reference manual, Thing has over 300 publicly exposed
methods, and it is not at all clear which ones carry the behavior I
want, or even whether they're "supposed" to be exposed.
I found that the breaking down of the library into chunks only worked
to get me a mostly-working system. Polishing the result meant I had
to actually know the whole thing - or at least all the code I was
directly or indirectly touching as well as the parts of the huge,
daunting mass that I *should* have been touching instead.
--Michael
steve....@gmail.com
> why object [that is, *noun*] dispatch is more intuitive than *verb* dispatch.
It's elementary linguistics: the meanings of the verb varies widely,
depending on the nouns involved. (The meaning of the noun can vary by
verb, but far less.) Further, the most common verbs are also the most
unstable.
'take' for instance: take the lantern, take a bath, take a cruise,
take a pill, take a shit
'make' for instance: make a cake, make love, make a mess, make the bed
The verb does not provide conceptual unity; the noun does.
Further: the programmatic object representing the verb must allow for
the verb's variability; the programmatic object representing the noun
can restrict the noun's meaning to a single object.
In OO programming, the *relations* are dynamic, their behavior
depending on the objects in question. -- While the objects represent
static concepts. It's that very metaphor (nominal-objects verbally-
doing-things with each other) which makes OO so convincing -- and
practical -- in the first place.
OKB (not okblacke)
> This is where I see something going genuinely strange in these
> discussions. While dispatch-by-object (or select-by-object, however
> you want to think about it) is the common case in IF design, I don't
> think it's *so* overwhelmingly common that dispatch-by-verb would
> never even comes up as a concept. And in a group of non-programmers,
> I'd think that dispatch-by-object would be the *less* intuitive
> approach. You'd have to explain it by analogy: *rather than*
> associating the action code with the verb, you associate it with the
> object that it's acting on.
Just thinking out loud here, but. . .
One thing that comes to mind is that verbs are rather abstract.
You can think of an object without it "doing" anything or anything being
done to it. It's difficult to conceptualize a verb without its objects.
(Imagine the sound of one hand clapping.) So the object is the thing
that anchors a particular action to the world; the verb is transitory
and difficult to grasp.
Another, perhaps related, thing, is that a verb is nowhere (or
everywhere), whereas an object is only in one place at a time, and a
place only has a certain set of objects in it at any time. This is
certainly relevant when PLAYING a game (as when interacting with the
real world), because you're limited to dealing only with the objects
that are available. The verbs on the other hand, are always all
available to you. It may be that this translates into coding, in that
it's easier to restrict ones focus "geographically" to the objects under
consideration and then think about what will be done to them. If you
start with the verbs, you have to think about all the verbs all the
time, because they never go "out of scope".
A third idea that occurs to me is this idea of "affordances" that
I've seen in some books and articles and whatnot (like "The Design of
Everyday Things" by Donald Norman). In essence, the claim is that our
perception of objects influences what we think we can do with them. We
don't go around thinking "hmmm, what can I yank on", but if we see a
door with a handle that sticks out invitingly, it "affords" pulling.
Similarly, it seems to me that, in my own experience, when programming a
game, I tend to think of the object as sitting there and someone coming
up to it. The question is then: what do they do? I don't think of
someone going through every room in the game and pulling everything, or
opening everything; I think of each object being under scrutiny and
subjected to a series of distinct actions.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
greg
> I wasn't asking why object dispatch is more intuitive than rule
> dispatch. I was asking why object dispatch is more intuitive than
> *verb* dispatch.
To a writer, I don't imagine that a verb would naturally
be seen as the kind of thing you dispatch *to*. A verb
is a kind of word -- it describes an action, it doesn't
*do* an action.
(I know that verbs are represented by objects in Tads,
but as far as I know they're more like passive pieces
of data -- you don't attach methods to them for carrying
out the action that the verb represents.)
Even if you do decide to attach action code to a verb,
it doesn't help you very much with organisation. You just
get a big long list of if-then statements for doing
different things depending on what objects you're
applying the action to.
It's exactly that kind of switch-statement coding style
that OO dispatch is designed to improve on.
> (I know why *programmers* built OO IF around objects!)
Have you considered that non-programmers might prefer it
for many of the *same* reasons?
Whether you've had prior programming experience or not,
you encounter the same problems of complexity management
when you attempt programming (which writing IF undoubtedly
is, however much we might wish it otherwise). OO has
proven to be a very effective way of managing complexity,
whereas rule-based systems haven't.
--
Greg
Jim Aikin
>
> A third idea that occurs to me is this idea of "affordances" that
> I've seen in some books and articles and whatnot (like "The Design of
> Everyday Things" by Donald Norman). In essence, the claim is that our
> perception of objects influences what we think we can do with them. We
> don't go around thinking "hmmm, what can I yank on", but if we see a
> door with a handle that sticks out invitingly, it "affords" pulling.
> Similarly, it seems to me that, in my own experience, when programming a
> game, I tend to think of the object as sitting there and someone coming
> up to it. The question is then: what do they do? I don't think of
> someone going through every room in the game and pulling everything, or
> opening everything; I think of each object being under scrutiny and
> subjected to a series of distinct actions.
While I agree with everything you've said in this post, I'm constrained
to point out that the IF author _does_ need, in some sense, to go
through every room in the game and think about what happens if someone
tries to pull every object, or fill it, or burn it, or hit it, or dip it
in the bucket full of water.
The player can't be relied on not to try these actions -- but: I agree
that the player sees an object and thinks, "What can I do with this?"
--JA
stu...@animats.net
<brenNOSPAMb...@NObrenSPAMbarn.net> wrote:
> Andrew Plotkin wrote:
> > This is where I see something going genuinely strange in these
> > discussions. While dispatch-by-object (or select-by-object, however
> > you want to think about it) is the common case in IF design, I don't
> > think it's *so* overwhelmingly common that dispatch-by-verb would
> > never even comes up as a concept. And in a group of non-programmers,
> > I'd think that dispatch-by-object would be the *less* intuitive
> > approach. You'd have to explain it by analogy: *rather than*
> > associating the action code with the verb, you associate it with the
> > object that it's acting on.
>
>
> everywhere), whereas an object is only in one place at a time, and a
> place only has a certain set of objects in it at any time. This is
> certainly relevant when PLAYING a game (as when interacting with the
> real world), because you're limited to dealing only with the objects
> that are available.
As stated before, the simple truth is that you add a lot more objects
to your game than verbs. From a practical point of view, this means
that when I add a new object, I can code that object and all the new
verb responses in one place. Sure, if I add a new verb I will need to
add code in many different places to all the existing objects, but
this happens far less often.
The fact that it is possible to take an identical verb library and
write anything from Science Fiction to Fantasy shows that it is the
objects that give character to a story, not the laws of physics (read
'default verb responses'). Drop a whiskey bottle in 1830 or a laser
gun in 2330 and they will both fall (provided you are on Earth, of
course). Push a bad-ass outlaw off his horse or a button to open an
airlock and the verb is still the same.
So to me, this all adds up to a having an object-focus when telling a
story (which just also happens to be a more convenient way to
program.)
Stuart
OKB (not okblacke)
> OKB (not okblacke) wrote:
>> I don't think of someone going
>> through every room in the game and pulling everything, or opening
>> everything; I think of each object being under scrutiny and
>> subjected to a series of distinct actions.
>
> While I agree with everything you've said in this post, I'm
> constrained to point out that the IF author _does_ need, in some
> sense, to go through every room in the game and think about what
> happens if someone tries to pull every object, or fill it, or burn
> it, or hit it, or dip it in the bucket full of water.
Sure, but is this the way you think when you're coding along? In
other words, is that the organization that you want to direct your
programming pace? To me it seems like this kind of verb-based thinking
is a sort of periodic "sweep" through to catch possible glitches,
whereas the ordinary procedure is to code each object together with the
verbs that seem most relevant to it.
greg
> My other thought is that many of I7's parts *follow* an OO model. All
> the object-based activities, for example. The semantics of "rule for
> printing the name of OBJECT", "rule for printing the name of KIND" are
> exactly the semantics of a class method.
But not in such a direct and obvious way as in a language
that directly embodies the concept of methods attached
to classes.
Also, you're thinking about it from the point of view
of someone who is already familiar with OO concepts.
You're capable of thinking "what I really want here is
a method" and then figuring out how to express that in
I7. Someone who doesn't have OO concepts in their
mental vocabulary isn't going to be able to do that.
> I was thinking
> about a terse, programmer-y, mathy model for expressing a rule model
> -- and one of the benefits was that you *could* express your
> collection of object-dispatched value rules in a way analogous to an
> OO object.
You can do OO programming in any language, but it's
much easier and less error-prone in a language that
directly supports it.
--
Greg
Jim Aikin
> Jim Aikin wrote:
>
>> OKB (not okblacke) wrote:
>>> I don't think of someone going
>>> through every room in the game and pulling everything, or opening
>>> everything; I think of each object being under scrutiny and
>>> subjected to a series of distinct actions.
>> While I agree with everything you've said in this post, I'm
>> constrained to point out that the IF author _does_ need, in some
>> sense, to go through every room in the game and think about what
>> happens if someone tries to pull every object, or fill it, or burn
>> it, or hit it, or dip it in the bucket full of water.
>
> Sure, but is this the way you think when you're coding along? In
> other words, is that the organization that you want to direct your
> programming pace? To me it seems like this kind of verb-based thinking
> is a sort of periodic "sweep" through to catch possible glitches,
> whereas the ordinary procedure is to code each object together with the
> verbs that seem most relevant to it.
Yes and no. Let's say you're introducing a novel action, such as dipping
a cookie into a glass of milk. In TADS, you would naturally modify Thing
with a dobjFor(DipInto) and an iobjFor(DipInto), so you would have
handled the default responses for everything in the game immediately.
To that extent, yes, I think about it when I'm coding along.
What happens later, in the sort of "sweep" phase you're talking about,
is that at some point I notice, "Hmmm, I've got a piece of paper here. I
really ought to have a non-default message for 'dip paper in milk'." At
that point I might go back and introduce isWettable and isSoggy
properties in Thing and rewrite my Thing dobjFor(DipInto) to test
whether the object is wettable and/or is already soggy.
That wouldn't be verb-based thinking, it would be another instance of
object-based thinking. The verb DipInto absolutely doesn't need to know
that the isWettable and isSoggy properties exist, and trying to write a
VerbRule that would handle it would probably be messy, because if you
later changed the properties of Thing you would also have to remember to
rewrite the VerbRule.
As it is, only the Thing class needs to know that these properties exist.
--JA
Ron Newcomb
I'm finding this argument for "noun first" thinking both fascinating
and convincing, especially as described by Greg. But all it says to
me in practical terms is, Inform 7 needs some syntactic sugar on its
action-based rules.
Take these:
Carry out rubbing the cat: ..
Carry out rubbing the parakeet: ...
Carry out grabbing the cat: ...
Carry out grabbing the parakeet: ...
and rewrite as:
When the cat is rubbed: ....
When the cat is grabbed: ...
When the parakeet is rubbed: ....
When the parakeet is grabbed: ...
I'm not real found of the passive tense in my code, but if it's easier
for Nyman's students to conceptualize, ::shrug::. It compiles to the
exact same thing.
-Ron
Ron Newcomb
puzzler
wrote:
> My only caution with statements like these is that they assume something is
> difficult for everyone to the same level. Any programming language can be
> difficult for non-programmers just as any new spoken language can be
> difficult for people who have never spoken it before and are trying to learn
> it. By this logic, a non-programmer could never learn a programming language
> because they can all be considered difficult, particularly if you're a
> non-programmer.
>
The flaw with that reasoning, of course, is that most people who want
to write IF don't particularly want to master the complex art of
programming. They just want to write an interactive story.
Obviously, a non-programmer can become a programmer if that's what
they really want to do, but they should go in recognizing that it's
hard, and that it takes a significant investment of time to become
skilled.
If you're already a competent programmer, TADS is a wonderful tool.
But to dive into TADS 3, thinking you'll pick up just enough
programming to get by, seems somewhat unrealistic to me. I look
forward to hearing how well this works for your group.
--Mark
Jim Aikin
> I'm finding this argument for "noun first" thinking both fascinating
> and convincing, especially as described by Greg. But all it says to
> me in practical terms is, Inform 7 needs some syntactic sugar on its
> action-based rules.
>
> Take these:
>
> Carry out rubbing the cat: ..
> Carry out rubbing the parakeet: ...
>
> Carry out grabbing the cat: ...
> Carry out grabbing the parakeet: ...
>
> and rewrite as:
>
> When the cat is rubbed: ....
> When the cat is grabbed: ...
>
> When the parakeet is rubbed: ....
> When the parakeet is grabbed: ...
Good suggestion! I hope they'll implement it.
--JA
Andrew Plotkin
> Andrew Plotkin wrote:
>
> > (I know why *programmers* built OO IF around objects!)
>
> Have you considered that non-programmers might prefer it
> for many of the *same* reasons?
Sure, but I don't have any way to evaluate whether it's *true*!
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're innocent.
ChicagoDave
Nice. I like this a lot.
David C.
Jeff Nyman
news:cd3040b5-ded9-4d40...@s37g2000prg.googlegroups.com...
> The flaw with that reasoning, of course, is that most people who want
> to write IF don't particularly want to master the complex art of
> programming. They just want to write an interactive story.
That may be true. Honestly, I can't speak for what most people do or don't
want in this venue. But what I can guess is that most people probably pretty
quickly figure out that many of the major systems that allow writing an
interactive story require programming. If they choose P.A.W.S, Inform 6 or
7, TADS 2 or 3, or Hugo, for example, it doesn't take too long to realize
that you have to learn a programming language.
So, faced with that, people have to decide if they still want to write
textual IF, at least with those types of systems. (As opposed to perhaps
something like ADRIFT, which I haven't used but which I believe requires no
or very little actual programming/scripting?)
It's a little bit of a selection process that probably weeds out the ones
who want to try and those who don't. It's a little like the old writer
saying: "I don't want to write. I want to have written." To do the one, you
have to do the other. Likewise, if you want to write textual IF, you may
have to learn how to utilize programming skills.
> Obviously, a non-programmer can become a programmer if that's what
> they really want to do, but they should go in recognizing that it's
> hard, and that it takes a significant investment of time to become
> skilled.
Certainly. The same applies to writing static fiction in a lot of ways. Not
in terms of programming, of course, but there's a lot to learn (about voice,
narrative, plotting, dialogue, characterization). You can apply that same
logic to just about anything. So I could re-word what you just said as:
"Obviously, a *non-writer* can become a *writer* if that's what
they really want to do, but they should go in recognizing that it's
hard, and that it takes a significant investment of time to become
skilled."
In fact, I've found people more often have trouble writing compelling
stories than they do learning programming. (Certainly the textual IF
community is ripe with many, many examples of people who learned to program;
it's probably got comparatively few examples of people who learned to be
writers.)
There is a caveat here: my group, as we all know, *is* a group of writers.
They are extremely interested in seeing if, how, and to what extent static
fiction techniques can be translated to textual IF. As such, they have a
compelling motivation of their own to learn whereas perhaps someone else
might not want to invest the time/energy/etc.
What I do find interesting is that I've seen threads where people do seem to
perceive Inform 7 as being "less programming" than TADS 3 or even Inform 6.
Of course you are still programming when you work in Inform 7 and it can be
just as complex as working with TADS 3 -- except, as Michael notes in his
post, when you get to the library aspects. On the other hand, I can see this
kind of complexity a bit with the extensions aspect of Inform 7. Those
extensions effectively become a larger library from which to choose.
From my own working with both (although I do have a programming background),
I think both TADS 3 and Inform 7 are easy to start out with (with Inform 7
probably edging out TADS in this regard); but when you really want to get
into modeling a dynamic world or having characters act and converse, both
languages can appear pretty complex.
> If you're already a competent programmer, TADS is a wonderful tool.
> But to dive into TADS 3, thinking you'll pick up just enough
> programming to get by, seems somewhat unrealistic to me.
Speaking as someone who often has to teach programming languages as part of
his career (usually to people with little to no background in programming
languages), I've found that most people can readily adapt to the thinking
required to learn a programming language. That's not to say there are not
hurdles and that's not to say it doesn't depend on the nature of the
language. (Keep in mind that, based on the nature of Inform 7's language, my
class originally did fully intend to use it for the second round. It was
after playing around for a bit that they started to go another direction.)
Supporting libraries of any language are usually the thing that really takes
the time. Learning the basics of C#-the-language is pretty easy; learning to
utilize the .NET library with C# can be very difficult. But you often don't
have to learn the whole thing. You just learn enough to do what you want to
do. The question then becomes whether or not there are enough supporting
elements (documentation or source comments or whatever else) that allow you
to figure out what else exists.
So picking up just enough to get by is often a very viable strategy, at
least in my experience.
But, all this being said, we'll see. I've already given an example in this
thread where a non-programmer was able to figure out the use of a property
and then use string interpolation (or embedding, if you prefer) to have that
property referenced (and incremented with ++). The stopping point was
'lexicalParent', which was not known at all, but once that *was* known, the
person once again knew enough, at that point, to get by.
> I look forward to hearing how well this works for your group.
Me too! Ultimately all of this is why I left the decision up to the group,
rather than just imposing a language on the class. I must admit that I am
curious to see what areas of cognitive friction this group encounters with
TADS 3. I already know most of what they encountered with Inform 7.
- Jeff
greg
> To me it seems like this kind of verb-based thinking
> is a sort of periodic "sweep" through to catch possible glitches,
> whereas the ordinary procedure is to code each object together with the
> verbs that seem most relevant to it.
I agree. When adding a new object, you want to be able
to write most of the necessary code there with it, rather
than have to go hunting down all the relevant verb
handlers and updating them.
For making sure you've covered all the actions, maybe
there should be an automated testing tool that methodically
goes through the game trying every action on every object.
--
Greg
greg
> Take these:
>
> Carry out rubbing the cat: ..
> Carry out rubbing the parakeet: ...
>
> Carry out grabbing the cat: ...
> Carry out grabbing the parakeet: ...
>
> and rewrite as:
>
> When the cat is rubbed: ....
> When the cat is grabbed: ...
>
> When the parakeet is rubbed: ....
> When the parakeet is grabbed: ...
I'm not sure that's all there is to it. There's still the
issue of where, physically, the code is positioned in the
source.
While you can adopt a convention of always putting rules
of that kind next to the declaration of the object they
apply to, as long as it's just a convention, you can't
be sure it's always being followed.
Also, I think there's an important difference between a
purely syntax-level feature and one that's actually
embodied in the data model. When you make a method call
in Tads, you *know* it's impossible for a method defined
on some other object to interfere, because of the way things
work at a fundamental level. That's not the case with I7
rules, whatever syntax or source layout conventions are
being used.
--
Greg
Jeff Nyman
news:6508j0F...@mid.individual.net...
> I'm not sure that's all there is to it.
Basically, I agree with this as well as your other comments.
Mind, I'm not saying the proposed change is bad. If people feel it could be
helpful, then I have no doubt it could be. But the issue in question was
only a small aspect of an entire set of issues that swirled around what I
talked about: the overall structure of how things are done between TADS 3
and Inform 7.
My response to Kevin (3/25/2008, 3:01 PM according to my newsreader)
highlighted just a subset of the issues that people felt and/or saw based on
their experience.
- Jeff
Ron Newcomb
> While you can adopt a convention of always putting rules
> of that kind next to the declaration of the object they
> apply to, as long as it's just a convention, you can't
> be sure it's always being followed.
Nor would we want it enforced. An OOP language's "a place for every
thing and every thing in its place" is like training wheels: helpful
when you're new, but eventually the rigidity stifles your
expressiveness. If such code arrangement is your bag, that's great!
But a good tool won't enforce the aesthetic on you.
There's been threads here about how people arrange their I7 code. Some
do it spatially (i.e., decided by the game's map), some temporally (by
scene), etc., and many keep the props for a particular scene or room
with that scene or room. But I7 allows new verbs to be tossed into an
extension or some other dusty corner, since they are mostly code and
little prose -- they have little bearing on the story. Straight OOP
demands the verb code be sprinkled throughout with the props.
-R
R. Alan Monroe
@mid.individual.net:
> For making sure you've covered all the actions, maybe
> there should be an automated testing tool that methodically
> goes through the game trying every action on every object.
This was one of the concepts behind the spreadsheet-based authoring idea I
mentioned in late February. I'm still futzing around with layouts trying to
find a good balance between compact and expressive.
Alan
Andrew Plotkin
>
> While you can adopt a convention of always putting rules
> of that kind next to the declaration of the object they
> apply to, as long as it's just a convention, you can't
> be sure it's always being followed.
True, but as Ron said, there *is* sometimes a need to break that
convention. That is to say, *I* want to break it sometimes. And OO
systems already go some distance towards making it breakable. I6 has
various ways to separate object logic from the object, and they're all
kind of ad-hoc and confusing. I don't see that as a strength, but they
all exist for reasons.
> Also, I think there's an important difference between a
> purely syntax-level feature and one that's actually
> embodied in the data model. When you make a method call
> in Tads, you *know* it's impossible for a method defined
> on some other object to interfere, because of the way things
> work at a fundamental level. That's not the case with I7
> rules, whatever syntax or source layout conventions are
> being used.
True. And in my hypothetical properties model, it would not be true.
That is... (making up some syntax for the sake of pseudocode):
elvish_backpack {
container: true;
capacity: 10;
}
would be syntactic sugar for: (equally off-the-cuff syntax)
define: container when (this==elvish_backpack):
return true;
define: capacity when (this==elvish_backpack):
return 10;
I'm just not convinced that there's a need for the fundamental system
to *insist* that "nothing else can interfere". I think it is
sufficient if the author can *know* that nothing else is interfering,
in the particular case that he's worried about. That kind of
reassurance needs to be easy, both from observing the code and from
looking at the compiler output indexia. And then the genuinely
complicated cases would remain complicated, but the author would know
they wouldn't bite him unless he delved into complicated territory.
Plus it should allow for incremental complication. You should be able
to start with the simple backback stanza above, and then decide to
throw in a wrinkle:
elvish_backpack {
container: true;
capacity: 10;
capacity: 5 when torn(this);
}
My position at this point is that getting there from I7 is not a
matter of throwing away the rule system, but simplifying both the
underlying model (complicated and too often bulky) and the syntax for
simple cases. (I compared object-based activity rulebooks to OO
methods, but the work needed to set up an I7 activity is several
sentences of boilerplate, and invoking one is icky too. And there's no
easy path there from a simple numerical property.)
I realize that this position is more of an ideology than an argument,
but it's what I want to keep hacking on. :)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
Kevin Forchione
> My position at this point is that getting there from I7 is not a
> matter of throwing away the rule system, but simplifying both the
> underlying model (complicated and too often bulky) and the syntax for
> simple cases. (I compared object-based activity rulebooks to OO
> methods, but the work needed to set up an I7 activity is several
> sentences of boilerplate, and invoking one is icky too. And there's no
> easy path there from a simple numerical property.)
>
> I realize that this position is more of an ideology than an argument,
> but it's what I want to keep hacking on. :)
Interesting. Your approach appears to be syntax sugar for an OO language as
well. I realize your examples are simplistic, and you'd probably need to
elaborate on the scope of such kinds of constructs. It's not very difficult,
howver to envision a translator phase that accumulates and then converts
your example into an object definition. For instance:
elvish_backpack: object
{
container = true
capacity()
{
if (torn(self)) return 5;
return 10;
}
}
This kind of syntax:
entityName {
property: value <when-condition>;
}
especially lends itself to that kind of translation, since every condition
on an identical property for an entity converts nicely to an if-statement
(or possibly a swtich). Of course the syntax for handling concepts as
inheritance and delegation would need to be sorted out... amongst other
things, but it's interesting, nonetheless.
--Kevin
Andrew Plotkin
>
> "Andrew Plotkin" <erky...@eblong.com> wrote in message
> news:fsgnfp$nmt$1...@reader2.panix.com...
>
> > My position at this point is that getting there from I7 is not a
> > matter of throwing away the rule system, but simplifying both the
> > underlying model (complicated and too often bulky) and the syntax for
> > simple cases. (I compared object-based activity rulebooks to OO
> > methods, but the work needed to set up an I7 activity is several
> > sentences of boilerplate, and invoking one is icky too. And there's no
> > easy path there from a simple numerical property.)
> >
> > I realize that this position is more of an ideology than an argument,
> > but it's what I want to keep hacking on. :)
>
> Interesting. Your approach appears to be syntax sugar for an OO language as
> well. I realize your examples are simplistic
Exactly. That example was demonstrating that the system *reduces* to
an OO model (with a familiar sort of syntax) for properties that act
like OO methods. (That is, properties of a single dependent variable
which is always an object.)
Naturally, if you don't go beyond that, OO is all you have.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're an American.
Kevin Forchione
> Here, Kevin Forchione <ke...@lysseus.com> wrote:
>>
>> "Andrew Plotkin" <erky...@eblong.com> wrote in message
>> news:fsgnfp$nmt$1...@reader2.panix.com...
>>
>> > My position at this point is that getting there from I7 is not a
>> > matter of throwing away the rule system, but simplifying both the
>> > underlying model (complicated and too often bulky) and the syntax for
>> > simple cases. (I compared object-based activity rulebooks to OO
>> > methods, but the work needed to set up an I7 activity is several
>> > sentences of boilerplate, and invoking one is icky too. And there's no
>> > easy path there from a simple numerical property.)
>> >
>> > I realize that this position is more of an ideology than an argument,
>> > but it's what I want to keep hacking on. :)
>>
>> Interesting. Your approach appears to be syntax sugar for an OO language
>> as
>> well. I realize your examples are simplistic
>
> Exactly. That example was demonstrating that the system *reduces* to
> an OO model (with a familiar sort of syntax) for properties that act
> like OO methods. (That is, properties of a single dependent variable
> which is always an object.)
>
> Naturally, if you don't go beyond that, OO is all you have.
So, in a multiple-dependent variable case, presumable we would maintain the
pattern, something like this?
(var1, var2, var3 ...) {
func: returnValue <when-condition>;
}
I changed "property" to "func" for want of a better name. Though I must
confess I'm not sure what this would represent, except perhaps that it would
more closely resemble a function, like this?
func(var1, var2, var3...) {
<when-condition1> return value1;
<when-condition2> return value2;
...
return valueN;
}
Is that along the lines of what you imagine?
--Kevin
vaporware
> "Andrew Plotkin" <erkyr...@eblong.com> wrote in message
>
> news:fsh2ds$h8h$1...@reader2.panix.com...
>
>
>
> > Here, Kevin Forchione <ke...@lysseus.com> wrote:
>
> >>news:fsgnfp$nmt$1...@reader2.panix.com...
>
> >> > My position at this point is that getting there from I7 is not a
> >> > matter of throwing away the rule system, but simplifying both the
> >> > underlying model (complicated and too often bulky) and the syntax for
> >> > simple cases. (I compared object-based activity rulebooks to OO
> >> > methods, but the work needed to set up an I7 activity is several
> >> > sentences of boilerplate, and invoking one is icky too. And there's no
> >> > easy path there from a simple numerical property.)
>
> >> > I realize that this position is more of an ideology than an argument,
> >> > but it's what I want to keep hacking on. :)
>
> >> Interesting. Your approach appears to be syntax sugar for an OO language
> >> as
> >> well. I realize your examples are simplistic
>
> > Exactly. That example was demonstrating that the system *reduces* to
> > an OO model (with a familiar sort of syntax) for properties that act
> > like OO methods. (That is, properties of a single dependent variable
> > which is always an object.)
>
> > Naturally, if you don't go beyond that, OO is all you have.
>
> So, in a multiple-dependent variable case, presumable we would maintain the
> pattern, something like this?
>
> (var1, var2, var3 ...) {
> func: returnValue <when-condition>;
>
> }
>
> I changed "property" to "func" for want of a better name. Though I must
I think it'd represent an I7-style relation, as in "Romeo loves
Juliet" = loves(romeo, juliet). Or, going beyond what I7 supports,
multi-way relations like "Gollum knows Frodo has the ring" = knows-
has(gollum, frodo, ring).
vw
Kevin Forchione
news:10867a4d-f17c-48a1...@a23g2000hsc.googlegroups.com...
> I think it'd represent an I7-style relation, as in "Romeo loves
> Juliet" = loves(romeo, juliet). Or, going beyond what I7 supports,
> multi-way relations like "Gollum knows Frodo has the ring" = knows-
> has(gollum, frodo, ring).
Ah... I see now. I've been working with something similar, but using a
prolog-style processing. Hmmm.
--Kevin
JDC
<jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
>
> As far as rationale: everyone just found it easier to conceptualize stories
> around objects. They felt that Inform 7 was a viable choice in a lot of
> ways, but that the conceptualizations were ultimately focused on rules,
> which was a harder mechanism by which to create narrative because it kept
> you focused on the implementation model rather than on the actual objects.
> Here they weren't talking about the Before, Instead, After rules but rather
> then notion of "rule for writing a paragraph about" or having constructs
> like "rule for deciding the concealed possessions of containers" and things
> along that nature.
One thing which surprised me a little about this is that I would have
expected that writers who were focused on narrative in IF would have
been more inclined to heavily guiding the player (rather than allowing
a more free-form exploration or trial-and-error type approach which
would be more common in a puzzle-heavy work), and I would have thought
that a rule-based approach would be appealing from that standpoint.
For instance, being able to write rules along the lines of "Instead of
doing anything other than sleeping when the player is in the
bed, ....", or "After noise-making action in the library, ...", or
"Instead of taking a something which is in a container when wearing
the gloves, ...". I'm thinking of the ability to group many actions
together into one rule, or being able to group a bunch of objects
together procedurally (rather than creating a class containing all the
relevant objects, etc.). Has this sort of broad or heavy guiding
approach been uncommon among your group, or do they find that this is
also more easily conceived of in terms of objects?
Another thing that has struck me reading this thread is that noun-less
verbs are pretty uncommon in IF. A lot of the ones that are used can
be viewed as having implicit nouns ("look", e.g., applied to the
location object, and similarly for directional commands). Commands
consisting of a verb alone (without an obvious implicit noun) or ones
with abstract nouns would also seem to be more easily treated by a
rules-based approach than an OO-based one. I wonder if part of the
reason for this is that these sort of commands seem to be at a higher
conceptual level ("plot revenge", "prevent global catastrophe"), and
(as others have noted) IF is not well-suited to this sort of thing,
requiring the step-by-step approach of actions with objects to
indicate this sort of intent.
-JDC
Jeff Nyman
news:93128ca4-1ad4-4c83...@c65g2000hsa.googlegroups.com...
> One thing which surprised me a little about this is that I would have
> expected that writers who were focused on narrative in IF would have
> been more inclined to heavily guiding the player (rather than allowing
> a more free-form exploration or trial-and-error type approach which
> would be more common in a puzzle-heavy work), and I would have thought
> that a rule-based approach would be appealing from that standpoint.
I don't think they were so much against a "rules-based approach" as it was
how the approach made them write their source text. In fact, the benefit of
rules could be seen, but it was the way the resulting source ended up having
to be constructed that seemed to be the most off-putting point for them.
Plus when they started to get into worrying about which rule was more
specific than another (which could be somewhat easy to determine, granted)
or where a rule had to be placed in a given rulebook and so forth, it just
became overhead so much so that they worried about having to use rules.
> For instance, being able to write rules along the lines of "Instead of
> doing anything other than sleeping when the player is in the
> bed, ....", or "After noise-making action in the library, ...", or
> "Instead of taking a something which is in a container when wearing
> the gloves, ...". I'm thinking of the ability to group many actions
> together into one rule, or being able to group a bunch of objects
> together procedurally (rather than creating a class containing all the
> relevant objects, etc.). Has this sort of broad or heavy guiding
> approach been uncommon among your group, or do they find that this is
> also more easily conceived of in terms of objects?
In fact that broad kind of approach was seen as a powerful way to set things
up but it went back to that issue of having to scour the source text to find
the rules and then making sure you aren't now making a more specific rule
that you don't want overridden or that you have a general rule somewhere
else that you forgot about and so on.
So, in fact, that very ability to make very generalized and very specific
rules actually led to the problems, at least in their eyes, becuase they
always felt they had to have an eye on the "whole set." Further, that whole
set could be distributed all over the source, rather than just looking at
one object that would be affected by the rule (or rules). To a certain
extent, you can argue that this just comes down to your conventions of
writing the source and I would agree. But the issue then became that
everyone felt like they kept concentrating on where to write rules, or
cutting a bunch to paste them all together.
In fact, when using the IDE we had to stop because it got way too cumbersome
since there's just the one source panel. Yeah, you have the Index, but
again, when you're in the flow of writing, that can become just as
cumbersome, particularly as the game grows. What did help is when I
presented EditPadPro and we used a multi-source file approach. Basically I
wrote a batch file that takes a series of .ni files and concatenantes them
in order. This worked a lot better and my group then felt they could more
easily group their rules into one file or place an object with all
associated rules in one file and so forth. So I think part of this issue
they had was not just the rules but wrestling with large source text in the
IDE.
> rules-based approach than an OO-based one. I wonder if part of the
> reason for this is that these sort of commands seem to be at a higher
> conceptual level ("plot revenge", "prevent global catastrophe"), and
> (as others have noted) IF is not well-suited to this sort of thing,
> requiring the step-by-step approach of actions with objects to
> indicate this sort of intent.
I probably can't speak to this very intelligently except to say that some
people in my group wanted to have situations where the player/reader could
type >CONSIDER OPTIONS or even, asking at some story level, >BENEFITS OF
REVENGE (the latter effectively being "> (what are the) benefits of
revenge").
I'm not stating this well.
One focus was looking at how readers read static fiction and how they think
about the character and the actions going on. A reader might say "Hmm, okay,
Jim-Bob is clearly plotting revenge against Mary-Sue here. But would that
really help him?" It's an interior dialogue that the reader has about the
story they are reading. (I've been involved in some interesting studies --
not related to IF -- where people are encouraged to read stories aloud and
intersperse with their 'commentary' on what they're thinking about as they
read. It's really fascinating stuff, actually, but I guess I'm straying
here.) That interior dialogue can be made more manifest in textual IF via
the actions a player takes. That, in fact, is something that *really*
intrigues my writers. The ability of the reader to "experiment" as it were
and see what happens. But, then, that leads to this interesting dichotomy
between "action steps" or more "conceptual actions."
I still haven't stated that well. But hopefully there's enough there to at
least see what we were considering or trying to look at it.
- Jeff
Blank
> Me too! Ultimately all of this is why I left the decision up to the group,
> rather than just imposing a language on the class. I must admit that I am
> curious to see what areas of cognitive friction this group encounters with
> TADS 3. I already know most of what they encountered with Inform 7.
>
> - Jeff
>
>
I think though you need to bear in mind that their experience of
programming is not typical of most RAIF denizens. For those of us
wanting to write IF but with no programming experience, learning to
program is a solitary activity.
It really hit me in one of your previous posts where someone was trying
to do something, and you commented "oh, what you need is lexicalParent":
thereby short-circuiting the usual learning process of 10-90 minutes of
scrolling back and forth through the library source followed by a post
to raif.
Pragmatically, the difference between the amount and style of the
documentation is at least as important for the solo learner as any
difference in power between the systems.
--jz
Jeff Nyman
news:47ecdf29$1...@news.kcl.ac.uk...
> It really hit me in one of your previous posts where someone was trying to
> do something, and you commented "oh, what you need is lexicalParent":
> thereby short-circuiting the usual learning process of 10-90 minutes of
> scrolling back and forth through the library source followed by a post to
> raif.
Or reading documentation. They read a Getting Started guide to learn about
lexicalParent. It wasn't just presented to them as a "here you go" sort of
thing and I'm sorry if I gave that impression. (I've actually had to
simplify a bit of the learning process when describing it in these posts,
but in all cases we had all documentation for both Inform 7 and TADS 3
available.) The concept of the lexicalParent, for example, gets introduced
on page 60 of the Getting Started guide.
In fact, nothing in either language was just "presented" as if on a platter.
We went through it together because part of my goal was to see how people
organically started to learn the systems, where they got stuck, what they
found easy, etc.
> Pragmatically, the difference between the amount and style of the
> documentation is at least as important for the solo learner as any
> difference in power between the systems.
This is absolutely true and an excellent point and, in fact, the perceived
"power" of the systems was not all that much of a selling point since both
systems were seen as very powerful. The question was how that power could be
used and how the system as a whole (libraries, extensions, etc) could be
referenced. And, here again, we come back to your point: the level of
supporting documentation. So all of this was seen as very important.
In fact, this was one weak point that was perceived with the Inform 7
documentation. The TADS 3 documentation, at least as a whole, introduces
things as they are needed and can support the information with examples that
makes sense in the immediate context. Inform 7's documentation often had
people referring to concepts that hadn't even been presented yet in any way
and so they often felt a bit adrift. However --- on the flip side of
that --- the Recipe Book was seen as a great way to learn Inform 7 because
it took the focus off the language and more on the techniques. This is what
the new "Learning TADS 3" documentation by Eric Eve also seems to be doing.
Again, I'm simplifying what was in fact a lot of discussion surrounding how
complicated or uncomplicated bits of the documentation were.
- Jeff
Andrew Plotkin
>
> Another thing that has struck me reading this thread is that noun-less
> verbs are pretty uncommon in IF. A lot of the ones that are used can
> be viewed as having implicit nouns ("look", e.g., applied to the
> location object, and similarly for directional commands).
Sleep, wake up, wait, listen... those have fairly common currency as
plot-relevant actions in IF games. (Listen can have a noun but often
doesn't. In my games I frequently implement breathe/inhale/smell in
the same way -- noun optional.)
Get up, unless you consider that a directional command. Pray, sing,
jump (but it is rare for those to be meaningful beyond library-default
responses).
You *could* view anything as having an implicit noun, so I don't think
that's a useful angle. (In a sense "wake up" implicitly refers to the
player; but in the same sense so does "kill troll with sword".)
> Commands consisting of a verb alone (without an obvious implicit
> noun) or ones with abstract nouns would also seem to be more easily
> treated by a rules-based approach than an OO-based one.
I prefer to think of OO as being suited only to the special case of
*one* relevant noun. :)
> I wonder if part of the reason for this is that these sort of
> commands seem to be at a higher conceptual level ("plot revenge",
> "prevent global catastrophe")
The ones I listed aren't.
> and (as others have noted) IF is not well-suited to this sort of
> thing, requiring the step-by-step approach of actions with objects
> to indicate this sort of intent.
As *other* others have noted, there's no reason that the step-by-step
action can't *be* at a different conceptual level. Imagine a game
where you are a corporation, preventing (or causing) global
catastrophe with a small set of familiar verbs like "acquire company",
"spin off division", "fund invention", "cancel project". Same rhythm
of play as Zork, but different level of abstraction.
(I originally wanted to go that way with _Wallpaper_ (part 2), but
wound up casting everything back to the "take" and "put" verbs. It's
still a game of manipulating events on a scene level, with the
"physical" object manipulation being a thin layer of means to that
end.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
Andrew Plotkin
> On Mar 27, 3:39 pm, "Kevin Forchione" <ke...@lysseus.com> wrote:
> > "Andrew Plotkin" <erkyr...@eblong.com> wrote in message
> >
> >
> > > an OO model (with a familiar sort of syntax) for properties that act
> > > like OO methods. (That is, properties of a single dependent variable
> > > which is always an object.)
> >
> > > Naturally, if you don't go beyond that, OO is all you have.
> >
> > So, in a multiple-dependent variable case, presumable we would maintain the
> > pattern, something like this?
> >
> > (var1, var2, var3 ...) {
> > func: returnValue <when-condition>;
> >
> > }
> >
> > I changed "property" to "func" for want of a better name. Though I must
> > confess I'm not sure what this would represent [...]
>
> I think it'd represent an I7-style relation, as in "Romeo loves
> Juliet" = loves(romeo, juliet). Or, going beyond what I7 supports,
> multi-way relations like "Gollum knows Frodo has the ring" = knows-
> has(gollum, frodo, ring).
I first came at this before Graham introduced relations to I7. (And I
wasn't thinking enough about dependent variables either.) So I
was breaking everything down to conditions, rather than relations.
(troll, sword) {
attack: <code> when <cond>;
}
would be shorthand for the rule
attack: <code> when (<cond> and (noun==troll) and (second==sword));
...the conditions just pile up. I'm up in the air whether "noun" and
"second" are dependent variables here, or global variables (as I6 has
them). I'm enough of a functionalist to prefer the former. So they'd
be declared somewhere. But this syntax, as I said, is handwaving.
I like relations but I would rather cast them into this form --
function-name, conditions, code -- to work with. That covers inherited
values (the condition is broad), and computed values as well. (I7
supports inherited properties and computed properties, but not
inherited or computed *relations*, despite the logical similarity of a
property to a one-place relation.)
And of course a zero-place property is a constant, or a variable,
or a function, depending on what the <code> looks like. Or, if there
are many rules for it with different conditions, it's a rulebook. If
we use these for *every* constant, including string constants, you get
a vast amount of library customizability for free.
Obviously I'm assuming that the compiler can optimize the hell out of
a simple property. The runtime cost for using a zero-place constant
property should be zero.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
Ron Newcomb
> Juliet" = loves(romeo, juliet). Or, going beyond what I7 supports,
> multi-way relations like "Gollum knows Frodo has the ring" = knows-
> has(gollum, frodo, ring).
In Prolog, that's written:
knows(Gollum, has(Frodo, ring))
-R
Emily Short
> I like relations but I would rather cast them into this form --
> function-name, conditions, code -- to work with. That covers inherited
> values (the condition is broad), and computed values as well. (I7
> supports inherited properties and computed properties, but not
> inherited or computed *relations*
Just to clarify this bit, since I'm confused: do you mean something
different by "computed relation" than I7's conditional relations like
Contact relates a thing (called X) to a thing (called Y) when X is
part of Y or Y is part of X.
and if so, what do you have in mind? (I agree that inherited relations
would be swell. That would simplify initializing the relations of
clothing types in my clothing examples, among other things.)
Andrew Plotkin
> On Mar 28, 12:22 pm, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > I like relations but I would rather cast them into this form --
> > function-name, conditions, code -- to work with. That covers inherited
> > values (the condition is broad), and computed values as well. (I7
> > supports inherited properties and computed properties, but not
> > inherited or computed *relations*
>
> Just to clarify this bit, since I'm confused: do you mean something
> different by "computed relation" than I7's conditional relations like
>
> Contact relates a thing (called X) to a thing (called Y) when X is
> part of Y or Y is part of X.
No, that's what I meant. Sorry. My brain must have been stuck in an
earlier version of I7.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.
greg
> True, but as Ron said, there *is* sometimes a need to break that
> convention.
Most systems provide some way to do that. E.g. in Tads
you can "extend" an existing class, but you have to
be fairly deliberate about doing it, which means there's
less likelihood that you'll do it without a good reason.
Even then, one still has the idea firmly in mind
that all the parts of the class are really part of
the same object, even if they happen to be written in
different places in the source. There's a solidity
to the conceptual model that isn't present in the
rule-based version.
-
Greg
JDC
<jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
> One focus was looking at how readers read static fiction and how they think
> about the character and the actions going on. A reader might say "Hmm, okay,
> Jim-Bob is clearly plotting revenge against Mary-Sue here. But would that
> really help him?" It's an interior dialogue that the reader has about the
> story they are reading. (I've been involved in some interesting studies --
> not related to IF -- where people are encouraged to read stories aloud and
> intersperse with their 'commentary' on what they're thinking about as they
> read. It's really fascinating stuff, actually, but I guess I'm straying
> here.) That interior dialogue can be made more manifest in textual IF via
> the actions a player takes. That, in fact, is something that *really*
> intrigues my writers. The ability of the reader to "experiment" as it were
> and see what happens. But, then, that leads to this interesting dichotomy
> between "action steps" or more "conceptual actions."
This reminds me of some aspects of Victor Gijsber's works, where the
game essentially asks you to specify why you are doing the things you
do. And the choice you make might not have any effect on changing the
further course of the game, but I find the act of specifying the
choice does actually effect my perception of what is happening.
It's not clear, though, whether I am (or should be) specifying the
PC's motivations or my own opinions on the actions (but this is an
issue with any sort of choice in IF, I suppose).
-JDC
JDC
> Here, JDC <jd...@psu.edu> wrote:
>
> > Another thing that has struck me reading this thread is that noun-less
> > verbs are pretty uncommon in IF. A lot of the ones that are used can
> > be viewed as having implicit nouns ("look", e.g., applied to the
> > location object, and similarly for directional commands).
>
> Sleep, wake up, wait, listen... those have fairly common currency as
> plot-relevant actions in IF games. (Listen can have a noun but often
> doesn't. In my games I frequently implement breathe/inhale/smell in
> the same way -- noun optional.)
>
> Get up, unless you consider that a directional command. Pray, sing,
> jump (but it is rare for those to be meaningful beyond library-default
> responses).
Good points (although I might claim that the sensory verbs have
natural implicit objects, generally the location).
> I prefer to think of OO as being suited only to the special case of
> *one* relevant noun. :)
I strongly agree with this. And I really do like rules-based approach;
it fits the way my brain works. And anyone who has seen one of my
desks would understand why the possibility of code ending up scattered
in different places (which seems to be a concern with Jeff's group)
doesn't bother me :).
> As *other* others have noted, there's no reason that the step-by-step
> action can't *be* at a different conceptual level. Imagine a game
> where you are a corporation, preventing (or causing) global
> catastrophe with a small set of familiar verbs like "acquire company",
> "spin off division", "fund invention", "cancel project". Same rhythm
> of play as Zork, but different level of abstraction.
Has anyone actually written a game where all or most of the actions
are at a higher level of abstraction like this? I can think of some
examples where there are particular moments where this happens, but
not one where it is maintained throughout.
-JDC
Jeff Nyman
> It's not clear, though, whether I am (or should be) specifying the
> PC's motivations or my own opinions on the actions (but this is an
> issue with any sort of choice in IF, I suppose).
Yes, this was an interesting area of study, I think. Specifically, you can't
ask the player to not have opinions or thoughts any more than you can do so
when they're reading a novel. Readers are always "judging" the actions and
motivations of characters. The difference in textual IF is that they can
actually attempt to influence this in some way, by interspersing their own
thoughts, opinions, etc.
On one hand that seems to argue *against* too much characterization of the
PC and thus of a narrative arc that depends on the PC's relation to the
world separate from the player. (After all, the player has no actual past
with the NPCs or the world, and so cannot have any true emotional
involvement with it. The PC, qua story character, does have such a past --
but that's often not considered in textual IF and so, again, authors don't
have to worry about that emotional involvement aspect.)
The argument is usually that since the player can affect things in ways the
author didn't anticipate (or at least in the order that the author
anticipated) and since the player can take longer or shorter to do certain
things (thus ruining pacing and perhaps defusing tension), it doesn't make
sense to craft such a story as a running narrative because it's too easy for
the narrative to "break."
On the other hand, this seems to argue *for* a possible direction in textual
IF, where the characterization of the PC is something the player is asked to
learn about, perhaps juxtaposing their own thoughts/opinions with the
demonstrated thoughts/opinions of the PC. In other words, you're in it
together. How I've often liked to think of it is that textual IF allows you
to be the "subconscious" (and perhaps the conscience?) of the PC. Much as
our own own thoughts in the real world sometimes suggest one thing, but we
do another, it would be interesting to see the extent to which this can be
incorporated into textual IF while still allowing the player to actually
proceed (rather than being told "I don't want to do that" or "You don't want
to do that").
Note, of course, that this style of textual IF would probably not be for
everyone. In another thread, there was talk of the "right direction" for
textual IF and I don't think there is such a thing. I do think there are
different directions textual IF can go to please different types of
audiences. The idea of choices made and actions taken can be a powerful
thing when the PC and the player are "forced" to disagree to some extent.
But there's also the much simpler aspect of a world being described to you
by a PC with his/her own biases, prejudices, interpretations, feelings,
moods, etc. In other words, you have to figure out a world that is being
described to you by a character that has their own motivations and interests
at heart, meaning you've got to learn to "work with" this person and figure
out what they're seeing and what's really happening.
- Jeff
R. Alan Monroe
news:5q6dncX7IbFjpHPa...@comcast.com:
> perhaps the conscience?) of the PC. Much as our own own thoughts in
> the real world sometimes suggest one thing, but we do another, it
> would be interesting to see the extent to which this can be
> incorporated into textual IF while still allowing the player to
> actually proceed (rather than being told "I don't want to do that" or
> "You don't want to do that").
[Your cognitive dissonance goes up by 1.]
>
Alan
Andrew Plotkin
Sure. Solidity is the opposite of flexibility.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.
Nikos Chantziaras
> Here, greg <gr...@cosc.canterbury.ac.nz> wrote:
>> Andrew Plotkin wrote:
>>> True, but as Ron said, there *is* sometimes a need to break that
>>> convention.
>> Most systems provide some way to do that. E.g. in Tads
>> you can "extend" an existing class, but you have to
>> be fairly deliberate about doing it, which means there's
>> less likelihood that you'll do it without a good reason.
>>
>> Even then, one still has the idea firmly in mind
>> that all the parts of the class are really part of
>> the same object, even if they happen to be written in
>> different places in the source. There's a solidity
>> to the conceptual model that isn't present in the
>> rule-based version.
>
> Sure. Solidity is the opposite of flexibility.
It's funny how some people complain about the system being too flexible
for its own good, and then others complain it's not flexible enough.
Guess you can't have them all.
JDC
> "Jeff Nyman" <jeffnyman__@__NOSPAM__gmail.com> wrote innews:5q6dncX7IbFjpHPa...@comcast.com:
>
> > perhaps the conscience?) of the PC. Much as our own own thoughts in
> > the real world sometimes suggest one thing, but we do another, it
> > would be interesting to see the extent to which this can be
> > incorporated into textual IF while still allowing the player to
> > actually proceed (rather than being told "I don't want to do that" or
> > "You don't want to do that").
>
> [Your cognitive dissonance goes up by 1.]
[Continuing a bit further off the original topic here...]
In tabletop RPGs players can be rewarded or penalized depending on how
well they play their character, e.g., by adding or deducting
experience points. I don't know if something similar happens in CRPGS
(I haven't played any recent ones, and I don't remember anything like
this from the ones I played long ago). As Jeff says, it could be
interesting to try something like this in IF; the player could be
allowed to do things which don't fit with the PC's character, but with
some sort of penalty attached. This might help encourage the player to
play a role (or it might simply break immersion; I'm not sure).
-JDC
greg
> It's funny how some people complain about the system being too flexible
> for its own good, and then others complain it's not flexible enough.
I would say it's good if the system can be made to flex
where and when you want it to, but bad if it's so flexible
that it flops around on its own.
--
Greg
Fergus Mcneill
"greg" <gr...@cosc.canterbury.ac.nz> wrote in message
news:65r6b6F...@mid.individual.net...
Your an idiot Greg.
