responses on whitepaper
steve....@gmail.com
> TADS 3 has around 420 main classes, varying from generative-semantics fundamentals
[not sure what that means, probably dumbly ungrammatical]
> such as SensoryEmanation to highly specific gizmos: Candle, AutoClosingDoor,
> ShipboardDirection. This is not meant as a criticism, merely as an observation that a
> rule-based natural language system may be most useful if it minimises the number of basic
> meanings, whereas an object-oriented programming language may serve its users better by
> going the reverse way.
Graham does not here make an argument, but only a suggestion: that I7
(or, more generally, a rule-based natural language system) "may" be
most useful if it minimises the number of "meanings".
"Meanings" -- Graham either equates or confuses with TADS 3 classes.
Anyway, the question is, why should anyone believe that I7 is better
(in itself) for having a smaller range of meaning?
In a provisional way, I can agree that a lightweight system has some
advantages. (I myself argued strenuously for a more lightweight system
for TADS 3, against Mike Roberts, a couple years ago. -- Mike won the
argument, I happily admit.) But a robust system has obvious advantages
as well, not least of which is this: any extensions to the system, no
matter its paradigm, will have to meld (or, more likely, conflict), and
anything obviously useful should be provided anyway.
So, to put the matter very simply, I think Graham is mixing two
separate questions, simplicity and functionality, over two separate
paradigms, I7 and TADS 3, which are in fact closer, in terms of
paradigm, than he admits. But anyway I think Graham has not
demonstrated that I7 is better-off being simple rather than more widely
functional.
steve....@gmail.com
> My objection is to the doctrine [of OO programming] that when components of a program
> interact, there is a clear server-client paradigm.
Graham writes this against the messaging technique of OO, which
technique in fact implies very little. (No, it does not imply
server-client paradigms.)
Graham Nelson
> > TADS 3 has around 420 main classes, varying from generative-semantics fundamentals
> [not sure what that means, probably dumbly ungrammatical]
> > such as SensoryEmanation
Generative semantics is a term introduced around 1968 by a school of
linguists who took what we might now regard as an extreme Chomskian
position: crudely, that meaning is the same thing as grammar. Few would
now take so extreme a view, but a milder form of this is commonly
accepted, from what I can tell of the literature. In particular, it is
possible to decompose the structure of "the meaning of a sentence"; one
could find that a reference to being able to hear something, for
instance, is an instance (hearing) of a broader class of meanings, tied
perhaps to spatial fundamentals (in this case, a class of sensory
emanations). See for instance Jackendoff, "Foundations of Language",
chapters 4 and 9. I was observing that T3, and I think perhaps the
credit for this may go back to WorldClass, provides a number of classes
which suggest a structural approach to meaning. I also noted that it
provides a whole bunch of convenient classes to "do" particular kinds
of object, like candles.
> Anyway, the question is, why should anyone believe that I7 is better
> (in itself) for having a smaller range of meaning?
My argument for this point runs to several pages; I refer anyone
interested to my paper.
> So, to put the matter very simply, I think Graham is mixing two
> separate questions, simplicity and functionality
[...]
> But anyway I think Graham has not
> demonstrated that I7 is better-off being simple rather than more widely
> functional.
In writing "simple rather than... functional", does one not exactly
make the confusion of simplicity with functionality which is being
complained of?
steve....@gmail.com
Graham Nelson wrote:
> steve....@gmail.com wrote:
> > > TADS 3 has around 420 main classes, varying from generative-semantics fundamentals
> > [not sure what that means, probably dumbly ungrammatical]
> > > such as SensoryEmanation
>
> Generative semantics is a term introduced around 1968 by a school of
> linguists who took what we might now regard as an extreme Chomskian
> position: crudely, that meaning is the same thing as grammar. Few would
> now take so extreme a view, but a milder form of this is commonly
> accepted, from what I can tell of the literature. In particular, it is
> possible to decompose the structure of "the meaning of a sentence"; one
> could find that a reference to being able to hear something, for
> instance, is an instance (hearing) of a broader class of meanings, tied
> perhaps to spatial fundamentals (in this case, a class of sensory
> emanations).
Are you ascribing this theory to TADS 3? If so, is it on account of the
way in which TADS 3 organizes its information around programmatic
objects?
A SensoryEmanation is an object which, basically, transmits a message
through a sense context. Whether the message is printed to the player's
screen depends on whether the message is successfully transmitted to
the PC.
> See for instance Jackendoff, "Foundations of Language",
> chapters 4 and 9. I was observing that T3,
Not that I care, but you might like to know that, formally, T3 is the
VM, and the library you're referring to is properly TADS 3.
> and I think perhaps the
> credit for this may go back to WorldClass, provides a number of classes
> which suggest a structural approach to meaning.
Again, you are not making any sense.
> I also noted that it
> provides a whole bunch of convenient classes to "do" particular kinds
> of object, like candles.
Right. My point is that *not* providing convenience classes is not
obviously advantageous, even if one considers the benefits of
simplicity. That's the question I'm raising, and...
> > Anyway, the question is, why should anyone believe that I7 is better
> > (in itself) for having a smaller range of meaning?
>
> My argument for this point runs to several pages; I refer anyone
> interested to my paper.
...your paper does not respond, and you seem to prefer to ascribe wierd
philosophical positions based on the datatypes TADS 3 uses to
encapsulate and process its data, rather than responding to the same
question here.
> > So, to put the matter very simply, I think Graham is mixing two
> > separate questions, simplicity and functionality
>
> [...]
>
> > But anyway I think Graham has not
> > demonstrated that I7 is better-off being simple rather than more widely
> > functional.
>
> In writing "simple rather than... functional", does one not exactly
> make the confusion of simplicity with functionality which is being
> complained of?
If there's a correlation between simplicity and functionality, it is
that a simple library is less functional.
Again, I have in the past taken the position that depsite the great
gains of a really robust library like TADS 3, simplicity is more
important. I changed my mind when a class of students picked up TADS 3
very quickly and easily, even getting quite far into the lower-level
(more complicated) stuff.
Since then I have considered the problems of simplicity from the other
side of the argument, namely 1) a simple library requires the user to
create the functionality that the library could have provided (without
prohibiting the user from doing it his own way); 2) complicated
extensions normally don't integrate well with each other, and are
better off integrated from the beginning, into a central library; 3)
the main library inevitably produces limitations to what is possible
and feasible, and as these limitations are pushed as the library
increases its functionality, it follows that a simple library has
tighter limitations.
Agree with these points or not, I expect that you probably *considered*
them, as they seem to me the obvious design questions.
Graham Nelson
> Graham Nelson wrote:
> Are you ascribing this theory to TADS 3? If so, is it on account of the
> way in which TADS 3 organizes its information around programmatic
> objects?
Essentially, what I'm saying is that the great range of classes in TADS
3 is motivated largely as a miscellany of useful tools, but that it is
also in some aspects suggestive of a systematic approach to providing
meanings - for instance, as in this case, in unifying different
meanings with a common underlying meaning, so to speak.
> Not that I care, but you might like to know that, formally, T3 is the
> VM, and the library you're referring to is properly TADS 3.
Noted! I assumed it was an abbreviation for the whole, certainly.
> > My argument for this point runs to several pages; I refer anyone
> > interested to my paper.
>
> ...your paper does not respond, and you seem to prefer to ascribe wierd
> philosophical positions based on the datatypes TADS 3 uses to
> encapsulate and process its data, rather than responding to the same
> question here.
I really don't discuss TADS 3 in my paper at all, except in that one
footnote, which was by way of acknowledging that the other people who
had worked on the same problem had come up with a different conclusion.
> Again, I have in the past taken the position that depsite the great
> gains of a really robust library like TADS 3, simplicity is more
> important. I changed my mind when a class of students picked up TADS 3
> very quickly and easily, even getting quite far into the lower-level
> (more complicated) stuff.
This may well be so. But, as I suggest in the paper, it may be a
question of different programming domains having different needs. An
object-based system may best be served by giving users a rich and
well-chosen variety of prototype objects to build from; a rule-based
system may best be served by giving users a rich and well-chosen
variety of rule-writing techniques.
It is also arguable that "functionality" must be seen in terms of what
is produced, and that what is produced is not only the object code, but
also the source code; a really super-duper library, but which is so
huge and cryptic that source code using it cannot be understood without
reference to an encyclopaedia, may not be as functional as it looks. (I
do not, of course, wish to imply that TADS 3 is such a thing - not at
all. But there are programming languages out there with vast and
annoyingly unselective "standard" libraries, often ignored by almost
all of the users of those languages, sometimes not very well tested. A
large library is not always a highly functional library.)
Emily Short
> My point is that *not* providing convenience classes is not
> obviously advantageous, even if one considers the benefits of
> simplicity.
I'd say that it's unobviously advantageous, though -- especially given
that this is only one of several languages available to the communiity.
While it's possible to remove or override pieces of an existing
library, I would say that standard libraries have an inevitable
influence on the form of everything written in the relevant language.
When I start out to use a library (as a designer), I think: what can I
do with this prefab set of tools? Do I want this feature, or do I want
to override it? How? And so the design process itself is to some extent
shaped by a set of binary decisions* about how the supplied world model
relates to the world model of the game I want to create.
* (Okay, these may not all be strictly binary -- I realize that many
libraries support multiple implementation options. But the design
process still becomes a kind of dialogue with the library: which of
these options fits me best? If none does, how can I adapt one of them
to most closely suit what I want to do? And this, I think, also fosters
the impression that the standard library defines a standard form of IF,
from which any major deviations are definitionally experimental.)
Where I contributed to the design of I7, I mostly took the line that it
would best capitalize on its particular strengths if it provided only a
minimal library. For one thing, the rules system means that one can
create one's own hooks into library processes; the pressure to build a
whole world model as a single integrated unit is not so strong, and the
cost of failing to anticipate a specific use is not as severe as in an
OO system. For another, relations struck me as a powerful way to build
new kinds of model quickly and elegantly, reducing the time-cost of
innovating from scratch.
So when I requested features, I tried to think about essential
components that go into creating a world model (and the machinery to
describe and parse appropriately). What might we want to do with the
information provided by relations? What kinds of control might we want
over printing, in order to let the author express aspects of the world
he has designed using these tools? How might we make it easier to
create parse tokens relevant to a newly-defined world model? And so on.
I don't think we've finished addressing these issues by any means, but
I do think those were the right questions to ask.
I have found that this approach works for me: I approach designing I7
games in a new and (to my mind) more productive way. I've discussed
this already in a couple of places, so I won't recapitulate it all; I
said it at most length at
http://groups.google.com/group/rec.arts.int-fiction/msg/6bb3e5a89b22c336?hl=en&
...but, to summarize some of a pretty long post, I find that, given a
stripped library and powerful toolset, I design each project around the
interaction type that I want to foster; the resulting games are not
only faster to write but also more focused in concept.
I also find that I can prototype these new models easily, so that I do
not mind the lack of prepackaged solutions. The purpose of Bronze is to
provide a novice-friendly experience with extensive and responsive
hints, so it includes an internal model of the player's knowledge and
the way objects relate in puzzles: this system would not have been
relevant to many another game. In Glass, the world model is mostly made
up of topics of conversation, with relational pathfinding tools to
control the traversal of those topics dynamically -- another thing I
had struggled towards with I6, but which I7's tools turned into a
15-minute implementation. Almost none of a standard IF library would
have been any use here, since I hardly model physical relationships at
all, and deviate severely from the typical models of conversation.
Finally, When in Rome 2 achieves something I had been trying
unsuccessfully do with I6 and RAP: an NPC (or actually a set of NPCs,
since behavioral characteristics are chosen semi-randomly at the start
of the game) capable of some basic goal planning (sleep, hide, eat,
bribe, threaten, attack, build a space ship and go home, deceive and
kill the player, etc.). There are some differences between the way this
handles and the way RAP handles -- the NPC does not automatically
compare multiple plans for the same action -- but the system was fairly
easy to program using only I7's built-in action handling, and generated
the sophistication I was looking for. Moreover, the
specificity-ordering of action report rules also means that it was easy
to add many specialized reports for particularly interesting NPC
actions...
But now I'm getting bogged down in particulars. The point is that each
of these projects takes its own view of what is interesting to model,
incompatible with the others; each accomplishes something I was never
able to achieve to my satisfaction in Inform 6; the design of each
arose from rethinking the model from scratch. I don't think it would
have occurred to me to try some of these things if I had started from a
library with many existing classes. The underlying message "here, use
this world model paradigm (or something like it)!" is subtly
compelling. So I do appreciate that it's useful to have a system that
provides powerful, carefully thought-out and integrated classes for the
kinds of things that are especially common in IF. I also believe that
there are benefits (for particular pieces, and for the growth of IF as
a medium) in a system that provides almost none -- as long as it hands
the author the means to make his own model with relative ease.
Correspondingly, the I7 documentation examples are intended to offer
borrowable solutions for common problems, while at the same time
discouraging any sense that these solutions are universal, or that any
one kind of world modeling is inherently preferable to all others. I
was frankly pushing my own agenda there.
In any case, I don't know how many other people will share my
experience, but I consider Inform 7's lack of extensive library to be
an essential aspect of what the language is. I hope, though I don't
know, that this will encourage fresh thought, and give rise to forms of
IF that we haven't really considered yet.
na...@natecull.org
Graham Nelson wrote:
> Generative semantics is a term introduced around 1968 by a school of
> linguists who took what we might now regard as an extreme Chomskian
> position: crudely, that meaning is the same thing as grammar. Few would
> now take so extreme a view, but a milder form of this is commonly
> accepted, from what I can tell of the literature. In particular, it is
> possible to decompose the structure of "the meaning of a sentence"; one
> could find that a reference to being able to hear something, for
> instance, is an instance (hearing) of a broader class of meanings, tied
> perhaps to spatial fundamentals (in this case, a class of sensory
> emanations). See for instance Jackendoff, "Foundations of Language",
> chapters 4 and 9. I was observing that T3, and I think perhaps the
> credit for this may go back to WorldClass, provides a number of classes
> which suggest a structural approach to meaning. I also noted that it
> provides a whole bunch of convenient classes to "do" particular kinds
> of object, like candles.
Hmm. I confess I'm also confused by this reference. Not having read
anything about generative semantics, I suppose I consider the idea that
'sentences have meanings' to be so obvious as to be self-evident - was
this insight really the foundation for an entire branch of study? And I
don't understand the link between a (to me, and I suspect most
programmers) obscure linguistic model and the OO concept of
inheritance, which is what I thought the TADS3/WorldClass model was
more directly influenced by. I can't parse at all what 'a structural
approach to meaning' means in this context.
My own bumbling layman's guess at where these ideas come from is that
OO ideas, particularly the class hierarchy, were influenced by
mathematical type theory, which ultimately came from the Platonic ideas
of Forms - in particular, it seems that classes were a bit of a
compromise, a way of trying to impose rigid (and thus easy to reason
about) compile-time types onto the more organic, runtime-dynamic
structure of OO which is really at its most natural when following a
prototype pattern.
The subsequent history of OO software development, it seems to me, has
shown that the approach works well for some kinds of complex system
realtime event-driven system (such as GUIs) but has very weird side
effects, the exact opposite of the initial claims made for
it:particularly, the reliance on rigid classes and the tight coupling
of data and behaviour has made software and interfaces very brittle,
very hard to modify and reuse, incompatible across system boundaries,
and overall not really scalable for large, fluid, rapidly-changing
distributed systems where the final result is not well known and all
participating nodes are not tightly centrally controlled by the same
party. The WWW is not object-oriented, despite massive research
investment in OO GUIs and operating systems during the 1990s. Few
industry observers that I recall predicted this. Why did they get it so
wrong, and why are they continuing to advocate rigid class hierarchies
as the cure-all for software complexity?
na...@natecull.org
na...@natecull.org wrote:
(Okay, the anti-OO rant now out of my system, and having read the
Wikipedia article on generative semantics:)
Would it be correct to say that GS asserts that understanding the
deep-structure form of a sentence is the same thing as understanding
the sentence itself?
This seems to be the main principle by which NL parsers of the kind we
have in IF work. IE:
transform 'eat the red apple' into: "Action: eat, Noun: <red apple>".
Rewriting a sentence into a deep-structure form and then parsing that
form.
I guess I don't get it. The philosophical stuff about meaning sort of
goes over my head.
Andrew Plotkin
Have you considered Smalltalk? I never got into it myself, but it was
OO before OO got obsessed with giant type hierarchies. It's supposed
to be flexible and not all wound up with data structures.
> and having read the
> Wikipedia article on generative semantics:)
>
> Would it be correct to say that GS asserts that understanding the
> deep-structure form of a sentence is the same thing as understanding
> the sentence itself?
>
> This seems to be the main principle by which NL parsers of the kind we
> have in IF work.
I think, from the point of view of semantics, a computer parser
(certainly the simple programs that are IF parsers) *only* futz with
syntax. Semantics is how meaning gets into human heads.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're innocent.
na...@natecull.org
Andrew Plotkin wrote:
> Have you considered Smalltalk? I never got into it myself, but it was
> OO before OO got obsessed with giant type hierarchies. It's supposed
> to be flexible and not all wound up with data structures.
I've not played with Smalltalk itself, though I rather like Ruby and
I've been poking at Io because of its concurrency support, and I find
Lua interesting. Languages like Ruby and Lua are probably why I'm fond
of the dynamic/prototype approach and don't dismiss OO outright. (I
ought to like JavaScript, but I don't.)
> I think, from the point of view of semantics, a computer parser
> (certainly the simple programs that are IF parsers) *only* futz with
> syntax. Semantics is how meaning gets into human heads.
Hmm. So does that mean that everything that happens inside an IF world
would also be considered manipulation of syntax?
Blank
Emily Short wrote:
(snip)
>
> I have found that this approach works for me: I approach designing I7
> games in a new and (to my mind) more productive way. I've discussed
> this already in a couple of places, so I won't recapitulate it all; I
> said it at most length at
>
> http://groups.google.com/group/rec.arts.int-fiction/msg/6bb3e5a89b22c336?hl=en&
Thanks Emily - that long post (well, article really) was very useful in
helping me understand what this bright shiny toy is intended to do.
I've suddenly realised that deep down I'd really only been thinking of
I7 as a handy way of writing I6 code by robot. Perhaps it would be worth
making that post permanently available through the I7 download site? Or
that and similar theoretical articles as part of the standard
documentation?
One of the things I enjoyed about the DM4 was that while all of it was
useful, parts of it, especially the Craft of Adventure, were a good,
thought-provoking read. ATM the I7 documentation is very strong on the
tactics of how-to, but a bit lacking in the strategy of design - the why.
Jayzee
steve....@gmail.com
> Essentially, what I'm saying is that the great range of classes in TADS
> 3 is motivated largely as a miscellany of useful tools, but that it is
> also in some aspects suggestive of a systematic approach to providing
> meanings - for instance, as in this case, in unifying different
> meanings with a common underlying meaning, so to speak.
I'm guessing that you've now realised how atmospheric this point is.
The thing is, I don't understand what motivated its introduction in the
first place. Read in context, it seemed quite off-topic.
> I really don't discuss TADS 3 in my paper at all, except in that one
> footnote, which was by way of acknowledging that the other people who
> had worked on the same problem had come up with a different conclusion.
This is arguable, but when you talk about OO, even when you talk about
"the I6 way of doing things," I believe you have TADS 3 in mind also.
> I suggest in the paper, [that] it may be a
> question of different programming domains having different needs. An
> object-based system may best be served by giving users a rich and
> well-chosen variety of prototype objects to build from;
But you do not suggest *why* this is something particular to OO
systems. (I think perhaps because you confuse game object-orientation
(I6) with programmatic object-orientation (TADS 3).) The intuitive
point would be that a rich and well-chosen variety of prototypes to
build from would be welcome, in any system.
> a rule-based
> system may best be served by giving users a rich and well-chosen
> variety of rule-writing techniques.
This is obvious, but the useful prototypes are not limited to
rule-writing techniques -- at least, not for any reason you explain.
As I said, the inevitable limitations of the main library are pushed as
the library increases its functionality, as it is increasingly
sophisticated. I believe you will certainly discover (in potential) a
wider variety of rule-writing techniques as you further sophisticate
the system.
(Be it said that, in a provisional way, I7 provides some of this, in
the "examples" which it hopes the user will borrow. Why not generalize
these examples into an integrated library, then expand and complete
it?)
I'm not complaining that I7 is unfinished. And I happily acknowledge
that a barebones system has some appeal. I am under the impression that
you're taking a certain obvious drawback, and misconstruing it as a
necessary, and even beneficial, consequence of the programming model,
which it is not.
====
I think you would be a genuinely more persuasive writer if, upon taking
a counterintuitive position -- that I7 is natural language, that a
barebones world model serves its user better than a robust model, etc.
-- you acknowledge that the point is counterintuitive, and that your
reader isn't simply misunderstanding your argument if initially it
sounds odd.
In other words, anticipate the rational objections to your argument --
"isn't naturality qualitatively different, something a programming
language doesn't achieve by approximation alone"; "aren't robust and
integrated tools quite useful" -- and respond to them with an
acknowledgement of their rationality.
In short, a little more "yes, I can see why you would think that" would
serve you very well indeed. Admitting rational objections only
increases the quality of the argument; it is not an admission of
weakness, and not to be feared and avoided.
That said, I well know that the English happen to be less flexibile in
their acedemic argumentation than the Americans, so this is by no means
a personal assault.
Stephen Granade
> I've suddenly realised that deep down I'd really only been thinking of
> I7 as a handy way of writing I6 code by robot. Perhaps it would be
> worth making that post permanently available through the I7 download
> site? Or that and similar theoretical articles as part of the standard
> documentation?
That's not a bad idea, but in the meantime it was archived on Brass
Lantern at
http://brasslantern.org/writers/iftheory/i7observations.html, with
Emily's kind permission.
Stephen
--
Stephen Granade
stephen...@granades.com
Emily Short
Blank wrote:
> I've suddenly realised that deep down I'd really only been thinking of
> I7 as a handy way of writing I6 code by robot.
I know what you mean, and I think it's a natural assumption at the
outset, especially for people who have some previous experience with IF
languages. Certainly I approached it that way for the first couple of
months of beta-testing. I didn't find the syntax generally that
difficult to get used to, but I did find that it took some time before
I made the necessary mental shift and saw how one might come at
designing things fresh in I7. Once that happened, though, I had no
desire to go back to the old way.
> Perhaps it would be worth
> making that post permanently available through the I7 download site? Or
> that and similar theoretical articles as part of the standard
> documentation?
Well, I don't know. Parts are meant more as an opinion piece than as
some kind of Official Statement.
> One of the things I enjoyed about the DM4 was that while all of it was
> useful, parts of it, especially the Craft of Adventure, were a good,
> thought-provoking read. ATM the I7 documentation is very strong on the
> tactics of how-to, but a bit lacking in the strategy of design - the why.
I occasionally get into specific tangents in the examples, but I think
I know what you mean.
At the same time -- well, it feels a little premature to add that kind
of information. The theoretical parts of the DM4 are mostly about IF
design in general; moreover, they were written or revised well after
Inform was introduced. In some respects I feel that any definitive
description of how to think about programming in Inform 7 would be
premature: the language itself is still too much in flux, and there is
still more to learn about the strengths and weaknesses of the system.
I did talk a bit, in the making-of segments for the worked examples,
about how I7's features affected the design of the particular things
I've written so far, as sort of an interim report.
Andrew Plotkin
>
> Andrew Plotkin wrote:
> > Have you considered Smalltalk? I never got into it myself, but it was
> > OO before OO got obsessed with giant type hierarchies. It's supposed
> > to be flexible and not all wound up with data structures.
>
> I've not played with Smalltalk itself, though I rather like Ruby and
> I've been poking at Io because of its concurrency support, and I find
> Lua interesting. Languages like Ruby and Lua are probably why I'm fond
> of the dynamic/prototype approach and don't dismiss OO outright. (I
> ought to like JavaScript, but I don't.)
It's always okay to dislike Javascript. (I'll be disliking it myself
for most of this afternoon.)
I am way behind on cutting-edge crazy languages. Other than I7 itself,
the last one I learned was Python. Too many things, too many things.
> > I think, from the point of view of semantics, a computer parser
> > (certainly the simple programs that are IF parsers) *only* futz with
> > syntax. Semantics is how meaning gets into human heads.
>
> Hmm. So does that mean that everything that happens inside an IF world
> would also be considered manipulation of syntax?
I hesitate to speak for semantics, because I've read even fewer
Wikipedia articles on it than you. But I think that's right.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation,
it's for one reason: they don't feel like it. Not because you're patriotic.
steve....@gmail.com
> > My point is that *not* providing convenience classes is not
> > obviously advantageous, even if one considers the benefits of
> > simplicity.
>
Ok, so the logic got a bit complicated. You are claiming that it's
better to avoid providing convenience classes, but for reasons which
are not obvious.
The single reason you give is that tools provided to a designer run the
risk of over-influencing the design. In short:
> [S]tandard libraries have an inevitable
> influence on the form of everything written in the relevant language.
This is not doubt true, but the implications of this are not so clear
as one might imagine.
First, recognize that the extended argument applies equally to
extensions. It appears to be an argument against general-purpose
anything. Also recognize that you did not consider I7's library, in
your statement against general-purpose libraries.
It may be true that I7 users will custom-sophisticate the world model
in unusual ways, but it is also true that these sophistications,
considered together, will be largely redundant, and will not benefit
from years of collaborative testing.
Another major (false) suggestion you make is that a system like I7 can
"get away with" a barebones library, because it's such a powerful
language that correctly sophisticating the world model can be done
easily. I consider this false because it implies that other languages
sort-of require a rigid model, because they're too difficult for people
to customise anyway.
Sounds like you're setting a false choice between I7, where you can
easily write a custom-sophisticated game, and TADS 3, where you are
trapped into using the sophisticated whatnot of someone else's design.
If, on the other hand, you could explain how I7 is more easily
extensible than TADS 3...
> I consider Inform 7's lack of extensive library to be
> an essential aspect of what the language is.
I think it's just not finished yet. A body of extensions will be built;
they will naturally collide; the system will be revised at least twice;
resulting will be something far more extensive.
Crudely, the celebration of I7's simplicity sounds a lot like the "fat
girlfriend" argument. Sure, she's very open to customization, but on
the other hand, that one's a porker.
Less crudely, simplicity is a value to be considered in balance,
definitely not an ideal to be pursued absolutely. Your argument in
favor of I7's lack of sophistication seems largely in service to a
single idea. Or, to put it better, it suggests that you haven't taken a
hard look from the opposite perspective.
steve....@gmail.com
> [Is] everything that happens inside an IF world
> [a] manipulation of syntax?
You could probably produce a philospohical argument, and define the
terms "IF world" and "syntax," such that this would be a convincing
statement. It might even be interesting within certain (probably quite
tight) limits. But I don't think that exercise would advance our
practical understanding of the genre or our tools for IF production,
not one iota.
It's my sense that far more conventional questions of narrative will be
the way forward, as IF advances as a genre.
Tools to ease writing will clear the way for further advances.
Philosophical speculations, where "meaning" is a confusing term of art
-- this has very little to do with anything at all.
Brian Campbell
> Here, na...@natecull.org wrote:
> > Hmm. So does that mean that everything that happens inside an IF world
> > would also be considered manipulation of syntax?
>
> I hesitate to speak for semantics, because I've read even fewer
> Wikipedia articles on it than you. But I think that's right.
I wouldn't trust Wikipedia too much on semantics; it's articles in that
field are severely lacking. Actually, finding any good sources on
semantics, that explain the variety of theories, is quite hard, since
it's a very political field. Noam Chomsky essentially doesn't believe
in the study of formal semantics, and since he has so much influence in
the world of formal, and generative, linguistics (seeing as how he
basically invented the field as it's studied today), his disapproval of
a particular field can be quite damaging.
Generative semantics have basically been discredited. They tried to
extend the "deep structure" of Chomsky's syntax into something that
could be considered a semantic meaning, and were amazingly complicated,
special cased for all sorts of things, and didn't end up producing
anything that resembled a meaning any more than the original syntax
had. This theory involved an awful lot of syntactic manipulation,
basically moving various parts of a sentence around, positing "hidden"
words and phrases that were posited in the deep structure but ended up
being deleted by the time the sentence was uttered, and so on.
On the other hand there was the Fregian approach to semantics. He
believed in the compositionality of meaning. Basically, each word has a
meaning, and each of the meanings combine, in a functional way, to
produce the meaning of the whole sentence. Frege himself never came up
with a consistent theory of composition in natural language, but he
laid out the foundation of a compositional semantics, and intensional
logic which was necessary for actually dealing with the meanings of
natural language.
Montague, in the 1970's, finally came up with a consistent, workable
theory for a compositional semantics, which involved intensional logic
(that Frege had begun investigation, but never formalized), and the
typed lambda calculus. His theory, known as the Montague grammar, is
basically the starting point for the modern field of formal semantics.
So what does formal semantics study? It basically consists of the study
of how the meanings of individual words combine to form the meanings of
the whole sentence, along with what types of meanings there are (and by
types, I mean in the formal, typed lambda calculus sense). Of course,
what this means depends a lot on what the inputs and outputs are; the
inputs are generally seen as being parsed trees with meanings
associated with the leaf nodes, and the final meaning is generally seen
as a function from possible worlds to truth values. So, for instance,
the meaning of "the sky is blue" is actually a function from every
possible world, to true if the sky is blue in that world, or false if
not. You can also look at this as a set of possible worlds, but the
functions actually make writing the composition rules a lot easier.
Semantics interacts with an awful lot of things; the shape of the input
tree depends on your syntactic theory, you can study what sorts of
meanings are possible for individual words as lexical semantics, how
the output of semantic interpretation interacts with certain forms of
buit-in common sense is the study of pragmatics, and how one sentence
interacts with the others around it is discourse analysis.
Now, there are some people who don't accept this as actually being
semantics. Noam Chomsky claims that this is just another kind of
syntax, which I disagree with. His conception of semantics seems to be
a lot closer to epistemology than what most people think of as
semantics. But anyway, that's neither here nor there. As you might say,
that's just arguing semantics (groan). I guess my final point is that
semantics is really the mapping between syntax and meaning. While a
computer can't necessarily manipulate "semantics" directly in the way
it can manipulate syntax, you can use theories of formal semantics to
create a mapping between natural language syntax (or, a subset thereof)
and a computer based model that is taken to be a virtual world. This
could be used to answer queries about the world (like Prolog), or to
actually build the world model from the meanings of the sentences.
That was a rather long winded, and probably not very clear, response to
a simple offhanded comment. Sorry if I made everything more confusing,
and let me know if I can clarify anything.
Graham Nelson
> > [S]tandard libraries have an inevitable
> > influence on the form of everything written in the relevant language.
>
> This is not doubt true, but the implications of this are not so clear
> as one might imagine.
>
> First, recognize that the extended argument applies equally to
> extensions. It appears to be an argument against general-purpose
> anything. Also recognize that you did not consider I7's library, in
> your statement against general-purpose libraries.
The point, perhaps, is that I7 is a rule-based system, not an
object-based system. It is rich in ways to write rules, which can be
specified with surprising flexibility. The idea is, I suppose, to give
people the tools enabling complicated ideas - especially those not
precisely coupled to individual objects - to be written quickly and
accurately.
Extensions have a clearly different status to built-in functions.
People can dip into them if they wish, not if they don't. There's no
sense of "here, do it this way, this is official". Instead, we
encourage the idea that the form is open, and that experiment is
welcomed. Moreover, there is no central claim that the extensions
constitute a complete suite, or that they should be studied as a mass.
The person who has worked through the whole I7 manual, but never looked
at a single extension, knows I7.
> Another major (false) suggestion you make is that a system like I7 can
> "get away with" a barebones library, because it's such a powerful
> language that correctly sophisticating the world model can be done
> easily. I consider this false because it implies that other languages
> sort-of require a rigid model, because they're too difficult for people
> to customise anyway.
I don't think it implies anything about other languages. Comparisons
are invidious. Again, though, this talk of a "barebones" library
presumes that all functionality derives from a library - which is not
necessarily the case. And if it were, I point out that the 300 or so
examples in the documentation do, in fact, provide a huge range of
rules to borrow from. We don't offer an official library to handle
flammability and the spreading of fire through buildings and objects,
for instance, but we do provide easily borrowable rules implementing
exactly that, and which can be tried out and observed in action with
two clicks.
> Crudely, the celebration of I7's simplicity sounds a lot like the "fat
> girlfriend" argument. Sure, she's very open to customization, but on
> the other hand, that one's a porker.
Well, don't you just get more charming by the day?
Graham Nelson
> I guess my final point is that
> semantics is really the mapping between syntax and meaning. While a
> computer can't necessarily manipulate "semantics" directly in the way
> it can manipulate syntax, you can use theories of formal semantics to
> create a mapping between natural language syntax (or, a subset thereof)
> and a computer based model that is taken to be a virtual world. This
> could be used to answer queries about the world (like Prolog), or to
> actually build the world model from the meanings of the sentences.
Just so, and this is more or less what Inform does, though it doesn't
explicitly use a Montague grammar. Given a sentence S, one can assert
that S is true at the start of play, and the mass of such assertions is
what constructs the model world; one can ask if S is true or not during
play ("if S, ..."); and one can tell Inform to make S true from here on
("now S").
It annoys me when people say "Oh, that's just semantics" - I always
want to say no, it's not just semantics, it's _semantics_. What people
often mean is "oh, that's just calling the same idea something
different" - which if anything is syntax. When the semantics are in
dispute, so are the underlying ideas.
steve....@gmail.com
> [Emily's] point, perhaps, is that I7 is a rule-based system, not an
> object-based system.
That's part of the background of Emily's point, very obviously. That
simplicity is by no means the sum of her point, though simple it may
be.
I'm happily to debate two people at once, but it gets confusing if
they're speaking for each other, going on at length to express simple
propositions, which are indeed questionable, and then corroborating
those statements with statements of the obvious, which do not, however,
contribute to the discussion.
So, granted, Emily is understanding I7 as a rule-based system, as
opposed to an object-based system.
The only interesting thing I can say to this is: I7 is less a
rule-based system than advertised. Obviously it involves rules, but its
world model is object-based, not only conceptually, but in programmatic
design. I believe this is inevitable, for an IF system.
But that's neither here nor there. I bet Emily's response would be more
interesting than this.
> > Crudely, the celebration of I7's simplicity sounds a lot like the "fat
> > girlfriend" argument.
>
> Well, don't you just get more charming by the day?
I admitted it's crude in the very same sentence. It's nevertheless the
typical metaphor for spinning the best of a fault. But perhaps you will
suggest a more charming image for the same idea. Meanwhile, enjoy the
fat girlfriend. :)
Mike Roberts
> It annoys me when people say "Oh, that's just semantics" - I always
> want to say no, it's not just semantics, it's _semantics_. What people
> often mean is "oh, that's just calling the same idea something
> different" - which if anything is syntax. When the semantics are in
> dispute, so are the underlying ideas.
This has been a pet peeve of mine for longer than I can remember. I think
at this point it's one of those lost causes of linguistic drift that
prescriptivists are always fretting about; this particular usage is so
ubiquitous that everyone understands that "arguing semantics" is a now
idiomatic for "arguing over labels," so there's no point thinking about the
meanings of the underlying words any more. It's like the way "by
definition" is coming to mean "emphatically true" (I've been seeing this
even in formal writing lately), or "beg the question" has become transitive
(sort of) and means "makes you ask: <x>."
--Mike
mjr underscore at hotmail dot com
Mike Roberts
> I think, from the point of view of semantics, a computer parser
> (certainly the simple programs that are IF parsers) *only* futz with
> syntax. Semantics is how meaning gets into human heads.
As the word is used in a CS context, and I think even in the colloquial
sense, IF parsers pretty clearly do semantics. The part where the syntactic
structures are resolved into simulation objects (noun phrases into direct
objects, indirect objects, actors; predicates into actions) is equivalent
what's called the semantic analysis phase in computer language compilers.
I'm sure it's debatable whether that sort of resolution constitutes
"meaning" in formal semantics (and I'm sure even that depends on which
variety of formalism you're talking about), but in the colloquial sense, the
distinction to me is that there's information extracted that transcends the
syntax. There's no purely syntactic juggling that can resolve the user's
input into simulation objects - indeed, since the input grammar is
ambiguous, even choosing the precise syntactic interpretation from the many
possibilities requires extra-syntactic information - on which words are
associated with which objects, on which objects are in scope, and on the
current state of the objects and their relationships to one another. Maybe
it's not semantics, formally speaking, but it's not syntax, either.
na...@natecull.org
steve....@gmail.com wrote:
> Emily Short wrote:
> > > My point is that *not* providing convenience classes is not
> > > obviously advantageous, even if one considers the benefits of
> > > simplicity.
> >
> > I'd say that it's unobviously advantageous, though[...]
>
> Ok, so the logic got a bit complicated. You are claiming that it's
> better to avoid providing convenience classes, but for reasons which
> are not obvious.
> The single reason you give is that tools provided to a designer run the
> risk of over-influencing the design. In short:
>
> > [S]tandard libraries have an inevitable
> > influence on the form of everything written in the relevant language.
>
> This is not doubt true, but the implications of this are not so clear
> as one might imagine.
Not that I want to speak for Emily, but it seems to me that this is a
*huge* issue in IF framework/library design, as has been discussed
elsewhere. It is *far* easier to add things to a standard world model
than to change or remove them, and in IF even more than in other
programming problems, the author very often needs to change or remove
potentially everything.
It's nice to have a pre-built 'locked door' class, for instance, but
that's absolutely useless if it assumes that 'locking' involves a key,
while you want a set of doors on a space station locked by entering a
code on a numeric keypad.
That's why I far prefer less stuff in the core world model than more,
and general cases over specific, combined with a simple way of
including extensions, and a way of overriding specific functionality. I
actually wish I7 had *less* in it by default and more in extensions.
TADS2's 'modify' and 'replace' directives were a good way of
approaching the 'prebuilt classes assume too much' problem. I presume
TADS3 has similar directives. I7's rules are another, different (and I
think more powerful, but possibly less predictable) approach. I'm not
sure either are the best solution that can yet be found, though.
steve....@gmail.com
> [I7] is rich in ways to write rules, which can be
> specified with surprising flexibility.
I think you are unaware of how this sounds, at least to the reader who
you are formally addressing. Not to be malicious, but let me take apart
this sentence. My main point here is that you are (at times) writing,
and I suppose thinking, in advertising-language, or propaganda, rather
than talking about the actual points in question.
You say that I7 is "rich" in ways to write rules, which is a judgment
or evaluation, a piece of unspecific praise; and you leave to the
imagination what you mean by "ways" -- how many ways are there to write
rules? One wonders, are there three, or seven? What qualifies as
"rich"; or, at what point should a rule-based system start
complimenting itself for its richness, and why, and what's the
difference between a non-rich rule-based system and a rich rule-based
system?
"Surprising" in what sense? You designed the system: did the
flexibility of rule-specification somehow come as a surprise to you? To
whom do you expect this surprising, and most of all -- how? Do you
imply that its flexibility is surprising because its flexibility
exceeds the flexibility of other systems?
"Flexible" is probably the most busy of buzzwords. There's a lawyer in
town here whose billboards read in bold font: "Smart. Strong.
Successful." The baloney billboards of system design certainly includes
"Flexible" in bold letters.
Nevertheless, "flexible," taken in context, is somewhat meaningful, and
indeed that's where you pick up the thread, and that is therefore where
the useful discussion begins...
> The idea is, I suppose, to give
> people the tools enabling complicated ideas - especially those not
> precisely coupled to individual objects - to be written quickly and
> accurately.
First, you're again confusing programmatic-OO with
game-object-orientation.
Second, two quibbles: "quickly" is arguable -- it would be far quicker
for me if the syntax weren't confused by the attempt at NL.
"Accurately" is another of those advertising words: in fact, accurate
the code may or may not be: it's impossible to judge because the user
is not given procedural oversight, and the exact meaning of the machine
instruction is anyway occluded by the parse layer. (In the end, I think
Dijkstra was arguing for the virtue of masterminding the code you've
written, an aesthetically compelling state: indeed, I think that
pleasure is what gets many people into programming in the first place.)
Nevertheless, where the absence of robust world-model is at stake,
yours is a good answer. However, a robust world-model is, for my money,
a considerably better answer, for reasons I have elaborated upthread
and elsewhere (and which you have not answered). And a robust system in
general, implemented on the user-level, not just the world model, is
clearly better by far.
A library capable of doing a few general searches easily -- this is
useful. (Indeed, I increasingly suspect that I7 is easier to program in
than I6, because certain types of iteration are easier.) But it's no
match for a library capable of doing anything you want on a procedural
level, where indeed you could code those individual searches and hooks
rather easily.
> Extensions have a clearly different status to built-in functions.
> People can dip into them if they wish, not if they don't. There's no
> sense of "here, do it this way, this is official".
That's right, and I agree for a number of reasons.
However, the inevitability, either principle or practical, and the
loss, in usability, creativity, etc. -- these things can be easily
overstated. If the first sentence I quoted above suggests a bias, this
argument you pose against full-featured systems is questionable, not in
mere point, but in emphasis.
> > Another major (false) suggestion [Emily] make[s] is that a system like I7 can
> > "get away with" a barebones library, because it's such a powerful
> > language that correctly sophisticating the world model can be done
> > easily. I consider this false because it implies that other languages
> > sort-of require a rigid model, because they're too difficult for people
> > to customise anyway.
>
> I don't think it implies anything about other languages.
Emily has written that she finds I7 easier to code in than I6, anyway,
and has written at length in favor of the rule-based model, as against
the OO model (although we know these models are not easy to practically
separate, and both TADS 3 and I7 participate in each, though of course
not equally).
I contend that the description of I7, though vague and
self-congradulatory, is true, but it is nevertheless equally true of
languages which do not have a barebones library. I7 would be improved
if the numerous extensions to come were melded as necessary, and
incorporated into the main library. Perhaps we're talking about I8, but
surely you catch my drift at this point.
> [T]his talk of a "barebones" library
> presumes that all functionality derives from a library - which is not
> necessarily the case.
I'm sure you know what I mean by "barebones library," as it's just a
shorthand for what you recognize as a library with relatively few
default classes and behaviors.
Still, the I7 base library is far more complex and determinate than
admitted; this is merely hidden behind the program-parser. The same is
true, in a way, of TADS 3, which is largely declarative: you don't get
into the complexities, and what is determined by default, until you get
into its underbelly. The thing that most bothers me, I think, about I7:
its underbelly is entirely out of the writer's reach.
This is not, of course, an objection I've invented just to complain
against I7. I have made similar complaints against aspects of TADS 3,
most recently the pattern-matching subroutine of the parser, which is
implemented native. (Happily, the necessary information is now
accessible at the library level.)
steve....@gmail.com
TADS 3, and TADS 2 for that matter, makes it pretty easy to 'modify' or
ignore base-classes, with no ill effects. The assumptions I can think
of, in the main library of TADS 3, are also necessary in I7: PC, Room;
location (which you can call a relation if you like). But of course, as
you know, TADS 3 is a programming language proper, and the entire
library is optional.
> It's nice to have a pre-built 'locked door' class, for instance, but
> that's absolutely useless if it assumes that 'locking' involves a key,
> while you want a set of doors on a space station locked by entering a
> code on a numeric keypad.
You seem to be talking about a hpyothetical system which is very badly
designed. I hope you are not implying that TADS 3 participates in any
form of this foolish hypothetical system. One could more easily make
fun of rule-based programming.
> That's why I far prefer less stuff in the core world model than more,
What's why? Because the core world model, its class hierarchy, is,
what, necessarily insifficiently variegated?
TADS 3 does it right. That's a major point of the entire exercise.
> I actually wish I7 had *less* in it by default and more in extensions.
I can appreciate the feeling of this -- I have felt this, and still do.
Later, I'll try to explain my theory of what should be in the main
library vs. what should be in extension.
> TADS2's 'modify' and 'replace' directives were a good way of
> approaching the 'prebuilt classes assume too much' problem. I presume
> TADS3 has similar directives.
Yes indeed. I have no appreciation for the "prebuilt classes assume too
much" pseudo-problem. This might be a problem in I6, which I7 solves,
but it does not surpass TADS 3 simply by avoiding programmatic
prototypes, world-model objects or otherwise.
The terms of comparison, so far, are very silly indeed. Not nearly
sophisticated enough. The main thing I hope for, in this and similar
debates, is a recognition of the simplicity of the terms and
distinctions we're making.
> I7's rules are another, different (and I
> think more powerful, but possibly less predictable) approach.
I think it's not a matter of "powerful" (vague term anyway) but "easy"
-- and easy because it doesn't require so much specification from the
user; the necessary information is filled-in, with defaults, and not
necessarily pre-planned defaults, but system-discovered defaults. So, I
think the "power" (or ease) and the lack of oversight are two sides of
the same coin.
I feel that I'm in very close agreement with you, Nate. I guess the
only major difference is that you've experienced the mind-changing
insight of the rule-based gestalt, and I have not yet.
Kevin Forchione
"Graham Nelson" <gra...@gnelson.demon.co.uk> wrote in message
> The point, perhaps, is that I7 is a rule-based system, not an
> object-based system. It is rich in ways to write rules, which can be
> specified with surprising flexibility. The idea is, I suppose, to give
> people the tools enabling complicated ideas - especially those not
> precisely coupled to individual objects - to be written quickly and
> accurately.
I suppose for me the I7 venture is an exploration in a shift of emphasis to
"relationship" (NL debates aside, I7 is of course *more* than just a
rule-based implementation of I6). And that's always been a bit problematic
for the OO game designer. Where do you put the code that forms the response
in complex interactions, how do you interface with that interaction, and how
do you structure it so that the output is clean and concise and generally
occurs in the desired sequence.
To me the rules tables attempt to answer these questions by, in essence,
providing a third party to handle the details of the interaction; ordering
the selection of those intermediaries by specificity; allowing only one
intermediary to execute for a given execution phase hook; keeping the
interface to the rules tables simple and consistent; etc. In I7 it appears
that the relationship tables have replaced those elements of the command
execution process that were once handled by object methods or functions.
It seems to be the consensus that the game world is best modelled with
objects. And indeed objects still form the backbone of both I7 and TADS 3
game worlds. It has also been the general consensus within the OO world at
least, that an object should govern its own states and behaviors. Both
languages have, to a certain extent, followed this practise. But this is an
interesting idea, this one of an intermediary for relationships -- as you
say, not coupled to individual objects. It's the age-old (well for OO
anyway) question - where do you stuff the code: in the shovel, in the dirt,
in the action, in the room, in the actor, or perhaps in the little dog
across the street? Oh my!
Please correct me if I'm wrong, but then the interesting thing about I7 is
that everything is in the intermediaries... Even behaviors that are
precisely coupled to individual objects. On the whole I don't see a problem
with this, but I wonder if an object oriented system would benefit from a
hybrid approach. My idea is that an author would create intermediaries only
for those cases where behaviors are not precisely coupled to individual
objects. If one were using TADS 3 one could probably make use of the
preinitialization process and the symbols table to analyze and order these
rules in their appropriate tables. One would then slightly modify the
command execution phases to first search these intermediary tables according
to the particular phase. Based on the return from the table one would then
determine whether to continue with the object-oriented interaction.
In this way perhaps the object-oriented paradigm could be enhanced, not just
in a language like TADS 3, but in any OO approach to interactive fiction.
The question is, of course, whether such a generalized mechanism as the one
I've outlined above would allow even the OO author to more easily code
complex relationships, or if the hybrid would create chaos for both
paradigms?
--Kevin
John Prevost
> I think you are unaware of how this sounds, at least to the reader who
> you are formally addressing. Not to be malicious, but let me take apart
> this sentence. My main point here is that you are (at times) writing,
> and I suppose thinking, in advertising-language, or propaganda, rather
> than talking about the actual points in question.
The thing I don't understand is why you seem to continually speak as if
there's some sort of competition here between TADS3 and I7, and then
suggest that people who like I7 or see promise in some of I7's feature
set are somehow deluding themselves or trying to sucker other people
into using I7 instead of TADS3.
This is just... bizarre. Not to mention incredibly objectionable.
Nobody is saying that using a rules system is the only way to write IF.
Nobody is saying that a language which is explicitly rule-based is the
only way to write a rules system. Nobody is trying to convince people
that TADS3 sucks and that I7 rules. And as time goes on, I suspect
nobody wants to keep hearing you suggest (sometimes directly, sometimes
indirectly) that these things are true.
Of course somebody who thinks that something (like a rule-based system)
is a neat concept and more people should explore it is going to
describe it in positive terms. If they didn't think of it positively,
they wouldn't be suggesting that people try it out. And as far as
"talking about the actual points in question", well, it takes two sides
to hold up a debate. A lot of people have addressed your points in a
lot of different ways. What it comes down to is that there is no "best
system" here. And nobody (except perhaps you) is trying to convince
anybody that there is. A lot of people *are* saying that there are
some compelling reasons to try a system like that used by I7. And some
of those same people are pointing out some of the drawbacks of I7's
implementation of these concepts.
I don't particularly care if you continue to post again and again about
the problems present in I7, although I'd be happier if you gave
specific examples of things that are hard to model in I7 but easy to
model in TADS3. But I would like to suggest that when people respond
reasonably to your criticism, you do something other than belittle them
by suggesting that they're either half-wits or evil masterminds out to
stamp out all other IF programming systems.
Now for something that's actually about the subject at hand:
For myself, I think there's a lot of promise in the model that I7 uses,
although I7 itself has a fair number of warts. Part of why I believe
that is related to why TADS3's modelling system has never appealed to
me much, even though its rich world model was intriguing.
In short: In TADS3's world, verbs are subordinate to nouns.
This is a fundamental feature of most OO programming systems--after
all, at the heart of object-based programming is the concept of sending
messages to objects, with the behavior of an object being a part of the
object. The way you think of the relationship between verbs and nouns
in TADS3 is in terms of the nouns deciding how they are going to act
when they encounter a given verb.
Now, I'm sure somebody is going to say "But that's not true! Here,
this is how you define all of the behavior of a verb together in a
piece of code..." Unfortunately, the whole point of my feeling of
distaste is about the *how*. Of course you can do anything you want,
but different programming paradigms work in ways that are more or less
awkward. You can model objects in pretty much any programming language
you want... but it's pretty hard to argue that a piece of code that
uses objects in a non-OO language is elegant. Likewise, your typical
imperative language is much more elegant when you write code in terms
of loops than when you write it in terms of recursion, and vice-versa
for your typical functional language.
In I7, on the other hand, verbs are treated more like the way I think
of them, based on my understanding of linguistics: as the heart of
language, the key concept without which nouns would be meaningless.
Among CONLANGers, people occasionally play with the concepts of
verbless and nounless languages... and as a general rule, they discover
that you can build a truly nounless language, because nouns can be
treated indirectly, but you can't build a truly verbless language,
because verbs can express multi-way relationships, but nouns can only
express static concepts. (This is a subtler point than I can really go
into right here, but I'm sure you can find more detail with a cursory
web search--the discussion of why this is the case should nearly be an
FAQ.)
Now, let's look at the specific details. Here's one of the examples in
the TADS 3 technical article on defining verbs. I've chosen it because
it's the simplest example that takes a noun as an argument, and I've
taken the liberty of extending it (since the example demonstrates the
default behavior, but not the behavior on any specifc thing or kind of
thing.)
DefineTAction(Repair);
VerbRule(Repair)
('repair' | 'fix') singleDobj
: RepairAction
verbPhrase = 'repair/repairing (what)'
;
modify Thing
dobjFor(Repair)
{
verify()
{
illogical('{You/he} do{es}n\'t know how to repair
{that dobj/him}. ');
}
}
;
// And here's my extension, which is later where some thing is
defined as
// part of a room. There's a bit of pseudo-code, because it's just
an example.
+watch: Thing 'broken/watch' 'broken watch'
"A small pocket-watch. Its back is open, exposing a jumble of
loose gears inside."
dObjFor(Repair)
{
verify() { }
action()
{
"You squint your eyes and try to work out how the gears were
originally
arranged. A glint of light on the back of the case catches
your eye--it appears
to be a small engraving.";
// blah blah do something to enable trying to read the
watch...
}
}
So we see, here, that defining the meaning of a verb is done by
assigning a rule to a noun (or class of nouns, for Thing) defining how
to handle the verb. One weird feature of this is that requirements of
action (say, whether you can touch something or not) are part of the
definition of the noun as well, not of the verb itself. The whole
model is even more awkward, to my mind, in the case of verbs which take
two nouns (treated as direct and indirect objects.) To which noun
should the meaty part of the action the verb describes be attached?
What if some response should happen when the action is taken, but that
response really ought to be on the part of a third party? You can
answer these questions, either with some thought or by fiat, but I find
myself irritated that I have to answer the questions at all.
Now let's look at the same example coded in I7:
Repairing is an action applying to one thing and requiring light.
Understand "repair [something]" as repairing.
Understand "fix [something]" as repairing.
Check repairing: say "You don't know how to repair that."
Check repairing: say "You don't know how to repair that." instead.
[ somewhere a watch has been described ]
Instead of repairing the watch, say "You squint your eyes and try to
work out how the
gears were originally arranged. A glint of light on the back of the
case catches your
eye--it appears to be a small engraving." [ do something to make it
possible to read
the engraving now. ]
This code is pretty damned equivalent, modulo I7's use of
pseudo-English instead of punctuation. But the feature that makes me
happy is that instead of describing what to do in terms of "any thing
has been told it's going to be repaired" or "the watch has been told
it's going to be repaired", the definition is in terms of "here is what
you do when repairing". In the case of the watch, sure, we've
associated the rule with both the verb and the noun... but it's a case
of a specific use. We could just as easily have a special rule:
Instead of repairing the watch during the concert, say "The noise
from the stage and
the jostling of dancing bodies make it impossible to do such
detailed work at the
moment."
The fact that the thing you're trying to fix is "the watch" is a
circumstance about fixing. The fact that the concert is going on while
you're working is a circumstance about fixing. And I am positively
ecstatic that they're treated as being largely equivalent.
In TADS 3, on the other hand, my understanding is that I would define
this overriding concert behavior in my definition of Thing's
dobjFor(Repair). Since in this case, I'm refusing to act, I think it's
possible to do it without a great deal of pain. More complicated cases
might have other problems, though.
Not that I7 doesn't have a certain degree of pain, here: In I7, it
turns out that these two rules have equivalent priority--which means
that whichever rule comes first in the source file happens first. So
if I put the concert rule for repairing the watch after the normal rule
for repairing the watch, I can fix the watch during the concert. But
if I put the rules in the other order, I can't.
In any case, both of these approaches have their merits. I happen to
like the more verb-oriented structure of I7 better than the more
noun-oriented structure, because it fits my inclinations better. On
the other hand, if I were trying to write a piece of code to describe
some very complicated behavior (say, a specific kind of search
algorithm for NPC decision making), I'd probably wish I had a more
directly "code-like" way to express it. (To do so in I7, I'd probably
escape out to I6 code for the complicated bits.)
And, I think, there's a part of me that believes that simple is good.
TADS 3 has a very impressive world model pre-defined. On the one hand,
I think "neat! They've put a lot of work into this." On the other, I
think "All of these pre-defined classes for things. Is it really so
hard to express these concepts that somebody decided they *needed* to
provide it as part of the standard library?" On the neat side: sense
connectors, the NPC model, things that are reasonably complicated. On
the "why" side: Pushbuttons. On the down side: I find it very easy to
imagine that the complicated bits wouldn't do exactly what I wanted,
and I'd have to figure out the right way to override behavior or I'd
have to roll my own anyway.
This feeling holds in Inform 7 as well, but not quite as much. I am
irritated by the classes that *are* hard-coded into I7... For example,
regions and rooms are both subtypes of thing. I think that there
should be a type that encompasses both regions and rooms, so that you
could decide "in [a place]" (and catch mistakes at compile-time), not
"in [a thing]" (which crashes at runtime if you ask it of a non-room
non-region.) I understand why a few kinds are hard-coded like this (so
the old I6 parsing code can continue to be smart), but it still makes
me grumpy. If everything down to the base level of kinds and relations
were definable with reasonably clear I7 code (with some slight appeal
to I6 for code that must be especially efficient or complicated), I
would *know* that I7's rule system can express pretty much anything I
think it ought to.
In the end, I7's basic modeling system appeals to me more than TADS 3's
does, for a variety of reasons. And TADS 3's actual model appeals to
me in some other ways. Since I usually care more about modelling
systems than models (I like building my own toys), I have a bit of a
bias towards the system I like more. But they each have their own
strengths and weaknesses, and when I finally get around to writing the
game I've had in my head for years, I'll choose whichever makes it
easier for me to express what I'm trying to say.
John.
Emily Short
====
On the rhetoric of libraries:
> The single reason you give is that tools provided to a designer run the
> risk of over-influencing the design. In short:
>
> > [S]tandard libraries have an inevitable
> > influence on the form of everything written in the relevant language.
>
> This is not doubt true, but the implications of this are not so clear
> as one might imagine.
I didn't imagine they were clear -- actually, I think the implications
are not very well understood at all, and one of the benefits I hope
will eventually accrue from the existence of Inform 7 is a better
perspective on this.
The question first came to my attention in Dennis Jerz's call for
papers for the "Text Technology" journal, in October of 2000:
Somewhere out there, I hope, is a computer programmer critically
equipped
to discuss the rhetoric of Nelson's programming language, Inform. For
example, embedded within Inform are default commands that encourage the
programmer/author to present the player's "death" as a "loss"; this
programming detail may be shaping shape the kinds of texts being
produced on
the Inform platform. (The same can certainly be said of other popular
programming platforms, such as TADS and ALAN.) [1]
I was intrigued at the time, but I didn't feel able to approach the
topic intelligently; nearly six years later, I still don't think I
could do it justice. The death/loss issue is only one of a number of
language aspects one might point to: one might also consider the stress
on light handling and transparency, support and containment; sleep and
hunger in TADS 2; the specific choices of implemented actions... All
these have had a major effect on the way games are written, and on the
way we think about the central problems of interactive fiction -- so
much so that I'm not sure we can get the perspective to understand it
yet.
We have seen various attempts to get past this rhetoric: hunger puzzles
and inventory limits are now widely deprecated, and authors who pay
attention to reviews are discouraged from creating them, even when
built-in features offer support; meanwhile, people have run
competitions or written games based around contradicting one or another
standard assumption of IF libraries (the One-Room Game Competition, "No
Room", the minicomp where players were not allowed an inventory [or was
that just a joke? I'm failing to find the reference on a search now];
one-move games like "Rematch" and "Aisle"; etc).
But all this is still very largely a dialogue about rejecting or
accepting the standards promoted by the standard libraries.
Every once in a while someone protests that we need a system that
deemphasizes some aspect of the standard model before we can fully
explore the possibilities of interactive fiction. I'm thinking in
particular of PJ's posts on eliminating the room paradigm [2]; José
Manuel García-Patos' comments on the need for more complete design
freedom [3]; the oft-repeated threads about eliminated compass
directions [4]. There are many others, too, of course. I've often
argued strenuously against these proposals, because they have tended to
be phrased in more sweeping terms than I'm willing to accept. I also
realize that several of the theorists in question would not be (or are
not) satisfied with I7 as a solution to their complaints.
Despite appearances, though, I have been persuaded by these exchanges
to a limited extent. I believe that the rhetoric of current systems (to
borrow Dennis' term) encourages authors to continue thinking in terms
of a limited set of relationships and kinds of world model; I hope that
the rhetoric of Inform 7 ("a world model is made up of relations
between things: now consider what relations matter in your game") and
its manual (intentionally provided with a spectrum of both traditional
and non-traditional examples) may suggest wider exploration.
Here is a critical difference, I think, underlying our conclusions.
Your entire argument, as I understand it, seems to be predicated on the
assumption that there can be found a correct baseline implementation
for some "obviously useful" set of IF tasks -- yes, an implementation
that can be customized or whose pieces may be ignored if they don't
suit, but still, an implementation that expresses an ideal standard of
object relations, room connections, conversation, and so on. By
providing this library, you communicate a wide range of assumptions not
only about how best to implement those things, but also about what the
domain of IF properly is and what interactions are good to implement.
And I'm interested in what happens if we make a deliberate effort not
to communicate that.
[1] Dennis Jerz,
http://groups.google.com/group/rec.arts.int-fiction/msg/dafb8c9754dac4df
[3] José Manuel García-Patos on Narcolepsy,
http://sparkynet.com/spag/backissues/spag43.html
and some followup discussion by r*if and email.
[4] Compass direction discussions, numerous,
http://www.ifwiki.org/index.php/Past_raif_topics:_Game_Mechanics:_part_1#Compass_directions_.2F_navigation
=====
On the existing I7 library:
> Also recognize that you did not consider I7's library, in
> your statement against general-purpose libraries.
Yes, this is true. I didn't get into a detailed critique of the
existing I7 library because I didn't have the designing of it from the
ground up, and some aspects are a legacy of Inform 6; it is not in all
ways a perfect expression of the theory I outlined. I thought that
delving into that issue too far would only muddy the waters, though,
given that I still consider I7 a *good* expression of said theory.
There are some bits to the I7 world model that I might have left out if
I were designing it myself, from scratch, without I6 compatibility to
worry about. But there are also many parts of the (reasonably slender)
I7 language and library that I think of as tools rather than object
prototypes or convenience classes or anything like that: the handling
of enumerated named values, units, scenes, time, and things like the
pathfinding functionality of relations, and so on.
It could still be argued that any such provisions at all will influence
authors unduly, or provide things that need to be overridden: someone
writing a game set on a planet with a 27-hour day would have to retool
the time handling, for instance. But to a large extent I think Graham
took his inspiration for many of these things from a desire to be able
to express in Inform ideas present in the English language: expressions
of quantities, time, states, and events. I will try to avoid getting
too far into this because I have not studied the linguistic side of it
as much as he has, and I don't want you to misread any errors I may
make as an expression of some fallacy on his part. I'm not trying to
speak for him, but to explain my own thinking where that's relevant.
But I would argue that these tools don't hand the author too many ideas
he didn't already bring to the table, simply by virtue of being a
speaker of English. (How I7 might differ if it were based on some other
language is an interesting question, but too speculative for me to want
to chase right now.) I would also argue that concepts like direction
and event are different in kind from concepts like candle and floor wax
-- the latter being less fundamental, and much more likely to be
handled diversely in different games.
In the end, of course, it will still be found that having things like
doors, rooms, and directions in the standard model do impose certain
preconceptions, and that they do entail certain implementation
decisions. I think some of this could be repaired if the system had
even more general-purpose power: given three-way relations to express
how a room connects to another room via a direction, I think we might
be able to dispense even with much of this as a built-in specialty of
the library -- or at least decrease the amount of special syntax and
special handling that now surrounds geographical features. But for now,
it's there, and constitutes an admission that a geographical layout and
object containment is so widely essential that one can't not support
it. Since it was not practical to strip that from the standard library,
I at least tried in the manual to demonstrate how to override some of
the standard expectations about geography, or (as in "Glass") eliminate
such representation entirely from the player's experience.
====
On the focus of extensions and the body of future libraries:
> First, recognize that the extended argument applies equally to
> extensions. It appears to be an argument against general-purpose
> anything.
Well -- yes and no. Extensions, except a very few bundled with I7, are
not stamped with any official status; moreover, they can be at odds
with one another. The incompatibility seems to be a major reason you
consider a collection of disparate extensions inferior to a standard
library. I disagree.
(As a side note, in case you are wondering: I'm not sure that Locksmith
really deserves to be bundled on general principles, but we decided to
provide it as an example of what extensions look like. There's more of
a case to be made for including things like Complex Listing, which
extends the capacities of the system in some generally useful ways. I
*could* imagine things like Complex Listing, or the Changed Implicit
Action extension, eventually working their way into the main library --
but these extensions provide tools or overrides of the existing
processes, rather than object prototypes or classes; and there are
relatively few of these things, as against the large number of possible
world model extensions.)
I also think there's proof that the absence of a standard
implementation of something can lead to innovation and to multiple
viable models: conversation. One of the reasons there has been so much
exploration of how to do conversation in interactive fiction is that
the built-in support of older languages is minimal. Conversation's a
difficult topic anyway, but I doubt that we would see the spectrum of
interesting solutions we have seen if, say, TADS 2 and Inform 6 had
come with the equivalent of the TADS 3 system. (We'd also have seen
fewer grotesquely shoddy NPC implementations, no doubt.)
As a result, we now have a number of different conversation models,
many of them implemented as extensions of one language or another.
Authors are free to select what most suits their projects; the absence
of a single standard keeps thought and innovation active. I appreciate
that the conversation library that comes with TADS 3 is a quite
powerful one, designed to address many of the implementation issues
that have arisen over the years. But, well, it is possible for such a
system to come into being mostly because of the exploration and
discussion that has occurred, not because someone sat down and invented
the ideal conversation system without any experience. Moreover, that
system -- though a very good implementation of many of the things most
often needed in a certain style of IF -- still doesn't do everything I
want to do in every case. If I want to customize a little, fine, but
sometimes I require something deeply, radically different -- so
different that I doubt I would be able to salvage much of the
implementation provided.
So I'm glad that system exists and that people use it, and I'm also
glad that people don't think of it as the one and only way of doing
business.
> but it is also true that these sophistications, [ie, those in extensions]
> considered together, will be largely redundant
So you assert, and this seems to be in keeping with your belief that
the domain of IF is already well-defined. I reject this premise: I
think they will diverge, as conversation implementations have diverged
-- in fact, I hope they diverge more than that. I would be most
delighted if somewhere down the road we find ourselves with extensions
to cover some standard physical modeling problems, a variety of
conversation modeling extensions, etc., but also extensions that
implement a plot model as the primary focus of the code, or replace the
whole standard set of actions with a completely different one, or...
well, some other things that I haven't had the imagination to think of
yet, but which represent entirely different classes of thing one could
write within the medium of IF.
And you also wrote:
> (Be it said that, in a provisional way, I7 provides some of this, in
> the "examples" which it hopes the user will borrow. Why not generalize
> these examples into an integrated library, then expand and complete
> it?)
Leaving all theoretical principles aside for a moment, this would not
be possible. There are two incompatible models of clothing; two
incompatible implementations of money; four or so incompatible
implementations of liquids; even more incompatible models of
conversation...
This is not an accident. I try to talk about why some models would be
best for some purposes, and how a given model might be fruitfully
extended for new needs, but I don't anywhere say, "Right: here is how
you model X, so now you know."
Naturally, "two incompatible models" doesn't always mean that there's a
good model and a bad model, or even (necessarily) a simple model and a
complex model. Conversation, for instance, can be organized around the
keywords the player uses; or as a tree, entirely pre-coded by the
author; or around topics of conversation (as in many variants of
ASK/TELL, of which the TADS 3 system is an enrichment); or around facts
and assertions (if we are keeping track of knowledge and the
player's/NPC's relation to that knowledge, as in "Best of Three" or
some of the Onyx Ring Library conversation models); or (as in "Glass")
around the interstices *between* topics, the things people say when
moving from one notion to another; or around emotional expression
rather than literal content (as in "Forever Always" and to some extent
"Varicella"); or according to plot stage (as in most games with a
simple >TALK verb)... How I choose my model will depend very much on
what I'm writing.
====
On the extensibility of Inform 7:
> Another major (false) suggestion you make is that a system like I7 can
> "get away with" a barebones library, because it's such a powerful
> language that correctly sophisticating the world model can be done
> easily. I consider this false because it implies that other languages
> sort-of require a rigid model, because they're too difficult for people
> to customise anyway.
I don't think I've said anything of the sort, nor do I agree that this
is the implication; you're trying to disprove my claim by negating a
consequent that doesn't actually follow. For that matter, I think
you're misunderstanding the claim a bit, too.
So, to unpack my argument a little:
You've stated that a well-constructed complex model is best developed
as a unit, because otherwise it will be more difficult to hook the
pieces together. I do not know whether this a true statement about
writing libraries for TADS 3; it does accurately describe my experience
with developing libraries for Inform 6, however, and I am willing to
take it at face value.
Inform 7 is designed with the explicit intention of making that less
true than it was with Inform 6, by making it easier to override pieces
of the library, and easier to add new behavior to existing pieces of
the library -- and also to override and build on other people's
extensions. This results not just from the general fact that the system
is rule-based, but from the specific ability to override named rules,
or to add behavior before or after these rules; it is possible to add
entry points to an action or a routine written by another person,
without the cooperation of the original author.
This insert-your-very-own-hooks aspect of the language means that
more-sophisticated extensions can be built on top of less-sophisticated
ones, even while the less-sophisticated libraries remain mostly
uncluttered by features designed to support complexity. This is one
reason I think it is more profitable to leave model development in the
hands of extension authors than it was in Inform 6 -- I think it will
prove easier for the community to build incrementally and have the
results fit together in a sensible way.
Now, there are caveats here about the way Inform 7 behaves. I'll point
out two issues that I perceive, though others may exist.
First, for rule replacements and additions to work properly, the
original author needs to construct his rulebooks and actions with a
certain discipline, giving names to all of the rules and striving for a
sensible modularization of functionality. Each individual rule should
not incorporate too many different functions at once. There is some
discussion of extensible style in chapter 16, 17, and 19 of the
documentation, and I suspect that further rules will emerge. So the
author of an extensible bit of code needs to have written that source
with the intention of its being extended in some way; on the other
hand, he does *not* necessarily have to have anticipated the specific
places and ways in which his work might be modified or replaced, nor
does he have to have provided intentional hooks for all those
behaviors. I believe this to be a genuine, functional distinction from
other languages; certainly it differs from Inform 6, and improves on
its extensibility.
The second caveat: there are a few places (like some aspects of parsing
behavior) where it is currently hard to meddle with the machinery with
the current version of Inform 7. Still, where the standard library
fails at this, the problem is not so much that the I7 concept is wrong
(I think) as that the library is still bound to its Inform 6 form and
has not been opened up sufficiently to I7-esque modifications. This may
be a challenge to those currently using the system, but it is something
that I hope we will improve, and I don't think this flaw negates the
validity of the rule-system in concept.
One possible angle of attack would be to argue that rule-based systems
are somehow inferior for parsing purposes, and that I7 will never be
able to render these things sensibly. But I think that is at the very
least too early to say; and indeed I seem to recall you remarking that
TADS 3 adopts something like a rule-driven system in handling parsing
issues.[1]
I do also note, that you also say "*correctly* sophisticating the
library". I can read "correctly" several ways. What it first suggested
to me was that there exists some ideal implementation for a given
object or activity; as I've said, I don't believe that to be true. Or
maybe you just meant "with few bugs", in which case I would say that I
haven't found my I7 code to be notably buggier on first writing than my
I6 code; or maybe you meant "in a way proven by lots of testing by
multiple people". There you do have me: an advantage of a centrally
created, centrally tested library is that it has been through a process
of verification and use. But that's only so helpful to me if it's
verified code that doesn't do what I want, and as soon as I start
customizing it, I again run the risk of inventing my own errors.
In any case, if we sift back down, my claim is this:
a) Inform 7's extensibility is of such a kind that layers of extension
may more reasonably be built than in Inform 6, and possibly more
reasonably than in other OO systems, though I make no definite
assertion about this because I have not explored the full possible
range.
b) The expressiveness of its relations system is such that the
rudiments of a custom world model can often be created extremely
quickly. Polishing and adding complexity to the behavior of this world
model does still take some effort, but the rule-specificity sorting
often means, in practice, that one can write new rules to handle
specialized cases without having to change the more general rules one
wrote earlier. Rapid sketching of new concepts is easy.
[1] Steve Breslin on rule-based parsing in TADS 3:
http://groups.google.com/group/rec.arts.int-fiction/msg/7e1e002196a984e8?hl=en&
====
On the future of Inform 7:
> > I consider Inform 7's lack of extensive library to be
> > an essential aspect of what the language is.
>
> I think it's just not finished yet. A body of extensions will be built;
> they will naturally collide; the system will be revised at least twice;
> resulting will be something far more extensive.
You're welcome to this prediction, of course, but it doesn't reflect
the way the language has evolved so far.
I think it is more likely that a body of extensions and games will be
written; inelegancies in the architecture of I7 will be revealed; the
system will be revised (number of times unspecified); result, a cleaner
and more powerful system of rules and relations with which to implement
things. I'm not sure this will in all cases even mean *more* of
something -- often, I find, improvements in I7 mean making the rule
abilities more powerful and the model less specific. It happened
several times over the course of development that idiosyncratic
features of the world model could be removed once the language itself
became sufficiently general: some things formerly implemented with
properties (and unusual, special syntax to handle those properties) are
now done with activities or relations.
We do have a longish list of suggested features submitted by users, but
a non-trivial percentage of these amount to requests that we make some
aspect of the language simpler and more internally consistent, so as to
have power in more domains than it currently does. While I don't agree
with quite all of what he says, I think Andrew Plotkin's remarks on
this are useful.[1]
You also said:
> the inevitable limitations of the main library are pushed as
> the library increases its functionality, as it is increasingly
> sophisticated. I believe you will certainly discover (in potential) a
> wider variety of rule-writing techniques as you further sophisticate
> the system. [2]
I agree that the limitations of the main library (and the language
itself) are pushed as one tries to implement more complex models.
I don't agree that that discovering of new rule-writing techniques must
necessarily stem from the process of building a standard library,
though: it might also occur (and to some extent has already occurred)
through the development of different, non-unified projects. One of my
roles here has been to try writing some different kinds of IF, and then
report back on what was difficult and what could be improved through
better features. And now, of course, we have lots and lots of people
trying this, instead of just me.
[1] Andrew Plotkin,
http://groups.google.com/group/rec.arts.int-fiction/msg/ac0577fe70c636bc
[2] Steve Breslin elsewhere in this thread,
http://groups.google.com/group/rec.arts.int-fiction/msg/cd05ddc13bffecac
====
On the comparison of Inform 7 with TADS 3:
> Sounds like you're setting a false choice between I7, where you can
> easily write a custom-sophisticated game, and TADS 3, where you are
> trapped into using the sophisticated whatnot of someone else's design.
No. I did not mention TADS 3. I realize that my remarks might be
construed to imply conclusions about it, but I have tried to be careful
about not suggesting anything at all about the relative merits of I7
and TADS 3, and about framing my statements as concrete comparisons
with my Inform 6 experience.
This isn't mere rhetorical caginess of some kind: I don't have the
experience with TADS 3 to talk about issues like ease of
implementation. I have observed the development list and have read
about the aspects of the system of most interest to me, and I have
dabbled very slightly in the coding when I collaborated on "Max
Blaster," but I don't feel that entitles me to make any broad remarks
about how much time X or Y might take, because I have never attempted
to write a solo game in TADS 3. I also think this kind of comparison is
better left to someone who has used both languages in roughly equal
degrees, rather than to someone who is proficient in one and a novice
in the other. Some of Eric Eve's comments are probably more relevant
than anything I could offer, and less biased by personal
investment.[1], [2]
Eric's remarks suggest to me that one should pick the language that
provides the most leverage on the kind of IF one wants to create, and
that some games will be better implemented in TADS 3 and others in
Inform 7. If so, then I think that's *good* -- having a spread of
language types seems to me more useful than having several mostly
similar languages that must be used in mostly similar ways.
A somewhat less obvious conclusion (but also true, I think) is that one
should pick the tool that leaves one to do the kind of work one enjoys
most or finds easiest. I enjoy drafting a new world model from scratch,
getting it to a basic level of performance very quickly, and then
polishing it under testing until it is as nuanced as I want it to be. I
find it more frustrating and less enjoyable (though sometimes
necessary) to modify a pre-existing implementation to get it to do what
I want. This is a matter of personal preference, I suppose, and also a
reflection of the fact that most of my games involve some kind of
non-traditional interaction or world model. If my temperament and goals
as a designer were different, my tool preferences might be different as
well.
> If, on the other hand, you could explain how I7 is more easily
> extensible than TADS 3...
No, I couldn't -- because I don't know TADS 3 well enough to say
whether this is true, and if so, how. But I have pointed out how I7
lays groundwork for extensibility, at least, and how I think it
partially gets past the need to build a unified system all at once,
which you insist does exist.
[1] Eric Eve on the comparison between TADS 3 and Inform 7,
http://groups.google.com/group/rec.arts.int-fiction/msg/33942d44bd3f73c7
[2] Eric Eve on NPC conversation,
http://groups.google.com/group/rec.arts.int-fiction/msg/abc04f1440aa42c1
====
On the argument for "sophistication" (or model complexity, I think,
since that is the respect in which I meant "sophisticated" earlier):
> Your argument in
> favor of I7's lack of sophistication seems largely in service to a
> single idea. Or, to put it better, it suggests that you haven't taken a
> hard look from the opposite perspective.
Hm. Well, okay. Here is my experience and the set of conclusions I've
drawn from it.
As I've mentioned before, I think, my first real effort with Inform was
an attempt to write a set of interlocking extensions that would handle
liquids, fire, objects divided and broken into pieces, ropes,
photography (so as to record and later report the changed states of
changed objects), and some miscellaneous other things -- I think I
tried to incorporate light levels and colors in there as well, and
rubbings of surfaces with raised text on them, and so on and so forth.
But I came to IF, essentially, as a zealot in the huge-library,
simulate-everything-and-make-it-all-work-together cause.
I spent many months of concerted effort on this project; not,
certainly, the kind of collective manpower that has been put into the
TADS 3 library, but enough to demonstrate to myself how each new system
vastly raised the complexity of all the other interlocked systems. To
bring in water is bad enough; to bring in water when you already have
fire makes both the water and the fire code hugely more complicated;
and then there's the light level... (There's a reason all the cooking
in Savoir-Faire is relegated to an automated machine.) I did get far
enough to make a bunch of bold and foolish claims on
rec.arts.int-fiction in late 1999 and early 2000, and to publish a
quickly-written little demonstration of the still-in-progress
libraries. (http://www.wurb.com/if/game/452, if we're keeping track.)
After a while, I realized, to my dismay, that this utterly trivial demo
had also exhausted a large percentage of the puzzles I could think of
using my library for. All that work, and it didn't create much more
range for interactive ingenuity than I had before. I began to question
the theory that a larger simulationist library would generate untold
masses of neat puzzle possibilities; instead I started to think that
one would need (roughly) one new system per game.
I also found that using these prototype libraries required adding vast
amounts of information to each game that used them, whether or not the
special features of the library were called upon. So for instance I
needed to specify shapes, colors, weights, odors, flammabilities, etc.,
etc., etc., for every object in my game just to get them to work
together sensibly when the new system was in place. To make them do
anything *interesting* with the new system required further
customization on top of that.
But I did complete and release WaterElement. I made some effort to
document it (though perhaps not good enough). It generated some
discussion and a moderate amount of upkeep, in that I've needed to help
people with it; and someone patched it when it became incompatible with
the latest version of the Inform library. Considering the number of
people who have mentioned it on the newsgroup, you might get the
impression it was one of the more successful extensions in the Inform 6
suite.
To the best of my knowledge no one has ever used it in a released game.
Discussion of WaterElement on the newsgroups has also led to
suggestions that one use the simplest liquid implementation that still
supports the actions the player will need to take. Which makes a lot of
sense to me. There's a lot of overhead in using WaterElement, both in
terms of computer power and in terms of author attention. Any library
must be understood to be used well, and it takes time to acquire this
understanding. And then a complex simulation, even with some attempts
at optimization (I freely admit that's not my strong suit, but still),
will tend to use more memory and processing power than a simple one.
(Something no one has really pointed out yet is that a library with the
heft of the TADS 3 library would probably not work at all with the
z-machine. One could advance the argument that the z-machine should be
abandoned now, but that's not the choice Graham made, and considering
how widely supported it still is, I understand why.)
Similarly, when I have tried to use very complicated extensions, the
result has usually been that I've given up before putting them into
play. I have studied and admired extensions like the NPC Engine
(designed to move NPCs around the map) and RAP -- but I've never
finished a project with one of them. I did use L. Ross Raszewski's
non-trivial GWindows extension suite, because it seemed to be the only
sane way to cope with complex window setups in Glulx at the time I was
writing "City of Secrets": so I'm not saying that complex libraries are
useless. But they take effort to learn to use, over and above the
effort to learn a language syntax; they often require wholesale and
systematic adjustments to the form of the code, or that one provide a
good deal of extra information about each individual object; they often
add non-trivially to the bulk of a project.
Even in the case that I'm developing a complex model for my own
in-house use, though, things haven't gone as smoothly as I might hope.
I wrote a number of variations on the "Pytho's Mask"/"Best of
Three"/"City of Secrets" conversation systems, over the years; did a
lot of refining, but never ever got it to a point where I didn't need
to strip and reimplement most of it for each new work (including a few
WIPs that never got to the release stage). Much of this may be
attributable to my incompetence rather than a general rule; still, I've
concluded that a complex model -- even one that could be selectively
used at less than full power -- was not necessarily the decisive
advantage I originally believed.
I don't think I'm unique in my preferences, either. By my observation,
the most used Inform libraries are things like Roger Firth's
SmartCantGo: small-to-medium libraries that can be included smoothly
and used easily, but do not require large-scale adjustments to the code
or major investments of time. Similarly, my impression is that large
substitute libraries for TADS 2 and Inform (Onyx Ring, Platypus,
Triform, Worldclass, Pianosa) have not seen much successful use* by
people other than their originators, even in cases where (in my
opinion) they offered considerable and obvious advantages over the
standard libraries for certain kinds of game. The Onyx Ring libraries
are a special case in that, while they're developed to work together,
they can also be included separately -- a definite advantage. But
still, my sense is that the adoption of these systems is not what one
might expect, given how useful they appear to be.
(* By "successful use," I mean "being incorporated into a complete
released game," regardless of that game's quality.)
There are, of course, all sorts of peripheral factors, and this is not
a scientific study: the number of other users and the availability of
continued support encourage people to stick with the standard library,
and of course none of these substitute libraries were (by definition)
promoted as widely as the standard, either.
On the other hand, I've observed that people *do* use *suggestions*
about implementation, offered on the newsgroup or elsewhere: that those
stumped about how to do liquid in their game may be better served by
some examples or a short discussion than by a whizgiggy class they can
plug in but don't comprehend. These considerations are, I think,
especially important for a language/library that aims to make itself
accessible to people who have not programmed much IF before, and who
may be coming into the project without 10+ years of reading the IF
newsgroups. For this audience, it's legitimate to worry that a) initial
complexity might be daunting, and b) the built-in features of the
language are likely to shape their thinking in decisive ways.
Furthermore, I've come around to a view on game design that makes me
less enthusiastic about using complex prepackaged systems: essentially
my inclination at this point is to avoid supporting many types of
interaction that are not relevant to the themes of the work, in order
to encourage the player to focus on the types of interaction that *are*
important. But we've been over all that before, and didn't agree then;
so I don't expect you to accept this last point as having any
significance.
And finally, my experience of games written with complex libraries by
people who didn't want their full potential has been, essentially, that
the play feels clumsy, overengineered, and hampered by distractions.
(Unfortunately, these have also tended to be games that aren't very
memorable otherwise, so I'm having a hard time recalling details to
cite; but I remember several times playing something and finding that
the default library behavior was prompting me to try actions but that
the game generated garbage as a result, because the author hadn't
filled in enough information to make the game play elegantly in its
expanded capacity.)
So those are my reasons for thinking that there's merit in a simple
world model: an aesthetic preference for focused interaction; doubts
about the puzzle value of a complex simulation used across many games;
frustration with my attempts to build and maintain complex models for
use in multiple games; frustration with attempts to use the complex
models provided by others; a desire not to overwhelm novice authors; a
wish to promote experimentation rather than standardization; concerns
about bulk and performance hits; reservations about the authorial
time-cost of implementing the objects for a complicated world model;
seven or eight years of observing use patterns and pedagogical
processes. Which is the bit I need to take a harder look at?
Unless what you mean is "You haven't written a full-sized,
solely-authored game in TADS 3." Since I wasn't drawing comparisons, I
didn't think that a necessary precursor to making informed statements
about I7; but if that *is* what you mean, you're right. I haven't. Have
you?
steve....@gmail.com
> [You] speak as if
> there's some sort of competition here between TADS3 and I7,
Well, something like that. But the debate has been framed as one
between OO and rule-oriented, a debate which has gone on for quite a
while before the release of I7, several years before the inception of
I7, depending on where you start counting. I take TADS 3 as a language
which does IF OO very well, and I7 as a language which arguably well
represents rule-oriented. To me it's a very interesting
comparison/debate. "Competition" implies some things I'd like to avoid,
and perhaps correct, in particular: unfairly favorable and unfavorable
misrepresentation of the systems, respectively.
> and then
> suggest that people who like I7 or see promise in some of I7's feature
> set are somehow deluding themselves or trying to sucker other people
> into using I7 instead of TADS3.
No, really not. But where a person starts praising "surprisingly
powerful flexibility" or somesuch, I'll remark that it can, indeed,
come across as mere advertising. Such is certainly the language of
advertising.
Anyway, I am among those who like and see promise in some of I7's
features. I've said so continually and from the beginning.
Graham Nelson
> This feeling holds in Inform 7 as well, but not quite as much. I am
> irritated by the classes that *are* hard-coded into I7... For example,
> regions and rooms are both subtypes of thing.
Properly speaking, they are both kinds of object, but not kinds of
thing. Region, room, thing and direction are all kinds of object, but
not of each other.
> I think that there
> should be a type that encompasses both regions and rooms, so that you
> could decide "in [a place]" (and catch mistakes at compile-time), not
> "in [a thing]" (which crashes at runtime if you ask it of a non-room
> non-region.)
Some of this reflects the teething stages of what is, after all, a
pretty new program. We do intend to make "in" work rather better (and
to take it further away from the I6 semantics), for instance, and
crashes are unacceptable - do send bug report forms...
The point about "both regions and rooms" is interesting. There is, in a
limited way, scope in I7 to handle what might be called union types -
indeed it uses several such types internally, when handling kinds of
value, and it could be said that the domain of applicability of a
property is sometimes a union of kinds on the object side. For
instance, "open" is a property applicable initially to "a door or a
container" - arguably that's also a union type. Essentially this is how
I7 tries to mitigate possible losses of convenience involved in being a
single-inheritance, rather than multiple-inheritance, system.
However. If there were a way to write something like, say, "Definition:
A place is either a room or a region." - we would need to recognise
that this is not a first-class kind, on a par with "container", say:
Inform would not know what to do if you declared "Camelot is a place" -
should it make a room, or a region? There's really no sense in
constructive terms of these two ideas being the same; only in
subsequent testing terms. So we would be evolving an idea of common
nouns which could be tested, but not asserted.
Graham Nelson
> Please correct me if I'm wrong, but then the interesting thing about I7 is
> that everything is in the intermediaries... Even behaviors that are
> precisely coupled to individual objects. On the whole I don't see a problem
> with this, but I wonder if an object oriented system would benefit from a
> hybrid approach. My idea is that an author would create intermediaries only
> for those cases where behaviors are not precisely coupled to individual
> objects.
Certainly the I7 code-generator, if it can be dignified by that name,
still compiles some information to I6 properties and attributes, and
some to free-standing data structures, as seems most convenient at the
time. I think the most important point is that this is all abstracted
from the author, who doesn't have to worry about whether something is
associated with anything in particular (and if so, what).
Consider the range of books which could be called "a history of the
twentieth century". One approach is to have a chapter on each decade,
and write chronologically. Another would be to write about economics,
social attitudes, the emancipation of women and so forth. Or to single
out case studies (Simon Schama's BBC history, in which he attempted to
cover the twentieth century in a single hour of television, did so by
presenting parallel biographies of Winston Churchill and George
Orwell). If you're a historian, you need the ability not just to
"implement" your book in one of these forms - you need the ability to
choose which you think best.
And I think the same here. It should be entirely up to the author
whether to write IF in a way which organises what happens around the
plot in chronological order, or around the places, or around the items,
or around the sub-plots following individual elements of the story,
etc. I don't think IF design systems are purely in the business of
giving the author functionality to achieve various outcomes in the
eventual story file; I think the author should be given considerable
latitude to write the source code in whatever order or style he likes
because that too is a part of the creativity.
Duncan Harvey
Kevin Forchione
<snip>
>I don't think IF design systems are purely in the business of
> giving the author functionality to achieve various outcomes in the
> eventual story file; I think the author should be given considerable
> latitude to write the source code in whatever order or style he likes
> because that too is a part of the creativity.
This is certainly a valid point, and one that shouldn't be overlooked. If
the functionality of the eventual storyfile can be decoupled from the
organizational structure of the author's code then I suspect a great many
more authors will experience a synergy with their projects.
--Kevin
Eric Eve
news:1153476563.4...@s13g2000cwa.googlegroups.com...
> Some of Eric Eve's comments are probably more relevant
> than anything I could offer, and less biased by personal
> investment.[1], [2]
> Eric's remarks suggest to me that one should pick the language
> that
> provides the most leverage on the kind of IF one wants to create,
> and
> that some games will be better implemented in TADS 3 and others in
> Inform 7. If so, then I think that's *good* -- having a spread of
> language types seems to me more useful than having several mostly
> similar languages that must be used in mostly similar ways.
Since I'm being cited here, I'll say that I totally agree with the
conclusions you're drawing at this point. TADS 3 was the right
system for me to write Square Circle, All Hope Abandon, and another
game that'll be coming out later this year - I'd've found using I7
(or I6) for those game a real struggle, and probably wouldn't have
been able to finish them (even if they hadn't been too big for I7 v8
games). On the other hand I6 was fine for Swineback Ridge, and had
I7 been available when I wrote it, it would have been fine too (I
have in fact now written an I7 version of Swineback as an exercise
in learning I7, and it mostly went pretty smoothly). Likewise, as I
remark in the postings to which you refer, I7 worked well for my
MCDream comp game. I said before (in that post) that though I could
have used TADS 3 it would have been overkill. I think some of your
remarks in this post have given me a clearer sense of *why* that's
the case, and why I7 may actually have been the better tool for that
project (see below).
OTOH (while trying to do my best to view this sine ira et studio), I
can see why someone might be concerned that someone coming new to
this forum might get the impression that being the new best thing I7
is the only system worth looking at, so that other systems might
seem in danger of being unjustly overlooked. Of course I know
perfectly well that's neither your intention nor Graham's nor anyone
else's; it's simply an accidental side-effect (a) of the way certain
discussions have gone and (b) of the perfectly justified excitement
I7 has generated in the community. But that said, I can also see why
it would be worth pointing out that TADS 3 is another new(ish)
system that's also well worth looking at, and hasn't become obsolote
just because I7 takes a different approach! (yes, I know that
*absolutely no one* has said that or intended to imply it, but I'm
just thinking of the impression that *could* be accidentally
created).
I also have some sympathy with Steve Breslin's questioning of the
White Paper's critique of the OO model, in that it didn't convince
me either (perhaps because it simply went over my head!). At least,
the argument may make perfectly good said at some abstract
theoretical level, but I have to say that at the purely pragmatic
level of using TADS 3, its OO approach has seldom seemed even
remotely problematic to me, even with actions involving multiple
objects. (I say seldom rather than never, because I have to admit
that there are occasions when the way the adv3 library handles this
situation can occasionally become frustrating when you want to
change the default behavior - because the adv3 libary will sometimes
involve all the objects that might be affected in a daisy chain of
methods sending you from one part of the library code to another in
an increasingly brain-swirling attempt to find the bit of code the
behaviour of which you want to modify - but this being problematic
is very much the exception rather than the rule). Purely
pragmatically, most of the time I don't see much difference in
complexity in writing an I7 rule referring to multiple objects or
writing a TADS 3 method setting out the same logic in slightly
different terms.
All that said, I'm still basically agreeing with you.
> A somewhat less obvious conclusion (but also true, I think) is
> that one
> should pick the tool that leaves one to do the kind of work one
> enjoys
> most or finds easiest.
Yes, and also the tool one finds it easiest and most enjoyable to do
it with. And behind this is another issue which could potentially
drive a futile dispute, namely the fact that we are all different
and our minds don't all work the same way, which makes general
assertions of the form "X is easier than Y" automatically suspect.
Whether "X is easier than Y" depends on the aptitudes, existing
skills and knowledge, and intellectual temperament of the person
concerned. "Modern French is easier to learn than classical Hebrew"
may be true for many or most modern English speakers, but perhaps
less obviously true for speakers of Arabic and almost certainly
false for anyone whose first language is modern Hebrew. I7's
approach is clearly opening doors for folks who'd be scared witless
by TADS 3, and that's great, but I can also quite understand why
Steve Breslin (and others) might find TADS 3 code more intuitive
than I7.
Again, this simply amplifies the point you're making; it's not
simply a question of the best tool for the job; it may calso be a
question of the best tool for the author. It's just never a question
of the best tool simpliciter.
> I enjoy drafting a new world model from scratch,
> getting it to a basic level of performance very quickly, and then
> polishing it under testing until it is as nuanced as I want it to
> be. I
> find it more frustrating and less enjoyable (though sometimes
> necessary) to modify a pre-existing implementation to get it to do
> what
> I want. This is a matter of personal preference, I suppose,
Very much so, I think; I think my preference would probably be the
reverse!
> (Something no one has really pointed out yet is that a library
> with the
> heft of the TADS 3 library would probably not work at all with the
> z-machine.
You're almost certainly right about this, if the size of compiled
TADS 3 games is anything to go by. You probably couldn't compile an
I6 equivalent of the adv3 library into a z8 file, let alone any kind
of game built on top of it! And this is another reason why I7 (or
I6) may be a better choice for some projects - especially those that
don't actually need the complexity of the adv3 (i.e. standard TADS
3) library. That said, I noticed that my I7 version of Swineback
Ridge compiled to a much larger file than the functionally
equivalent original I6 version (262 K for the I7 version as opposed
to 108K for the I6 version), so folks are likely to run into the
need for Glulx more quickly with I7 (once I7 supports Glulx).
> One could advance the argument that the z-machine should be
> abandoned now, but that's not the choice Graham made, and
> considering
> how widely supported it still is, I understand why.)
Indeed so; and once Glulx support is added to I7, that shouldn't be
a problem; the fact that some games will continue to fit in the
z-machine will be an obvious benefit, not a drawback.
> Furthermore, I've come around to a view on game design that makes
> me
> less enthusiastic about using complex prepackaged systems:
> essentially
> my inclination at this point is to avoid supporting many types of
> interaction that are not relevant to the themes of the work, in
> order
> to encourage the player to focus on the types of interaction that
> *are*
> important.
This where you articulate what I think (at least in part) lies
behind my intuition that TADS 3 would be overkill for certain
projects. Whereas it's not so hard to adapt or extend a complex
world model such as TADS 3 provides, it is harder work to suppress
the parts you positively don't want when they're a potential
distraction in your game (or it may be, depending what it is you
want to suppress).
> And finally, my experience of games written with complex libraries
> by
> people who didn't want their full potential has been, essentially,
> that
> the play feels clumsy, overengineered, and hampered by
> distractions.
> (Unfortunately, these have also tended to be games that aren't
> very
> memorable otherwise, so I'm having a hard time recalling details
> to
> cite; but I remember several times playing something and finding
> that
> the default library behavior was prompting me to try actions but
> that
> the game generated garbage as a result, because the author hadn't
> filled in enough information to make the game play elegantly in
> its
> expanded capacity.)
I can see how this would happen. If you're going to write a game
with something as complex as the adv3 library you'd better be
prepared to customize a lot of default responses, at the very least
(which is something that TADS 3 at least makes it pretty easy to
do). But I suspect there's an area here where player tastes may
differ as well as author tastes - I can imagine some people quite
liking an IF world in which there are plenty of things to play with
and try out, even if they don't advance the action much, while
others will be more impatient of the possibility of trying a
multitude of things that don't advance the plot.
> So those are my reasons for thinking that there's merit in a
> simple
> world model: an aesthetic preference for focused interaction;
That can certainly be an advantage for certain types of game, no
doubt; it probably was for Swineback Ridge, and I think almost
certainly was for my MC Dream entry (sorry, I don't mean to keep
pushing it, it's just the only relevant piece of relevant personal
authorial experience I can draw on).
> doubts
> about the puzzle value of a complex simulation used across many
> games;
> frustration with my attempts to build and maintain complex models
> for
> use in multiple games; frustration with attempts to use the
> complex
> models provided by others;
I was going to say that it may be less of a frustration when the
complex model is part of the standard library, but may be there's a
temperamental difference here too: although I've never produced
anything using Platypus or Worldclass, I've played with both of them
and found them quite fun rather than frustrating. Of course, it
depends what you've mean by "complex" ; I've used some fairly
complex third-party extensions in some of my TADS 3 efforts, but
much of the complexity was in the extension code rather than the
author interface or the conceptuality of what the extensions were
aiming to provide. I wonder if I'm right in suspecting that part of
your frustration lay in wrestling with complex models that didn't
quite do what you wanted them to?
> a desire not to overwhelm novice authors; a
> wish to promote experimentation rather than standardization;
I can understand both these points, although I think there's also a
flip side to them: standardization can be of some value in terms of
conforming to players' expectations and not requiring novice authors
to reinvent too many wheels. But we're not really disagreeing here,
since we're both keen to argue that there's room for both approaches
(i.e. those exemplified by I7 and TADS 3).
> concerns about bulk and performance hits;
Yes, TADS 3 games look pretty bloated compared to z5 ones, and they
probably wouldn't run that fast on low-powered machines, but they're
fine on a reasonably modern PC or laptop. Bu then, to a lesser
extent, I suspect the same argument could favour using I6 rather
than I7. Of course this depends on how far reaching the widest
possible audience for your IF work is a major factor in choosing
what system to use (and I'm making no judgment on how important it
*should* be - IMHO that's entirely up to individual authors).
> reservations about the authorial
> time-cost of implementing the objects for a complicated world
> model;
Again, different authors will no doubt have different views on how
much that's something they hate, don't much mind, or love spending
time on (and all points in between). There can be a certain
satisfaction in producing a richly-implemented world for its own
sake, and some players, I think, appreciate such richly-implemented
worlds. Of course there's much more to IF than simulationism, and
simulationism can certainly be carried too far, but a certain amount
of world-simulation well done does, I think, provide one dimension
of the pleasure both authors and players can derive from IF.
Still, I don't think we're disagreeing; I'm mostly indicating my
agreement with you here, but taking the opportunity to qualify a few
points along the way.
-- Eric
Emily Short
Eric Eve wrote:
> OTOH (while trying to do my best to view this sine ira et studio), I
> can see why someone might be concerned that someone coming new to
> this forum might get the impression that being the new best thing I7
> it would be worth pointing out that TADS 3 is another new(ish)
> system that's also well worth looking at, and hasn't become obsolote
> just because I7 takes a different approach!
Sure -- I agree entirely.
> I also have some sympathy with Steve Breslin's questioning of the
> White Paper's critique of the OO model, in that it didn't convince
> me either (perhaps because it simply went over my head!). At least,
> the argument may make perfectly good said at some abstract
> theoretical level, but I have to say that at the purely pragmatic
> level of using TADS 3, its OO approach has seldom seemed even
> remotely problematic to me, even with actions involving multiple
> objects.
Ah hm yes. In my experience, the OO approach of Inform 6 was either not
an appreciable problem at all, or a fairly thorny one, depending on
what I was trying to do. Some of this had to do with inelegant
implementation (especially when it came to indirect objects) that I
have reason to believe TADS 3 handles more systematically. But I ran
into trouble particularly when
1) trying to specify actions that were going to affect or depend on
three or more factors;
2) trying to specify actions whose reporting was going to depend on the
states of multiple objects;
3) handling cases where I wanted objects to inherit some but not all of
the standard behavior of their classes.
To make a really convincing point of this, I'd need to go back and
unpack some of the code I wrote (for "City of Secrets" and
"Savoir-Faire") and essentially step the reader through the design
problems I had, how I resolved them, and why I think I7 makes them
lots, lots easier. Which I don't have time to do this afternoon, but if
there is a general interest in it I will try to add it to the to-do
list.
> I7's
> approach is clearly opening doors for folks who'd be scared witless
> by TADS 3, and that's great, but I can also quite understand why
> Steve Breslin (and others) might find TADS 3 code more intuitive
> than I7.
Yes -- though I'm also not sure it's as simple as a
programmer-vs-novice issue, either. But yes, clearly different people
find different modes of expression easiest to work with.
> > And finally, my experience of games written with complex libraries
> > by
> > people who didn't want their full potential has been, essentially,
> > that
> > the play feels clumsy, overengineered, and hampered by
> > distractions.
...
> I can see how this would happen. If you're going to write a game
> with something as complex as the adv3 library you'd better be
> prepared to customize a lot of default responses, at the very least
> (which is something that TADS 3 at least makes it pretty easy to
> do). But I suspect there's an area here where player tastes may
> differ as well as author tastes - I can imagine some people quite
> liking an IF world in which there are plenty of things to play with
> and try out, even if they don't advance the action much, while
> others will be more impatient of the possibility of trying a
> multitude of things that don't advance the plot.
Sure. I did enjoy the richness of texture of "Return to Ditch Day", for
instance. It's obviously possible to use these systems well and get a
good result out of them. But I don't think it's quite right to say
"since a complex world model is provided, even novice/lazy authors will
be able to get good complex behavior into their games" -- since some
work will still be entailed, and in some cases an uncustomized complex
model is more glaringly deficient than an uncustomized simple one.
> I wonder if I'm right in suspecting that part of
> your frustration lay in wrestling with complex models that didn't
> quite do what you wanted them to?
Or models that -- in *order* to be fully generalizable and powerful --
required me to express things in more complicated ways than I would
otherwise have to.
> Still, I don't think we're disagreeing; I'm mostly indicating my
> agreement with you here, but taking the opportunity to qualify a few
> points along the way.
Ditto.
Kevin Forchione
> Ah hm yes. In my experience, the OO approach of Inform 6 was either not
> an appreciable problem at all, or a fairly thorny one, depending on
> what I was trying to do. Some of this had to do with inelegant
> implementation (especially when it came to indirect objects) that I
> have reason to believe TADS 3 handles more systematically. But I ran
> into trouble particularly when
>
> 1) trying to specify actions that were going to affect or depend on
> three or more factors;
> 2) trying to specify actions whose reporting was going to depend on the
> states of multiple objects;
> 3) handling cases where I wanted objects to inherit some but not all of
> the standard behavior of their classes.
These cases are probably somewhat exasperated by the I6 library, which I
would describe as "object-based" rather than "object-oriented" in that the
game objects (or their superclasses) do not handle the action of the command
themselves (at least as the default), but rather this is handled by
functions. Certainly case 3 is something that should not be all that
difficult to achieve in a srictly OO design: i.e. a mix-in class could
easily perform this service, masking out certain behaviors).
> To make a really convincing point of this, I'd need to go back and
> unpack some of the code I wrote (for "City of Secrets" and
> "Savoir-Faire") and essentially step the reader through the design
> problems I had, how I resolved them, and why I think I7 makes them
> lots, lots easier. Which I don't have time to do this afternoon, but if
> there is a general interest in it I will try to add it to the to-do
> list.
Of course, the OO solution (or rather the object-based one) should be
discoverable by a simple perusal of the I6 code generated.
What would be of interest then, would be to place the two sets of code
side-by-side so that one can see what the design *could* be if done in the
I6 environment. The fact that I6 is accomplishing this through rule-based
tables and would be in a coding style "produced by a robot" doesn't discount
the fact that this is a viable solution that one *could* make use of in an
OO environment. It would remain then to determine if any of the code
generated by I7 being game-specific could be abstracted into a mechanism
useful in the general case. The OO solution would then involve the
definition of the pertinent classes, defintion of the pertinent rules, and
the ordering of these rules by hand.
All of which is not to say that I7 isn't easier, but that the solutions I7
creates for problems can be mapped onto solutions used by "traditional"
programming languages, as indeed I7 does with I6. The question that I keep
coming back to in my own head is that if these mechanisms make certain
problems easier to implement then perhaps a hybrid approach would be of
benefit to the OO community of languages... after all, neither I6 nor TADS 3
is *strictly* OO, why posit arguments in terms of pure paradigms?
--Kevin
Graham Nelson
> All of which is not to say that I7 isn't easier, but that the solutions I7
> creates for problems can be mapped onto solutions used by "traditional"
> programming languages, as indeed I7 does with I6.
Sure - these are all Turing machines; you can imitate pretty much any
approach from within any other, if you can stomach the appearance of
the resulting source code.
> The question that I keep
> coming back to in my own head is that if these mechanisms make certain
> problems easier to implement then perhaps a hybrid approach would be of
> benefit to the OO community of languages... after all, neither I6 nor TADS 3
> is *strictly* OO, why posit arguments in terms of pure paradigms?
To take this further - why must there be an orientation at all?
Shouldn't the author be able to express what's wanted in any style of
his own choosing?
Dennis G. Jerz
> I was intrigued at the time, but I didn't feel able to approach the
> topic intelligently; nearly six years later, I still don't think I
> could do it justice.
Has it been that long? My goodness!
I'm on vacation and away from all my notes, so I'm afraid all I can say
right now is "good post"!
Like any human artifact, a computer program -- and a programming
environment that makes the program impossible -- is going to reflect,
to at least some extent, the values of its creator. My favorite
examples are "As good looking as ever" and "Violence isn't the answer
to this one," though I've never actually asked Graham about the origin
of that phrasing. One of the first things I noticed about Inform 7 was
the new syntax for ending the game, which still preserves the concept
of victory, but no longer ties death so closely to loss.
As for personalizing libraries, I've observed something similar when I
introduce students to web design for the first time. Almost invariably,
they change the default colors of their sample website to their
favorite colors, and the first things their beta-testers say is "I hate
the orange-on-pink color scheme," so that by the second or third
revision we see a lot more pale blue and tan. Coming up with an
expandable library that serves a large number of people isn't the same
thing as coming up with the perfect library that works the way you want
it to. I'd agree with Emily's feeling that a simple world view, that
can be easily expanded, is far more important. If a default world
model includes variables for hunger, mass and volume for each inventory
object, or a default "readable things" concept burdened with intensity
of light that must be cross-referenced to the size of type on legible
items and cross-referenced with the degree of player tiredness, then
beginning programmers will focus far too much on world concepts that
might otherwise have little do to with whatever story idea prompted
them to pick up Inform 7 and start working with it.
I've had some experience teaching Inform since I wrote that original
CFP, and I'm looking forward to more teachinig this fall. In the past,
with Inform 7, only a few very devoted students got much beyond the
simple Inform exercises I created for them. I'm eager to see what
they'll be able to accomplish with Inform 7. I think the simplicity of
the world model and the well-integrated interface will really help the
students (who will be mostly English or other humanities majors) find
their own creative voice. Of course, for students who are not already
familiar with the conventions of IF, the world model is actually fairly
complex.
Thanks, Emily, for picking up that ball. As always, I'm impressed with
your clarity of thought.
Dennis G. Jerz
http://jerz.setonhill.edu/weblog
Kevin Forchione
> Kevin Forchione wrote:
>> All of which is not to say that I7 isn't easier, but that the solutions
>> I7
>> creates for problems can be mapped onto solutions used by "traditional"
>> programming languages, as indeed I7 does with I6.
>
> Sure - these are all Turing machines; you can imitate pretty much any
> approach from within any other, if you can stomach the appearance of
> the resulting source code.
Some of these guys insist they can. I wouldn't want to know what they eat
for breakfast though.
>> The question that I keep
>> coming back to in my own head is that if these mechanisms make certain
>> problems easier to implement then perhaps a hybrid approach would be of
>> benefit to the OO community of languages... after all, neither I6 nor
>> TADS 3
>> is *strictly* OO, why posit arguments in terms of pure paradigms?
>
> To take this further - why must there be an orientation at all?
> Shouldn't the author be able to express what's wanted in any style of
> his own choosing?
Absolutely. Having a language capable of supporting multiple programming
styles and multiple programming paradigms would go a long way toward
producing elegant solutions to the more intractable problems.
--Kevin
Emily Short
Eric Eve wrote:
> I can see how this would happen. If you're going to write a game
> with something as complex as the adv3 library you'd better be
> prepared to customize a lot of default responses, at the very least
> (which is something that TADS 3 at least makes it pretty easy to
> do). But I suspect there's an area here where player tastes may
> differ as well as author tastes - I can imagine some people quite
> liking an IF world in which there are plenty of things to play with
> and try out, even if they don't advance the action much, while
> others will be more impatient of the possibility of trying a
> multitude of things that don't advance the plot.
Just a quick addition, because my previous reply was written under a
bit of time pressure and I didn't answer this as fully as I meant to:
I'm not arguing here against complex models within specific games, only
against the complex model provided as a default; I do think that it can
be fun and relevant to have a deeply modeled world in a specific game.
I've written elsewhere that I think the liquid handling in Savoir-Faire
is relevant to the purpose and nature of the game, for instance, even
though there are lots of things to do with it that aren't at all useful
for plot advancement. Similarly, I enjoyed the range of wacky
alchemical results one can get in Dreamhold, the thoroughness of
description and scenery in Worlds Apart, the flexibility of gadgets in
Spider and Web, the unnecessary responses built into the computer in
Slouching Towards Bedlam, and so on -- providing some aspect of the
world that opens up to playful exploration contributes a lot to a game.
But, again, I think it's useful to be selective about where that effort
goes; and much of what makes these things *fun* is the stuff that you
can't draw from a standard library: unexpected bits of description,
unanticipated outcomes, flashes of humor, moments when the action that
doesn't advance the plot nonetheless reveals some interesting
tangential fact about the backstory or the world.
Eric Eve
Thanks for your further thoughts, which all make pretty good sense
to me; but they also prompt some further reflections of my own.
You say above that you're arguing "only against the complex model
provided as default". But if we're thinking in terms of comparing
the world models of Inform (whether I6 or I7) and TADS 3 (which
seems to me to be a useful exercise to earth an otherwise abstract
discussion), I'm not entirely sure how far the additional complexity
of the TADS 3 model (strictly speaking, the adv3 library) actually
impacts on the player (as opposed to the author) by default.
For example, the fact that TADS 3 has a much more complex class
hierarchy that either I6 and I7 is *partly* to do with differences
in implementation rather than differences in the underlying world
models (which, at root, are actually pretty similar). What Inform
does by means of properties/attributes (such as openable, lockable,
enterable and the like) TADS (2 or 3) does by means of classes
(Openable, Lockable, NestedRoom), so this in itself requires TADS 3
to have a more elaborate class hierarchy (although I'm not
pretending this is the full story, see below).
Again the fact that the TADS 3 library provides more ready-made
classes by default (e.g. Candle and Flashlight) does not in itself
entail that it presents a more complex model to the player. An
out-of-the-box TADS 3 Flashlight will probably behave identically
from the player's point of view as a plain-vanilla I7 flashlight
built from a device.
It is perfectly true that the TADS 3 library models as standard
things that are not modeled as standard in Inform (I6 or I7), such a
bulk and weight, different lighting levels, sense passing and the
like, but I'm not sure that any of these additional complexities
automatically present themselves to the player unless the author has
deliberately made use of them; they don't seem to me to present
distracting or obtrusive parts of the world model (from the player's
perspective) just because they're part of TADS 3's standard library.
I grant you that there are a few features of TADS 3's standard
library (not shared by Inform) that would be apparent to a player
simply by virtue of their being included as standard: actor posture
is one such (this allows the player to type SIT, LIE and STAND
commands and have the PC change posture); another would be the
inclusion of PUT UNDER, LOOK BEHIND and PUT BEHIND as standard
(which is ulimately my fault, IIRC!), which could in theory (though
is less likely in practice to) result in players wasting time trying
futile actions: just because the TADS 3 libary provides Underside
and RearSurface classes as standard doesn't force any game author to
use them, so they don't *automatically* add complexity to the world
model perceived by the player.
It's true that the default handling of THROW X AT Y in TADS 3 can be
problematic, in terms of allowing useless actions with sometimes
dodgy default responses (e.g. "The dagger hits the boss without any
obvious effect, and falls to the floor.") which Inform blocks with
the laconic "futile", but that, I think, is properly an issue
concerning the implementation of certain actions, not the complexity
of the world model per se. (Is the fact the the adv3 library
supplies a greater range of actions than the I7 one by default part
of what you had in mind, perhaps?).
Or to come at this from a slightly different angle, as an exercise
in providing some pieces of sample TADS 3 code for people to look at
I've produced TADS 3 ports of the William Tell and Captain Fate
examples from the IBG, and of the Ruins example from the DM4 (all
available from http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm).
Now, while it's true that there are one or two places where I had to
tweak TADS 3 behaviour to imitate Inform behaviour a bit more
closely, these weren't really issues of model *complexity*, and so
far as I can tell, my TADS 3 ports play pretty much the same as
their Inform originals (with one or two differences, no doubt). As
the author of these ports I'm probably the worst person to judge,
but it doesn't seem to me that the fact that they're based on the
adv3 library rather than the Inform library presents the player with
a significantly more complex model to interact with.
So, although I initially agreed with you that the more complex world
model of TADS 3 might clutter a game with more irrelevant
destractions than the leaner I7 model, on further reflection, I'm
having a hard time seeing why that should be. Perhaps you could help
me out with some examples? (You don't have to name games if you want
to spare their authors!)
-- Eric
Richard Bos
> Graham Nelson wrote:
> > [I7] is rich in ways to write rules, which can be
> > specified with surprising flexibility.
>
> I think you are unaware of how this sounds, at least to the reader who
> you are formally addressing.
To the reader Graham formally addresses? That would be the entire
newsgroup, then - since that is how newsgroups work, like it or not.
Well, as part of that newsgroup, let me state that to me it sounds like
a sentence which is entirely reasonable for the author of said system to
write, regardless of whether or not I agree with it.
Richard
Emily Short
Eric Eve wrote:
> You say above that you're arguing "only against the complex model
> provided as default". But if we're thinking in terms of comparing
> the world models of Inform (whether I6 or I7) and TADS 3 (which
> seems to me to be a useful exercise to earth an otherwise abstract
> discussion), I'm not entirely sure how far the additional complexity
> of the TADS 3 model (strictly speaking, the adv3 library) actually
> impacts on the player (as opposed to the author) by default.
>
> For example, the fact that TADS 3 has a much more complex class
> hierarchy that either I6 and I7 is *partly* to do with differences
> in implementation rather than differences in the underlying world
> models (which, at root, are actually pretty similar).
Well, okay. I sympathize with the desire to look at actual data in
support of what has been a rather abstract discussion, but I also worry
that we're about to confuse the issue. On the one hand, you suggest
that the world model of TADS 3 is not always much more complex than the
world model of Inform 7; on the other hand, you invite me to critique
the play experience of TADS 3 games in support of my argument that
excessively complex standard world models can cause defects in play. To
the extent that the models are similar, such critique will not prove
anything about the argument at hand; so I'd like to talk about the
world models of the two libraries a little first.
It seems dumb to say this in a post replying to you, Eric, but for
anyone else who may be reading who has not taken a look at one of these
languages, a lot of the TADS 3 classes are explained in the TADS 3 Tour
Guide, to be found at
http://users.ox.ac.uk/~manc0049/TADSGuide/index.html
and that more information may be found in the protodocumentation
available from
and the Inform 7 documentation is online at
http://www.inform-fiction.org/I7/Manual.html
> What Inform
> does by means of properties/attributes (such as openable, lockable,
> enterable and the like) TADS (2 or 3) does by means of classes
> (Openable, Lockable, NestedRoom), so this in itself requires TADS 3
> to have a more elaborate class hierarchy (although I'm not
> pretending this is the full story, see below).
I agree: TADS classes appear to handle a great deal that Inform (6 or
7) would do with properties (Immovable, Food, TravelPushable, along
with others that you named); much that I7 would handle with rules
(Heavy, AutoClosingDoor, StairwayDown, StairwayUp, TravelWithMessage,
TravelBarrier, etc); and a few things that I7 would handle with
relations (I'm thinking of Component vs. the "is part of" relation).
Of course, the equivalence is not completely simple. There are cases
where the I7 implementation of something with rules would require a bit
more effort than using the TADS 3 class: for instance, it takes more
lines to set up a staircase or ladder -- though the manual does explain
how to do this, or make a kind to handle it automatically. There are
also cases where the I7 implementation appears a bit more flexible,
assuming I understand what's going on in TADS 3. I could be entirely
mistaken in this, but my impression of the Component class, for
instance, is that a component may be required to remain a portion of
the thing it's part of; whereas the I7 "part of" relation can be formed
or broken during play if the author chooses, allowing for, say, sticky
labels that can be moved from object to object, or items being glued to
other items. Not, I admit, something one is likely to need with
overwhelming frequency, but still, it is a way in which the relational
treatment may come with a bit more intrinsic power -- always assuming
that I'm even right about my initial reading of the way the class
works.
A bit more subtly, in the TADS 3 library, all these are provided:
GiveTopic
ShowTopic
GiveShowTopic
AskTopic
TellTopic
AskTellTopic
AskForTopic
AskAboutForTopic
AskTellShowTopic
AskTellGiveShowTopic
The combinations make sense as a class-based shorthand way of saying
"hey, deal equally with all these verbs when applied to this topic",
but in I7 I would handle this with a compound rule, or -- if I
anticipated needing to associate the same set of actions repeatedly --
by defining a kind of action. So this is another place where a tool is
provided for the author, but TADS 3 provides the tool in the form of a
class definition, and I7 in the form of a bit of rule-writing syntax.
But what I'm mostly saying is that I agree with your assessment that
the TADS 3 class-complexity does not mean in all cases a greater
complexity of modeled world, and this makes me want to be a bit
cautious in deriving conclusions about world modeling complexity by
comparing I7 and TADS 3.
If I may revert briefly to an earlier topic, though: in looking at all
this I am impressed by a sense of the conceptual differences between
the two languages, even where the player's experience of the
implementations may wind up being nearly identical. For instance: TADS
3 offers a comprehensive set of ways to model space, including some
neat abstract thinking about the way spatial relationships affect a
player's participation in the world: whence classes like SpaceOverlay,
Distant, OutofReach, HighNestedRoom; or, less obviously,
TravelConnector, PushTravelBarrier, Occluder, SenseConnector, etc.
Though I realize the player would not experience them as such, I find
myself thinking of these things as reified in a way that has no
equivalent in my conception of an I7 world model. I envision, e.g., a
TravelConnector as a sort of tube between locations. I'm not quite
certain what effect that would have on my coding style, but it is a way
in which I immediately imagine the created world differently than I
would in another language. (This reminds me a tiny bit of the mental
shift required to do 3D modeling: suddenly one begins to think of
physical objects in terms of the regular solids, lathed surfaces,
extrusions, unions and intersections of space; the round hollow inside
a teapot becomes, conceptually, a thing in itself, when it must be
created and then subtracted from another shape.)
In any case, one implicit idea in the TADS 3 library seems to be that
we express a great deal of what we need to express about an IF world in
terms of physical space; that physical relationships are intrinsic and
often static, so that (say) being-behind-something, or
being-part-of-something, or even
waiting-to-be-present-later-in-the-game, can itself be a fundamental
aspect of a thing; that relationships may need to be represented as
hierarchical even when no physical hierarchy exists, as with
PermanentAttachments having one attachment as an attachedObject of the
other regardless of physical arrangement represented.
I7 transfers many of these ideas to the realm of relations, which are
potentially fluid (ie, do not necessarily indicate unchangeable aspects
of an object -- something can cease to be part of another object
midplay, whereas something cannot cease to belong to the Component
class, I assume); bidirectional (ie, do not necessarily impose a
hierarchical relationship between the related objects); and computed on
the fly (in the case of relations that express conditions). What is
expressed by I7's kinds is often instead the *potential* to participate
in a given relation: a container is that which may contain things, a
supporter that which may support things, and so on; and for reasons
both of expressiveness and of memory optimization, it is often wise to
define new kinds to indicate what things may participate in a new-made
relation. (Of course in TADS 3 containers may or may not be containing
anything at the moment, and so on -- my point is just that TADS 3
appears to use classes both to express the possibility of relationship
and, in some cases, the fact of that relation being present, whereas I7
tends to use kinds more in the former case only.) And, as I said, I7
does not provide as many built-in varieties of spatial relationship.
Conversely, I7 has a more extensive vocabulary (again, as far as I can
tell from my overview of TADS 3 classes; forgive me if I missed
something) for dealing with concepts of time, narrative, and
circumstance, as separate from objects. In particular, I think there is
a stronger idea that an arbitrary set of facts about the world can
control an action (as opposed to that action being dependent on mostly
on the one or two objects named). This is partly to do with fact that
action-handling is rule-based, and partly with the specific types of
rules that I7 allows us to write. Events need not be tied to fuses;
scenes monitor world state and react to arbitrary combinations of
changes; there are mechanisms for writing rules depending on how often
an action has previously occurred, or whether it has occurred at all;
and so on. Of course I am certain that one could emulate these effects
in TADS 3 by attaching counters in the relevant places, but my sense is
that the means to manipulate time, plot, scenes, etc., are treated as
less significant by the TADS 3 library (though I know extensions
provide some of these things in more detail).
This is all somewhat tangential to the question of game design
aesthetics from a player perspective, however -- and, obviously, my
grasp of TADS 3 is much weaker than my grasp of I7, so please do
correct me if I've misrepresented anything. I'm sure there's lots else
to be said here, too.
> Again the fact that the TADS 3 library provides more ready-made
> classes by default (e.g. Candle and Flashlight) does not in itself
> entail that it presents a more complex model to the player. An
> out-of-the-box TADS 3 Flashlight will probably behave identically
> from the player's point of view as a plain-vanilla I7 flashlight
> built from a device.
This is probably true. I still think that there is an argument to be
made that ready-made classes influence the designer to implement in a
specific way; the counter-argument would be, of course, that a
ready-made class may remind the designer of issues in his
implementation that he might otherwise have forgotten to consider. But
in terms of the specific issue of complicating player experience,
you're presumably right -- classes of this kind can be included or not,
and if the author doesn't want them, they won't affect the game at all.
So possibly there's no real loss in having these in the standard
library (unless the class prototypes add bulk to the game, and even so
that may not be a major consideration); though I'm also not sure I'm
convinced there's much gain. What would be lost by relegating these
more particular ready-mades to an extension?
> It is perfectly true that the TADS 3 library models as standard
> things that are not modeled as standard in Inform (I6 or I7), such a
> bulk and weight, different lighting levels, sense passing and the
> like, but I'm not sure that any of these additional complexities
> automatically present themselves to the player unless the author has
> deliberately made use of them; they don't seem to me to present
> distracting or obtrusive parts of the world model (from the player's
> perspective) just because they're part of TADS 3's standard library.
Here I would need to go back and replay a bunch of games to decide
whether I agree or disagree; but see below.
> It's true that the default handling of THROW X AT Y in TADS 3 can be
> problematic, in terms of allowing useless actions with sometimes
> dodgy default responses (e.g. "The dagger hits the boss without any
> obvious effect, and falls to the floor.") which Inform blocks with
> the laconic "futile",
I've run into this, yes.
> but that, I think, is properly an issue
> concerning the implementation of certain actions, not the complexity
> of the world model per se.
I would consider action handling to be an aspect of the world model,
though, alongside the specific objects themselves. This is definitely
an action I'd rather have turned off by default, because making it work
sensibly in a given game almost always requires at least some
customization: it's very much more likely that I will write a game in
which THROW X AT Y will never be important than that I will write one
in which every object should bounce harmlessly off every other. All it
takes is one windowpane, letter opener, china vase, vicious pitbull,
etc., and suddenly you've got an immersion-breaking bug. (I've never
liked the default of >JUMP in Inform, either, because it produces bugs
as soon as you have a floorless location; but I think THROW is worse
just because the likelihood of introducing a fragile or dangerous
object into a given game is higher.)
> (Is the fact the the adv3 library
> supplies a greater range of actions than the I7 one by default part
> of what you had in mind, perhaps?).
Well, not adv3 specifically, but libraries in general that do so.
I argued in a somewhat-related post a while back[1] that design of
actions and action grammar is itself a subtle art: that the game should
(in my opinion) ask from the player exactly as much information as the
world model requires to fully determine the action, but that some world
models will require more information than others, and that therefore
grammars should be adapted accordingly. So for instance >CUT FOO might
be useful in some cases, but in others >CUT FOO WITH BAR might be a
more appropriate syntax; the default implementation can actually get in
the author's way if he wants to do something differently-phrased, and
the generic default implementation usually doesn't add much of interest
to the player's experience except perhaps an acknowledgement that the
game recognizes "CUT" as a verb. Even that may be counter-productive,
in the sense that, if I'm totally on the wrong track with even thinking
about cutting things, and the game is really about conversation (or
whatever), I'd rather have an indication that this is not going to be a
useful verb. (I'm reminded of Adam Cadre's early complaint about
"Galatea" that the game did not have any interesting reaction to
>JUMP.)
In this respect, the I7 standard library doesn't behave exactly in the
way I might now draft something myself, especially if I were doing so
from scratch and with no particular reliance on I6. I might well strip
out such things as locking and unlocking by default and leave those to
extension territory; and I might change the handling of completely stub
actions (I'm thinking of things like >WAVE and >SING and >RUB) so that
one just got a somewhat generic "you don't need that action" response
unless the author had done something to customize the action. To a
player familiar with the default messages, the generic response often
already sends that message, more or less, but there's a bit more of a
chance that the verb might be useful under special circumstances; and a
few responses ("There's nothing to drink here", e.g.) do become
obviously nonsensical sometimes. Finally, sometimes even when the
author supplies a "you don't need that action" message, the grammar of
the default library still puts the player through a stupid two-step.
One of the intentions of the
Understand "unlock [text]" as a mistake ("You don't need to unlock
anything in this game.").
syntax, in Inform 7, is to provide for catching UNLOCK DOOR, UNLOCK
DOOR WITH SILVER KEY, etc., in a systematic way without ever making the
player go through a nonsense exchange like "...What do you want to
unlock that with? ...Sorry, unlocking isn't necessary in this game."
In glancing at the TADS 3 library for related issues, I noticed that
there seems to be a kind of half-implementation of fire and burning,
complete with a FireSource class, but that actual burning and
being-on-fire does not seem to be addressed by the library. (Again:
I've perused the Tour Guide and the Proto-Documentation, but, not
having spent much time playing with the language myself, I am not
always entirely sure that my conclusions are correct, so I apologize
for any errors of fact.) If I have this right, anyway, I think it's a
case where I would have taken a different approach. I would not want to
handle burning in any standardized way either, but I'm not convinced
that even this partial default is entirely desirable; it seems to me
that it will encourage interactions like
> burn martyr
What do you want to light him with?
> match
He is not something you can burn.
or perhaps
> burn martyr
(with the match)
He is not something you can burn.
...even in cases where no useful burning will ever occur in the
entirety of the game; yet the impression, from the disambiguation
question or intelligent defaulting, may be that burning is a meaningful
interaction in this work but doesn't happen to do anything with the
chosen direct object.
The better the game is otherwise, the less this kind of thing is likely
to distract the player, because the author will have provided a host of
other clues about goals and appropriate interactions. But I'm still not
convinced that it's a net advantage to anyone, and in poorly-designed
works it can become a serious disadvantage.
[1] Me, on a bunch of subjects partly including action design:
http://groups.google.com/group/rec.arts.int-fiction/msg/9dc271ee31797fb0?hl=en&
> Or to come at this from a slightly different angle, as an exercise
> in providing some pieces of sample TADS 3 code for people to look at
> I've produced TADS 3 ports of the William Tell and Captain Fate
> examples from the IBG, and of the Ruins example from the DM4 (all
> available from http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm).
> Now, while it's true that there are one or two places where I had to
> tweak TADS 3 behaviour to imitate Inform behaviour a bit more
> closely, these weren't really issues of model *complexity*, and so
> far as I can tell, my TADS 3 ports play pretty much the same as
> their Inform originals (with one or two differences, no doubt). As
> the author of these ports I'm probably the worst person to judge,
> but it doesn't seem to me that the fact that they're based on the
> adv3 library rather than the Inform library presents the player with
> a significantly more complex model to interact with.
Again, I'd have to fiddle with them to be sure, but at a guess I would
imagine you're probably right. The thing is that a complex standard
implementation becomes more problematic the more the game's interaction
style deviates from that standard. I expect that I would not find any
extra detail provided by being able to SIT, STAND, LOOK BEHIND, etc.,
to be particularly jarring in "William Tell" or "Captain Fate", given
that these are themselves (as I recall) fairly standard
physical-interaction games, and the added actions are in keeping with
the general behavior required elsewhere.
> So, although I initially agreed with you that the more complex world
> model of TADS 3 might clutter a game with more irrelevant
> destractions than the leaner I7 model, on further reflection, I'm
> having a hard time seeing why that should be. Perhaps you could help
> me out with some examples? (You don't have to name games if you want
> to spare their authors!)
For what it's worth, when I said that I'd played some games where a
complex world model was a distraction, I had in mind a couple of TADS 3
games, but also other games in other systems; and for the reasons I've
cited, I'm not sure that my critique on TADS 3 games would necessarily
be conclusive about the point I was originally making, which was
explicitly not an I7/TADS 3 comparison.
Still, I'm willing to have a look back at some games I remember working
poorly for me, and see what further examples emerge. Unfortunately, I
do not have more time to spend on this now, but I'll try to get to it
later.
na...@natecull.org
Emily Short wrote:
> It could still be argued that any such provisions at all will influence
> authors unduly, or provide things that need to be overridden: someone
> writing a game set on a planet with a 27-hour day would have to retool
> the time handling, for instance.
Yes, and this is not an academic issue: one of the very first game
fragments I tried to implement in I7 when I first saw the beta was one
set on Mars, which would have a roughly 25-hour day with a
non-hour-based time system (like in Kim Stanley Robinson's Mars
trilogy), and I sighed when I realised time handling was still
hard-coded and measured in 'minutes', so I didn't bother to follow up
that idea any further. I mean, I''m sure I *could* implement that, but
it would involve large chunks of I6 and replacement of the standard
library. (Or maybe it would just take a few new phrases - can't tell
without looking at the library).
That's an example of the sort of stuff that I think should be a
configurable module, not hard-coded in a basic library.
Emily Short
na...@natecull.org wrote:
> Emily Short wrote:
>
> > It could still be argued that any such provisions at all will influence
> > authors unduly, or provide things that need to be overridden: someone
> > writing a game set on a planet with a 27-hour day would have to retool
> > the time handling, for instance.
>
> Yes, and this is not an academic issue: one of the very first game
> fragments I tried to implement in I7 when I first saw the beta was one
> set on Mars, which would have a roughly 25-hour day with a
> non-hour-based time system (like in Kim Stanley Robinson's Mars
> trilogy), and I sighed when I realised time handling was still
> hard-coded and measured in 'minutes', so I didn't bother to follow up
> that idea any further. I mean, I''m sure I *could* implement that, but
> it would involve large chunks of I6 and replacement of the standard
> library. (Or maybe it would just take a few new phrases - can't tell
> without looking at the library).
Hm -- hard for me to tell much without a little more specificity about
what you wanted to do. How would you want number-of-turns to relate to
the passage of time? What basic time unit would you use, if any? And
would you want to be able to use event-scheduling, or would that have
been irrelevant to you?
na...@natecull.org
Emily Short wrote:
> Hm -- hard for me to tell much without a little more specificity about
> what you wanted to do. How would you want number-of-turns to relate to
> the passage of time? What basic time unit would you use, if any? And
> would you want to be able to use event-scheduling, or would that have
> been irrelevant to you?
Well, for a start, I would generally rather deal in 'turns' as the base
unit of time than 'minutes'. I would like all event scheduling to talk
about 'x turns from now' or 'x turns after play begins' or just 'x
turns'. Because the IF model is turn-based (okay, leaving aside
real-time games like Border Zone), and for some games, it simply isn't
appropriate for turns to map to minutes at all - like Christminster,
for instance, where time is assumed to not change except at major scene
boundaries. I would like the default assumption to be that there is no
(or indeterminately flexible) time passing except where the author
specifies this.
Then, if I was going to use a time system, I would like to specify:
a) the structure and representation of the time unit system -
presumably that would use the normal Inform multiple-number-slot unit
system - do I want seconds/minutes/hours, maybe, for a very fast-paced
action game? Or hours/days/weeks for a long-term travel game? Or my
custom Martian time, or some futuristic decimal time based on work
shifts?
c) how to display the time on the status bar: do I want to show '8:00
am', or '0800 Zulu'?
b) the initial time for turn zero, or 'when play begins' - do I want
the game to start at 8:00 am, 9:00 am, 12:59 pm Wednesday night?
c) how many base time units advance on each turn - do I want a turn to
be one minute, five minutes,
d) ways of manually advancing or retarding the time for scripted events
- so that the time / calendar can jump forward an hour or day when the
player gets arrested, for instance
With of course sensible defaults, like minutes etc, if you pick the
default implementation - but the basic idea being that 'minutes' not be
hardwired anywhere as a proxy for 'turns'.
'The time is <whatever>' should ideally just be a function call /
phrase that resolves to the value of a 'time' global, which may or may
not be the same as 'turns since start of game'. I don't mind if 'time'
is reserved as the signifier for 12-hour-minute-based time, we can use
'military time' or 'space time' or 'Mayan time' whatever as the
signifiers for other exotic time systems, just as long as we can get
away from time-as-rigid-turn-advance if we need to.
Emily Short
na...@natecull.org wrote:
> Emily Short wrote:
> > Hm -- hard for me to tell much without a little more specificity about
> > what you wanted to do. How would you want number-of-turns to relate to
> > the passage of time? What basic time unit would you use, if any? And
> > would you want to be able to use event-scheduling, or would that have
> > been irrelevant to you?
>
> Well, for a start, I would generally rather deal in 'turns' as the base
> unit of time than 'minutes'. I would like all event scheduling to talk
> about 'x turns from now'
This you can do.
> Then, if I was going to use a time system, I would like to specify:
> a) the structure and representation of the time unit system -
> presumably that would use the normal Inform multiple-number-slot unit
> system - do I want seconds/minutes/hours, maybe, for a very fast-paced
> action game? Or hours/days/weeks for a long-term travel game? Or my
> custom Martian time, or some futuristic decimal time based on work
> shifts?
This you can do by specifying your own units.
> c) how to display the time on the status bar: do I want to show '8:00
> am', or '0800 Zulu'?
Description of new units you define is not so hard either; Inform will
make a default printing rule for the unit you design, but you can add
your own say phrases to modify this...
> b) the initial time for turn zero, or 'when play begins' - do I want
> the game to start at 8:00 am, 9:00 am, 12:59 pm Wednesday night?
No problem there.
> c) how many base time units advance on each turn - do I want a turn to
> be one minute, five minutes,
You can set this by changing the behavior of the advance time rule.
> d) ways of manually advancing or retarding the time for scripted events
> - so that the time / calendar can jump forward an hour or day when the
> player gets arrested, for instance
Sure.
I think there are a couple of places that still use the concept of 24
hour time mandatorily, one being scheduling of clocktime events and one
being the "time since scene began is foo minutes" construct; and I
would be sympathetic to the argument that the scene business, at least,
might be better expressed in terms. (Some such argument has in fact
already been advanced.)
But you can handle a lot of your issues as in the following example:
<code>
The Barren Lavender Surface of Zql is a room. "It is late twilight on
Zql. Overhead, two crescent moons, both green, mark the sluggish
passage of time. A cold wind is blowing over the pale purplish ground
cover, but it does not penetrate your airtight suit."
A Zqlran date is a kind of value. 14-88 specifies a Zqlran date with
parts zqls and frbs.
Current zqlran date is a zqlran date that varies. The current zqlran
date is 8-22. Previous zqlran date is a zqlran date that varies. The
previous zqlran date is 8-20.
When play begins:
change left hand status line to "[current zqlran date], or [current
zqlran date in words]".
Procedural rule:
substitute the Zqlran time rule for the advance time rule.
This is the Zqlran time rule:
increase turn count by 1;
change the previous zqlran date to current zqlran date;
change the current zqlran date to current zqlran date + 0-02;
repeat through the Table of Zql Schedule
begin;
if era entry is greater than previous zqlran date and era entry is
not greater than current zqlran date
begin;
say event entry;
say paragraph break;
blank out the whole row;
end if;
end repeat.
To say (Zqlra - a Zqlran date) in words:
say "[zqls part of Zqlra] Z, [frbs part of Zqlra] f."
Table of Zql Schedule
era event
8-24 "A wisp-thin cloud blows rapidly across the face of Nepenthe, the
lesser of the two green moons."
8-28 "The cloud across Nepenthe clears."
</code>
And of course Inform's unit handling will also mean that if you need to
parse Zqlran time for some command or other, it will automatically
provide an appropriate parse token. Similarly, if you want you can then
change the current zqlran time at other points in play. (You can change
the time of day too, if you want, during play.)
> 'The time is <whatever>' should ideally just be a function call /
> phrase that resolves to the value of a 'time' global, which may or may
> not be the same as 'turns since start of game'. I don't mind if 'time'
> is reserved as the signifier for 12-hour-minute-based time, we can use
> 'military time' or 'space time' or 'Mayan time' whatever as the
> signifiers for other exotic time systems, just as long as we can get
> away from time-as-rigid-turn-advance if we need to.
Yeah. Well, there may still be bits of your request that this doesn't
adequately handle...? But if the answer is that a) the code above
pretty much does the kind of thing you want and b) you just didn't
realize this was possible, maybe I should look into making some such
thing an example in the docs.
Gene Wirchenko
>na...@natecull.org wrote:
>> It is *far* easier to add things to a standard world model
>> than to change or remove them[.]
Quite.
>TADS 3, and TADS 2 for that matter, makes it pretty easy to 'modify' or
>ignore base-classes, with no ill effects. The assumptions I can think
>of, in the main library of TADS 3, are also necessary in I7: PC, Room;
>location (which you can call a relation if you like). But of course, as
>you know, TADS 3 is a programming language proper, and the entire
>library is optional.
>
>> It's nice to have a pre-built 'locked door' class, for instance, but
>> that's absolutely useless if it assumes that 'locking' involves a key,
>> while you want a set of doors on a space station locked by entering a
>> code on a numeric keypad.
>
>You seem to be talking about a hpyothetical system which is very badly
>designed. I hope you are not implying that TADS 3 participates in any
>form of this foolish hypothetical system. One could more easily make
>fun of rule-based programming.
It is a cleaner design to be able to say:
Assume this, that, and other thing.
Here is my code.
than:
Here is my code, but
please do not assume alpha, beta, or gamma,
or anything else that I do not want, but because I do not
know the entire model, I am unable to specify and may only find out
after I thought I was complete.
With no default library, you get the first scenario.
There is nothing stopping you from deciding that you want the
assumptions of a given model. That is also the first scenario.
Why suffer from assumptions though if you do not want them?
>> That's why I far prefer less stuff in the core world model than more,
>
>What's why? Because the core world model, its class hierarchy, is,
>what, necessarily insifficiently variegated?
>
>TADS 3 does it right. That's a major point of the entire exercise.
With different preferences, it is also true that it does it
wrong.
>> I actually wish I7 had *less* in it by default and more in extensions.
>
>I can appreciate the feeling of this -- I have felt this, and still do.
>Later, I'll try to explain my theory of what should be in the main
>library vs. what should be in extension.
Why even have a main library? (By main library, I refer to one
that is always included.)
>> TADS2's 'modify' and 'replace' directives were a good way of
>> approaching the 'prebuilt classes assume too much' problem. I presume
>> TADS3 has similar directives.
>
>Yes indeed. I have no appreciation for the "prebuilt classes assume too
>much" pseudo-problem. This might be a problem in I6, which I7 solves,
>but it does not surpass TADS 3 simply by avoiding programmatic
>prototypes, world-model objects or otherwise.
If one has to turn it off somehow, it is already a problem.
>The terms of comparison, so far, are very silly indeed. Not nearly
>sophisticated enough. The main thing I hope for, in this and similar
>debates, is a recognition of the simplicity of the terms and
>distinctions we're making.
>
>> I7's rules are another, different (and I
>> think more powerful, but possibly less predictable) approach.
>
>I think it's not a matter of "powerful" (vague term anyway) but "easy"
>-- and easy because it doesn't require so much specification from the
>user; the necessary information is filled-in, with defaults, and not
>necessarily pre-planned defaults, but system-discovered defaults. So, I
>think the "power" (or ease) and the lack of oversight are two sides of
>the same coin.
>
>I feel that I'm in very close agreement with you, Nate. I guess the
>only major difference is that you've experienced the mind-changing
>insight of the rule-based gestalt, and I have not yet.
I have programmed OOP, and I have never bothered with the IF
languages, because I really could not see a solution to the
which-object-gets-the-code problem.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Eric Eve
>
>
> Of course, the equivalence is not completely simple. There are
> cases
> where the I7 implementation of something with rules would require
> a bit
> more effort than using the TADS 3 class: for instance, it takes
> more
> lines to set up a staircase or ladder -- though the manual does
> explain
> how to do this, or make a kind to handle it automatically. There
> are
> also cases where the I7 implementation appears a bit more
> flexible,
> assuming I understand what's going on in TADS 3. I could be
> entirely
> mistaken in this, but my impression of the Component class, for
> instance, is that a component may be required to remain a portion
> of
> the thing it's part of; whereas the I7 "part of" relation can be
> formed
> or broken during play if the author chooses, allowing for, say,
> sticky
> labels that can be moved from object to object, or items being
> glued to
> other items.
>
> are
> potentially fluid (ie, do not necessarily indicate unchangeable
> aspects
> of an object -- something can cease to be part of another object
> midplay, whereas something cannot cease to belong to the Component
> class, I assume);
Actually it can, and hence one can detach a component from its
possessor. TADS 3 allows you to change the class of an object
dynamically at run-time, so, for example, if I wanted a component to
come loose (e.g. the handle comes off the suitcase), I could write:
handle.setSuperclassList([Thing]);
And now the handle behaves like a (loose, portable) Thing, and is no
longer a Component.
There is, however, a different problem with the TADS 3 Component
class, namely that a Component is contained by the thing of which it
is a component (so that the handle would be shut inside the suitcase
when you close the suitcase); there is a standard TADS 3 solution to
this (you'd need to make the suitcase a ComplexContainer), but it is
a bit of a fiddle. But my main point is that TADS 3 classes are
*not* necessarily fixed essences, since they can be changed at
run-time.
> Conversely, I7 has a more extensive vocabulary (again, as far as I
> can
> tell from my overview of TADS 3 classes; forgive me if I missed
> something) for dealing with concepts of time, narrative, and
> circumstance, as separate from objects.
This is certainly true (with the caveats you give below).
> In particular, I think there is
> a stronger idea that an arbitrary set of facts about the world can
> control an action (as opposed to that action being dependent on
> mostly
> on the one or two objects named). ... Of course I am
> certain that one could emulate these effects
> in TADS 3 by attaching counters in the relevant places, but my
> sense is
> that the means to manipulate time, plot, scenes, etc., are treated
> as
> less significant by the TADS 3 library (though I know extensions
> provide some of these things in more detail).
Indeed so, but I take your point that the TADS 3 library doesn't
automatically encourage authors to think in terms of Scenes and the
like. But as you say, a combination of Fuses and Daemons can
probably emulate the effect, and it wouldn't be hard to come up with
a Scene (perhaos implemented a bit like the AgendaItem class) if you
wanted one.
> This is all somewhat tangential to the question of game design
> aesthetics from a player perspective, however --
Indeed.
> and, obviously, my
> grasp of TADS 3 is much weaker than my grasp of I7, so please do
> correct me if I've misrepresented anything. I'm sure there's lots
> else
> to be said here, too.
No problem; and please forgive me if I've come over as excessively
didactic in my correction!
> So possibly there's no real loss in having these [sc Flashlight
> and the like] in the standard
> library (unless the class prototypes add bulk to the game, and
> even so
> that may not be a major consideration); though I'm also not sure
> I'm
> convinced there's much gain. What would be lost by relegating
> these
> more particular ready-mades to an extension?
Not much. There are some adv3 library files you can exclude from
compilation if you don't need them, but not many, and arguably the
library could have been arranged to allow more. I don't get the
impression that economizing on compiled game size was a major design
goal of TADS 3! I suppose Mike took the view that this wasn't much
of an issue on modern machines (but I'm just guessing here, and I
don't and shouldn't attempt to speak for him).
>> It's true that the default handling of THROW X AT Y in TADS 3 can
>> be
>> problematic, in terms of allowing useless actions with sometimes
>> dodgy default responses (e.g. "The dagger hits the boss without
>> any
>> obvious effect, and falls to the floor.") which Inform blocks
>> with
>> the laconic "futile",
>
> I've run into this, yes.
>
>> but that, I think, is properly an issue
>> concerning the implementation of certain actions, not the
>> complexity
>> of the world model per se.
>
> I would consider action handling to be an aspect of the world
> model,
> though, alongside the specific objects themselves.
Okay - I'm happy to accept your definition in the interests of
facilitating discussion.
> This is definitely
> an action I'd rather have turned off by default, because making it
> work
> sensibly in a given game almost always requires at least some
> customization: it's very much more likely that I will write a game
> in
> which THROW X AT Y will never be important than that I will write
> one
> in which every object should bounce harmlessly off every other.
I take your point. I'd guess the reason Mike implemented THROW X AT
Y the way he did is that it's non-trivial to implement (the code in
the I7 Kyoto example exemplifies that, and the TADS 3 code is
perhaps more complex in the way it has to decide where a thrown
object falls and whether there are any obstacles between the thrower
and the target). It would be quite difficult for an author to
implement all this and get it right, so it's useful to have it in
the library. On the other hand, the action handling could all be
there and still turned off my default with a suitable placed check()
rule (which could then be overridden where authors positively want
to allow throwing things at targets).
>All it
> takes is one windowpane, letter opener, china vase, vicious
> pitbull,
> etc., and suddenly you've got an immersion-breaking bug. (I've
> never
> liked the default of >JUMP in Inform, either, because it produces
> bugs
> as soon as you have a floorless location;
JUMP similarly requires careful customisation in TADS 3.
Perhaps part of the problem with commands like JUMP and THROW AT is
that, in many circumstances, they are actions that someone *could*
do, and it may be frustrating to players if the parser doesn't
understand them (or, conversely, if it does understand them but
disallows them for what may seem no very good reason). One seems
almost forced to dream up non-default responses that don't jar (in
some particular cases) whatever the default responses are.
> I argued in a somewhat-related post a while back[1] that design of
> actions and action grammar is itself a subtle art: that the game
> should
> (in my opinion) ask from the player exactly as much information as
> the
> world model requires to fully determine the action, but that some
> world
> models will require more information than others, and that
> therefore
> grammars should be adapted accordingly. So for instance >CUT FOO
> might
> be useful in some cases, but in others >CUT FOO WITH BAR might be
> a
> more appropriate syntax;
I seem to recall this discussion, yes.
> the default implementation can actually get in
> the author's way if he wants to do something differently-phrased,
> and
> the generic default implementation usually doesn't add much of
> interest
> to the player's experience except perhaps an acknowledgement that
> the
> game recognizes "CUT" as a verb.
I suppose that depends how easy or difficult it is to modify the
command grammar in the system one's using.
> Even that may be counter-productive,
> in the sense that, if I'm totally on the wrong track with even
> thinking
> about cutting things, and the game is really about conversation
> (or
> whatever), I'd rather have an indication that this is not going to
> be a
> useful verb.
Yes, agreed: it may be good practice in such a case to say something
as blunt as "There's no need to cut anything in this game" (or at
least something that conveys the same information, perhaps phrased
more felicitously) - this may require some work on the part of the
author, but shouldn't be all that difficult in any decent system,
surely?
> In this respect, the I7 standard library doesn't behave exactly in
> the
> way I might now draft something myself, especially if I were doing
> so
> from scratch and with no particular reliance on I6. I might well
> strip
> out such things as locking and unlocking by default and leave
> those to
> extension territory;
Yes, I can see that not every game would have things that are
lockable (and also that not all those that do would handle them in
the same way - here the TADS 3 library makes less assumptions about
how lockable things should behave than the I7 library, in that it
provides more options, though I grant that in other instances TADS 3
makes more assumptions than I7)
> and I might change the handling of completely stub
> actions (I'm thinking of things like >WAVE and >SING and >RUB) so
> that
> one just got a somewhat generic "you don't need that action"
> response
> unless the author had done something to customize the action.
I can see the sense of that.
> In glancing at the TADS 3 library for related issues, I noticed
> that
> there seems to be a kind of half-implementation of fire and
> burning,
> complete with a FireSource class, but that actual burning and
> being-on-fire does not seem to be addressed by the library.
Yes, that's basically right. The TADS 3 library thinks of flammables
almost solely in terms of matches and candles (and analogous
objects), not in terms of the potential for general conflagration.
> The better the game is otherwise, the less this kind of thing [sc
> the non-flammable martyr} is likely
> to distract the player, because the author will have provided a
> host of
> other clues about goals and appropriate interactions. But I'm
> still not
> convinced that it's a net advantage to anyone, and in
> poorly-designed
> works it can become a serious disadvantage.
True - but then how far is it the job of a standard library to guard
against poorly-designed works? I take your point that a richer set
of actions provided by default can provide more traps for the unwary
author, but removing them isn't going to turn a poorly-designed game
into a good one.
> Again, I'd have to fiddle with [my ports of Ruins etc.] to be
> sure, but at a guess I would
> imagine you're probably right. The thing is that a complex
> standard
> implementation becomes more problematic the more the game's
> interaction
> style deviates from that standard. I expect that I would not find
> any
> extra detail provided by being able to SIT, STAND, LOOK BEHIND,
> etc.,
> to be particularly jarring in "William Tell" or "Captain Fate",
> given
> that these are themselves (as I recall) fairly standard
> physical-interaction games, and the added actions are in keeping
> with
> the general behavior required elsewhere.
Okay; but then I think I'd in any case agree with you (and thought I
already had) that a rich standard library like that of TADS 3 is of
less benefit in a game that's going to depart significantly from a
standard physical interaction model (except, perhaps in the case of
TADS 3, it was going to be a conversation-based game that made heavy
use of the TADS 3 conversation model). If I was going to write a
game that made no or only slight use of standard physical
interactions and was otherwise going to work in non-standard ways,
I'd certainly consider using I7 rather than TADS 3.
> For what it's worth, when I said that I'd played some games where
> a
> complex world model was a distraction, I had in mind a couple of
> TADS 3
> games, but also other games in other systems; and for the reasons
> I've
> cited, I'm not sure that my critique on TADS 3 games would
> necessarily
> be conclusive about the point I was originally making, which was
> explicitly not an I7/TADS 3 comparison.
Fair enough; I appreciate that neither of us is (or wants to be)
involved in any kind of TADS 3 vs I7 polemic here. The reason I
chose to focus the discussion on this comparison (as I'm sure you
appreciate) is that the two systems so clearly exemplify the
different approaches we're talking about.
> Still, I'm willing to have a look back at some games I remember
> working
> poorly for me, and see what further examples emerge.
> Unfortunately, I
> do not have more time to spend on this now, but I'll try to get to
> it later.
I certainly didn't mean to put you to any trouble; I simply wondered
if you might have any examples that came to mind.
-- Eric
Emily Short
Eric Eve wrote:
> Actually it can, and hence one can detach a component from its
> possessor. TADS 3 allows you to change the class of an object
> dynamically at run-time, so, for example, if I wanted a component to
> come loose (e.g. the handle comes off the suitcase), I could write:
>
> handle.setSuperclassList([Thing]);
>
> And now the handle behaves like a (loose, portable) Thing, and is no
> longer a Component.
Ah, aha. Interesting. Thanks for the correction: this makes the system
less static than I imagined. In practice, do you find you reset classes
a great deal, sometimes, or only rarely? (Okay, now I sound like a
badly written survey, but I'm curious both about the potential uses of
the language and in the ways this turns out in practical coding.)
> > This is definitely
> > an action I'd rather have turned off by default, because making it
> > work
> > sensibly in a given game almost always requires at least some
> > customization: it's very much more likely that I will write a game
> > in
> > which THROW X AT Y will never be important than that I will write
> > one
> > in which every object should bounce harmlessly off every other.
>
> I take your point. I'd guess the reason Mike implemented THROW X AT
> Y the way he did is that it's non-trivial to implement (the code in
> the I7 Kyoto example exemplifies that, and the TADS 3 code is
> perhaps more complex in the way it has to decide where a thrown
> object falls and whether there are any obstacles between the thrower
> and the target). It would be quite difficult for an author to
> implement all this and get it right, so it's useful to have it in
> the library. On the other hand, the action handling could all be
> there and still turned off my default with a suitable placed check()
> rule (which could then be overridden where authors positively want
> to allow throwing things at targets).
That's a possibility (though again I find myself wondering what would
be wrong with offering this in an extension form, or something along
those lines). But I suppose there is one case where Inform 7 uses
exactly this approach: a GIVE X TO NPC action is coded, then blocked
with a check rule, so that the functionality is there if and only if
the author turns it on.
> Perhaps part of the problem with commands like JUMP and THROW AT is
> that, in many circumstances, they are actions that someone *could*
> do, and it may be frustrating to players if the parser doesn't
> understand them (or, conversely, if it does understand them but
> disallows them for what may seem no very good reason). One seems
> almost forced to dream up non-default responses that don't jar (in
> some particular cases) whatever the default responses are.
> ... it may be good practice in such a case to say something
> as blunt as "There's no need to cut anything in this game" (or at
> least something that conveys the same information, perhaps phrased
> more felicitously) - this may require some work on the part of the
> author, but shouldn't be all that difficult in any decent system,
> surely?
No doubt. All I am arguing is that the task of tidying up a bunch of
little details caused by a complex library may make that library less
convenient than it originally appeared.
> > For what it's worth, when I said that I'd played some games where
> > a
> > complex world model was a distraction, I had in mind a couple of
> > TADS 3
> > games, but also other games in other systems; and for the reasons
> > I've
> > cited, I'm not sure that my critique on TADS 3 games would
> > necessarily
> > be conclusive about the point I was originally making, which was
> > explicitly not an I7/TADS 3 comparison.
>
> Fair enough; I appreciate that neither of us is (or wants to be)
> involved in any kind of TADS 3 vs I7 polemic here. The reason I
> chose to focus the discussion on this comparison (as I'm sure you
> appreciate) is that the two systems so clearly exemplify the
> different approaches we're talking about.
Well, but that's the thing: they exemplify a difference between
simplicity and complexity of world model, but only to an extent; TADS 3
does not even come close to the theoretical extreme sometimes suggested
on the newsgroup, of a highly comprehensive physical world model that
systematically handled fire, liquid, rope, explosives, etc. Similarly,
it doesn't attempt the other thing I've heard suggested a few times,
namely, providing an absolutely massive library of prototype rooms and
objects -- so that one could, for instance, grab a sort of template
restaurant and have it come ready-outfitted with tables, chairs,
plates, cups, silverware, menus, and a staff of servers. So there's
much further that way one could attempt to go, though with how much
success, I don't know. Conversely, as I've pointed out already, one
could strip more out of the I7 library.
Meanwhile, much of the other class complexity, etc., of the TADS 3
library is associated with other functionality that I7 provides in
other ways: it doesn't provide a class to associate with "a message you
print when the player can't go a certain direction", but it does
provide a form of rule-writing, "Instead of going nowhere...", to allow
authors to write instructions about that case.
So, as I said, I think we need to be careful about what conclusions we
draw from the comparison -- but I think that we are agreeing that a
complicated model is a help if the author wants the kind of complexity
it offers, and otherwise a hindrance to the author (and potentially to
the player, depending on how good a clean-up job the author does).
> > Still, I'm willing to have a look back at some games I remember
> > working
> > poorly for me, and see what further examples emerge.
> > Unfortunately, I
> > do not have more time to spend on this now, but I'll try to get to
> > it later.
>
> I certainly didn't mean to put you to any trouble; I simply wondered
> if you might have any examples that came to mind.
The things that come to mind are mostly of the form "well, Game X felt
a bit sluggish" or "Game Y was confusingly hard to play", but it seems
like we'd needs some bits of transcript demonstrating the unhelpful
interaction patterns in order to conclude anything interesting there.
Eric Eve
> Ah, aha. Interesting. Thanks for the correction: this makes the
> system
> less static than I imagined. In practice, do you find you reset
> classes
> a great deal, sometimes, or only rarely? (Okay, now I sound like a
> badly written survey, but I'm curious both about the potential
> uses of
> the language and in the ways this turns out in practical coding.)
To date, this is something I've used only rarely (a couple of times
in my latest TADS 3 effort, which I can't say much about yet).
Unfortunately, there's a bug associated with it in the current
iteration of TADS 3, in that UNDO doesn't undo the effect of
setSuperclassList(), which makes things a bit messy if a player uses
UNDO at just the wrong moment! (I'm just hoping an update to TADS 3
fixing this bug comes out before the deadline for IF Comp
entries...). It has proved useful on the occasions when I have used
it, since although it would be possible to achieve the same effect
in other ways, it would be quite laborious.
BTW, it's also possible to hybridize (if there's such a word) class
inheritance in TADS 3, something you mentioned would be useful in
another connexion in another post. For example, in doing the TADS 3
Ruins port I had to get round the fact that TADS 3 assumes a
TravelPushable (= pushable between rooms) is non-portable, but the
Ruins sodium lamp is poth pushable and portable, so I needed to
reinstate the Thing Take and Drop behaviour, which is basically just
a question of doing this:
dobjFor(Drop) ( action() { inherited Thing; } }
dobjFor(Take) ( action() ( inherited Thing; } }
In other cases it would be more complicated, since you'd need to
cover verify() and/or check() and/or preCond as well, but in
principle you can make an object use class A's behaviour for action
X and class B's for action Y.
> That's a possibility (though again I find myself wondering what
> would
> be wrong with offering this in an extension form, or something
> along
> those lines).
I have some sympathy with that view. As I mentioned before, there
are *some* parts of the TADS 3 library you can exclude if you don't
want them. E.g. if you don't want to include scoring in your game,
you just exclude the file score.t from the build and it all degrades
very nicely (the status line is automatically adjusted to exclude
the score, and the SCORE command then simply tells you that this
game doesn't use scoring). With the wisdom of hindsight (and in view
of our discussion), I think it would have been neat if there were
more parts of the library that could be excluded this way. Maybe in
some future version the TADS 3 library could be reconfigured so that
more parts could be optionally excluded (for the sake of backward
compatibility I think it would now have to be optional exclusion,
not optional inclusion). The basics of the world model would all
have to remain (because they're all pretty much integrated and too
complex to disentangle), but it might be possible to hive off (say)
everything to do with Locks and Keys or with varous types of
LightSource gadgets into separate files so they could be excluded if
not needed, and maybe the same could be done with some of the more
exotic actions.
Still, there's no chance of Mike considering this for the first
official release of TADS 3!
> No doubt. All I am arguing is that the task of tidying up a bunch
> of
> little details caused by a complex library may make that library
> less
> convenient than it originally appeared.
Point taken; though there is obviously a trade off here: it's less
convenient if you don't need what the library implements and have to
suppress it; it's more convenient if you do need it and don't want
to invent it from scratch.
> Well, but that's the thing: they exemplify a difference between
> simplicity and complexity of world model, but only to an extent;
No, but it's probably the most complex standard library of any
system currently in use, so it's an obvious target for comparison.
> TADS 3
> does not even come close to the theoretical extreme sometimes
> suggested
> on the newsgroup, of a highly comprehensive physical world model
> that
> systematically handled fire, liquid, rope, explosives, etc.
I've seen vague suggestions about including at least some of these
things in a subsequent version of TADS 3. Some time back I already
made the point on the TADS 3 list that if they were included it
would be good if they were implemented in a modular way (i.e. in
separate source files that can simply be excluded if not wanted).
And if you're about to say that such additional library features
should be opt-in rather than opt-out I'll agree with you!
> Similarly,
> it doesn't attempt the other thing I've heard suggested a few
> times,
> namely, providing an absolutely massive library of prototype rooms
> and
> objects -- so that one could, for instance, grab a sort of
> template
> restaurant and have it come ready-outfitted with tables, chairs,
> plates, cups, silverware, menus, and a staff of servers.
No, indeed, and that certainly would be several dozen steps too far
(to my mind, a bit too much like writing a novel by assembling a
sequence of pre-written chapters)! But then this doesn't represent
an extreme any real system has reached or is at all likely to reach.
I shan't say that no one is arguing that "more (complexity) is
automatically better", but I'm certainly not!
> So there's
> much further that way one could attempt to go, though with how
> much
> success, I don't know. Conversely, as I've pointed out already,
> one
> could strip more out of the I7 library.
One could, though perhaps not that much (to my mind). Some of the
less useful actions perhaps (SING, JUMP and PRAY spring to mind as
obvious examples), as you've already suggested. Given the minimalism
elsewhere I was a little surprised that device merits being a
standard kind (not that I have any strong objection to it as such).
> Meanwhile, much of the other class complexity, etc., of the TADS 3
> library is associated with other functionality that I7 provides in
> other ways: it doesn't provide a class to associate with "a
> message you
> print when the player can't go a certain direction", but it does
> provide a form of rule-writing, "Instead of going nowhere...", to
> allow
> authors to write instructions about that case.
Yes, that's absolutely right. Well, not quite absolutely since
you're not strictly comparing like with like here, I think. TADS 3
doesn't use a class for the equivalent of "Instead of going
nowhere...", it simply uses the cannotGoThatWay() method on the
current location. You may be thinking of the NoTravelMessage class,
but that's more nearly equivalent to "Instead of going north in the
lounge" when there's no exit north from the lounge (i.e. a message
tied to a specific direction, rather than a general can't go that
way message). But you're absolutely right that a lot of the
differences between the two systems come down to providing similar
functionality in different ways.
> So, as I said, I think we need to be careful about what
conclusions we
> draw from the comparison -- but I think that we are agreeing that
> a
> complicated model is a help if the author wants the kind of
> complexity
> it offers, and otherwise a hindrance to the author (and
> potentially to
> the player, depending on how good a clean-up job the author does).
Yes indeed, we are agreeing about that. My post yesterday was more
about the player's than the author's experience, I wasn't
questioning the potential advantages of a leaner model for the
*author* for certain projects (I7 was ideal for Dreadwine for
example, although I'm sure I could have produced much the same
result in TADS 3 without too much difficulty); indeed, all I was
really trying to ascertain was how you found "the complex model
provided as a default" impacting negatively on your playing
experience.
> The things that come to mind are mostly of the form "well, Game X
> felt
> a bit sluggish" or "Game Y was confusingly hard to play", but it
> seems
> like we'd needs some bits of transcript demonstrating the
> unhelpful
> interaction patterns in order to conclude anything interesting
> there.
Hm. Like:
>eat boss
The boss does not appear to be edible.
>clean boss
You wouldn't know how to clean him.
>throw pebble at boss
You don't need to throw things around in this game.
>cut boss with pebble
You can't cut anything with the pebble.
(Taken not from a real game but from a scratch file I use to test
things out in - like that response to "throw pebble at boss"
generated by my trying to emulate the 'understand ... as a mistake'
idea in TADS 3 (hint - use a StringPreParser). The responses to EAT,
CLEAN, AND CUT are perhaps less that felicitous here (The boss
doesn't *appear* to be edible? I'm sure I know how to clean him, I
just don't fancy it. And okay, maybe the pebble isn't particularly
sharp, but there must be something with more of an edge to it round
here...). So yes, I can see why a game with too much of this kind of
thing might feel less than ideal.
But I feel my brain start to shut down for the night (in fact, I
think it started several paragraphs back), so I'd better stop now.
As you say, I don't think we're actually disagreeing about anything
of substance in any case.
-- Eruc
na...@natecull.org
Emily Short wrote:
> I think there are a couple of places that still use the concept of 24
> hour time mandatorily, one being scheduling of clocktime events and one
> being the "time since scene began is foo minutes" construct; and I
> would be sympathetic to the argument that the scene business, at least,
> might be better expressed in terms. (Some such argument has in fact
> already been advanced.)
>
> But you can handle a lot of your issues as in the following example:
[wonderful Zqlran example snipped]
Right, I figured I could do most of what I wanted with units. The
'advance time rule' is probably the bit that I was missing - it's
something that seems sufficiently low-level that I would normally think
twice before messing with. The other main one being the 'at....'
construct, which you've bypassed using tables. I think I would probably
never use 'at...' in any serious game anyway.
The units feature is very nice.
I still don't like the fact that this example turns all time-based
events into cases of printing text. I know theoretically I can make
custom say phrases to do actual stuff and embed them in the text, but
that just seems icky and wrong - text should only be generated when
necessary, which would mean if the player was nearby to witness an
event, but the event should happen regardless. I guess adding a 'rule'
column to the table would help, but still... ennh. I'd rather, instead
of using a table, have some short syntax for defining a 'when Zqlran
time is...' rule that can completely replace 'at'. (And I'd also like
support for arbitrary syntaxed clauses in rules so that 'firing the
phaser at Zqlran era 81' or 'drinking before 11 am' can be handled
with full benefit of specificity sorting, rather than relegated to
'when', but that's a wider request than just time handling.)
> Yeah. Well, there may still be bits of your request that this doesn't
> adequately handle...? But if the answer is that a) the code above
> pretty much does the kind of thing you want and b) you just didn't
> realize this was possible, maybe I should look into making some such
> thing an example in the docs.
That would be useful, yeah. It would be good at least to show simple
worked examples for 12-hour vs 24-hour time, changing the starting
hour, and handling wraparound after midnight, and Zqlran is small
enough that it would be worth putting in.
Kevin Forchione
>
> Eric Eve wrote:
>> Actually it can, and hence one can detach a component from its
>> possessor. TADS 3 allows you to change the class of an object
>> dynamically at run-time, so, for example, if I wanted a component to
>> come loose (e.g. the handle comes off the suitcase), I could write:
>>
>> handle.setSuperclassList([Thing]);
>>
>> And now the handle behaves like a (loose, portable) Thing, and is no
>> longer a Component.
>
> Ah, aha. Interesting. Thanks for the correction: this makes the system
> less static than I imagined. In practice, do you find you reset classes
> a great deal, sometimes, or only rarely? (Okay, now I sound like a
> badly written survey, but I'm curious both about the potential uses of
> the language and in the ways this turns out in practical coding.)
Manipulating objects in this way is much more complicated that manipulating
simple attributes in Inform, mainly because the interface for behaviors
tends to be encapsulated within the object, rather than a library function.
Changing an object's superclass list effects the genetics of the object.
Changes made to any object are immediately reflected in all objects that
inherit from that object.
Imagine an object as being composed of a deck of cards. The top card
represents the "self" of the object. This card contains the directly-defined
states and behavior of the object, as well as any subsequent state changes
resulting from messages directed toward the object or "self". The
superclasses of the object represent decks of cards in their own right, with
each of those superclasses having a "self" card and being further composed
of superclasses. As confusing as this may sound, each object has a definite
and computable inheritance order. It is therefore programmatically possible
to determine which card in the deck is going to respond to a message sent to
the object.
If you take an object and replace its superclass list it will still retain
any directly defined behaviors and states, as well as any states produced
through messages sent to the object or "self". So successfully changing an
object from a container into a surface needs to provide a behavioral
interface that will accomodate both identities. Likewise, changing a card in
the deck might result in incompatible states for the new sets of behaviors.
So the technique calls for uniformity in the interface.
My own uses have been for non-game projects: parsers and such. I've also
used the technique in conjunction with cloning to create snapshots of object
states during game play that allow you to rollback a single object state.
--Kevin
steve....@gmail.com
> I don't think we're actually disagreeing about anything
> of substance in any case.
I agree. I would like to take the happy opportunity to point out that
the complexity problem should be understood on more than one axis. Let
us not say simply, "TADS 3 [...] currently has around 420 main
classes," and infer/imply a simple notion, that TADS 3 is some Goliath
of IF, with all attendant weaknesses.
However one chooses to describe "world model" or "the typical author's
work," most of adv3 is entirely outside the range. Except for a
relatively few data-management processes on a relatively few intrinsic
classes, it's implemented on the library level. But this implies only
that you can do practically whatever you want within your game --
there's no code that anyone could possibly want to alter that you can't
get to. This does not imply that the regular user needs to know any of
this stuff (e.g., the internal workings of the parser or the
sense-passage mechanism, or even the relevant method calls). It's like
a car, and these parts are "under the hood" -- you're basically doing
fine if you know where the wiper-fluid goes.
In fact there are several layers, not just a surface and an "under the
hood" layer. There's the surface, declarative layer, then customizing
action processes with a handful or two of standard methods and globals,
a few other standard behaviors, like daemons, NPCs, travel and such,
and a host of more advanced features which are conceptually independent
(from the user's perspective), and which one can investigate as needed.
Now one can certainly make the case that the library *looks* like
Goliath at first. (Oh, think how David must have felt before the
fight!) But one very easily gets things running and the size is not
significantly more alarming than the size of any other program on your
computer. (And, hey, David didn't have so much trouble either.)
So I appreciate the novice's trepidation, and any conseqent hostility,
nervous or otherwise -- but in my experience the novice will become
pretty capable and confident rather quickly and easily. So "big scary
library" no longer feels to me like a major concern in serious debate.
(This is not to be dismissive: a couple years past, I was sounding the
same kind of alarm, so I understand and well sympathise with this
perspective; I simply no longer share it.)
Another axis to consider is the more formal-structural setup. This is
primarily where the "opt-in to a bunch of assumptions about a complex
world model" gets answered: TADS 3 considers this a central issue, and
by developing with this continually at the forefront, TADS 3 gets it
right.
On one level, all the standard IF verbs are provided, but not in their
full complexity. Although they do represent the base range of
possibility for the world model, all but the most trivial are designed
to fail gracefully, unless you've opted-in by including in your game a
relevant game-object Class (which carries with it a special behavioral
assumption).
As for that and the rest, there's relatively few basic assumptions,
only about two of which are of any concern to the normal user: there is
a player, in a place. Past that, the user can optionally opt-in to any
other assumption, and the assumptions are layered so you can pick and
choose, and stop opting-in at any time. Also, any assumption can be
modified or replaced as needed.
So, again another layering that solves the problem. If you don't want
sense-passage, you naturally won't be using SenseConnectors; if you
don't want the built-in TADS 3 conversation system, you simply do not
opt-in; you can opt-in to one of the two (or three?) currently
extensions, or you can write your own. I would be glad if no serious
debate considered a fault of TADS 3 that one must opt-in to a bunch of
unwanted behavior.
I apologise if it has seemed to me that honest (albeit misguided)
concerns have seemed to me something more like rhetorically charged
misprisions determined by an agenda. There's not much that anyone can
do for the latter but aggressively debunk, but perhaps we can all work
together to answer the former.
Emily Short
na...@natecull.org wrote:
> I still don't like the fact that this example turns all time-based
> events into cases of printing text. I know theoretically I can make
> custom say phrases to do actual stuff and embed them in the text, but
> that just seems icky and wrong - text should only be generated when
> necessary, which would mean if the player was nearby to witness an
> event, but the event should happen regardless. I guess adding a 'rule'
> column to the table would help, but still... ennh. I'd rather, instead
> of using a table, have some short syntax for defining a 'when Zqlran
> time is...' rule that can completely replace 'at'.
This could well have been implemented with a list of rules tied to
times, sure, if you want to have more complex events going on.
> That would be useful, yeah. It would be good at least to show simple
> worked examples for 12-hour vs 24-hour time, changing the starting
> hour, and handling wraparound after midnight, and Zqlran is small
> enough that it would be worth putting in.
I'll look into it.
Emily Short
Eric Eve wrote:
> > Well, but that's the thing: [TADS 3 and I7] exemplify a difference between
> > simplicity and complexity of world model, but only to an extent;
>
> No, but [TADS 3 is] probably the most complex standard library of any
> system currently in use, so it's an obvious target for comparison.
True -- though the question of world model design, as separate from the
rest of it, could usefully address some of the other non-standard
library packages as well. The OnyxRing Library provides a different set
of options, for instance, than anything we've talked about so far: a
conversation library that can track things like NPC knowledge and
emotive expression such as compliments and insults; stub provisions for
magical spells; etc. (You see me starting to think that it would be fun
and/or revealing to do some kind of systematic comparison of the
library packages out there. In my copious spare time. Well, anyway...)
> > Similarly,
> > it doesn't attempt the other thing I've heard suggested a few
> > times,
> > namely, providing an absolutely massive library of prototype rooms
> > and
> > objects -- so that one could, for instance, grab a sort of
> > template
> > restaurant and have it come ready-outfitted with tables, chairs,
> > plates, cups, silverware, menus, and a staff of servers.
>
> No, indeed, and that certainly would be several dozen steps too far
> (to my mind, a bit too much like writing a novel by assembling a
> sequence of pre-written chapters)! But then this doesn't represent
> an extreme any real system has reached or is at all likely to reach.
> I shan't say that no one is arguing that "more (complexity) is
> automatically better", but I'm certainly not!
Nonetheless I have heard something like this suggested a number of
times; in some cases, coupled with a different approach to world
modeling and parsing that would provide the game with a very large
dictionary (or something like WordNet), so that some level of the
system would be able to interpret "ask bartender for a martini" as a
conceptual subset of "ask bartender for a drink" -- but obviously all
this is pretty far off from the way any existing system works. I share
your skepticism.
> > Meanwhile, much of the other class complexity, etc., of the TADS 3
> > library is associated with other functionality that I7 provides in
> > other ways: it doesn't provide a class to associate with "a
> > message you
> > print when the player can't go a certain direction", but it does
> > provide a form of rule-writing, "Instead of going nowhere...", to
> > allow
> > authors to write instructions about that case.
>
> Yes, that's absolutely right. Well, not quite absolutely since
> you're not strictly comparing like with like here, I think. TADS 3
> doesn't use a class for the equivalent of "Instead of going
> nowhere...", it simply uses the cannotGoThatWay() method on the
> current location. You may be thinking of the NoTravelMessage class,
> but that's more nearly equivalent to "Instead of going north in the
> lounge" when there's no exit north from the lounge (i.e. a message
> tied to a specific direction, rather than a general can't go that
> way message).
Right -- sorry, that was sloppily phrased.
> Hm. Like:
>
> >eat boss
> The boss does not appear to be edible.
>
> >clean boss
> You wouldn't know how to clean him.
>
> >throw pebble at boss
> You don't need to throw things around in this game.
>
> >cut boss with pebble
> You can't cut anything with the pebble.
Something like that, though sometimes more so.
I recalled having some similar issues with version 1 of "Mix Tape", and
I've reproduced some of them in the transcript below. (Apologies to
Brett Witty -- I don't mean this as a general criticism of the game;
this is one of the most polished pieces in which I've run into this
kind of trouble, and I am selecting it to talk about because it
generally *didn't* feel slapdash -- so when I ran into confusing
moments I was less inclined to say "oh, that's just bad authorship" and
more inclined to question the underlying library support.)
Here are a couple of troublesome bits. I'm sticking to the first couple
of scenes to avoid spoiling too much, though I suppose these still
constitute mild spoilers for those who like to avoid any advance
contact with a game.
===
> x peter
He is standing at the cliff edge. Peter stares out across the grey sea,
lost in thought.
> x sea
Far below the cliff, the white foam of the sea rolls and churns all the
way out to the horizon.
> x path
A thin dirt path wends its way through the scrabble of trees, following
the clouds.
> peter, hello
"Er, Pete?"
He rubs a finger across his top lip, and then turns his face towards
you. "Val?"
(You could ask him why you are here.)
> ask him why I am here
You see no him why i am here here.
> ask peter why I am here
You see no peter why i am here here.
> ask peter why you are here
You dread asking. He shattered your heart before and you're not tough
enough to face it again. But you still love him and have trust in
him...
====
Or, along completely different lines:
====
[Peter tells me we need to burn a scrapbook; ending with...]
Peter sighs and says, "Okay. Let's find some kindling. "
> burn scrapbook
What do you want to light it with?
> i
You are carrying a satchel and your scrapbook.
[I decide I can't burn it now; some time elapses, during which Peter
builds a campfire.]
> burn scrapbook
What do you want to light it with?
> campfire
Peter stops you. "No wait... We should do this, you know,
ceremoniously. Tear out a page at a time."
> tear out page
...
====
In both these cases the "what do you want to light it with?"
clarification doesn't help matters, and in fact distracts me as player
from what is really going on -- in the first case, that I need to wait
for the game to get into a ready state, and in the second case, that I
do not need to use the regular BURN command anyway. My sense is that,
the more of such actions come pre-built, the less likely the author is
to customize them himself; but I think this scene would have benefited
from a customized BURN action, one that didn't bother to clarify what
one wanted to use (since there will only ever be one fire source
available) but which did give a better response when it was not yet
time to act.
Then, once I've gotten to Peter's apartment, we have a somewhat stilted
conversation, and then some oddnesses of the space modeling start to
get to me. For instance, this description:
====
> w
Dining area
The dining room is almost spartan, in stark contrast to Peter's
lounge to the south. In fact, if it weren't for the large dining
table taking up most of this room, it'd basically be a short
connecting room to the kitchen to the east. In other words, Peter's
done nothing for this room except put a large table in it. All his
energy goes into his lounge, and not just in a Feng Shui way.
Boys are goofy like that sometimes.
The oven contains an instant lasagna.
Peter is in the lounge, sitting on the velvet beanbag.
> x oven
It's too far away to make out any detail.
> x lasagna
It's too far away to make out any detail.
===
It appears that the oven is being described even though I'm not in the
kitchen, but I'm being reminded of what's in it, even though I can't
actually see that from here; and from this description alone I might
even get the impression that the oven is in the same room with me,
because it doesn't say anything like "Off to the east..." or "Over in
the kitchen..." or whatever.
Now, I assume that it is possible to further customize much of this,
but when I first played the game I spent quite a lot of time puttering
around the apartment trying to do things, not sure what I could do to
advance the plot, and being distracted by stuff that was completely
tangential; and also finding some of the descriptions confusing, and
often being a little unsure about how to imagine the layout of space.
Overall, it seemed to me that, given the point of this particular
story, a little less complexity in the physical model and a little more
content to the conversational one would have been an improvement.
Eric Eve
> True -- though the question of world model design, as separate
> from the
> rest of it, could usefully address some of the other non-standard
> library packages as well. The OnyxRing Library provides a
> different set
> of options, for instance, than anything we've talked about so far:
> a
> conversation library that can track things like NPC knowledge and
> emotive expression such as compliments and insults; stub
> provisions for
> magical spells; etc. (You see me starting to think that it would
> be fun
> and/or revealing to do some kind of systematic comparison of the
> library packages out there. In my copious spare time. Well,
> anyway...)
Yes, we can but dream! Well, if you ever do find yourself with such
a superfluity of spare time, I'm sure your comparison would make
interesting reading! :)
>> No, indeed, and that certainly would be several dozen steps too
>> far
>> (to my mind, a bit too much like writing a novel by assembling a
>> sequence of pre-written chapters)! But then this doesn't
>> represent
>> an extreme any real system has reached or is at all likely to
>> reach.
>> I shan't say that no one is arguing that "more (complexity) is
>> automatically better", but I'm certainly not!
>
> Nonetheless I have heard something like this suggested a number of
> times; in some cases, coupled with a different approach to world
> modeling and parsing that would provide the game with a very large
> dictionary (or something like WordNet), so that some level of the
> system would be able to interpret "ask bartender for a martini" as
> a
> conceptual subset of "ask bartender for a drink" -- but obviously
> all
> this is pretty far off from the way any existing system works. I
> share
> your skepticism.
Yes, I think we're very much in agreement on this kind of point.
>> [I go on about the difference between cannotGoThatWay() and
>> NoTravelMessage]
> Right -- sorry, that was sloppily phrased.
No - I was just being over-pedantic.
> Here are a couple of troublesome bits. I'm sticking to the first
> couple
> of scenes to avoid spoiling too much, though I suppose these still
> constitute mild spoilers for those who like to avoid any advance
> contact with a game.
[snip]
>> peter, hello
> "Er, Pete?"
>
> He rubs a finger across his top lip, and then turns his face
> towards
> you. "Val?"
>
> (You could ask him why you are here.)
>
>> ask him why I am here
> You see no him why i am here here.
>
>> ask peter why I am here
> You see no peter why i am here here.
>
>> ask peter why you are here
> You dread asking. He shattered your heart before and you're not
> tough
> enough to face it again. But you still love him and have trust in
> him...
Yes, I can straightaway envisage the code that gave rise to that
interchange. I'm guessing Brett Witty used a ConvNode at this point.
It will have contained one SpecialTopic coded something like:
++ SpecialTopic 'ask him why you are here' ['ask', 'him', 'peter',
'why', 'you', 'are', 'here']
"You dread asking..."
;
If only this has been:
++ SpecialTopic 'ask him why you are here' ['ask', 'him', 'peter',
'why', 'you', 'i', 'are', 'am', 'here']
"You dread asking..."
;
You wouldn't have had the problem with it that you did. At least,
I'm arguing on analogy with similar cases that my beta-testers
pulled me up on in my TADS 3 games (lucky for me I had good
beta-testers). What happens here, I think (or what happened in my
case) is that the TADS 3 author reads the stuff on how SpecialTopics
are meant to work, and then somehow goes with away with the
impression that this will be obvious to the *player* as well; for
example, in this case, that if the game prompts the player with "
(You could ask him why you are here.)" the player will know s/he has
to stick to the wording displayed "ask him why you are here". Of
course, most players haven't read the documentation on TADS 3
ConvNodes and SpecialTopics (a somewhat novel conversational
interface) and so in practice they'll try the kinds of alternative
phrasings you did with the results you saw.
Actually, it's not the world model you should blame for this - it's
the guy who wrote the Tour Guide. Just look at the example under
SpecialTopic there:
++ SpecialTopic, StopEventList 'ask what she thinks'
['ask', 'her', 'sarah', 'what', 'she', 'thinks']
...
;
When the player types "what do you think" this will fail. Obviously
what the Tour Guide should have said was:
++ SpecialTopic, StopEventList 'ask what she thinks'
['ask', 'her', 'sarah', 'what', 'she', 'thinks', 'do', 'you',
think']
;
Together with an explanation why that's a good idea, so that
unwitting TADS 3 authors won't be led into that kind of mistake.
Someone should tell that Tour Guide author to get a grip! Hopefully
he'll put it right in the next update. In the meantime it's a bit
tough to blame the TADS 3 library for this. I think a fairer account
would be to say that the ConvNode/SpecialTopic mechanism is still so
novel that best practice for using it hasn't become all that obvious
yet.
>> burn scrapbook
> What do you want to light it with?
>
>> campfire
> Peter stops you. "No wait... We should do this, you know,
> ceremoniously. Tear out a page at a time."
>
>> tear out page
> ...
> ====
>
> In both these cases the "what do you want to light it with?"
> clarification doesn't help matters, and in fact distracts me as
> player
> from what is really going on -- in the first case, that I need to
> wait
> for the game to get into a ready state, and in the second case,
> that I
> do not need to use the regular BURN command anyway.
Except that it's the obvious BURN command that leads to the less
obvious TEAR OUT PAGE command, which seems fair enough to me. And
although the library model wasn't helpful here (since the prompt
"What do you want to light it with?" does indeed seem superfluous
with), in fairness to the TADS 3 library, it does provide a pretty
good system for assuming that an appropriate default gets chosen in
this kind of case:
+ campfire: Fixture 'camp fire/campfire' 'campfire'
...
iobjFor(BurnWith)
{
verify() { logicalRank(150, 'fire source'); }
}
;
Then you'd have seen:
>burn scrapbook
(with the campfire)
Peter stops you. "No wait... We should do this, you know,
ceremoniously. Tear out a page at a time."
Which I think would have been fine. But I take it your point is that
the game requires customisation to do this? But then it would
require some sort of customisation if BURN WITH wasn't in the
standard library. Or is you point that its absence from the library
would force the author to think more about its implementation? (I
can see a case could be made along such lines).
> My sense is that,
> the more of such actions come pre-built, the less likely the
> author is
> to customize them himself; but I think this scene would have
> benefited
> from a customized BURN action, one that didn't bother to clarify
> what
> one wanted to use (since there will only ever be one fire source
> available) but which did give a better response when it was not
> yet
> time to act.
And indeed, this is the case you're making! (And I grant you that
since the campfire is the only conceivable fire source here your
suggestion of a custom BURN action would look neater from a player
perspective than the custom BURN WITH action announcing a default
indirect object).
Yes, this is odd. I'm guessing that what's happened here is that the
Dining area and the Kitchen are joined by a DistanceConnector (so,
to that extent, some customization has already taken place, since
TADS 3 doesn't set up any DistanceConnectors by default). The oven
has been defined as a Container, Fixture (or some such) in the
kitchen, and the lasagna placed in the oven. All these objects have
been left (I'm guessing) with the library default sightSize =
medium. The oven is not mentioned in the room description because
it's a Fixture (if it were a separately listed item then the
standard library would have said that it was in the kitchen), but
the lasagna is because it's a portable object, and the standard
libary simply lists it in relation to its immediate container, in
this case the oven.
The result, I have to agree, is hardly felicitous. Either the oven
should have been mentioned in the room description, or it should
have been made to describe itself as being in the Kitchen, or the
DistanceConnector (which is the source of the problem) shouldn't
have been used, or the lasagna should have been given
sightSize=small so it wouldn't even be mentioned from a remote
location. But without that DistanceConnector, you wouldn't have seen
any problem.
> Now, I assume that it is possible to further customize much of
> this,
Absolutely!
> but when I first played the game I spent quite a lot of time
> puttering
> around the apartment trying to do things, not sure what I could do
> to
> advance the plot, and being distracted by stuff that was
> completely
> tangential; and also finding some of the descriptions confusing,
> and
> often being a little unsure about how to imagine the layout of
> space.
> Overall, it seemed to me that, given the point of this particular
> story, a little less complexity in the physical model and a little
> more
> content to the conversational one would have been an improvement.
Fair enough; but maybe if the author hadn't used DistanceConnectors
here, some of this confusion would have been removed (as in the
example above). Is this a library design issue or a game design
issue, or some of each? I guess one could argue it more than one
way. Again, part of what's happening here is the use of a novel
tool/Concept (the DistanceConnector) that's not sufficiently
familiar for there yet to be an established body of advice on how
best to deploy it and what pitfalls to avoid with it. Here, I think,
you could make a good case for saying it shouldn't have been used at
all (it adds complication to the physical model where this really
isn't the point of the game). OTOH I'm guessing that maybe Brett
Witty had a clear idea of the space he was trying to model here, and
given that idea of the flat had a clear notion that the PC and NPC
should be able to see each other from different rooms in this
apartment (hence the DistanceConnectors).
Anyway, my apologies to Brett for trying to reverse engineer his
code and then comment on it from the snippets of your transcript!
But thanks for digging this example out and commenting on it. I'm
not engaging with your comments to be contrary, but simply because
it seemed right that I should engage with them given that you'd gone
to the trouble of writing them!
I think the lesson to be drawn from this example is not that more
complex world models are a bad thing per se, but that they do need
to be handled with care.
That said, are these examples of infelicity really all that much
worse than ones could draw from a poorly-implemented game written
with a minimal library? Perhaps your reply would be that since
Mix-Tape *wasn't* a poorly implemented game overall, this isn't a
fair comparison, and I'd take your point, but I wonder if a case
couldn't be made for suggesting that *any* IF system would contain
potential pratfalls even for reasonably good authors. Goodness, I
even know of one fellow who very nearly entered a game into a
certain recent competition forgetting to make a form of rail
transport train non-portable...
-- Eric
na...@natecull.org
Eric Eve wrote:
> "Emily Short" <ems...@mindspring.com> wrote in message
> news:1153857142....@m73g2000cwd.googlegroups.com...
> > (You could ask him why you are here.)
> >
> >> ask him why I am here
> > You see no him why i am here here.
> Yes, I can straightaway envisage the code that gave rise to that
> interchange. I'm guessing Brett Witty used a ConvNode at this point.
> It will have contained one SpecialTopic coded something like:
>
> ++ SpecialTopic 'ask him why you are here' ['ask', 'him', 'peter',
> 'why', 'you', 'are', 'here']
> "You dread asking..."
> ;
Hmm. This ConvNode thing looks interesting, but kind of a step
backwards in that you have to phrase the entire line exactly.
I can see it being a useful idiom, though, if you can use any of the
words as a shortcut for the whole phrase - sort of like a text menu.
> >> burn scrapbook
> > What do you want to light it with?
> >
> >> campfire
> > Peter stops you. "No wait... We should do this, you know,
> > ceremoniously. Tear out a page at a time."
> >
> >> tear out page
> > ...
This is an interesting example of the effect Zarf was talking about
earlier, where working out the correct precedence order between syntax
error, disambiguation, rejecting a valid but plot-inappropriate
command, processing a normal command, and processing a plot-specific
command becomes complicated.
My instinct (in Inform, at least, with Nevermore) was to write multiple
grammar lines for commands like 'burn': one accepting an argument, and
one without, so as to handle disambiguation manually - mainly because I
couldn't get the Inform noun-guesser to guess usefully, but also I see
that sometimes there are plot reasons why allowing noun-guessing should
be blocked.
It still seems to me that this kind of deeply semantically embedded
parsing is the perfect domain for some form of contraint logic
programming: ambiguous and incomplete input, a partially conflicting
set of interpretations to be explored in parallel, rules specifying
what is apppropriate when...
'... assume the first word is a verb unless it can be construed as an
actor...
'... assuming we know the verb, make sure this verb is allowed by the
wider plot before disambiguating nouns...'
'... if a ConvNode is active, check whether all words in this sentence
can be construed as words in a special phrase...'
'... if we just posed a disambiguation question, check whether all
words in this sentence can be a disambiguation response...'
How to tightly control the order of lookups and inferences while
allowing for arbitrary expansion and overriding seems the tricky bit.
steve....@gmail.com
> > > [S]tandard libraries have an inevitable
> > > influence on the form of everything written in the relevant language.
> >
> > This is not doubt true, but the implications of this are not so clear
> > as one might imagine.
>
> I didn't imagine they were clear[...]
Perhaps, but you nevertheless draw an implication which is quite
unclear to me, anyway.
Now, I have never argued that a simple, streamlined library is a bad
idea: certainly there are some benefits. (Whether this well describes
I7, I shall leave for another time.) I only say that any model is
finally realised after balances and trade-offs at every turn, and
nobody
should take at face value an argument aggressively in favor of one
solution over all others. Such one-sidedness is simply a sign that the
person hasn't considered the entire argument carefully.
So, while I agree that any library or extension risks overly
influencing
the author, I don't see any reason to believe that I7, by simply
failing
to supply this-or-that, avoids the problem of influence better than any
rival system. As I said, the problem of influence and its implications
are not as clear as you seem to believe.
That said, I doubt that you really mean what you've said, that
probatory hypothesis hardens into points of dispute, when your
favorite system is called into question. But I bet if you're in a
reflective mood, you'd never pose the superiority of one model, and
not merely because you know that form of argument is wrong.
> [Although I7] is not in all
> ways a perfect expression of the theory I outlined [of the
> perfect-because-uninfluentual library,] I still consider I7 a *good*
> expression of said theory.
>
> There are some bits to the I7 world model that I might have left out if
> I were designing it myself, from scratch, without I6 compatibility to
> worry about. But there are also many parts of the (reasonably slender)
> I7 language and library that I think of as tools rather than object
> prototypes or convenience classes or anything [that would influence the
> author unduly.]
I'll only note in passing that you're putting a lot of emphasis on this
"theory" without clarifying it beyond saying that people like to use
powerful tools (a fact which actually doesn't sound so worrisome as one
might like to imagine) -- tools which, when disparaging, you call
"prototypes or convenience classes." And I note in passing that while
you
have made some attempt at justifying that I7 is *good* at representing
your
theory, you have not explained why one should believe that it expresses
your theory any better than does TADS 3 for example (that is, why I7 is
"relatively good" at expressing your theory).
What I would like to point out especially, something that might be of
some use if you'd like to clarify or continue thinking on these
points.... This concept of "world model" you're using needs quite some
work. It's a misleading notion in itself, confusing the simulated world
with the programming model designed to produce the simulation. So for
example you complain about "prototypes or convenience classes" without
recognizing that a Class is simply a prototype for an instantiated
programmatic construct -- and I think it's clear from other parts of
your argument that you're complaining about too sophisticated a
simulated world, quite apart from whatever programming model provides
it.
That said, I think you are basing a lot of speculation on bad
experiences with I6 which have no analogue whatsoever in TADS 3. Be
wary of the fact that, in attempting to articulate the strengths of I7
(over and against I6, or in general), that you'll sound like you're
talking about systems which far surpass I6, and which are at least
equally appealing as I7. Unqualified praise of I7, and unqualified
criticism of alternative -- it's just silly and sounds really
one-sided.
> [T]he absence of a standard
> implementation of something can lead to innovation and to multiple
> viable models: conversation. One of the reasons there has been so much
> exploration of how to do conversation in interactive fiction is that
> the built-in support of older languages is minimal. Conversation's a
> difficult topic anyway, but I doubt that we would see the spectrum of
> interesting solutions we have seen if, say, TADS 2 and Inform 6 had
> come with the equivalent of the TADS 3 system.
Well there are now at least three conversation systems availible in
TADS
3. The fact that one is bundled (and exceptionally well programmed)
does
not discourage anyone from exploring other options. It's not like
anyone
thinks that the bundled one is somehow more "official" than the others,
or that it's necessarily superior.
While we're on the subject of future development, I think future
development will be done by programmers, not writers so much. (No
offence to those who consider themselves artists first and perhaps
programmers second; the programmer's efforts are entirely in your
service!) But as far as the capabilities of the systems, this will be
explored by programmers (although guided by writers, of course). Thus I
would expect that a language that is good to program in will be a
language which is likely to break new ground.
> Inform 7's extensibility is of such a kind that layers of extension
> may more reasonably be built than in Inform 6, and possibly more
> reasonably than in other OO systems, though I make no definite
> assertion about this because I have not explored the full possible
> range.
I doubt it, and it's going to get messy at some point either way. I
don't think you can demonstrate that extension-collision is
theoretically less of a problem in rule-based systems, but if you know
of such an argument, do share.
Also, I'm entirely unconvinced that dropping a "before X do Y" rule,
for
example, is any different from finding the part of code that performs
X,
and inserting a call to Y immediately before. Why do you suggest that
an
automatic rule engine makes things so much better? For each type of
rule,
is there not a basically equivalent procedural technique? So, rather
than
magically good commingling I see a loss of control, which means an even
greater chance for arbitrary, unanticipated behavior, which is
basically
what we mean by extension-collision.
> The expressiveness of its relations system is such that the
> rudiments of a custom world model can often be created extremely
> quickly.
Even as one wonders what you might mean by expressiveness, one could
make a more precise and convincing case for TADS 3's suite of keywords
for library customization: modify, replace, inherited, delegated, etc.,
to say nothing of remapping and so on.
> > Your argument in
> > favor of I7's lack of sophistication seems largely in service to a
> > single idea. Or, to put it better, it suggests that you haven't taken a
> > hard look from the opposite perspective.
>
> Hm. Well, okay. Here is my experience and the set of conclusions I've
> drawn from it.
[snip]
Yes, well you go on a lot about simulationism, confusing the complex
infrastructure provided by the TADS 3 library with the custom behavior
of an author's given game world, trying to imply that your failure of
at
doing simulationism has anything to do with TADS 3. Here's a much
better
way to look at it: TADS 3 is not involved in simulationism, but in what
programming constructs can be usefully generalized from the
range of possible needs of the author. It does not provide a
simulation,
but a bunch of general tools for designing a game.
So, ya, you could probably interrogate this a bit more seriously, and
indeed, much less one-sidedly.
na...@natecull.org
> Emily Short wrote:
> > The expressiveness of its relations system is such that the
> > rudiments of a custom world model can often be created extremely
> > quickly.
>
> Even as one wonders what you might mean by expressiveness, one could
> make a more precise and convincing case for TADS 3's suite of keywords
> for library customization: modify, replace, inherited, delegated, etc.,
> to say nothing of remapping and so on.
The more I look at logic programming, the more I'm thinking that
relations really are the core of everything. You can fairly trivially
implement a typed OOP infrastructure out of some basic relations and
inferences. A lot harder to do it the other way around.
The OO approach still hardcodes a lot into the library about the
*order* in which events happen and control flows, and that's the thing
that's often the most contested and subject to rapid change in IF
development.
> > Hm. Well, okay. Here is my experience and the set of conclusions I've
> > drawn from it.
>
> [snip]
>
> Yes, well you go on a lot about simulationism, confusing the complex
> infrastructure provided by the TADS 3 library with the custom behavior
> of an author's given game world, trying to imply that your failure of
> at
> doing simulationism has anything to do with TADS 3.
*blink*
Er, actually, what Emily went on about was her experience (with I6 and
I7) and the set of conclusions she drew from it. *You* implied all that
other stuff.
Steve, you're not on a winning track here, either on facts, logic or
rhetoric. Give it a rest.
JDC
steve....@gmail.com wrote:
> While we're on the subject of future development, I think future
> development will be done by programmers, not writers so much. (No
> offence to those who consider themselves artists first and perhaps
> programmers second; the programmer's efforts are entirely in your
> service!) But as far as the capabilities of the systems, this will be
> explored by programmers (although guided by writers, of course). Thus I
> would expect that a language that is good to program in will be a
> language which is likely to break new ground.
One might argue that the capabilities of systems will be refined and
perfected by programmers, but I think that a lot of innovation will be
spurred by writers (or, perhaps "IF writers", since these are not
necessarily the same). So far this does not necessarily contradict what
you have said, but I think that a language in which it is easier for
naive ideas to be translated into working code will be more beneficial
for this sort of innovation. Certainly a programmer will be able to
find a better way to implement, say, a particular style of conversation
than a non-programmer, but until someone sees a need for this system it
will not be programmed.
So a writer may say "Wouldn't it be cool to achieve the following
effect here?" If the mechanism for this already exists, great; if not,
he must either figure out how to do it himself or enlist someone else
to do it. I think a lot of people involved in IF enjoy the ability to
create an entire work individually, so I suspect that a lot of new
ideas would not be implemented if the person who thought of them
couldn't implement them himself. If the new effect is particularly
useful, others will improve it and it may eventually be incorporated
into an extension or the language itself (and here is where programmers
come to the forefront). But if the idea is never implemented a first
time it may never see the light of day.
-JDC
Eric Eve
news:1153872737.4...@p79g2000cwp.googlegroups.com...
>
> Eric Eve wrote:
>> "Emily Short" <ems...@mindspring.com> wrote in message
>> news:1153857142....@m73g2000cwd.googlegroups.com...
>> Yes, I can straightaway envisage the code that gave rise to that
>> interchange. I'm guessing Brett Witty used a ConvNode at this
>> point.
>> It will have contained one SpecialTopic coded something like:
>>
>> ++ SpecialTopic 'ask him why you are here' ['ask', 'him',
>> 'peter',
>> 'why', 'you', 'are', 'here']
>> "You dread asking..."
>> ;
>
>
> Hmm. This ConvNode thing looks interesting, but kind of a step
> backwards in that you have to phrase the entire line exactly.
>
> I can see it being a useful idiom, though, if you can use any of
> the
> words as a shortcut for the whole phrase - sort of like a text
> menu.
Yes, the player can use any of the words (or combination of words)
listed in the square brackets as a shortcut for the whole phrase,
provided that this uniquely identifies the phrase; if the choices
on offer are 'I hate you' and 'I love you' you can use 'hate' or
'love' but obviously 'you' by itself won't work. In such a case as
this 'i' by itself won't work for a different reason - it would be
taken as an inventory command. But those caveats aside, it does work
as you would wish.
-- Eric
Emily Short
Eric Eve wrote:
> What happens here, I think (or what happened in my
> case) is that the TADS 3 author reads the stuff on how SpecialTopics
> are meant to work, and then somehow goes with away with the
> impression that this will be obvious to the *player* as well; for
> example, in this case, that if the game prompts the player with "
> (You could ask him why you are here.)" the player will know s/he has
> to stick to the wording displayed "ask him why you are here". Of
> course, most players haven't read the documentation on TADS 3
> ConvNodes and SpecialTopics (a somewhat novel conversational
> interface) and so in practice they'll try the kinds of alternative
> phrasings you did with the results you saw.
Actually I have read some of this -- and I'd played some other games
that also use this system -- but it was not immediately obvious to me
that the i/you business would not be taken care of.
All the same, I do see your general point that many of the problems I
pointed out here are likely to become less problematic as the library
comes to be better understood by authors and players: there will be a
better sense for what authors need to do in order to make the system
work for them, and players will be a little more conversant in the
nuances, too.
> And indeed, this is the case you're making!
(Yup.)
> Is this a library design issue or a game design
> issue, or some of each?
...
> That said, are these examples of infelicity really all that much
> worse than ones could draw from a poorly-implemented game written
> with a minimal library? Perhaps your reply would be that since
> Mix-Tape *wasn't* a poorly implemented game overall, this isn't a
> fair comparison,
Yes, that's more or less the line I'd take.
> and I'd take your point, but I wonder if a case
> couldn't be made for suggesting that *any* IF system would contain
> potential pratfalls even for reasonably good authors.
Well, yes. But I think it likely that the number of these potentially
tricky areas does increase at least somewhat with the complexity of the
standard world model (and possibly with the complexity of the library
in general, though we've mostly been trying to distinguish between
these two levels).
In any case, as I said at the outset, I do recognize that the
conveniences may outweigh the problem areas, for certain kinds of work.
Emily Short
steve....@gmail.com wrote:
> Yes, well you go on a lot about simulationism, confusing the complex
> infrastructure provided by the TADS 3 library with the custom behavior
> of an author's given game world, trying to imply that your failure of
> at
> doing simulationism has anything to do with TADS 3.
I really don't recognize this as a summary of my remarks at all, I'm
afraid. I've tried to articulate some of the principles I brought to
(my contributions to) the I7 design process, and the experience that
led to my forming those principles; you have insisted a) that these
principles contain an implicit criticism of TADS 3 but then also that
b) the criticism is ill-thought-out and also partially inapplicable
because, in fact, TADS 3 succeeds in fulfilling several of the
guidelines I articulated.
I do see that some of my earlier posts may have seemed to conflate
library complexity with world-model complexity, but I think my recent
exchange with Eric has cleared that up pretty well. Otherwise, you seem
mostly to be refuting a set of claims about the relation of TADS 3 and
Inform 7 that I have tried strenuously to avoid making in the first
place.
steve....@gmail.com
> [Y]ou seem
> mostly to be refuting a set of claims about the relation of TADS 3 and
> Inform 7 that I have tried strenuously to avoid making in the first
> place.
You'll find that you need not strenuously avoid anything if you get
your ideas right in the first place. Otherwise you'll probably be found
frequently to imply the wrong ideas despite your best efforts at
avoiding the explicit statements.
steve....@gmail.com
> The more I look at logic programming, the more I'm thinking that
> relations really are the core of everything. You can fairly trivially
> implement a typed OOP infrastructure out of some basic relations and
> inferences. A lot harder to do it the other way around.
I think you're saying that it's harder to write a rule-resolution
engine than it is to model an OO infrastructure in, e.g., Prolog. Even
granting this, which seems a sketchy claim -- what does that have to do
with the larger discussion?
> The OO approach still hardcodes a lot into the library about the
> *order* in which events happen and control flows, and that's the thing
> that's often the most contested and subject to rapid change in IF
> development.
So one could say, but this is all very abstract. Could you give an
example where the order of events (i.e., the program flow) is a problem
for the development of the genre? Or could you cite one of those
frequent contests to which you refer?
Note that there's a number of places in TADS 3 where the order of
events is recognized as necessary to customize: the firing of daemons
(or any schedulable event, including the player's turn, the order of
object resolution in the player's command, logical resolution (in
either the tentative or finalized stages). In other words, at least
some of the problems one might imagine can be well handled within a
sifficiently sophisticated OO framework.
> > > Hm. Well, okay. Here is my experience and the set of conclusions I've
> > > drawn from it.
> >
> > [snip]
> >
> > Yes, well you go on a lot about simulationism, confusing the complex
> > infrastructure provided by the TADS 3 library with the custom behavior
> > of an author's given game world, trying to imply that your failure of
> > at
> > doing simulationism has anything to do with TADS 3.
>
> *blink*
>
> Er, actually, what Emily went on about was her experience (with I6 and
> I7) and the set of conclusions she drew from it. *You* implied all that
> other stuff.
I inferred, perhaps, two things:
That when Emily criticizes a particularly large OO library with (what
she takes to be) a complex world model, she's principally criticising
the TADS 3 approach, as she has been since the little manifest she
first exposed in the "72 Transcripts" thread. Apologetical
protestations of the "I'm talking about I6 and my experience only"
variety simply do not ring true. The fact is, there's a lot one could
rightly complain about TADS 3, if one knows what one is talking about.
That a lot of the conceptual basis for this criticism (to the extent
that it has a basis) is in the problems of I6 (doing OO badly), and the
problems of strict simulationism (doing world-modeling badly) -- and of
course do not apply to TADS 3, whatever Emily's implications may be.
Now this is probably needless to say, to anyone who has been following
the discussion with sufficient attention. For her part, Emily seems to
have convinced herself that she never intended anything of the sort,
and she's resolved to "strenuously avoid" making such implications.
Nevertheless, it's probably worth pointing this stuff out, in certain
terms, lest the casual reader get the wrong idea.
Zonk the Troll Questioner
Since you have degraded the level of discourse to the plainly
content-less (and discussion-halting) "If you'd think like me in the
first place, you wouldn't be implying stupid things with your
statements", I felt inspired to re-write Emily's statements in this
thread, and as a bonus, Graham's white paper, in order to make them
pleasing to you.
Emily:
"My experience as author of several IF games and developer of some
complex general-purpose extensions for I6 surely disqualifies me from
making any intelligent statements about the conclusions I drew from
such experience regarding complex built-in libraries. Clearly I am not
honestly discussing that experience and how it informed my
contributions to I7 -- my only goal is to sneakily imply that the TADS
3 approach is fatally flawed. Despite my clear admissions of where my
knowledge of, and thus judgement of, TADS 3 is incomplete, I am
nevertheless waging a war against that development tool. Thank
goodness someone who has never authored a complete work of IF (only a
NPC tech demo), and who has no real experience of the languages (I6,I7)
I worked in and on, is here to set my wrong ideas about my experience
right!"
New improved version of Graham's white paper:
"I apologize. There is only one correct way to implement an IF
development tool, and I did it the wrong way. I should have written
TADS 3. Or TADS 3 - II, the exact clone."
ZtTG
Graham Nelson
> That said, I doubt that you really mean what you've said, that
> probatory hypothesis hardens into points of dispute, when your
> favorite system is called into question.
The word is "probative", but it's not a fruitful discussion to have, so
let's move on.
> While we're on the subject of future development, I think future
> development will be done by programmers, not writers so much.
Personally, I doubt that. The authors of TADS, Hugo and Inform (among
others) are all people who have themselves written substantive works of
IF. It's a domain which has been explored, but is for the most part
unmapped: the only way to get a feeling for what is really there is to
have a go yourself, and to talk to those who have been before. (I've
found that suggestions for new features from people who have actually
written IF are generally shrewder than suggestions from well-meaning
people who haven't.)
> Also, I'm entirely unconvinced that dropping a "before X do Y" rule,
> for
> example, is any different from finding the part of code that performs
> X,
> and inserting a call to Y immediately before.
But what if you're not the author of X? And can't easily, or can't at
all, modify the source code at X? (For instance, if X is some
micro-step inside the standard library of verb routines, or if X turns
up in someone else's extension which you're using.) What if you don't
understand, or have never seen, the source code for X? Or don't know
the implications of inserting such code - if it's safe to do so without
side-effects?
Obviously, with a Turing machine, you can simulate any programming
approach with pretty much any other. But in so doing, you may vastly
complicate your code. Why should you have to take your bit of
expression about Y and glue it into the middle of the X stuff? Why
shouldn't you have the option of writing it where you prefer, and where
it makes most sense to you?
Being able to more or less freely intermix material has turned out to
be rather good for collaboration, too; it's easy to have Chapter 1 -
Fred's Stuff and Chapter 2 - Janet's Stuff in the same work, have both
Fred and Janet add things, and indeed have all of their objects
interacting, without any serious clashes or difficulties in merging
code. We tried some of this sort of thing experimentally before
releasing the I7 beta, and it was actually rather fun - quite like a
multi-author MUD, really. Had it been necessary for Fred's code to work
by "inserting a call to Y" immediately before Janet's X all of the
time, it just wouldn't have worked.
And, as I've said in this thread a few times already, one wants the
freedom, as a writer, to express things in one's own style, with one's
own preferred arrangement.
steve....@gmail.com
Graham Nelson wrote:
> > That said, I doubt that you really mean what you've said, that
> > probatory hypothesis hardens into points of dispute, when your
> > favorite system is called into question.
>
> The word is "probative", but it's not a fruitful discussion to have, so
> let's move on.
Oh piss off.
OED:
probatory
1. = PROBATIVE 1; testing. Now rare.
1625 USSHER Answ. Jesuit 172 Although it be a probatory, and not a
purgatory fire that the Apostle there treateth of. 1662 HIBBERT Body
Div. I. 130 Those tribulations..were onely probatory, to trie his
strength. 1799 Usef. Proj. in Ann. Reg. 411/1 Preparation of the new
probatory Liquor [= testing liquid]. 1874 BUSHNELL Forgiveness & Law
II. 139 In a scheme of probatory discipline. 1970 Internat. Jrnl.
Cancer V. 311/1 Samples of tumours or normal tissue were obtained by
probatory excision.
{dag}2. = PROBATIVE 2; proving. Obs. rare.
1593 G. HARVEY Pierce's Super. Wks. (Grosart) II. 325, I am content to
referre Incredulity, to the visible, and palpable euidence of the Terme
Probatory. 1638 FEATLY Transubst. 179 That [these words] are not
argumentative or probatorie. 1656 Artif. Handsom. 126 His other heap of
arguments are only assertory, not probatory.
3. (See quot.)
1924 P. S. ALLEN in Library Mar. 255 The manuscripts are identified in
the catalogue by the first words of the second leaf, the 'probatory
words'.
d.ki...@btinternet.com
> Oh piss off.
With a wit that sharp, you'll have to be careful to not cut yourself.
Graham Nelson
> > The word is "probative", but it's not a fruitful discussion to have, so
> > let's move on.
>
> Oh piss off.
>
> OED:
> probatory
>
> 1. = PROBATIVE 1; testing. Now rare.
Ah, clearly the word is not "probative" at all, then. No no.
I see that Chambers also agrees with you on this (again saying
probatory is synonymous with probative), though curiously the Oxford
Dictionary of American English doesn't! But it may just be that my
computer's access to the latter is filtering out uncommon but genuine
words.
Expressive stuff, natural language...
na...@natecull.org
steve....@gmail.com wrote:
> na...@natecull.org wrote:
> > The more I look at logic programming, the more I'm thinking that
> > relations really are the core of everything. You can fairly trivially
> > implement a typed OOP infrastructure out of some basic relations and
> > inferences. A lot harder to do it the other way around.
>
> I think you're saying that it's harder to write a rule-resolution
> engine than it is to model an OO infrastructure in, e.g., Prolog. Even
> granting this, which seems a sketchy claim -- what does that have to do
> with the larger discussion?
The point being that relations are indeed an extremely powerful and
expressive construct, as has been claimed by others.
>
> > The OO approach still hardcodes a lot into the library about the
> > *order* in which events happen and control flows, and that's the thing
> > that's often the most contested and subject to rapid change in IF
> > development.
>
> So one could say, but this is all very abstract. Could you give an
> example where the order of events (i.e., the program flow) is a problem
> for the development of the genre? Or could you cite one of those
> frequent contests to which you refer?
This is the core issue with IF development, as I see it. The contests
are between the library author and the game writer, or between the game
writer at one time and at another. This is because every game has
different requirements, and there is such thing as a single 'correct'
set of behaviour which can be designed once and verified. Every game is
essentially a rewrite from first principles, if the writer is taking
the approach that a game should be based around something unique in its
behaviour. The library is never 'done' or 'complete', and never should
be.
Because of this, there's a chicken-and-egg dependence between each
layer of 'library' and 'game' code. Both have to be able to evolve side
by side.
The case of program flow derives from this, and . Since you don't know
for any given game just what component is primary or which
modifications to the baseline IF model the writer may need (special
grammar, special parsing, special world interactions, verbs that are
disallowed in one scene but not another, etc), you can't necessarily
assume that there is always a 'correct' order in which interactions
should happen. The best approach is to provide sensible *default*
orderings, but allow every one to be overridden to achieve the exact
required effect.
Sorry if that's still too 'abstract' for you, but I don't have time
right now to dump masses of actual code on you. Others, and myself,
have already described specific issues with worked code examples in
excruciating detail.
>
> Note that there's a number of places in TADS 3 where the order of
> events is recognized as necessary to customize: the firing of daemons
> (or any schedulable event, including the player's turn, the order of
> object resolution in the player's command, logical resolution (in
> either the tentative or finalized stages). In other words, at least
> some of the problems one might imagine can be well handled within a
> sifficiently sophisticated OO framework.
Yes, daemons definitely require finessing of exact ordering, otherwise
you get off-by-one timing errors. Another case is the listing of
objects within a room description: if the description of one object
refers to another, one has to be listed first. Resolution of exceptions
to standard event processing is a huge area, and one where the flow of
control changes wildly within a single game.
If I >SHOOT BLOFELD, which circumstance takes priority: that I have a
gun, that I have ammunition, that my wrist is bandaged, that I'm not in
the evil lair, that the beautiful henchperson loves me, that Oddjob is
turned towards or away from me, that I have not yet armed the explosive
wristwatch (and thus shooting Blofeld would cancel my mission to
retrieve his code papers)? Any or all of these exceptions conditions
could be the 'most' important depending entirely on the game writer's
tastes and the exact plotting of the game - they can't be predicted by
a library writer or by any standard world model assumption about
physics, and they may change radically between edits of a game as plot
elements get rearranged. So they need a mechanism which is able to
handle rapid modification and rewriting, by multiple authors who do not
necessarily have the time or desire to completely replace each others'
prewritten components with their own code, but just tweak the aspects
they need to modify.
The point being that requiring a 'sufficiently sophisticated framework'
to be able to make such changes is actually an admission of defeat.
First, sophistication is complexity, and complexity is something to be
avoided except where absolutely necessary. Second, the game writer
shouldn't be in the position of needing the library writer's
prearranged understanding and permission to change a feature of the
library that, for this particular purpose, is unwanted - because
practically speaking, the library author will never predict exactly how
the library is going to need to be modified. So the base language
system, as much as possible, needs to facilitate such modification as
much as possible without requiring the permission and knowledge of
either party.
The standard OO design philosophy, from all examples I've seen,
including T3, is not oriented toward this development model. It assumes
that programmers will be creating standardised components which are
known to be correct and can then be reused, *without* major change, in
larger asssemblies. Dynamic OO systems like T3 extend this a bit,
allowing existing components to be modified in small ways (overriding
slots), but changing control flow is hard because you have to replace
an entire method, you can't easily make changes *within* a unit of code
execution flow. Polymorphic dispatch on a single method receiver only
gets you so far. What is needed are fully generic methods that can
refer to objects not directly involved in either 'party' of the message
send - and generalise those sufficiently and you get rules. Keep just
the rules, then, and you can dispense with a lot of now unneeded
framework complexity.
Kevin Forchione
news:1153960668.6...@b28g2000cwb.googlegroups.com...
> The standard OO design philosophy, from all examples I've seen,
> including T3, is not oriented toward this development model. It assumes
> that programmers will be creating standardised components which are
> known to be correct and can then be reused, *without* major change, in
> larger asssemblies. Dynamic OO systems like T3 extend this a bit,
> allowing existing components to be modified in small ways (overriding
> slots), but changing control flow is hard because you have to replace
> an entire method, you can't easily make changes *within* a unit of code
> execution flow. Polymorphic dispatch on a single method receiver only
> gets you so far. What is needed are fully generic methods that can
> refer to objects not directly involved in either 'party' of the message
> send - and generalise those sufficiently and you get rules. Keep just
> the rules, then, and you can dispense with a lot of now unneeded
> framework complexity.
Perhaps. Some years back I discussed with Mike Roberts the idea of breaking
down actions into their most basic atomic units. What's being referred to as
a rule (in I7 for most of these discussions) are in fact very low-level
functions with side-effects that return a boolean. For instance, this is a
typical rule in I7, reformatted for my convenience:
! first reaction after rule :
[ R_25
;
! [1: abide by i6 react_after property]^"; #endif;
scope_reason=REACT_AFTER_REASON;
parser_one=0;
SearchScope(ScopeCeiling(player),player,0);
scope_reason=PARSING_REASON;
if (parser_one~=0)
rtrue;
rfalse; ];
Unlike a prolog "rule" this one is composed of procedural code, and that
code is going to perform about 4 statements before the function even
performs an if-statement to see if it will return true or false. If I'm
reading the file correctly this is the first reaction after rule, meaning
it'll be the first rule of its kind to be examined, so this logic would get
performed every time the reaction after rules get performed.
You see what I'm getting at, don't you? This is just one example, but you'll
find more if you look. Underneath the hood there is a structure and sequence
of operations going on. Arguably I6 is largely an object-based library,
which means that most of the library consists of function calls operating on
object properties (making I7 a natural... excuse the pun... extension). But
my point is that the library (and there is a library here composed of
mechanisms to handle parsing, command execution, daemon execution, scoping
and containment, and basic support for a collection of player commands) has
a structure, that command executin has a sequence. It's roughly the same
sequence that TADS (2 or 3) goes through. There are hooks, of course, and
those hooks make use of rulebooks. We're not, unless I'm completely
mistaken, dealing with a program entirely composed of rulebooks and rules
and subject to the whim a random shuffle like a deck of cards.
BUT *if* it were, now wouldn't that be interesting? Naturally there would be
some order, but if that order weren't rigidly enforced... if it were simply
a matter of moving a rule about within a rulebook to make daemons fire
before command execution, etc., then we'd definitely be looking at a library
that most of us couldn't get our heads around! And why bother with objects
in that case? Perhaps an object would merely be another rulebook? Could be
fun stuff... could take years and years to write (let alone debug).
--Kevin
Adam Thornton
And with only half of that wit, he'd better mind the jagged edges as
well.
Adam
ifnyou
Zonk the Troll Questioner wrote:
<snip>
While I don't want to add fuel to what looks perilously close to
becoming a flame war (in spite of the nigh-saintly patience of some
participants) I am seeing a pattern of communication that looks a lot
like the following:
Person A: "I'm saying X."
Person B: "You're not saying X, you're saying Y."
Person A: "I'm pretty sure I'm saying X."
Person B: "Yeah, you wish you were saying X, but the fact is you're
saying Y, and what's more, it's really stupid to be saying Y because Y
is WRONG."
I guess if we're more interested in the truth of opinions than in who
is guilty of holding them, then since both person A and person B are
happy to disavow the truth of X, we can leave it there. If, however,
the more important thing is to try to run down individual people on
whatever arbitrary basis is available, we can argue ad infinitum about
whether opinion X is being implied by one party or inferred by another,
generating all the sour feelings and hidden resentments one could
possibly wish for.
Someone once said that the battles for academic advancement are only so
vicious because the prizes are so small... I guess a similar phenomenon
is at play in this hobby... which seems a real shame.
Duncan Harvey
> > The word is "probative", but it's not a fruitful discussion to have, so
> > let's move on.
>
> Oh piss off.
Tsk! You and your urinary tracts. <wags finger>
--
Duncan Harvey
Graham Nelson
What's being referred to as
> a rule (in I7 for most of these discussions) are in fact very low-level
> functions with side-effects that return a boolean. For instance, this is a
> typical rule in I7, reformatted for my convenience:
>
> ! first reaction after rule :
> [ R_25
> ;
> ! [1: abide by i6 react_after property]^"; #endif;
> scope_reason=REACT_AFTER_REASON;
> parser_one=0;
> SearchScope(ScopeCeiling(player),player,0);
> scope_reason=PARSING_REASON;
> if (parser_one~=0)
> rtrue;
> rfalse; ];
This is not an entirely typical example: it provides backwards
compatibility with the "react_after" mechanism in I6, which is not used
by I7 at all. It's therefore a rule with no effect in any I7 game I
know of; it's only there in case people try to dump entire I6 objects
into the middle on an I7 work. (When we started I7, it seemed terribly
important to allow this: nowadays it really doesn't.)
> Unlike a prolog "rule" this one is composed of procedural code, and that
> code is going to perform about 4 statements before the function even
> performs an if-statement to see if it will return true or false.
It's certainly true that the content of a rule is procedural code.
Inform leaves it up to the author how much code that is, but the
standard library of verbs (and associated modelling code such as for
passing through barriers) has been pretty well atomised: the idea is
that no rule should do more than one conceptual thing.
> We're not, unless I'm completely
> mistaken, dealing with a program entirely composed of rulebooks and rules
> and subject to the whim a random shuffle like a deck of cards.
Actually, Inform does do this, but at a more granular level. All of the
important things are rulebooks, which can freely be rearranged,
including during play. True, that doesn't apply to the individual lines
in a block of procedural code. But then there's no good way to refer to
such a position in code: one needs a name: and as soon as one applies a
name, well then, one has a separate rule and all is well. So I think
Inform allows people to have lots of rules, or few rules, as they
prefer. The library errs on the "many small rules" side, because it
wants to be maximally flexible, and we generally suggest that
extensions may wish to do the same.
Note that many rules cause other rulebooks to be run through, so it's
not the case that you leave rule-land and enter procedural-coding-land
at any specific point.
Kevin Forchione
news:1153995761....@m73g2000cwd.googlegroups.com...
> It's certainly true that the content of a rule is procedural code.
> Inform leaves it up to the author how much code that is, but the
> standard library of verbs (and associated modelling code such as for
> passing through barriers) has been pretty well atomised: the idea is
> that no rule should do more than one conceptual thing.
Brilliant.
Thanks for clarifying my understanding on the structure and functioning of
the library. Seems I was mistaken in some very important details. The model
sounds a lot cleaner and more flexible than I had imagined.
The closest that I've imagined to "atomising to a single conceptual
function" in the OO model is the desire to reduce the class hierarchy to a
collection of services, each of which performs a single "atom" of
state/behaviors. But when you get right down to it, you then have to ask
yourself that if the object is that granular why bother with an object at
all.
Obviously an object in that sense would be a set of states associated with
set of rules (a rulebook), at which point I'm not even sure what advantage
one gets from associating the rulebook to the object. Or as Inform utilizes,
a set of attributes upon which rules can act. At which point an object
becomes a placeholder, without messaging or inheritance. It could just as
well be an entry in a lookup table (which has been in my thoughts of late).
--Kevin
steve....@gmail.com
Kevin Forchione wrote:
> "Graham Nelson" <gra...@gnelson.demon.co.uk> wrote in message
> news:1153995761....@m73g2000cwd.googlegroups.com...
> > It's certainly true that the content of a rule is procedural code.
> > Inform leaves it up to the author how much code that is, but the
> > standard library of verbs (and associated modelling code such as for
> > passing through barriers) has been pretty well atomised: the idea is
> > that no rule should do more than one conceptual thing.
>
> Brilliant.
Howso? Don't we do this with methods also? Aren't well-formed methods
also single conceptual units?
Graham proposed that rule-based programming avoids the problems of OO,
writing, on the question of inserting modifications vs. adding rules:
> But what if you're not the author of X? And can't easily, or can't at
> all, modify the source code at X? (For instance, if X is some
> micro-step inside the standard library of verb routines, or if X turns
> up in someone else's extension which you're using.)
This sounds like a good advertisement for implementing everything on
the library-level, and a good reminder to break methods into atoms, so
that the user can easily do { newCode; inherited(); } or { inherited();
newCode; } -- whichever suits.
But this does not sound like an argument in favor of rule-oriented
programming, since it's exactly the same problems (hidden processes and
multi-step procedures), and exactly the same solutions (disclose the
process, and break the procedure into atoms), whichever programming
model we choose.
Kevin Forchione
news:1154026016....@p79g2000cwp.googlegroups.com...
>
> Kevin Forchione wrote:
>> "Graham Nelson" <gra...@gnelson.demon.co.uk> wrote in message
>> news:1153995761....@m73g2000cwd.googlegroups.com...
>> > It's certainly true that the content of a rule is procedural code.
>> > Inform leaves it up to the author how much code that is, but the
>> > standard library of verbs (and associated modelling code such as for
>> > passing through barriers) has been pretty well atomised: the idea is
>> > that no rule should do more than one conceptual thing.
>>
>> Brilliant.
>
> Howso? Don't we do this with methods also? Aren't well-formed methods
> also single conceptual units?
Ideally, yes, but it becomes a matter of perspective I suppose, whether you
are comparing a method to a rule or a method to a rulebook. Some methods
often perform a complete conceptual *process* composed of several steps
rather more like a rulebook than a rule, but unlike a rulebook modification
of a step of the process requires overriding the whole method. Just as an
example, let's explore the doActionOnce() method of the TADS 3 Action class:
doActionOnce()
{
/*
* Perform the sequence of operations to execute the action. If
* an ExitSignal is thrown during the sequence, skip to the
* end-of-turn processing.
*/
try
{
local result;
local impReport;
/*
* Before doing any actual execution, check the command for
* remapping. If we end up doing any remapping, the
* remapping routine will simply replace the current command,
* so we the remapping call will terminate the current action
* with 'exit' and thus never return here.
*/
checkRemapping();
/*
* If this is an implicit action, check for danger: we never
* try a command implicitly when the command is obviously
* dangerous.
*/
if (isImplicit)
{
/*
* verify the action for an implicit command, checking
* for actions that aren't allowe implicitly - we never
* try a command implicitly when the command is (or
* should be) obviously dangerous or is simply
* non-obvious
*/
result = verifyAction();
/*
* If the action can be performed, but can't be performed
* implicitly, abort. Note that we only silently ignore
* the action if it is allowed normally but not
* implicitly: if it's not even allowed normally, we'll
* simply fail later with the normal failure message,
* since there's no harm in trying.
*/
if (result != nil
&& result.allowAction
&& !result.allowImplicit)
abortImplicit;
}
/*
* If this is an implicit command, display a message
* indicating that we're performing the command.
*/
impReport = maybeAnnounceImplicit();
/*
* Make one or two passes through verifications and
* preconditions. If any precondition performs an implicit
* command, we must run everything a second time to ensure
* that the implicit command or commands did not invalidate
* any earlier precondition or a verification.
*
* Run verifications before preconditions, because there
* would be no point in applying implicit commands from
* preconditions if the command verifies as illogical in the
* first place.
*/
for (local iter = 1 ; iter <= 2 ; ++iter)
{
/* verify the action */
result = verifyAction();
/*
* if verification doesn't allow the command to proceed,
* show the reason and end the command
*/
if (result != nil && !result.allowAction)
{
/* show the result message */
result.showMessage();
/* mark the command as a failure */
gTranscript.noteFailure();
/*
* if we have an implicit report, mark it as a mere
* attempt, since the action can't be completed
*/
if (impReport != nil)
impReport.noteJustTrying();
/* terminate the command */
exit;
}
/*
* Check preconditions of the action. If we don't invoke
* any implicit commands, we can stop here: nothing in
* the game state will have changed, so there is no need
* to re-verify or re-check preconditions.
*
* Only allow implicit actions on the first pass. Do not
* perform implicit actions on the second pass, because
* if we did so we could get into an infinite loop of
* conflicting preconditions, where each pass would
* reverse the state from the last pass.
*/
if (!checkPreConditions(iter == 1))
break;
}
/*
* Disable sense caching once we start the action phase -
* once we start making changes to game state, it's too much
* work to figure out when to invalidate the cache, so simply
* turn off caching entirely.
*
* Note that the sense cache will already be disabled if we
* executed any implied commands, because the first implied
* command will have disabled the cache as soon as it reached
* its execution phase, and no one will have turned caching
* back on. It does no harm to disable it again here.
*/
libGlobal.disableSenseCache();
/* run the before-action processing */
beforeAction();
/*
* notify the actor's containers that an action is about to
* take place within them
*/
gActor.forEachContainer(callRoomBeforeAction);
/* call beforeAction for each object in the notify list */
notifyBeforeAfter(&beforeAction);
/*
* Invoke the action's execution method. Catch any "exit
* action" exceptions - these indicate that the action is
* finished but that the rest of the command processing is to
* proceed as normal.
*/
try
{
/* notify the actor of what we're about to do */
gActor.actorAction();
/* execute the action */
execAction();
}
catch (ExitActionSignal eaSig)
{
/*
* an exit action signal was thrown - since we've now
* skipped past any remaining action processing, simply
* continue with the rest of the command processing as
* normal
*/
}
/* call afterAction for each object in the notify list */
notifyBeforeAfter(&afterAction);
/* notify the actor's containers of the completed action */
gActor.forEachContainer(callRoomAfterAction);
/* run the after-action processing */
afterAction();
}
catch (ExitSignal exc)
{
/* the execution sequence is finished - simply stop here */
}
}
Now while we can change the behavior of any of the method/function calls
within the doActionOnce() method by overriding or class inheritance, to
actually change the behavior of the method itself we need to override the
entire method. So for my "rules" library extension I override the method to
insert a few calls into the method to access my "rulebook" calls.
This can be a source of collission, of course, if you also need to override
the method to place your own hooks or pieces of code, and if you also need
to include my changes into the code. Now consider this bit of code from the
Tokenizer:
rules_ = static
[
/* skip whitespace */
['whitespace', new RexPattern('<Space>+'), nil, &tokCvtSkip, nil],
/* certain punctuation marks */
['punctuation', new RexPattern('[.,;:?!]'), tokPunct, nil, nil],
/*
* Words - note that we convert everything to lower-case. A
* word must start with an alphabetic character, but can contain
* alphabetics, digits, hyphens, and apostrophes after that.
*/
['word', new RexPattern('<Alpha>(<AlphaNum>|[-\'])*'),
tokWord, &tokCvtLower, nil],
/* strings */
['string single-quote',
new RexPattern('\'(.*)\''), tokString, nil, nil],
['string double-quote',
new RexPattern('"(.*)"'), tokString, nil, nil],
/* integer numbers */
['integer', new RexPattern('[0-9]+'), tokInt, nil, nil]
]
Now in practice you can easily override this property (as the library does
through deriving a new class) and I've done so myself in some of my library
extensions. However, my toksync library extension actually does something
else. It inserts the token rule it needs into the existing rules list, and
it actually performs a semi-intelligent check to determine where in the
rules list to insert the rule so that it becomes effective. Of course
collisions can occur here as well, if the rule being performed before your
rule matches and processes on the string then your rule never gets called.
That's certainly a risk. A bit like having one of your game objects
intercept the action and exit before it reached the object you've intended
to have handle it. However, unlike the method, if you need to change one of
the rules within the rulebook then you can always pinpoint the exact rule to
replace, and if you want to place a rule in relation to another rule you can
do so using the insertRule() method, which allows you to insert a rule
before or after a named rule.
Now wouldn't it be rather handy if we could do this sort of thing with other
functions or methods of the library? Sure, a method might be composed of one
conceptual unit, but in cases like the doActionOnce method above, perhaps
replacing the method with a rule table such as the rules_ of the tokenizer,
and perhaps having a rulebook class as a datatype to handle the intricacies
of rule manipulation would be of practical benefit to complex modelling,
even if that modelling is OO for the most part.
> Graham proposed that rule-based programming avoids the problems of OO,
> writing, on the question of inserting modifications vs. adding rules:
Well... it looks like rule-based programming would have its own set of
problems. Ordering of rules in the rulebook is one; but another problem
would, I suspect, be processing speed. In theory nothing can be faster than
top-down procedural code. But when your processes involve searching through
large rulebooks I would imagine there's a performance issue lurking.
--Kevin
Graham Nelson
> > Graham proposed that rule-based programming avoids the problems of OO,
> > writing, on the question of inserting modifications vs. adding rules:
(The obligatory "that's not what I said, of course" moment coming right
up: I didn't say that rule-based programming "avoids the problems of
OO" - I think it suits IF's needs better, but I wasn't saying that
there. What I actually said was that I didn't think altering the
behaviour of existing rules by writing further rules was functionally
equivalent to altering the definition of those further rules at the
source.)
> Well... it looks like rule-based programming would have its own set of
> problems. Ordering of rules in the rulebook is one; but another problem
> would, I suspect, be processing speed. In theory nothing can be faster than
> top-down procedural code. But when your processes involve searching through
> large rulebooks I would imagine there's a performance issue lurking.
Both of these are issues. Ordering is tricky for two reasons - one
theoretically horrible but actually innocuous, the other theoretically
harmless but actually quite bad. The theoretically difficult case is
when you have two rules, predicated on conditions A and B: to decide
which takes priority, you need to try to decide if A semantically
entails B or vice versa. That's not easy at all. In practice, though, a
relatively crude mechanism which mostly gets it right works fine. The
actual problem occurs because you have rules predicated on A and B
where A and B are so different in context that it's really just a
matter of opinion which should take priority. Suppose A is "doing
something in the presence of an animal" and B is "doing something in an
outdoor room" - which should take priority? It really depends on the
author's own views and on the nature of the game being designed,
probably.
Except for stack usage, performance is not too terrible a problem,
because this is code which is running on a virtual machine where there
is very little overhead for branches - function calls are cheap, so
breaking routine X into little routines X1, X2, X3, ... stored in a
jump table is not as inefficient as might be expected. But the ability
to hack rules at run-time does impose overhead, and one of the jobs
waiting in my big list of things to do is to try to make procedural
rules (which have the ability to meddle) run faster. On the whole,
though, I'm not too worried about performance on these grounds - there
are more serious issues elsewhere; I'm trying to make more efficient
loops get generated, for instance - because Inform games do seem
playable at the moment, and this is only the beginning of its design
lifetime.
The most intensive use of rulebooks is usually during the printing of
complicated messages, too, where the golden rule is: if what you're
doing is printing, it really doesn't matter if it's slow. Because there
are only a thousand words or so on screen at once, if you can make your
decision in under a thousandth of a second, you're doing fine. And in
practice that's an eternity, even for a virtual machine, these days.
But in any case, in most IF settings, if there's a trade-off between
customisability and execution speed, customisability is almost always
the way to go.
Kevin Forchione
> Kevin Forchione wrote:
>> > Graham proposed that rule-based programming avoids the problems of OO,
>> > writing, on the question of inserting modifications vs. adding rules:
>
> (The obligatory "that's not what I said, of course" moment coming right
> up:
Um... I didn't say you said that! I believe Steve did.
--Kevin
Kevin Forchione
> But in any case, in most IF settings, if there's a trade-off between
> customisability and execution speed, customisability is almost always
> the way to go.
That's always been my viewpoint.
--Kevin
steve....@gmail.com
> > > Graham proposed that rule-based programming avoids the problems of OO,
> > > writing, on the question of inserting modifications vs. adding rules:
>
> (The obligatory "that's not what I said, of course"
I don't know that the "of course" means, but I've never tried to
misrepresent any of your positions.
> What I actually said was that I didn't think altering the
> behaviour of existing rules by writing further rules was functionally
> equivalent to altering the definition of those further rules at the
> source.)
If this is what you were on about, you were responding to a different
point than the one I was raising. Nate had suggested that the problem
of layering extensions is somehow alleviated by rule-based systems. I
say, although the automatic ordering cuts out some of the programmer's
legwork (at the expense of procedural oversight), the insertion of
rules into the RO precedence order seems equivalent to inserting code
in the OO program flow.
(And no, I don't think you can get off via the trivial claim that
everything is equivalently a Turing machine; equivalences between
branches are more than the fact that they share a common root.)
James Cunningham
<notl...@hotmail.com> said:
> [snip]
> Emily:
> "My experience as author of several IF games and developer of some
> complex general-purpose extensions for I6 surely disqualifies me from
> making any intelligent statements about the conclusions I drew from
> such experience regarding complex built-in libraries.
> Clearly I am not honestly discussing that experience and how it informed my
> contributions to I7 -- my only goal is to sneakily imply that the TADS
> 3 approach is fatally flawed.
Emily, you *cad*! It is no wonder that Li'l Stevie is able to wipe the
floor with your ilk so easily.
Best,
James
BrettW
the problems you mentioned are implementation issues. That is, my
fault. Some of it is bad coding, some are quirks of TADS 3 I didn't
give enough time to fix.
The "ask why you are here" thing was because I didn't put in the right
vocab for that special event. As Eric correctly guessed, the
definition is
++ SpecialTopic 'ask him why you are here'
['ask', 'peter', 'him', 'why', 'you', 'are', 'you\'re', 'here', 'he',
'brought']
"You dread asking. He shattered your heart before and you\'re..."
;
A more correct one would have a monstrously long list of keywords
given the different monikers you can give to Peter or yourself. That
doesn't even include the markedly different ways you can rephrase
something like "ask why you are here". The SpecialTopic approach is a
hack and probably best reserved for catching odd conversational
responses rather than being front-and-center in the conversation.
The space modelling in the apartment was a nightmare. And it still
didn't work. The sense connectors are (by default) non-restrictive. So
a lot of my code was involved in restricting things enough so that I
had some sense of physical simulation, but not too much. There isn't
an entirely consistent system underlying this in the library. It's a
powerful system, but a hassle. I had similar problems with the
rambling old man. He essentially lives inside a globe that blocks or
attenuates various senses depending on where he is (virtually).
So yes, there are many tools in order to customize this behaviour, it
just takes a lot of work to get it right. To fix the current
implementation of the kitchen would require a reasonable amount of
work adding the correct, dynamic Occluders, distant descriptions and
behaviours and tinker with the various links between objects and
rooms.
> Overall, it seemed to me that, given the point of this particular
> story, a little less complexity in the physical model and a little more
> content to the conversational one would have been an improvement.
Absolutely. I admit I got caught up in the detail.
My feeling is that the physical simulation approach is very hard to
get right in TADS 3. Things that did work in Mix Tape were that if you
knock on the door, Peter responds to the sound and changes state
correspondingly. This involves removing certain objects from his
person (the headphones), moving through the game world appropriately
(actually getting up and moving). Unfortunately, this is all invisible
to the player. I didn't give the project enough time to implement such
things for more visible effects.
I think I could have easily defined Peter throughout the whole game as
a much simpler entity as far as code went: no special topics, no
special behaviours, any actions he performed were actually "by
magic"... But I wanted things to be detailed and realistic. I wanted
conversations a little closer to real dialogue. The trap I fell for is
that you think that detail vs code is linear in TADS 3 when it is
actually exponential (more detail often involves much more code). The
Adv3 library suggest that you use what's available, but to make all
the systems work together, you need to do a lot of work if you do
anything complicated. The systems are smart, but the author needs to
be smarter sometimes. I misjudged my ability (and time-management) in
Mix Tape. It's not *hard* to work with these systems, they're just
complicated and time-consuming. Though when they work, they work
beautifully.
BrettW
BrettW
> then comment on it from the snippets of your transcript!
No problem :) You get a gold star for getting it eerily close to the
reality.
> I think the lesson to be drawn from this example is not that more
> complex world models are a bad thing per se, but that they do need
> to be handled with care.
Definitely. That's what I learnt. I was too cavalier with implementing
details and didn't give an appropriate amount of time to do it.
Cheers,
BrettW
Emily Short
BrettW wrote:
> My feeling is that the physical simulation approach is very hard to
> get right in TADS 3. Things that did work in Mix Tape were that if you
> knock on the door, Peter responds to the sound and changes state
> correspondingly. This involves removing certain objects from his
> person (the headphones), moving through the game world appropriately
> (actually getting up and moving). Unfortunately, this is all invisible
> to the player. I didn't give the project enough time to implement such
> things for more visible effects.
Huh. Neat idea, anyway.
> The systems are smart, but the author needs to
> be smarter sometimes. I misjudged my ability (and time-management) in
> Mix Tape. It's not *hard* to work with these systems, they're just
> complicated and time-consuming. Though when they work, they work
> beautifully.
Makes sense.
Thanks for your feedback -- it's interesting to know how this worked in
practice.
Damien Neil
> My feeling is that the physical simulation approach is very hard to
> get right in TADS 3. Things that did work in Mix Tape were that if you
> knock on the door, Peter responds to the sound and changes state
> correspondingly. This involves removing certain objects from his
> person (the headphones), moving through the game world appropriately
> (actually getting up and moving). Unfortunately, this is all invisible
> to the player.
I suspect that this is one of the main problems facing the TADS3
library's world model: Sophisticated behavior is only useful when the
player is aware of it.
- Damien
Kevin Forchione
news:neild-usenet4-BE9...@news.individual.net...
That is quite likely to be the case with any world model. The only time that
the player is likely to notice sophistication and nuance is in the manner of
the responses to his commands. Object manipulation and travel are less
likely to reveal this than say, conversation exchanges, hence many of our
more articulate authors have concerned themselves of late with conversation
models rather than with issues of physical simulation. However, a more
sophisticated world model will provide a superior context for the object
disambiguation mechanism. With any luck this will translate into a parser
that more often correctly selects game objects, and this may become
noticeable to the player.
--Kevin
Damien Neil
> "Damien Neil" <neild-...@misago.org> wrote in message
> news:neild-usenet4-BE9...@news.individual.net...
> > library's world model: Sophisticated behavior is only useful when the
> > player is aware of it.
>
> That is quite likely to be the case with any world model. The only time that
> the player is likely to notice sophistication and nuance is in the manner of
> the responses to his commands. Object manipulation and travel are less
> likely to reveal this than say, conversation exchanges, hence many of our
> more articulate authors have concerned themselves of late with conversation
> models rather than with issues of physical simulation.
Well, yes, of course. But simpler world models are less likely to
contain complex behaviors that go unnoticed, and custom-crafted,
game-specific models are more likely to be integrated into the behaviors
needed to progress through the game.
> However, a more
> sophisticated world model will provide a superior context for the object
> disambiguation mechanism. With any luck this will translate into a parser
> that more often correctly selects game objects, and this may become
> noticeable to the player.
Seems like a lot of work to improve object disambiguation, which isn't
really one of the burning issues in modern IF.
- Damien
Kevin Forchione
> Seems like a lot of work to improve object disambiguation, which isn't
> really one of the burning issues in modern IF.
Ah yes... those burning issues. Which ones are those?
--Kevin
Adam Thornton
"Why does it hurt when I double-double-rotating-pee?"
Adam
Kevin Forchione
news:eap82s$471$1...@fileserver.fsf.net...
Sounds like a paradigm shift to me...
--Kevin
Adam Thornton
Kevin Forchione <ke...@lysseus.com> wrote:
>"Adam Thornton" <ad...@fsf.net> wrote in message
>news:eap82s$471$1...@fileserver.fsf.net...
>> In article <XnVzg.7941$5K2.5929@fed1read03>,
>> Kevin Forchione <ke...@lysseus.com> wrote:
>>>Ah yes... those burning issues. Which ones are those?
>> "Why does it hurt when I double-double-rotating-pee?"
>Sounds like a paradigm shift to me...
I assure you that Thomas Kuhn would be rotating in his grave were I to
attempt a double-double-rotating-pee atop it.
Adam
steve....@gmail.com
> > I think you're saying that it's harder to write a rule-resolution
> > engine than it is to model an OO infrastructure in, e.g., Prolog. Even
> > granting this, which seems a sketchy claim -- what does that have to do
> > with the larger discussion?
>
> The point being that relations are indeed an extremely powerful and
> expressive construct, as has been claimed by others.
I quite agree, aside from the minor quibble, that I would avoid
hyperbolic language ("extremely") if we're having a serious
conversation. Indeed, I should guess that everyone quite agrees with
your point, so much so that the point seems hardly worth arguing. (One
could just as well argue that OOP is powerful and expressive
("extremely" so, if you wish) -- I can't imagine anyone seriously
disagreeing with this either.)
Perhaps you mean also that rules, and the relations they form, are
"surprisingly" powerful and expressive -- that they do can do things
that one might not expect them capable of, and do things with greater
ease than one might expect; that learners tend to be surprised by how
useful this programming paradigm turns out to be. I would agree with
this as well.
This may mean that a rule-based system will not only be great at
parsing, as expected, but might be better-than-expected at supporting a
object-based world model for instance, for one example of a general
problem of the IF domain which rule-based systems do not immediately
seem ideal for. (The recently-fashionable claim that "IF is not about
objects but relations" is a bit of illogic I will attempt to debunk
shortly, but in a separate post.)
I agree. To recap: every relevant aspect of the library should be
easily customizable towards the unique and unforseeable needs of the
particular game, and this includes execution order of all relevant
elements in the program cycle.
> Sorry if that's still too 'abstract' for you, but I don't have time
> right now to dump masses of actual code on you. Others, and myself,
> have already described specific issues with worked code examples in
> excruciating detail.
It's not too abstract, a very simple point, and one everyone can agree
upon. I think disagreement, and the need for examples for the sake of
clarifying the point, will only come if one wishes to insist either
that 1) execution order is a serious practical problem; 2)
rule-oriented programming is clearly better at flexible execution
order. (To say nothing of the benefits of different programming
paradigms on balance.) These appear to be important and interesting
questions, and you seem to have some examples in mind... could you
refer to one or two (hopefully minus the excruciation)? But I see that
you provide a few new examples below....
> Yes, daemons definitely require finessing of exact ordering, otherwise
> you get off-by-one timing errors. Another case is the listing of
> objects within a room description: if the description of one object
> refers to another, one has to be listed first. Resolution of exceptions
> to standard event processing is a huge area, and one where the flow of
> control changes wildly within a single game.
Yes, any standard library should allow the user to customize this
stuff.
> If I >SHOOT BLOFELD, which circumstance takes priority: that I have a
> gun, that I have ammunition, that my wrist is bandaged, that I'm not in
> the evil lair, that the beautiful henchperson loves me, that Oddjob is
> turned towards or away from me, that I have not yet armed the explosive
> wristwatch (and thus shooting Blofeld would cancel my mission to
> retrieve his code papers)? Any or all of these exceptions conditions
> could be the 'most' important depending entirely on the game writer's
> tastes and the exact plotting of the game - they can't be predicted by
> a library writer or by any standard world model assumption about
> physics, and they may change radically between edits of a game as plot
> elements get rearranged. So they need a mechanism which is able to
> handle rapid modification and rewriting
It may be true that rule-based system is capable of handling these
sort-of Rube-Goldberg cases more cleanly than OO -- I don't have a
strong opinion on that matter, though I'd estimate it's about the same.
But some related points:
1) it's never terribly hard to figure out many workable and several
decent implementations of this sort of thing in a well-designed OO
library, and then argue over which one is most stylistically correct,
as only anal-retentive CS geeks can. :)
2) these elaborate scenarios do not seem to be frequent (where they
appear at all, it's a one-off per game), and so not the sort of thing
to optimize a library for. Sure, you'll want to allow for these highly
complex cases, but if you can optimize the library for the greater
majority of cases, you'll probably prefer to do that. You might argue
in turn that these cases are infrequent because no library so far well
supports them, but I think that the "Rube-Goldbergs everywhere" game is
a very narrow sub-genre indeed.
3) I don't think your argument is most interesting for implementing a
complex-but-isolated case, but a level of complexity which encompasses
several somewhat-related cases, i.e., what we normally call
"simulationism."
> by multiple authors
I'd love to see big collaborative productions, and it's certainly
something to encourage in library design. But don't rules clash as
easily as procedures conflict? (That rule resolution is handled
automatically does not of course imply that the handling will be
correct.)
> The point being that requiring a 'sufficiently sophisticated framework'
> to be able to make such changes is actually an admission of defeat.
> First, sophistication is complexity, and complexity is something to be
> avoided except where absolutely necessary. Second, the game writer
> shouldn't be in the position of needing the library writer's
> prearranged understanding and permission to change a feature of the
> library that, for this particular purpose, is unwanted - because
> practically speaking, the library author will never predict exactly how
> the library is going to need to be modified. So the base language
> system, as much as possible, needs to facilitate such modification as
> much as possible without requiring the permission and knowledge of
> either party.
I basically agree with your first point (about the evil of complexity),
and that's been my main qualm with the TADS 3 design philosophy. But I
would not say that TADS 3 admits defeat, simply because its designer
made a decision I find risky. In fact, TADS 3 wins some substantial
victories, despite and because it take a tack that does not always
appear the safest. I have the same hope for I7, although my confidence
has been a bit shaken where the designer has pretended certain
fundamental and clear objections are nonsense -- Mike, by contrast, has
been known to understand the values of each perspective.
I'm a bit confused by the second point, but only a bit. TADS 3 is very
free with permission, and rarely will you run into an assumption which
is inconvenient to revise and comb out. I certainly agree with your
conclusion, that it's extremely important (and here I would say
"extremely") that the base system facilitate modification. Indeed, this
is one of my main joys in TADS 3, and one of my most severe concerns
with I7.
> The standard OO design philosophy, from all examples I've seen,
> including T3, is not oriented toward this development model. It assumes
> that programmers will be creating standardised components which are
> known to be correct and can then be reused, *without* major change, in
> larger asssemblies. Dynamic OO systems like T3 extend this a bit,
> allowing existing components to be modified in small ways (overriding
> slots), but changing control flow is hard because you have to replace
> an entire method, you can't easily make changes *within* a unit of code
> execution flow. Polymorphic dispatch on a single method receiver only
> gets you so far. What is needed are fully generic methods that can
> refer to objects not directly involved in either 'party' of the message
> send - and generalise those sufficiently and you get rules. Keep just
> the rules, then, and you can dispense with a lot of now unneeded
> framework complexity.
I think I understand what you're driving at. Thanks for the big picture
explanation -- I think it's turned some lights on.
steve....@gmail.com
I recognize that you're making a bit of a joke, but I believe there's a
decisive answer to this rhetorical question: Artificial Intelligence,
particularly better NPC modelling, but also better parsing (as you were
just talking about immediately upthread), and dynamic narrative control
(among probably several other avenues). So, if the future is AI, the
system of the future will be the one which is easiest to program in,
particularly to write search and CSP algorithms from the ground up, and
which is fastest.
There will always be the old way: the dumb objects tell the story, and
narrative disclosure and control is of the lock-and-key variety. That
can be fun of course, and easy enough to write in any modern IF
language, though people will have their favorites for their various
reasons; but if you want the genre to move somewhere, the most
important tool is the relatively low-level programming language itself.
Kevin Forchione
news:1154727896.9...@h48g2000cwc.googlegroups.com...
>
> Kevin Forchione wrote:
>> "Damien Neil" <neild-...@misago.org> wrote in message
>> news:neild-usenet4-FFF...@news.individual.net...
>> > Seems like a lot of work to improve object disambiguation, which isn't
>> > really one of the burning issues in modern IF.
>>
>> Ah yes... those burning issues. Which ones are those?
>
> I recognize that you're making a bit of a joke, but I believe there's a
> decisive answer to this rhetorical question: Artificial Intelligence,
> particularly better NPC modelling, but also better parsing (as you were
> just talking about immediately upthread), and dynamic narrative control
> (among probably several other avenues). So, if the future is AI, the
> system of the future will be the one which is easiest to program in,
> particularly to write search and CSP algorithms from the ground up, and
> which is fastest.
Indeed. I think the next decade of IF is going to be very interesting in
this respect.
> There will always be the old way: the dumb objects tell the story, and
> narrative disclosure and control is of the lock-and-key variety. That
> can be fun of course, and easy enough to write in any modern IF
> language, though people will have their favorites for their various
> reasons; but if you want the genre to move somewhere, the most
> important tool is the relatively low-level programming language itself.
Yeah... I'm in agreement with this. I'm quite sentimental, but I'm also of
the opinion that the programming language is going to be the important piece
here, not the library per se. The more powerful the language and the more
supportive it is to the requirements of the IF problem domain, the more
compact and concise the library is apt to be.
--Kevin
Adam Thornton
<steve....@gmail.com> wrote:
>I agree. To recap: every relevant aspect of the library should be
>easily customizable towards the unique and unforseeable needs of the
>particular game, and this includes execution order of all relevant
>elements in the program cycle.
...
>2) these elaborate scenarios do not seem to be frequent (where they
>appear at all, it's a one-off per game), and so not the sort of thing
>to optimize a library for. Sure, you'll want to allow for these highly
>complex cases, but if you can optimize the library for the greater
>majority of cases, you'll probably prefer to do that. You might argue
>in turn that these cases are infrequent because no library so far well
>supports them, but I think that the "Rube-Goldbergs everywhere" game is
>a very narrow sub-genre indeed.
...which is my basic problem with the state of the TADS3 development
community (at least as exemplified on the T3 list): almost all of the
discussion for the last two years or so has been about really abstruse
edges of the library, to the point where I honestly feel that the only
people who will even *notice* them, whether to be convenienced or
inconvenienced by them, are the people who have *already* been arguing
about it on the list, and are all perfectly capable of writing their own
implementations thereof.
>I'm a bit confused by the second point, but only a bit. TADS 3 is very
>free with permission, and rarely will you run into an assumption which
>is inconvenient to revise and comb out. I certainly agree with your
>conclusion, that it's extremely important (and here I would say
>"extremely") that the base system facilitate modification. Indeed, this
>is one of my main joys in TADS 3, and one of my most severe concerns
>with I7.
In which case, let's *please* document what we have with T3, call it
"good enough" and release. No, I'm not volunteering for the
documentation project--which is what's stopping me, mostly, from doing a
serious game in T3. But honestly, we don't need another item class for
tallow-not-wax-candles-of-diameter-greater-than-an-inch-but-less-than-three
in the library. If an author needs that, he can extend the library
himself. The library is extensible. So let's stop adding little
baroque bits to it, and instead work on explaining how to use what's
there and how you extend it if you need to. I don't know TADS well
enough to write that documentation, or (had I but time) I'd do it.
OK, so I exaggerate about the candle thing.
Adam