Teaching Storytelling (via IF)
Jeff Nyman
its nose in here and there, it's taken me a lot longer to get through some
of my analysis as well as the classes as I would have liked. But I finally
did get through one full "semester" and actually have some findings. I'll
just throw them out in anecdotal form here. The full write up is still being
done. This is a bit of a long post so feel free to ignore if you have no
clue what I'm even talking about here.
= = = = = = = =
For those who remember, I was teaching (in the loosest sense of the word) a
class that included writers (who had at least short stories or one novel
published), writer wanna-be's [meaning, their primary aim was to write
stories, not games] and game writer wanna-be's [meaning, their primary aim
was to write games, not stories]. There was a breakdown of who did and did
not have programming experience but it was a distinction I ended up caring
less about. The one truism was that none of the people had programmed
Interactive Fiction before. (Some had played it, either long ago or
recently, but it wasn't something I worried about too much. The key thing
for me was that they had not specifically programmed in it.)
The focus was on Inform 7, with side-trips into TADS 3. (Similar to how you
might learn, say, Python but also do some dabbling into C to show a
different style of programming.) The goal there was to provide some context
of two different "schools of thought" regarding the nature of crafting
stories in the format of Interactive Fiction. I word that precisely because
the goal really was to see how receptive various people were to Interactive
Fiction as a method of storytelling (whether that be for a game purpose or
for a "pure" story-telling purpose).
I find some really interesting things. (To me they were interesting. To
others, they may either be totally obvious or so uninteresting as to elicit
surprise that I would find them interesting.)
= = = = = = = =
Inform 7 vs. TADS 3: the end result -- no one really cared in a lot of ways.
The different "style" of programming didn't matter except to those who were
already programmers and had issue with recasting their thinking.
Interestingly, I had one programmer who was very proficient with LISP and
Prolog and so, to him, Inform 7 was by far the easier to conceptualize. I
had another who was very proficient with Python and so to him Inform 7
actually matched a lot of those Pythonic constructs (such as using
spaces/tabs to indent). But I also had a C++/Java guru who most emphatically
preferred TADS 3 in terms of programming language.
** BUT ** even with those preferences of style, no one felt that the style
unduly constrained what they could do. In other words, in terms of looking
at these tools as storytelling engines, no one felt that one had a clear
advantage over the other unless you were looking at aspects that didn't
relate to storytelling, such as trying to create pure simulation works or
so-called "emergent solution" games. (I should briefly note that both
largely simulationist works as well as emergent solution games were found
to be almost antithetical to good storytelling and narrative.)
This lack of concern about the system held even when we discussed aspects of
conversational NPCs or "real-world" modeling of things, like ropes and
liquids. As far as the massive world-model of TADS 3 and the sparse one of
Inform 7, no one really cared. The only thing I can say is that most people
had a very difficult time relating story aspects to rules and relations.
People (even the non-programmers) were much better able to conceptualize
their story ideas when those ideas were concretized as objects that had
certain [attributes/properties/settings/fields/whatever] rather than as a
perceived vague grouping of statements that executed in a certain order
under certain conditions [rules, primarily].
To determine how "real" this was, we did some aspects of testing ideas in
TADS 3 and Inform 7. One of these was using the rules.t extension (since
updated to a rulebooks library) in TADS. People found they used the
rulebooks -- but only very sparingly and only for very limited situations. I
had a JBoss programmer as well as a Prolog programmer and they felt more at
home with the rules structure but also felt it wasn't necessarily the best
path for a game programming medium. (They were emphasizing the game aspects
rather than the story aspects.)
Now here's the main thing I found interesting: the storytellers in my crowd
didn't feel that object-based vs. rules-oriented approaches really had any
bearing on the ability to *tell a story.* Everyone agreed it might have some
impact on the ability to craft puzzles but even then it was felt that it
just depended on your level of experience with the programming style in
question. Even with that being said, the overall consensus was that people
would probably create more "puzzly" games with Inform 7 because using
relations and rules almost forces you to that kind of thinking; TADS 3, it
was felt, could lead people to focus on narrative-driven games because the
emphasis was seen as more on how individual objects interact rather than as
how the world as a whole acts.
[I found this interesting because, to me, it actually focused on the wrong
elements of both languages but, on the other hand, it showed me how people
perceive the tools and, further, allowed me to draw those conceptual maps
along the lines of what people were primarily intending to produce: game or
story. An interesting side-note is that people felt TADS 3 would be used to
create more "puzzly" games *if it was used as a simulationist engine*, which
it was felt TADS's library "encouraged." On the other hand, TADS was felt to
allow for more story possibilities given its structure if most of the
library was not utilized. Inform 7, on the other hand, it was felt
encouraged more emphasis on story than on game mechanics because of its
sparse library but the rule structure was hard to relate to the idea of
story elements.]
= = = = = = = =
** Presentation **
People didn't give a hoot about the presentational elements. In fact, the
"flashier" or more "typographic" the interpreter, the less it was liked.
Gargoyle, for example, was most definitely not liked by just about anyone.
People tended to prefer white background with black text with as little
"font fanciness" as possible. Most didn't like blue background with white
text and about the most that people want to see in terms of text formatting
was bold and italics.
People really liked the minimalist approach because it provided more
emphasis on the story. (The strict game writer wanna-be's didn't like the
lack of glitz but, for them, that really applied to a text-based medium as a
whole, rather than the interpreter. When they got hooked on a game, they too
didn't seem to miss any of the so-called flashier presentation elements.)
Graphics were almost universally seen as distracting. We didn't do anything
with sound in our own stories but the feedback I got was sound would be
similarly unwelcome. We did play around with "Spellcasting 101" and
"Timequest," both of which do use sound. People didn't like it. We also had
a "Lurking Horror" that was capable of playing sound. Sparse as it was, it
was still thought to severely detract from the story. Similarly, menu-based
approaches or "clickable" areas were seen as similarly "childish" looking.
Even the hyperlinks of TADS were not liked all that much at all and were
seen as an intruding element rather than a welcome shortcut. Menu-based
conversations were seen as a huge distraction and disruptive of narrative
flow.
[That being said, we did some experiments to see how this could be
mitigated. The problem is that people found they "left the narrative" when
encountering a menu because they had to stop and think what the alternative
choices might get them and they didn't know if they could go back. So, in
the end, menus were found to be not so great from a story-telling
perspective but were agreed to be a useful game mechanism.]
** System abilities**
Most people didn't care how "powerful" one system was over another or what
was going on "under the hood." What everyone was most concerned about was
how much and to what extent you could have text itself change based on
context and situation and how easy it was to manipulate text. The one
"power" most people saw (from a writing perspective) was the ability to
allow for fluid text, something that isn't obviously allowed in your average
printed book.
The ability to contextualize text based on a player's *growing understanding
of the world* was seem as being of paramount importance. (Interestingly,
here most everyone found Inform 7 a little weaker than TADS 3. This was even
the case with the non-programmers. The problem was with limits that people
felt were in place regarding how you could manipulate the text, in terms of
spacing, as well as how convoluted some double-quoted strings became when
you really wanted to conditionalize quite a bit. For example, we often had
to work quite a bit to get the spacing of text accurate, such as with [line
break] and [paragraph break] and [run paragraph on]. This was felt to be too
intrusive to the game text -- from a writing perspetive, obvoiusly, not from
a game player perspective. But the problem was that sometimes this lead the
writers to trying to get the text formatted exactly right for the player and
this was discouraging.)
** "Lifelike" NPCs **
No one really cared for this too much. It depended on execution, of course,
but just like in printed novels, dialogue is often sharp and to the point
and the actions of other characters than the protagonist are often
constrained by the dictates of the story, as opposed to some aspect of
realism. That's how people wanted to see the games written more.
What was appreciated was the ability to (again) contextualize the text
surrounding an NPC (both in terms of how the NPC was described as acting)
and what the NPC had to say. (For example, the NPC repeating the exact same
clump of dialogue was seen as a bit less than optimal.) NPCs that were truly
"realistic" -- meaning that wandered all over the place or were capable of
apparently purposeful action -- were seen as distracting. The thief from
"Zork," for example, was considered a bad element. (Maybe not to the game
play perspective, but from a story perspective.) A game that was felt to
strike a good balance was "Babel" (relatively recent) and "Plundered Hearts"
(relatively not so recent).
As I briefly alluded to earlier, menu-based conversations were seen as
horribly distracting and completely breaking of the story. One of my authors
referred to these as "gaping potholes in the narrative flow." (One recent
game we looked at was "Fate" and while people really enjoyed the story, they
didn't like the menu-based conversations. Although, that said, they did
recognize the challenge in trying to present how to communicate with NPCs.)
** Viewpoint **
No one felt third-person was very workable. We tried to write various story
ideas (short snippets of them) with various viewpoints. First-person and
second-person were in constant competition for the preferred mode. (Some of
you may remember my "use of second person" discussion from way back when
dinosaurs still wore polyester. Well, I've come to accept and embrace some
of the storytelling possibilities of second person.)
In the end, the general agreement was that truly story-driven "game" worked
better in first-person, but the quality of writing had to be pretty high.
However, in a game that placed equal emphasis on puzzles along with story
(or with just puzzles), second-person was found to be much more effective.
Alternatively, if the author wasn't all that good at crafting narrative and
wasn't good at knowing when to step in and out of protagonist introspection
and/or exposition, second-person was better. But when the author was an
effective storyteller first (and game writer second), first-person always
won hands down.
There is one major exception to this: if multiple viewpoints were allowed in
the story, third-person one hands down. However, the reaction against
third-person even in this venue went very much to the storytelling ability
of the author. The story had to be engaging and the different viewpoints
truly had to seem like different viewpoints, meaning different protagonists.
One of the major challenges we worked on was getting characters that the
player had to learn about -- and this also fed back into that
"contextualized descriptions" and "situational narrative text" that I
mentioned a couple times now.
And that last point speaks to all of the viewpoint issues as well as some
wider ones: just about everyone felt that current and past Interactive
Fiction was lacking in making the protagonist just as much a "puzzle" to
figure out as the situation and/or game world. No one who had any
storytelling bone in their body liked the conflation of the player with the
player character, at least when that meant getting to "know" the player
character was subsumed. Most of the storyteller crowd felt that learning
about who the player character was, and what their limitations were, and
then working within those to solve the game, was something that wasn't done
all that much.
= = = = = = = =
As I mentioned, a lot of this involved Inform 7 as the focus. So what were
the thoughts there?
In general, very positive.
One of my authors, for example, had already had a vampire book published (by
Permuted Press). He was working on a sequel and he found that one thing
Inform helped him do was prototype the story. For example, he wanted to work
on a "siege scene" for the novel. He wanted his characters to have to use
things around the house to barricade themselves and eventually to fend off a
siege of vampires. He used Inform to craft a location (the house) and then
set about creating items within it, using the player character as a foil to
determine what they would have to do in order to survive.
Another author is publishing an online science-fiction novel. He used Inform
7 to flesh out ideas for what the spaceship would look like, what it would
contain, what it's layout would be, and how to take the reader through it
(in narrative) by seeing how to take the player through it (in game).
I found prototyping to be an aspect of Inform that people really liked.
What I found was that people more often than not found it easier to
conceptualize Check, Carry Out, and Report. The Before, Instead, After
didn't (for various reasons) seem to fit well into their thinking of a
player interacting with their story. But I can expand on this a bit.
People were much more comfortable with the idea of "rules" being attached to
a specific object (or an entire class of objects). This was felt to provide
a logical mechanism for concentrating relevant code in a given location in
the source. So it definitely helped to present aspects in a more
object-oriented format but then show how rules "attach" to those objects.
Even if that isn't quite entirely correct, with that visual in mind, people
were more readily able to grasp the concepts. (This is mainly due, I think,
to the fact that people respond much better to visual-spatial concepts and
can relate those to what we call "objects." Rules seem like an amorphous
cloud of facts -- which they sort of are -- and don't seem concrete unless
you are applying them to some object base. Plus heuristic-based thinking,
although subject to rules, is concretized around rules-affecting-objects.)
People didn't like how the structure of when to use Before, Instead, After,
Check, Carry Out, and Report was so seemingly arbitrary. (I would argue it's
not arbitrary -- at least when you get down to it -- but it does sometimes
seem that way.) People were also concerned about how one structure (like
using Before/Instead) could cause problems with some of their other
structures (like Carry Out/Report). They weren't always sure what effects a
lot of their code would have and, of course, that's the kiss of death for
any programming language, at least in a lot of people's estimation. The
problem here, however, was more from a storytelling perspective. People
simply couldn't relate "rulebooks" to stories very well.
Further, the ability to have rules succeed (pass) or stop (fail) often
seemed arbitrary to people as well. Eventually they just fiddled enough to
get things to work. But that left everyone feeling like they were building
on a house of cards.
People loved the recipe book concept. My kudos to Emily and crew for putting
that in place. It was a fantastic addition. The response to this was that it
truly added to the understanding of Inform. Interestingly, I found this also
tied in with the lack of concern for "system abilities" or the "power" of
the system. People weren't really interested in all the things you could do
with relations or every single way a rule could be used (or whether it was
action-based or object-based). They just wanted to have an understanding of
the different "things" they could do, with perhaps some explanation of how
to generalize those things a bit for situations. (In fact, many people felt
that the use of relations and elaborate rules would be things that were used
just because they were there; i.e., to create "gimmicks" or clever coding
mechanisms but that would ultimately not serve any aspect of the evolving
story.)
In other words, and this is the best way I could think of it, they basically
wanted a running tutorial that was also part of the Recipe Book. In other
words, the Recipe Book contains all that it currently contains, but an
extended tutorial example runs through the whole thing like a thread. In
taking a brief excursion into the DM4 to show them how "Ruins" was built up,
everyone was unanimous: "Anything but that!" Here the complaint was that
"Ruins" was interspersed with too much other material. Then we took a brief
look at the IBG. People liked that but felt there wasn't enough to explain
how to generalize and/or modify. So that's what I mean by combining the
tutorial aspect (IBG) with the reference/explanatory aspect (DM4 Ruins,
current Recipe Book). We started to do this with our own example called
"Zork: Age of Science", where we combined some fantasy, some horror, some
science-fiction and even some romance to try to appeal to various
storytellers in the crowd as well as to see various narrative possibilities.
All of this so far was just with a crowd of adults. I did a very different
round of testing -- less-extensive, certainly -- with a group of children
and pre-teens. The children ranged in age from 9 to 12. The second group
were teens, ranged in age from 13 to 16. (I really have to thank Andrew High
School, Tinley Junior High, and the Kruse School District for allowing me
access not only to the students, but also to their facilities for a
non-credited "course" that was utilized during "zero hour", lunch times, and
after school time frames. I also have to thank the Parent Teacher
Association of Kruse School for giving some help with this in terms of
coordinating activities.)
Anyway, that's about it for now. Just wanted to update with some anecdotal
material. I plan to write up something a bit more formal about these
experiences but I literally have so much material -- from both groups --
that we talked about and discussed that it's going to take me awhile to
distill everything.
- Jeff
Emily Short
<jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
> In between a little bout with some health problems and real life sticking
> its nose in here and there, it's taken me a lot longer to get through some
> of my analysis as well as the classes as I would have liked. But I finally
> did get through one full "semester" and actually have some findings. I'll
> just throw them out in anecdotal form here. The full write up is still being
> done. This is a bit of a long post so feel free to ignore if you have no
> clue what I'm even talking about here.
This is really intriguing and helpful. Thanks very much for taking the
time to do this research and then write it up so thoroughly.
I'm still chewing it over, so may have more questions later that I
don't have now, but in the meantime, I wanted to say this kind of
input is highly appreciated.
> [That being said, we did some experiments to see how this could be
> mitigated. The problem is that people found they "left the narrative" when
> encountering a menu because they had to stop and think what the alternative
> choices might get them and they didn't know if they could go back. So, in
> the end, menus were found to be not so great from a story-telling
> perspective but were agreed to be a useful game mechanism.]
What did they think about TADS 3-style conversation prompts like "(You
could ask the Duke about the death of the Duchess.)"?
> He was working on a sequel and he found that one thing
> Inform helped him do was prototype the story. For example, he wanted to work
> on a "siege scene" for the novel. He wanted his characters to have to use
> things around the house to barricade themselves and eventually to fend off a
> siege of vampires. He used Inform to craft a location (the house) and then
> set about creating items within it, using the player character as a foil to
> determine what they would have to do in order to survive.
This is something I hadn't really thought about at all. I wonder how
many other people do this kind of work with Inform, and whether it's
something we could support better.
> Further, the ability to have rules succeed (pass) or stop (fail) often
> seemed arbitrary to people as well. Eventually they just fiddled enough to
> get things to work. But that left everyone feeling like they were building
> on a house of cards.
It's pretty clear from conversation here as well that we could do a
better job of fully explaining action handling and making all the
pieces of the process sufficiently open, so this doesn't entirely
surprise me.
> In other
> words, the Recipe Book contains all that it currently contains, but an
> extended tutorial example runs through the whole thing like a thread. In
> taking a brief excursion into the DM4 to show them how "Ruins" was built up,
> everyone was unanimous: "Anything but that!" Here the complaint was that
> "Ruins" was interspersed with too much other material. Then we took a brief
> look at the IBG. People liked that but felt there wasn't enough to explain
> how to generalize and/or modify. So that's what I mean by combining the
> tutorial aspect (IBG) with the reference/explanatory aspect (DM4 Ruins,
> current Recipe Book).
Hrm. It's not quite clear to me how to do this -- I mean, I can
imagine gluing a running tutorial into the Recipe Book. In fact Graham
and I at one point talked about having a chapter of the recipe book
that was another opening tutorial, rather longer and more complex than
the charter boat example, but that idea got shelved because it would
take longer to write than I had time for at the time. But it's hard
for me to imagine how to do a running example that also gave enough
possibility for "expansion" without it getting Ruins-esque in the
amount of interspersed material. A running tutorial in the Recipe Book
couldn't very easily be tied into the main documentation, either, so I
wouldn't want such a thing to replace the existing examples.
What I have been thinking recently is that the current tutorial
materials aren't oriented very well around things like, "okay, I want
to make a new action. How do I do that from start to finish? What are
the possible variations? What design concerns should I be worried
about (such as providing synonyms, deciding what kinds of rules to
use, handling different kinds of phrasing that the player could use,
communicating hints to the player about the use of this action,
etc.)?" Or "How do I write text that encourages the player to explore
interactively? What goes into constructing and structuring prose, from
an IF perspective?" And so on. Which sounds like not quite what you're
asking for, but I wonder whether it would have helped bridge the gap a
bit in terms of thinking about the relation between IF mechanics and
good story-telling (or game design, for that matter).
> We started to do this with our own example called
> "Zork: Age of Science", where we combined some fantasy, some horror, some
> science-fiction and even some romance to try to appeal to various
> storytellers in the crowd as well as to see various narrative possibilities.
Is that available anywhere?
Jeff Nyman
news:e959a596-204f-46cc...@60g2000hsy.googlegroups.com...
> This is really intriguing and helpful. Thanks very much for taking the
> time to do this research and then write it up so thoroughly.
In fact, I wish I could be more thorough. I really want to try to write this
up more concisely but with more detail. Also, part of what I now really want
to work on is a "tutorial" based on my experiences.
> What did they think about TADS 3-style conversation prompts like "(You
> could ask the Duke about the death of the Duchess.)"?
AH! Excellent point. How could I forget to mention this? Interestingly,
people didn't like this all that much but opinions were somewhat divided.
The idea was that as a mechanism to suggest where to go next, it was at
least helpful. But, from a storytelling perspective, it was found to be a
bit too intrusive.
A common consensus seemed to swirl around the idea of having some mechanism
whereby the player could "query" the player character in some sense about
what he/she thinks they have learned so far. Sort of like "go through the
memory" of what's happened. Or perhaps a "summarize" command that allowed
the player character to give *their* take on what has so far transpired.
This latter idea had a lot of takers because of the idea of not conflating
the player character with the player. In other words, the player's job is to
determine not just what's going on but to figure out how the PC is thinking
about things.
Another element was having the player character sort of summarize things via
minimal exposition which would in turn suggest what to ask about or what to
do next. So instead of:
"You could ask the Duke about the death of the Duchess."
Something like:
"I knew I should probably take this moment to ask the Duke about the death
of the Duchess."
So the idea was never allowing things like menus or suggested topic prompts
to appear exterior to the story but rather allowing the player to figure out
what to ask based on what the player character thinks and how the player
character responds. It was definitely realized this could be challening and
one added challenge to that (which I tried to get people to look at) was
allowing for the player character to totally come up with an out-of-left
field interpretation that the *player* would be surprised at. This wouldn't
be "unreliable narrator" so much but rather just exploring a world through
someone else's eyes and further it's someone that has their own personality,
their own opinions, etc. So while you as the player might think it obvious
to ask the Duke about certain things, the player character may take you in a
totally different direction.
This, by the way, was the only level of "emergence" we found useful, wherein
the player can be surprised not just by the story elements but by the way
the story elements play out, based on how much or how little this accords
with what they *thought* they knew or understood. We started getting
perilously close to character-driven stories, where the focus was definitely
on the plot but it was how the plot expanded and took on shape based on how
the characters helped the player drive the story along. (I'm *not*
explaining that well.)
> This is something I hadn't really thought about at all. I wonder how
> many other people do this kind of work with Inform, and whether it's
> something we could support better.
I can tell you I'm using it this way for my zombie novel (tentatively titled
"The Dead Cycle"). In fact, it was during writing this novel that I got some
of the ideas for using Inform 7 in this way and that led to talking to other
writers and that, in turn, led to the classes. I've been thinking about this
too -- in terms of "could it be supported" -- because one thing that people
kept coming up with was the notion of how they couldn't relate the rules to
the storytelling. But when crafting the story (for your novel), you're often
thinking of how your characters are going to be constrained. After all, the
narrative path and pacing will suggest some of that. So I actually started
to see the rules as a way to look at narrative and pacing by saying "these
rules can only fire in these situations *and that's because I need this
narrative fork to continue*."
Now, granted, one issue is that the rules are very "programmatically" named,
as opposed to being named in the context of a story, so I think that was
part of people's "resistance" to seeing how rules could be used as gating
mechanisms of some sort. What I started to look at was coming up with
rulebooks with more "storytelling" names that would then essentially
encapsulate the regular rulebooks. I'm not sure if this is a viable approach
but it's what I'm looking at now.
> It's pretty clear from conversation here as well that we could do a
> better job of fully explaining action handling and making all the
> pieces of the process sufficiently open, so this doesn't entirely
> surprise me.
I usually found if I just clearly broke down all of the action handling
points, people would come around. What I ended up doing was taking parts
from 7.1 to 7.5 (including 7.8 and 7.9) and just talking about those, with a
minimum of examples. Then I brought in some stuff from chapter 12
(specifically just 12.1, 12.2, 12.9). This allowed people to see the full
Before, Instead, Check, Carry Out, Report, After process in one go. I could
then present some examples of when they should use both. For example, just a
really simple thing:
[[ START: INFORM 7 CODE ]]
The trap door is a door. It is open. It is lockable. It is down from the
Stage and up from the Platform.
The player carries an iron key.
The iron key unlocks the trap door.
[Before locking the trap door with, try closing the trap door.]
[Instead of locking the trap door with, try closing the trap door.]
[[ END: INFORM 7 CODE ]]
Here I would then have them uncomment whatever one they wanted to try. Here,
of course, the Before rule does what you want. The Instead does not because
it just closes the door but doesn't lock it. Simple examples like that
really helped convey *when* to use certain rules over others.
Another example:
[[ START: INFORM 7 CODE ]]
The trap door is a door. It is open. It is down from the Stage and up from
the Platform.
[Before entering the trap door, try going down.]
[Instead of entering the trap door, try going down.]
[[ END: INFORM 7 CODE ]]
Here I could easily show the Before rule does the one action "going down"
and then also fires the "enter trap door" action, which takes you back up.
The Instead rule, on the other hand, does exactly what you want.
As you can imagine, I then did similar examples with using Check, Carry Out,
and Report.
> Hrm. It's not quite clear to me how to do this -- I mean, I can
> imagine gluing a running tutorial into the Recipe Book. In fact Graham
> and I at one point talked about having a chapter of the recipe book
> that was another opening tutorial, rather longer and more complex than
> the charter boat example, but that idea got shelved because it would
> take longer to write than I had time for at the time. But it's hard
> for me to imagine how to do a running example that also gave enough
> possibility for "expansion" without it getting Ruins-esque in the
> amount of interspersed material. A running tutorial in the Recipe Book
> couldn't very easily be tied into the main documentation, either, so I
> wouldn't want such a thing to replace the existing examples.
Right -- this was an area I was trying to figure out as well. I'm still
looking into a good way to do this. I've made a few starts but then I keep
running into "Ah, well, if I show that, I have to show this first." I'm
convinced there is some way to do this, I just haven't found it yet.
That's actually my current goal: to write up some kind of tutorial that can
cover all the relevant aspects in a way that allows people to gradually
accrete knowledge of how Inform works.
> Is that available anywhere?
Not quite yet. I'm getting there. I'm trying to distill everything we did
into some format that's a bit more intelligble. My one regret is that I
didn't structure this better at the beginning so that we had clear-cut
goals. So much of this grew organically that to people not participating,
the end result looks a bit messy. I should add that we did use the Inform 7
IDE a lot but we mainly used EditPad Pro and I built a batch file system
that allowed multi-source file compilation as well as viewing the generated
Index material outside of the IDE. So part of this organic growth means
material spread over numerous source files.
- Jeff
Jeff Houck
observations have piqued a bit of interest in me regarding the way I had
thought to approach an IF work in which I'm currently engaged in writing.
Graham Nelson
commentary is: food for thought. I too think it would be very well
worth-while writing up a formal paper on your experiences with these
classes.
Jim Aikin
> One of my authors, for example, had already had a vampire book published (by
> Permuted Press). He was working on a sequel and he found that one thing
> Inform helped him do was prototype the story. For example, he wanted to work
> on a "siege scene" for the novel. He wanted his characters to have to use
> things around the house to barricade themselves and eventually to fend off a
> siege of vampires.
That was about three different episodes of _Buffy_, wasn't it? Including
one near the end of the last season, after Zander's eye has been put out.
I may have a more substantive response to this excellent post later.
--JA
Jim Aikin
> The ability to contextualize text based on a player's *growing understanding
> of the world* was seem as being of paramount importance.
This should be tattooed somewhere or other.
An example of this technique, in the DM4, was transforming the name of
an object from "that harmless old book of Geoffrey's" to "that lethal
old book of Geoffrey's".
The technique probably works better with short bits like this than with
room descriptions. A room description _should_ change as the player
character's knowledge grows, but who has the patience to keep reading
room descriptions to see if anything has changed? (Of course, you can
put the game in brief mode and then make a room unvisited if its
description has changed, but making it unvisited might have side
effects....)
> And that last point speaks to all of the viewpoint issues as well as some
> wider ones: just about everyone felt that current and past Interactive
> Fiction was lacking in making the protagonist just as much a "puzzle" to
> figure out as the situation and/or game world. No one who had any
> storytelling bone in their body liked the conflation of the player with the
> player character, at least when that meant getting to "know" the player
> character was subsumed. Most of the storyteller crowd felt that learning
> about who the player character was, and what their limitations were, and
> then working within those to solve the game, was something that wasn't done
> all that much.
This is extremely interesting. In a puzzle-oriented game, it hardly
matters that the PC is a cipher. In a story, it certainly does matter,
or should. The exception might be a story like Moby-Dick, where the
viewpoint character is not the main character. But that's probably not a
good approach to IF.
I can see two techniques for characterizing "you" in more concrete ways.
There may be others. First, how the software responds to the player's
commands, and second, how NPCs react to the PC.
Even refusal messages can add character:
>climb tree
How unladylike! You'd surely run your stockings.
The trick, I think, is to make it seem as if the refusal is arising
within the PC, not that the parser is lecturing the PC (or the player).
Consider these three possible responses to a simple command:
>eat the bread
You're not hungry right now.
>eat the bread
You're not that hungry -- and besides, you still need to take off the
five pounds you gained over Christmas.
>eat the bread
You gaze at the bread, your mouth watering, and sigh deeply. You're
beginning to regret that you promised yourself you'd lose the five
pounds you gained over Christmas.
The first fails to characterize the PC. The second gives us a bit of
background on the PC (getting a little chubby), but it comes off rather
as if the parser is lecturing. The third, while it's overwritten,
nevertheless makes it clear that the PC him/herself is the one who is
concerned about losing the weight -- and THAT creates characterization.
An NPC's reaction to the PC might work like this:
The duke leans forward and puts his hand on your knee. "Care for another
glass of sherry, my sweet?"
We can infer from this that the PC is reasonably young and attractive
and probably (though not certainly) female.
Here's an example from my most recent game -- a text output that gives a
feeling about the PC. The PC is a 12-year-old (sex unspecified, but
quite possibly male), who for puzzle-solving reasons needs to don a
magical wig. It's an ugly wig, and is intended to be worn by a woman:
>wear the wig
After a quick glance at the bedroom window to make sure none of your
friends has crept up with a ladder to watch you making such a fool of
yourself, you don the wig.
Since the PC's friends are not characters in the story, this is clearly
a momentary flash of adolescent paranoia -- and fitting even if the PC
is a girl, because the wig is ugly.
This particular game doesn't do very much to characterize the PC -- I'm
just suggesting that that type of text output is worth mulling over.
Replacing "Taken." with a whole paragraph for EVERY item in the game
would be horrible, but perhaps as much as 1/4 of the items in a typical
game might benefit from something like this:
>take knife
You wrap your fingers firmly around the hilt of the knife.
(We can guess from this that the PC is a warrior, or would like to be one.)
I think this type of thing is worth exploring. I hope others will chime
in with their ideas.
--JA
Ron Newcomb
<jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
Wow, thank you for all your time on this, Jeff. I feel a lot better
after reading, because I know that I'm not the only one who feels the
same way about many of those things your class mentioned:
> For example, we often had
> to work quite a bit to get the spacing of text accurate, such as with [line
> break] and [paragraph break] and [run paragraph on]. [snip] [T]his was
> discouraging.
I've already nagged the Inform 7 powers that be to allow me to define
what a line break is. (Number of carriage returns, indent or not,
etc.) Changing it is nearly impossible.
> The ability to contextualize text based on a player's *growing understanding
> of the world* was seem as being of paramount importance.
I've touched this too, asking how to do introductions, or a group of
objects' shared history, or just "smart text" in general, that knows
when it still needs to be presented to the player, and kinda keeps
track of what exposition the player himself knows. (Emily was kind
enough to make an Introductions extension which helps alleviate this a
bit.)
> People (even the non-programmers) were much better able to conceptualize
> their story ideas when those ideas were concretized as objects that had
> certain [attributes/properties/settings/fields/whatever] rather than as a
> perceived vague grouping of statements that executed in a certain order
> under certain conditions [rules, primarily].
(I never understood this issue. Objects make nouns, rules make
verbs. What's the problem?
Jim? Help?)
> No one who had any
> storytelling bone in their body liked the conflation of the player with the
> player character,
Eh? Wouldn't they feel that they were put out of the work by keeping
such a distance from the PC? Like, they were a puppetmaster above the
world instead of a person in it?
It's something of a law in RPGs that the DM doesn't tell the player
"you can't do that because your character doesn't feel like it /
doesn't understand why he should / knows something about himself that
you don't." Else, what's the player sitting at the table (or command
prompt) for? Just to watch the DM's genius?
Interesting also that only the ones already trained in written
fiction's storytelling keep that viewpoint regarding characters, while
all the others could go either way.
Looking forward to more of your posts, Jeff.
-Ron
denni...@gmail.com
> I too think it would be very well
> worth-while writing up a formal paper on your experiences with these
> classes.
I know I'd love to read something like that.
Jim Aikin
>
>> People (even the non-programmers) were much better able to conceptualize
>> their story ideas when those ideas were concretized as objects that had
>> certain [attributes/properties/settings/fields/whatever] rather than as a
>> perceived vague grouping of statements that executed in a certain order
>> under certain conditions [rules, primarily].
>
> (I never understood this issue. Objects make nouns, rules make
> verbs. What's the problem?
> Jim? Help?)
I can't speak for others, but my own view of it is that as I'm
attempting to learn to write I7 code, each rule that I devise feels
rather like a free-floating bit of DNA drifting through the protoplasmic
soup. (This may be simply because I don't understand yet what I7 does
during compilation.)
If the rule applies, for instance, to a particular object (let's say a
revolver that may need to be fired, or loaded, or aimed), I'll probably
type the rule next to the paragraph where the revolver is introduced,
but then the compiler is going to take it away and put it in a rulebook
somewhere, and I don't have a clear picture in my mind of exactly how
that rule will relate to other rules (having to do with the revolver, or
with putting a bullet into small containers, or whatever) because I can
type my rules in any order.
I'm pretty sure the rules won't be in a rulebook called "rules for the
revolver." The check if the revolver is loaded rule will be off in Room
49 with the other check rules, right?
In OOP, the same rule would be called a method, and would have to be
written in the block of code for the revolver (or the bullet). I can put
the methods of the revolver object in any order I like (and that's an
effective and often-used way to make a mess of my source) -- BUT: All of
the code for the revolver is pretty much guaranteed to be in one place,
and if I need to write a complex method that tests six things (for
instance, whether the revolver is loaded, whether it's pointed at
anyone, whether it's being held or is in the rucksack, whether the
safety is off, etc.), I know what order those things will be handled in,
because I'm putting them in order myself. I can see the order on the
screen and make sure that it's sensible. I don't have to tell the
compiler "put this rule before that other rule."
And this does make a difference, because if there are five different
reasons why "fire the revolver" can fail, I need total control over the
order in which the reasons are listed. If the revolver is unloaded, the
safety is on, and it's in the rucksack (but in scope), it would be
totally wrong for the parser to respond, "Click -- the hammer falls on
an empty chamber." I'm sure you can create the correct order of
responses in I7, but I'm not aware offhand how one would do it. Perhaps
someone else can enlighten us on that point.
So yes, "rules" make verbs, but whether we call them rules or methods
is, in the end, a distinction without much of a difference. The key
difference, to my way of thinking, is in terms of how the source is
organized and how it presents itself to the author.
Of course, even in TADS you have to be careful, because you can sprinkle
your source with modify Thing blocks and end up not knowing what the
properties or methods of Thing are. Whether that's good or bad coding
style depends on what sort of constraints you impose on yourself when
doing it, but it's allowed by the language. You could do the same thing
with the revolver object, I believe -- tuck bits of modify revolver in
the code next to the bullet object. But nobody would ever do that (I hope).
>> No one who had any
>> storytelling bone in their body liked the conflation of the player with the
>> player character,
>
> Eh? Wouldn't they feel that they were put out of the work by keeping
> such a distance from the PC? Like, they were a puppetmaster above the
> world instead of a person in it?
This is a nice psychological distinction. We could say that immersion in
a story will be more thorough if you actually believe you ARE Emma
Bovary, seeing the world through her eyes -- but Flaubert didn't write
it in 2nd person. He trusted you to trust HIM as the storyteller. I
think that may be a key point. If the player trusts the author to be
unfurling a story that's worth experiencing, their vicarious
participation in the life of the lead character probably won't be
diminished by the fact that they are discovering the story by issuing
commands.
Issuing commands becomes, perhaps, vaguely analogous to turning the pages.
> It's something of a law in RPGs that the DM doesn't tell the player
> "you can't do that because your character doesn't feel like it /
> doesn't understand why he should / knows something about himself that
> you don't."
I guess that's a major difference between RPGs and IF. The parser very
often tells you exactly that, and it doesn't seem to bother anyone
unduly, if it's done gracefully.
--JA
miket...@embarqmail.com
>
> In OOP, the same rule would be called a method, and would have to be
> written in the block of code for the revolver (or the bullet). I can put
> the methods of the revolver object in any order I like (and that's an
> effective and often-used way to make a mess of my source) -- BUT: All of
> the code for the revolver is pretty much guaranteed to be in one place,
> and if I need to write a complex method that tests six things (for
> instance, whether the revolver is loaded, whether it's pointed at
> anyone, whether it's being held or is in the rucksack, whether the
> safety is off, etc.), I know what order those things will be handled in,
> because I'm putting them in order myself. I can see the order on the
> screen and make sure that it's sensible. I don't have to tell the
> compiler "put this rule before that other rule."
>
would do it. I think I see something which has not been explained
very well. The check rules can (and should) be grouped together and
will fire in the order you place them, depending on specificity. I
think (correct me if I'm wrong) it's the specificity issue that's
bugging you. This is the exact reason I try to avoid writing rules
like:
Check firing the revolver in the library.
I write new action code like:
[pseudo code]
check firing:
if the second noun is not the revolver,
say "You can't fire that." instead.
check firing:
if the second noun is unloaded,
blah... instead.
check firing:
if the location is the library,
say "That would be too noisy" instead.
[/pseudo code]
The above code executes in the order I wrote it. Specificty is not an
issue, because each rule has the same specificity ("check firing").
When you write rules like "check firing when..." it get confusing,
because then, as you point out, it's sometimes not clear what order
everything falls into. Am I on the wrong track here?
As far as other "methods", it would depend upon the situation. If I
had a loading action for the revolver, I would group the code in the
same section as the revolver itself (separate from, but perhaps
immediately before or after the firing rules). I would probably,
however, group these rules differently if I had cannons as well as
revolvers. The actions would be grouped together, and I would still
use general language in the rule names ("check firing"). The code
inside each individual rules would just be a little more complex.
Skinny Mike
Jeff Nyman
news:77fd92a9-71ce-4e5d...@e10g2000prf.googlegroups.com...
> (I never understood this issue. Objects make nouns, rules make
> verbs. What's the problem?
Part of this is *exactly* what Jim mentions in his post. (It's interesting
that Jim is also a writer, which matches one of the criteria of my group.)
But I can also say that Jim's issues did match many of my own (and I do have
a fairly good programming background).
A major issue was the notion that code for elements could be distributed all
over the place and do not seem to be part of an "object" that may have to
deal with or respond to the rules. It wasn't always clear when things would
happen, particularly when you had to now worry about sorting rules to
achieve some effect.
Note here that part of the problem was the perceived emphasis on rules.
Inform seems to put that emphasis in place when, in fact, the rules can be
somewhat subsumed under a simple framework of realizing that it might be
better to concentrate almost solely on Begin, Instead, After rather than on
working on those *plus* Check / Carry Out / Report.
I've read a lot of the posts of the last couple of months talking about the
benefits or lack thereof to the number of points where you can interfere.
What often doesn't come up though is using limited rules in limited ways to
achieve effects based on the other elements of Inform, most notably
relations, which I think get the short end of the stick as well as the
ability to create new kinds of action ("unmaidenly behavior") that can
better describe the story world relative to those relations. When you put
this emphasis on things, the need and desire to work with rules, at least as
the emphasis, starts to get reduced.
Getting a little abstract here, but based on what I saw and have learned,
from a writing standpoint, the brain tends to work in the way it normally
does in other venues. To wit, our brain usually use an object-mapping
strategies when we're dealing with uncertainties or being creative. Our
brain tends to use a structure-mapping strategy when we're dealing with
known facts or a situation which has no important unknown variables. This is
the basis for how we cross-over to heuristic (rules of thumb) based
thinking. This starts early on as babies -- where our rule-firing mechanisms
are amazingly lithe -- and then slows down considerably by about the
mid-twenties or even earlier.
With structure-mapping, you start by forming a framework of an overall
"plan" and, from that plan, you work downwards to sort out all the
structural elements at an increasing levels of detail. With object-mapping,
you don't necessarily have a fixed or definite plan of the final structure.
You might start anywhere and then build up a structure from small parts
which are fitted together as you go along.
This is how the brain is wired to work. Part of why object-oriented
technologies have prospered as they have is truly due to these aspects. It's
not that OOP forced people to think this way; rather OOP dealt with the way
people think. People do think in terms of rules as well, but not as
*explicitly* as they do with objects. Inform asks them to reverse a lot of
ingrained nature.
But, again, I would only argue this is the case if the emphasis is put on
the rules themselves. For example, I might get all this just as part of a
basic LOOK for a room:
[Rule "standard set taking variables rule" does not apply.]
[Rule "standard set going variables rule" does not apply.]
[Rule "determine visibility ceiling rule" applies.]
[Rule "Setting action variables for exiting" does not apply.]
[Rule "room description heading rule" applies.]
[Rule "room description body text rule" applies.]
[Rule "room description paragraphs about objects rule" applies.]
[Rule "check new arrival rule" applies.]
[Rule "other people looking rule" applies.]
How many of those do I really need to concern myself with in order to
actually tell a compelling story? How many of those do I really need in
order to provide NPCs with a sense of connectedness to the the story objects
around them (including other NPCs)?
I should also say, by way of side-note, that people had much less trouble
relating rules to activities. For example:
Rule for printing the name of the smoking gun while listing contents: say
"clearly the weapon of choice in this particular murder".
> Eh? Wouldn't they feel that they were put out of the work by keeping
> such a distance from the PC? Like, they were a puppetmaster above the
> world instead of a person in it?
It seems to depend upon how much emphasis you want to put on game (game
playing) and how much on story (or storytelling). People don't generally
feel this way with novels. Unless the novel is bad or just not for the
reader's taste, readers tend feel they are being carried along on a
compelling narrative journey, peopled with interesting characters. There's
been this assumption I think in the textual IF world that the reader has to
be "part of the world" or has to "be the protagonist" in every particular.
Clearly, to some extent, you are the protagonist given that you control the
character who allows the narrative to unfold. But the notion that any remove
from the player character is somehow disadvantageous to the story/game
experience is one area that I think has stifled the narrative possibilities
with textual IF.
Going to your point, though, and trying to operationally question it, we did
a lot of comparisons with graphical games, notably games like the "Broken
Sword" series, some of the "Agatha Christie" games, "The Longest Journey",
and so forth. Just using the last one as an example, no one felt they were
"put out of the work" by their distance from April Ryan (the
protagonist/PC). They were very much a "puppetmaster" in that sense,
literally clicking everywhere she goes. But what made that game very
successful was the story line and the narrative along with the characters
she met along the way.
This was one area we really tried to hammer down on: the viewpoint of the
story, the notion of who the narrator is, what a "player character" means,
etc. What it pretty much always came back to was this: the strength of
textual IF was seen to be its ability to combine strong storytelling and
characterization with a certain degree of "narrative exploration" and agency
that wasn't possible with static fiction. The trick was not making the
latter elements solely rely on puzzles but, rather, having puzzles be more
situational and environmental -- fitting into the context of the story.
Admittedly, though, this was the hardest area to really focus on because a
lot of times people "knew what they meant" but didn't know how to say it.
One way we tried to get around this was to take existing novels and write up
at least some situation from the novel in the form of textual IF. In other
words, take the writing style and the situational elements and then see how
those could also make a compelling game to go along with the story
experience. One we tried, for example, was Jack McDevitt's "Infinity Beach."
We leared a lot by trying to take something existing as static fiction and
convert it into dynamic fiction. I felt we learned a lot about the
differences between the two forms by doing this.
- Jeff
Blank
Yes, one of my favourite games is Rameses, which uses
can't/won't/shouldn't refusals to characterise the PC.
--jz
Jim Aikin
> I would probably,
> however, group these rules differently if I had cannons as well as
> revolvers. The actions would be grouped together, and I would still
> use general language in the rule names ("check firing"). The code
> inside each individual rules would just be a little more complex.
...and that's where the OOP model has a clear advantage, it seems to me.
If you have five things that can be fired -- or, perhaps more likely to
occur in a game, five containers that can be filled with liquid -- the
very last thing you want to do is write a global "check filling with"
method for the entire game, with if-tests stacked up to the ceiling in
order to peel off each individual case. I think that's what you're
describing, isn't it? I can't help feeling it would be far better --
less error-prone and easier to fine-tune -- to put the tests for filling
the bucket with **in the bucket object**.
--JA
miket...@embarqmail.com
Well, yes, I guess that is what I was describing, but no, not really
what I meant. I had assumed that your main difficulty was with the
specificity issue. After I posted I looked back at your post and
realized that your main objection, as clearly reiterated above, was
having "methods" for objects scattered around. No, I wouldn't use a
stack of if...then's, as that is difficult to read and even more
difficult to add to or debug. I pretty much use the if's I described
as a single conditional ("if the noun is loaded") in an action that
was only being planned for one set of objects (i.e. a game with only
one gun.)
In a work where the author was planning (or at least wanted the
flexibility to be able) to add to an action like shooting with
multiple types of guns/ordinance/effects, you are correct, a more
object - oriented approach is appropriate. That is one of the
purposes of the object-based rulebooks (ch 18.8). I started an
example of how one could use them for a more oop - style coding of a
shooting action, but I haven't finished and I have to go now. I will
post it later in a new thread, since I seemed to have veered us way
OT.
Skinny Mike
Jeff Nyman
news:9e6bb033-0757-4fac...@s12g2000prg.googlegroups.com...
> object - oriented approach is appropriate. That is one of the
> purposes of the object-based rulebooks (ch 18.8). I started an
> example of how one could use them for a more oop - style coding of a
> shooting action, but I haven't finished and I have to go now. I will
> post it later in a new thread, since I seemed to have veered us way
> OT.
On the contrary, Mike, I think this part of the conversation is really good.
The example Jim brings up about the gun and its effects and, more
particularly, how to write these elements clearly is definitely an extremely
helpful aspect.
One of the issues I found people had was finding out how to constrain the
"morass of rules" relative to certain very defined actions to be taken with
or against very defined objects, particularly those that were seen as key to
the story. You both have broken this down into a very useful, concrete
example. Much appreciated.
- Jeff
Emily Short
> miketarb...@embarqmail.com wrote:
> > I would probably,
> > however, group these rules differently if I had cannons as well as
> > revolvers. The actions would be grouped together, and I would still
> > use general language in the rule names ("check firing"). The code
> > inside each individual rules would just be a little more complex.
>
> ...and that's where the OOP model has a clear advantage, it seems to me.
> If you have five things that can be fired -- or, perhaps more likely to
> occur in a game, five containers that can be filled with liquid -- the
> very last thing you want to do is write a global "check filling with"
> method for the entire game, with if-tests stacked up to the ceiling in
> order to peel off each individual case.
Yes, that is indeed the last thing you want to do. As Mike says,
that's where you might use an object-based rulebook or an activity, so
that for each object in question you can write something like
Rule for loading the Colt: ...
and have it be consulted in the right place. The difference between an
object-based rulebook and an activity is mostly that an activity has
Before, For, and After stages automatically; an object-based rulebook
has only one stage; also that with an activity, you can use the test
of whether the activity is in progress in order to control other
rules, as in
Rule for printing the name of the Colt while loading something: ...
So the question is how many hooks you want, and whether you want the
fact that you're in one rulebook to be observed by other parts of the
program.
> I think that's what you're
> describing, isn't it? I can't help feeling it would be far better --
> less error-prone and easier to fine-tune -- to put the tests for filling
> the bucket with **in the bucket object**.
One of the things I always found annoying about the OOP model is that
if I have parts of an action determined by the object being a member
of a class and parts of it determined by the object individually, it
can get confusing or difficult to interleave those effects properly.
With a stack of rules, I find it less trouble to layer together
conditions that are based on different kinds of information any of
which may be relevant. (And yes, of course I realize that "I find it
less trouble" has something to do with the amount of time I've spent
with I7...)
To be fair, I've not used TADS 3 very extensively, and I expect it
handles this stuff more rigorously than Inform 6 did, which is my
chief OOP experience.
I do also find that I tend to think broadly in terms of process rather
than in terms of Individual Stuff when I am designing a new action or
bit of simulation for I7. Like: what in general do I want this to do?
What's the basic procedure going to be? Drafting rulebooks and
relations (again, this is purely speaking for myself here) tends to
lead to a more top-down design than drafting objects used to be. In I6
I tended to start by making the new classes I thought I was going to
need and putting properties on them to do the things I thought I was
going to want to do, and sometimes I found that that had kind of
locked me into a design that actually wasn't such a hot idea -- after
I'd already written object behavior for half the stuff in my game,
say, it turned out that I had boneheadedly left out an obvious check
and now I needed to split all those function properties into two,
or... well, you get the idea.
Starting some new piece of I7 feels more like doing a fast pencil
sketch: I come up with what I think are going to be the core relations
and the main set of rules, and that takes only a few minutes to do,
usually, and then I have a minimally-functional prototype that I can
play with to see whether it works; then once that's done I start
introducing more complicated behavior by sticking new rules into the
rulebooks, but having the rulebook there means that I always have in
front of me (or can look up in the index) what is the *design* of the
whole process. My I6 code could get absolutely horrible that way --
different functions scattered around, hacks on hacks... well, probably
I wasn't doing it right! But there were times when I realized I really
did not understand any more how the conversation code for City of
Secrets (say) worked *as a whole*; whereas I find it easier with I7 to
design a rulebook that represents (because of the English names,
because it's kept orderly in the menu) all the important steps, and
then parcel out any particularly object-oriented portions into object-
based rulebooks/activities.
Emily Short
> On Mar 10, 5:10 am, "Jeff Nyman"
> > The ability to contextualize text based on a player's *growing understanding
> > of the world* was seem as being of paramount importance.
>
> I've touched this too, asking how to do introductions, or a group of
> objects' shared history, or just "smart text" in general, that knows
> when it still needs to be presented to the player, and kinda keeps
> track of what exposition the player himself knows. (Emily was kind
> enough to make an Introductions extension which helps alleviate this a
> bit.)
This is something I'd love to hear more about if there are specific
suggestions -- especially if Jeff found any particular trends. It's
already not especially hard to use text variations to do things like
give different text after something has been seen a lot (I use "[one
of]...[or]...[or]...[stopping]" sorts of constructions all the time,
say). But I'm curious about what other kinds of systematic support are
thought to be desirable for this.
Graham and I at one point talked about explicitly having a "fact" kind
of value, so the author could set up a table of facts that were
important in the game and then use them to create conditions about
what should be printed and that kind of thing. It would look something
like this, probably:
Table of Knowable Facts (continued)
fact summary
hates-sister "Davy cannot stand his sister Maria."
or whatever; and then one could write
"[if the player knows hates-sister]Stuff[otherwise]Other stuff[learn
hates-sister][end if]."
or even just
"[if the player knows hates-sister]Stuff[otherwise]Other stuff[hates-
sister][end if]."
...so "saying" a fact would not print anything to the screen, just
register that the player now knows this fact, which might in turn
affect the conditions for other text printed. It would also be
possible, for streamlining purposes, to make some special text
conditions that would shorten the "if..." pieces; along the lines of
"[one of]" and so on. Or similarly one could write scenes to deliver
new information, like
Revealing-Shuggoth starts when ... and the player does not know
horrible-truth.
...and horrible-truth would be made manifest as a result.
Anyway, I argued against making that part of the library, because what
we were proposing to build into the language wasn't anything more than
the author could easily do himself, and I'm leery of adding trinkets
to the Standard Rules unless they do things that the author really
can't do on his own and/or they're of near-universal value.
Maybe I was wrong about the psychology of this; maybe I'm thinking
about it too much as a veteran user (who can imagine and whip together
this functionality in about fifteen seconds) and not enough as a
novice who either can't do that by himself or wouldn't think of doing
it. Or, on the other hand, maybe I was wrong on the design end, and
there is some kind of shortcut that we could add in here that would
make this really really useful. To me, as sketched, this design looks
too trivial to do anything important that the user can't already do
himself. But maybe I am not just having a grand enough vision about
how the game might use information behind the scenes.
Victor Gijsbers
> >eat the bread
> You're not hungry right now.
>
> >eat the bread
> You're not that hungry -- and besides, you still need to take off the
> five pounds you gained over Christmas.
>
> >eat the bread
> You gaze at the bread, your mouth watering, and sigh deeply. You're
> beginning to regret that you promised yourself you'd lose the five
> pounds you gained over Christmas.
This triad of options is really clarifying. Thanks.
Regards,
Victor
Jim Aikin
> On Mar 10, 11:19 pm, Ron Newcomb <psc...@yahoo.com> wrote:
>> On Mar 10, 5:10 am, "Jeff Nyman"
>
>>> The ability to contextualize text based on a player's *growing understanding
>>> of the world* was seem as being of paramount importance.
>> I've touched this too, asking how to do introductions, or a group of
>> objects' shared history, or just "smart text" in general, that knows
>> when it still needs to be presented to the player, and kinda keeps
>> track of what exposition the player himself knows. (Emily was kind
>> enough to make an Introductions extension which helps alleviate this a
>> bit.)
>
> This is something I'd love to hear more about if there are specific
> suggestions -- especially if Jeff found any particular trends. It's
> already not especially hard to use text variations to do things like
> give different text after something has been seen a lot (I use "[one
> of]...[or]...[or]...[stopping]" sorts of constructions all the time,
> say). But I'm curious about what other kinds of systematic support are
> thought to be desirable for this.
I find that I often use T3's ability to call methods from within a text
block. This lets me print variable text as needed, and allows me to
craft arbitrarily complex sets of tests or switches for the printout
without having to clutter up the main text block with a lot of if/else
switching.
Adding a bit to the I7 library that simply allowed a rule to execute
from within a text output would provide the same level of functionality.
Something like this:
The description of the grand ballroom is "The grand ballroom is
[ballroom printing rule]"
Ballroom printing rule: if the ballroom encloses the prince begin;
... [etc]
--JA
Emily Short
Hm, interesting.
You can already write your own "to say..." phrases, like
To say ballroom printing:
if the ballroom...
but if you prefer to write that as a rule, you could add to your code:
<code>
To say (N - a rule):
say "[run paragraph on]"; follow N.
</code>
...and then what you describe should work. I think "to say" phrases
are generally a little more efficient, because rules generally assume
you're starting a new context and therefore want a paragraph break
before and after, so you might also need your ballroom printing rule
to end with "run paragraph on".
But this is pretty doable, yeah.
Ron Newcomb
> This is something I'd love to hear more about if there are specific
> suggestions -- especially if Jeff found any particular trends.
I'm still brainstorming (and curious about the opinion of Jeff et al.)
but I do have a single data point here.
> Graham and I at one point talked about explicitly having a "fact" kind
> of value,
I do this in my WIP, but as an object called "concept", and it's used
in lieu of Topics and your "fact" kind-of-value simutaneously. It
gave me five benefits:
1) Primarily, I no longer have to make two versions of every
conversation action. With a TALK TO or ASK/TELL system it's no big
deal, but if you want to RECOMMEND and ACCUSE and BEG FOR and so on,
it's a real pain in the keister to make two versions, one for [thing]
another for [text], and keep them in sync as the game evolves.
2) Since its an object, relations like Knows-about and Suspects work
smoothly with it.
3) Printing it is a snap. Topics, not so much. Alternately, it's
trivial to define a To Say (concept - an object) phrase that sets the
Knows relation in lieu of printing it's name.
4) I can subclass things like Secret, Plan, Event, Exposition,
Tension, etc., etc., from it.
5) It's relatively easy to give an NPC "brainstorming" abilities
using I7's wonderful object descriptors. Something like [a list of
every known secret that involves the sister] for example.
(And 6: It works just as simply as your sample code: "[if the player
knows hates-sister]Stuff[otherwise]Other stuff[learn hates-sister][end
if].")
I've seen other I7 author's code that also makes a concept or idea,
for similar purposes IIRC.
> Revealing-Shuggoth starts when ... and the player does not know
> horrible-truth.
> ...and horrible-truth would be made manifest as a result.
Hey sure, a Reveal rulebook.
> Anyway, I argued against making that part of the library, because what
> we were proposing to build into the language wasn't anything more than
> the author could easily do himself, and I'm leery of adding trinkets
> to the Standard Rules unless they do things that the author really
> can't do on his own and/or they're of near-universal value.
That's a good guideline in general, but by adding Fact/Concept/
whatever as an object, we can strike out using [text] and Topics and
all the exceptions that flow from them. So, even though it's easy for
an author to add, making it standard simplifies a completely different
part of the system.
I know Topics save more memory, but that just isn't holding water with
me; my time is more important than saving an extra K of memory. I'm
not asking Topics to go away -- I know every object has one -- I just
don't want to deal with them and their exceptions.
-Ron
Ron Newcomb
> from within a text output would provide the same level of functionality.
Easy answer:
To say consider (code - a rule): abide by the code.
Or whatever.
-R
Ron Newcomb
> I can't speak for others, but my own view of it is that as I'm
> attempting to learn to write I7 code, each rule that I devise feels
> rather like a free-floating bit of DNA drifting through the protoplasmic
> soup.
Yes, that's exactly how it feels. But that's a good thing, cause it
means you're no longer having to micromanage.
The difference between a method and a rule is how you define *when* it
is called. A method doesn't say anything; other imperative code
decides when to run it. And if you change something about the method
(like, number of parameters), you find yourself jumping all over your
code fixing it wherever it's called from. By contrast, a rule not
only says what to do, but when to do it, so it's more "organized
together" than methods ever could be.
Rules also free you from having to decide which object they should go
in. For complicated examples using a combination of objects, there
isn't a perfect way to categorize anyway.
When I first learned OOP after years of C & Pascal, I felt the same
loss of control. I'd call a function -- which is, in the end, a
method -- but I didn't know which bits of code would execute. It just
jumped around in the protoplasm. It took me 18 - 24 months before I'd
internalized the "laws" of method dispatch.
Soon enough Jim you'll internalize the laws of rule selection, and all
will be good. I promise.
-R
Ron Newcomb
<jeffnyman_nospam@_pleasenospam_gmail.com> wrote:
[Re: rules]
Well, I think rules easier because time & space doesn't proceed in
lockstep like most languages: a statement always executing after the
one on the line above it. Rules allow specifying the When as well as
the What, and that's gotta be a good thing.
I guess I can't really argue with how writers feel. I minored in
physics, so rules without solid objects are second nature to me.
(But, then there's cultural rules, taboos... oh nevermind.)
[Re: PC/Player conflation]
> There's
> been this assumption I think in the textual IF world that the reader has to
> be "part of the world" or has to "be the protagonist" in every particular.
> But the notion that any remove
> from the player character is somehow disadvantageous to the story/game
> experience is one area that I think has stifled the narrative possibilities
> with textual IF.
I just have a gut reaction to PC-as-partial-NPC because I'm worried it
reduces agency. Also, in my experience, players can't empathize with
their own PC like they can with an NPC. I also feel that, if the PC
starts becoming an NPC, it increases the story / game split rather
than heals it: April Ryan is the protag of the cutscenes, the player
the protag of the interactive bits, and never the twain do they meet.
And in this, April is still an NPC separate from the PC and can be
empathized with.
Nevertheless, I found your initial post's Viewpoint (1st/2nd/3rd
person) very enlightening. I won't say PC-as-partial-NPC is
necessarily a bad thing, but, I won't be convinced til I see it.
I enjoyed Varicella, I think he's an amusing, nasty bit of work, but I
still see him as a very separate person than me. Throughout the
castle, I walk with him, not as him.
-Ron
Jeff Nyman
> code fixing it wherever it's called from. By contrast, a rule not
> only says what to do, but when to do it, so it's more "organized
> together" than methods ever could be.
Yes, but when you have many rules, that can become a tangled mess -- at
least in some people's perception. You ending up trying to figure out why
your rule didn't fire. Ah, it's because another rule took precedence. And
maybe normally you want that -- except in this one particular case, where
you don't. So sometimes the notion of "when" has to be kept in mind in
relation to a series of numerous other rules, some of which you didn't even
write, and that becomes difficult to untangle.
This said, I agree that people can effectively utilize both objects and
rules to handle this, but conceptualizing this can often be difficult,
particularly, as I found, when people's emphasis was more on telling a story
than creating a game. For example, people could more often relate to one
object telling another object when to do something (by calling a method on
that object). Under what conditions was that object told to send the
message? When the player interacted with that object. So people could
conceptualize where to look (which object) for the effect they desired to
achieve. I even found, when using TADS 3 as my alternative, that people
(even the initial non-programmers) could often write up these elements quite
a bit faster once they understood the language, because it had a clear
structure that they felt was transparent. The rules were seen as an
intransparent structure, at least in some respects.
Again, I don't present all this as fact; rather just as a distillation of
what I observed and what we discussed.
> Rules also free you from having to decide which object they should go
> in. For complicated examples using a combination of objects, there
> isn't a perfect way to categorize anyway.
That first sentence is actually a "freedom" that I found many people have
the most trouble with. I'm not saying that makes objects "better" and rules
"worse" (or vice versa), but it was definitely the area most of my group had
trouble with.
- Jeff
Emily Short
> I know Topics save more memory, but that just isn't holding water with
> me; my time is more important than saving an extra K of memory. I'm
> not asking Topics to go away -- I know every object has one -- I just
> don't want to deal with them and their exceptions.
This I whole-heartedly agree with, and it's at the core of the
conversation system I'm working on to have subjects of conversation
which can then have complicated parsing rules, etc., and be generally
more reliable than topics management.
The reason to model facts separately from subjects of conversation
would be in case the same piece of information ("the Duke had a
fifteen-year affair with a local nun") came up in several possible
places (conversation with the abbess, the Duke's confession, etc.) and
we wanted to model the player's knowledge of that regardless of where
he learned it.
Jim Aikin
>
> Rules also free you from having to decide which object they should go
> in. For complicated examples using a combination of objects, there
> isn't a perfect way to categorize anyway.
This is true. It's an issue in both I6 and T3, specifically in the case
of actions that have two nouns. When the input is 'lower the bucket into
the well' does the bucket get the first crack at handling it, or does
the well?
In T3 you have to be especially careful because, if nothing stops the
action, BOTH the bucket and the well will be able to execute an action
phase. (In I6, IIRC, only the second noun gets this opportunity.) So you
have to develop a consistent way of handling actions whenever the
default is not going to do the job.
When the action is going to be stopped for some reason, T3's verify and
check mechanisms work in a very supple manner. If you know how to use
them, you'll always see the most appropriate output. But the actions you
have to be careful of.
--JA
steve....@gmail.com
> I too think it would be very well
> worth-while writing up a formal paper on your experiences with these
> classes.
Leaving aside the witless inanity ("very well worth-while" -- really
you are a ham-brain wank), how is it that you imagine that you are
agreeing ("I too") with the prospect that a *more formal* paper should
be written? Perhaps you are attempting to spread some concept faux-
formal? Narci.. Narciss...
Please spare us the "oh well I meant 'formal' in the scholarly sense
of 'more finely worked-out' and surely I am not the masterbateur."
I for one would prefer to see a honest discussion (preferably not
steered by Short), and certainly not a wanked-up whitepaper.
Blank
My experience of trying to learn T3 is that it's much harder to dump
stuff that you don't care about (the sense passing stuff, for example)
which is built into the library than it is to include stuff that you do
want when you need to extend the library.
Perhaps instead of thinking of the library as a single "core", it would
be better to think of it as a linked group of modules, and make this
explicit - so when a new project opens in the IDE instead of just having
"A new story" by "The Author"
in the file, it would have a list of standard includes "Include standard
light rules", "Include standard time rules" etc. If an author was able
to set up a personalised template in order to automatically include
favourite extensions/modules then this would be no inconvenience at all.
(I realise that I can create my own "Include favourite stuff" extension,
and I intend to, but it feels like a hack rather than the way I7 is
"meant" to be used.)
--jz
Blank
I've been using both conversation objects and text matching for
conversation, (using Eric Eve's conversation package extenstion) but hit
a snag. I found that if I had a rule matching on a topic (e.g. matching
text of "daughter/susie/teenager") and then later created an object - in
this case the susie object - then the presence of the susie object now
masks any topic words in the previous rule which happen to match her
vocab words. This obviously makes using topics rather fragile and
bug-prone, but using /only/ conversation objects can lead to
disambiguation hell because, knowlege modelling aside, they're always
all in scope.
What's other people's experience here?
--jz
Adam Thornton
<steve....@gmail.com> wrote:
(paraphrased)
> Graham is the Devil
Ah. Nice to have you back.
Maybe Jacek Pudlo will get out of jail again soon, too.
Adam
Ron Newcomb
> > On Mar 10, 5:10 am, "Jeff Nyman"
> > > The ability to contextualize text based on a player's *growing understanding
> > > of the world* was seem as being of paramount importance.
>
> > I've touched this too, asking how to do introductions, or a group of
> > objects' shared history, or just "smart text" in general, that knows
>
> suggestions -- especially if Jeff found any particular trends.
> thought to be desirable for this.
Emily, here's a specific suggestion for some systematic support of
"smart text". The construction just came to me last night. (Kids,
don't drink coffee before bedtime.) You remember that code you posted
to raif that could search a room description's text to see if a noun
entered on the command line existed in the description? Well, given
the compiler to do something similar at compile time...
---- begin code -------------
The gazebo is a room. "A vine-entwined parapet encircles the top of
this whitewashed gazebo."
This is the Exhaustion rule:
if "[...]vine-entwined parapet encircles[...]" has not been
said, say "Your legs grow tired. If only there were a place to rest.".
----- end code ------
I'm using the "[...] and [...]" constructions to refer to a
pre-existing bit of I7 text. (Programmer speak: they are an address-
of operator; they create a pointer.) The compiler does a textual
FIND command to find which text it refers to.
If this text reference type would be a kind of object...
----- begin I7 Library code -----------
Prose is a kind. Prose can be said or unsaid. Prose is usually
unsaid. Prose has some text [reference] called the printed name.
To decide whether (p - prose) has been said: if p is said, decide
yes; otherwise decide no.
To decide whether (p - prose) has not been said: if p is unsaid,
decide yes; otherwise decide no.
--- end library code ---------
..then we could give properties to pieces of text, and decide things
on them...
----- begin code -------
Prose can be sister-involving.
Prose is usually not sister-involving.
"[...]passed away when I was[...]" is sister-involving.
Prose has a person called the likely informant.
The likely informant of "[...]passed away when I was[...]" is Mrs
Davenport.
The likely informant of "[...]vine-entwined[...]" is the narrator.
This is the Pick Some Exposition rule:
repeat with idea running through the list of unsaid sister-
involving prose begin;
if the idea is [etc.] begin;
schedule the likely informant of the idea exposing the
idea; [schedule or try]
continue the action;
end if;
end repeat.
---- end code -----
...and especially if Say were to be promoted to an Activity with those
Before and After rules...
---- begin code ----
Before saying sister-involving prose:
if Yana is recently mentioned begin;
[regular expressions change Yana to She]
end if.
After saying "[...]passed away when I was[...]":
now the mood of every present person is sadness.
--- end code -----
What do you think?
-Ron
James Jolley
> On Mar 11, 12:44 pm, Emily Short <emsh...@mindspring.com> wrote:
>
> > On Mar 10, 11:19 pm, Ron Newcomb <psc...@yahoo.com> wrote:
> > > On Mar 10, 5:10 am, "Jeff Nyman"
> > > > The ability to contextualize text based on a player's *growing understanding
> > > > of the world* was seem as being of paramount importance.
>
> > > I've touched this too, asking how to do introductions, or a group of
> > > objects' shared history, or just "smart text" in general, that knows
>
> > This is something I'd love to hear more about if there are specific
> > suggestions -- especially if Jeff found any particular trends.
> > But I'm curious about what other kinds of systematic support are
> > thought to be desirable for this.
>
> Emily, here's a specific suggestion for some systematic support of
> "smart text". The construction just came to me last night. (Kids,
> don't drink coffee before bedtime.) You remember that code you posted
> to raif that could search a room description's text to see if a noun
> entered on the command line existed in the description? Well, given
> the compiler to do something similar at compile time...
>
> What do you think?
>
this sounds really quite brilliant. Perhaps an extension could come
out of it then? I suppose it would be possible for you to make one up,
just substitute the rules as needed for your own rulebook perhaps.
Best
-James-
Ron Newcomb
> this sounds really quite brilliant. Perhaps an extension could come
> out of it then? I suppose it would be possible for you to make one up,
> just substitute the rules as needed for your own rulebook perhaps.
Oh thank you James!
I tried conceiving of it as an extension, but I couldn't figure it out
and don't think it's possible as an extension. See, I'm not using the
[...] as a To Say phrase, I'm using the whole "[...] as a compiler
keyword of sorts.
And then the whole Finding aspect of it should really be done at
compile time, so the compiler could throw problem messages if an
excerpt wasn't found in exactly one piece of double-quoted text.
-Ron
Daryl McCullough
Leaving aside the witless inanity ("Nice to have you back." -- really
you are a wank-brain ham), how is it that you imagine that you are
contributing anything substantial ("Ah.") to the
discussion when you are neither accurately quoting Steve's
incisive criticisms nor inserting any of your own self-styled
"humor"?
Perhaps you are attempting to spread some concept of
faux-humor? Narco.. Narcolep...
(sorry, I fell asleep during the last line)
Please spare us the "oh well I meant 'Nice to have you back.'
in the ironic sense of 'I would rather remove my own tonsils
with a Sharper Image nose-hair trimmer than read another post
by you' and surely I am not yet a master debater."
I for one would prefer to see an honest discussion (preferably
not while sober), and certainly not a wa... wan... wanked...
wanked-out...
Sorry, what was I saying? I must have drifted off. Your
inane, pretentious style of reading, with your brows
furrowed and your lips pursed to prevent them from moving
while you read, has bored me to the point of somnolence.
--
Daryl McCullough
Ithaca, NY
chipjack
> I tried conceiving of it as an extension, but I couldn't figure it out
> and don't think it's possible as an extension. See, I'm not using the
> [...] as a To Say phrase, I'm using the whole "[...] as a compiler
> keyword of sorts.
It seems as if you want to just throw some text into, say, the
description of a room, and then later in your code go find it and
mutate it in various ways, perhaps replacing it outright with
something else. That seems a little... unintuitive?
If that text, and all the things that might be done to it, were
encapsulated by an object or a rulebook or something, that'd be much
easier for me to debug and maintain. Finding all the places that grab
a particular piece of text (by searching various patterns within its
contents), and figuring out what changes are wrought by each, possibly
with cryptic REGEX operations... Wow.
I think you're on to something Ron, but there's probably a way to
accomplish what you're looking for that doesn't involve changing the
language specification and compiler to make text a first-class object.
-- chipjack
Emily Short
> Emily, here's a specific suggestion for some systematic support of
> "smart text". The construction just came to me last night. (Kids,
> don't drink coffee before bedtime.) You remember that code you posted
> to raif that could search a room description's text to see if a noun
> entered on the command line existed in the description? Well, given
> the compiler to do something similar at compile time...
>
> ---- begin code -------------
>
> The gazebo is a room. "A vine-entwined parapet encircles the top of
> this whitewashed gazebo."
>
> This is the Exhaustion rule:
> if "[...]vine-entwined parapet encircles[...]" has not been
> said, say "Your legs grow tired. If only there were a place to rest.".
My *first* reaction to this was to imagine the horrified noises that
Graham would make if I suggested this to him.
However, I put that aside and have been thinking about it since you
posted, and I keep coming back to thinking that keying to literal text
would make my life as author harder, not easier: that it would be
easier to keep track of a text's possible variations if they're all
represented there in the text with tags ("[learn sister-death]" or
whatever).
The bit that seems most promising is the idea of being able to trigger
new parts of the narrative if the game decided the player needed to
know something he doesn't yet -- except that on your model I don't
quite see how this would be automated, exactly. For bits that happen
in room descriptions and similar places, does the narrator just
helpfully announce this out of the blue to the player at some point?
It seems as though a lot of special-case coding would be required to
handle each instance of having an agent expose a piece of information,
which undercuts the usefulness of having this all automated.
Hm.
Adam Thornton
Daryl McCullough <stevend...@yahoo.com> wrote:
>Sorry, what was I saying? I must have drifted off. Your
>inane, pretentious style of reading, with your brows
>furrowed and your lips pursed to prevent them from moving
>while you read, has bored me to the point of somnolence.
You think it's easy to compose incisive replies with only my left hand?
Especially with my vision as poor as it now is. Kids, if you do it
enough, you *do* go blind.
Adam
Jim Aikin
> In article <atala5-...@quicksilver.fsf.net>, Adam Thornton says...
>> In article
<6705e533-3e58-47a5...@d45g2000hsc.googlegroups.com>,
>> <steve....@gmail.com> wrote:
>>
>> (paraphrased)
>>
>>> Graham is the Devil
>> Ah. Nice to have you back.
>>
>> Maybe Jacek Pudlo will get out of jail again soon, too.
>>
>> Adam
>
> Leaving aside the witless inanity ("Nice to have you back." -- really
> you are a wank-brain ham), how is it that you imagine that you are
> contributing anything substantial ("Ah.") to the
> discussion when you are neither accurately quoting Steve's
> incisive criticisms nor inserting any of your own self-styled
> "humor"?
Ah, I see you have two email accounts, Steve. How clever of you to come
up with a stratagem by means of which you can bamboozle us into thinking
that someone out there actually _agrees_ with you.
--JA
vaporware
> >> In article
> <6705e533-3e58-47a5-91a9-eee8f94c0...@d45g2000hsc.googlegroups.com>, >> <steve.bres...@gmail.com> wrote:
>
> >>
> >> (paraphrased)
> >>
> >>> Graham is the Devil
> >> Ah. Nice to have you back.
> >>
> >> Maybe Jacek Pudlo will get out of jail again soon, too.
> >>
> >> Adam
> >
> > Leaving aside the witless inanity ("Nice to have you back." -- really
> > you are a wank-brain ham), how is it that you imagine that you are
> > contributing anything substantial ("Ah.") to the
> > discussion when you are neither accurately quoting Steve's
> > incisive criticisms nor inserting any of your own self-styled
> > "humor"?
>
> Ah, I see you have two email accounts, Steve. How clever of you to come
> up with a stratagem by means of which you can bamboozle us into thinking
> that someone out there actually _agrees_ with you.
I think it was meant as a parody: compare it to the original post line
by line and note the parallel structure.
Now, what can we conclude from the fact that Daryl's parody was
indistinguishable from an original Fightin' Steve post?
vw
Ron Newcomb
> My *first* reaction to this was to imagine the horrified noises that
> Graham would make if I suggested this to him.
Glad to know I can still instill fear in decent people everywhere.
~heh~
I'll move this into its own thread. I probably should've started it
in its own thread.
Daryl McCullough
>
>Daryl McCullough wrote:
> > Leaving aside the witless inanity ("Nice to have you back." -- really
> > you are a wank-brain ham), how is it that you imagine that you are
> > contributing anything substantial ("Ah.") to the
> > discussion when you are neither accurately quoting Steve's
> > incisive criticisms nor inserting any of your own self-styled
> > "humor"?
>
>Ah, I see you have two email accounts, Steve. How clever of you to come
>up with a stratagem by means of which you can bamboozle us into thinking
>that someone out there actually _agrees_ with you.
What is the world coming to when supposedly intelligent
supposed humans cannot distinguish between the actual
Steve Breslin and a cheap, witless would-be satirist?
Your response is an insult to Steve and to real satirists
everwhere.
Conrad
wrote:
> What is the world coming to when supposedly intelligent
> supposed humans cannot distinguish between the actual
> Steve Breslin and a cheap, witless would-be satirist?
> Your response is an insult to Steve and to real satirists
> everwhere.
...to *would-be* satirsts everywhere...
Conrad.
ps -
Q: How much wood would a would-be satirst satyrize if a would-be
satirist would satyrize wood?
A: Huh, huh... He said "wood."
Adam Thornton
Daryl McCullough <stevend...@yahoo.com> wrote:
>What is the world coming to when supposedly intelligent
>supposed humans cannot distinguish between the actual
>Steve Breslin and a cheap, witless would-be satirist?
>Your response is an insult to Steve and to real satirists
>everwhere.
Brandon Van Every would say,
FUCK YOU! YOU'RE IN MY KILLFILE! NEXT!
Perhaps it is fortunate that I am not Brandon Van Every. Instead I
shall carry on with at least one of my five-finger, my one-finger, or my
one-wrist exercises.
Adam
Daryl McCullough
Enough! These attempts at humor only obscure Steve's larger point,
which is that Graham Nelson, Emily Short, Andrew Plotkin, and many,
many others (probably including you) are a bunch of poopy-heads.
Until we as a community come to terms with this simple truth,
we can never make progress.
Conrad
> a bit faster once they understood the language, because it had a clear
> structure that they felt was transparent. The rules were seen as an
> intransparent structure, at least in some respects.
>
> Again, I don't present all this as fact; rather just as a distillation of
> what I observed and what we discussed.
Jeff, with so many writers talking IF, I wonder if the discussion ever
got around to plot in IF, and if so what people's thoughts were?
Conrad.
Jeff Nyman
news:e9f8ba90-01e2-4d0c...@e60g2000hsh.googlegroups.com...
On Mar 11, 7:33 pm, "Jeff Nyman"
> Jeff, with so many writers talking IF, I wonder if the discussion ever
> got around to plot in IF, and if so what people's thoughts were?
In fact, this came up quite a bit -- and is going to come up again in the
second class, which starts at the end of April. I'll post thoughts gathered
on plot in another thread. Then I'll also do another thread with character,
which came up quite a bit.
- Jeff
