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