[Lelah's Beginner's IF Writing Tool]
Paul F. Snively
Hi, Lelah!
First of all, let me compliment you on the clarity of the exposition of
your idea.
> 1. This is impressionistic only. I obviously did not work out the
> logical or syntactic problems even with the example. I was just
> trying to give a general idea of a way that I could more easily work
> on IF writing. (The popup menu idea is so that when you say something
> is an item, the subclasses then pop up for you to choose between,
> etc.)
If your goal is to simplify the creation of objects and their attributes,
then I think this could be a very useful system.
> 2. I don't expect you to write it. I just want to know if it would
> be possible.
Yes, with some caveats that I'll get to in a moment.
> 3. This is (I think) less graphical than some other suggestions that
> have been suggested on raif. The basic idea is for something that
> would work on top of a language like TADS or Inform, the way Windows
> works over DOS. The point was to help a writer get over the syntax
> hurdle, so they :) could focus on the logical problems.
Well, the only thing that really seems to be addressed here in terms of
"logic" is helping the writer to ensure that, where there are multiple
choices of descriptions of things, they're all filled out. Of course, this
alone is probably quite helpful to an IF writer!
> What does Connie look like? You are Constance Stevens, a young,
> strongly muscled, overworked coffee shop waitress.
It might not be clear to a novice user that the text here should be in the
second person.
> Does Baby Joey ever do anything different? Yes no
> (Yes) How many turns go by before Baby Joey does something different?
> 3
> What does Baby Joey do after 3 turns? Baby Joey waves and throws the
> spork wildly, but it flops over behind the booth next to where he is
> sitting.
One of the questions I would have here is "how do you make objects respond
to more stimuli than just the passage of time?" This is the hard part;
there's no obvious mechanism for actually providing logic that defines the
interactions of various objects in the world.
> Can the player see the box? Yes no
> (no) Does the player have light to see by? Yes [so no visibility
> prompt string needed, which would run along the lines of "What does
> the player need to have in order to see the box?" a torch. Does the
> player have the torch? yes no etc.]
Does the torch burn the box? Or is it that other kind of "torch?" ;-)
> What will Connie see when she finds the box? You look behind the
> booth where baby Joey threw his spork and see an old cardboard box you
> hadn't noticed before.
This points up a logic problem already: this description presumes that Baby
Joey threw his spork already. This happens after three turns. But what if,
by accident, our experienced adventurer sees the initial room description
and immediately says "look behind booth?" Also, shouldn't there be a spork
behind the booth as well? :-)
Ideally, there'd be a spork in the world. Initially it'd be nowhere, after
three turns Joey's "throw spork action" would be taken which would
generate the description *and move the spork object from nowhere to behind
the booth*. That way the object isn't there when it shouldn't be, and is
when it should. But we've now already moved into programming, in some
sense, even for something as trivial as moving an object into a place.
> 1) Does something happen to Connie when the stick of dynamite 1) is
> lit? yes no
> (Yes) You gasp, and lean over for a closer look -- this can't be a
> real stick of dynamite, can it?
> Can Connie take the stick of dynamite? Yes no
> (Yes) What happens when Connie takes the stick of dynamite? As you
> pick up the stick of dynamite, it explodes with a fearsome blast and
> destroys everything in the coffee shop.
> What happens to Connie now? You have died.
> What happens to the game? Game over.
> What options does Connie have now? Restore, restart, undo last move.
The problem I see with this is that there's no a priori reason why the
player's manipulating an object should only affect the object or the
player. For example, perhaps the object in question is a switch, and the
player's manipulating it in some fashion causes a change in some other
object, an object not even necessarily in the same room. Will this tool
literally ask the author about every object in the game? How will it
accomodate objects that the author hasn't written about at all yet?
> [etc etc ad nearly infinitum, basically repeating with pop-ups and yes
> no options the various options and qualities of objects characters and
> actions]
It's the lack of means for specifying anything much beyond multiple
descriptions, coupled with the "ad infinitum" part, that bothers me about
this. I see a huge combinatorial explosion occurring in practice. Having
said that, I do see value in this in assisting the writer precisely in
ensuring that everything that needs describing is described, and the
business about having the tool extract alternatives by number, e.g. 1) lit 2)
unlit, from the author's provided text seems clever.
A concern that I have about the general idea of these kinds of tools,
however, is that they shield the would-be IF author from the (at least
currently) inescapable need to either be a programmer in the sense that we
currently understand that term, or to at least have access to one, to see
their creative vision come to fruition. Having been the programmer dealing
with the writer(s) on more than one professional occassion, I can assure
you firsthand that it's a nerve-wracking experience for all concerned, and
unfortunately, some would-be authors are likely to throw up their hands in
despair if they go from something like the above directly into the gaping
maws of Inform or TADS. :-)
Still, we have to start somewhere, and I imagine the notions of multiple
story branches and time-delayed non-player actions would be a sufficiently
novel beginning to writers coming from non-interactive genres.
Paul Snively
Piouhgd
This is a little bit like the 'Creation by playing' (or 'God Mode') thread a
week or so ago except one is like filling out forms and the other is more
interactive. I'm not saying Lelah's idea isn't good, though. I think that
/something/ is needed to strip a little tedium out of coding up objects and
rooms, which would free up the programmer for more important things (like
smart-alec responses!). The only problem that I have with Lelah's Tool is
sometimes I don't know the answer to a question asked by the program /just
yet/. I do realize, however, that it wouldn't be hard to go back into objects
and 'finish' them using the forms.
I use Inform, so I thought about how something like a 'God Mode' could be
created in Inform. The game could not compile within itself, but the 'creation
game' you play would instead generate 'transcripts' of Inform code[*]. For
instance, you have a 'blank' game, filled with objects that are 'nowhere'.
When you 'dig' a room, it automatically sets the description of that room as
the 'code' from Inform.
*** Start Sample ***
! Bare Room Code
Object Room_1 "Bare Room"
has light;
> description here "It's a nice room."
Set.
> l
Bare Room
! Bare Room Code
Object Room_1 "Bare Room"
with description "It's a nice room.",
has light;
> codename here "Nice_Room"
Set.
> l
! Bare Room Code
Object Nice_Room "Bare Room"
with description "It's a nice room.",
has light;
> name here "Nice Room"
Set.
> l
! Nice Room Code
Object -> Nice_Room "Nice Room"
with description "It's a nice room.",
has light;
> create Toy
Object 'Toy' created.
> l
! Nice Room Code
Object Nice_Room "Nice Room"
with description "It's a nice room.",
has light;
Object -> Toy "Toy"
with name "toy";
> dig north that returns south
You dig a north/south passange.
*** End Sample ***
Once you are done with your game, you could use a 'decompile' verb, which would
turn your transcript on, dump all object's desc based on the object tree, and
close the transcript (including a few 'standard' objects in the tree such as
including the parser, initialize, etc).
How difficult would this be to create in Inform? A set of blank objects, a lot
of routines to handle the variables, a few verbs, standard description routine,
in addition to the already useful (for this type of activity) debugging verbs.
Authors couldn't do any major programming with this, but they /could/ create a
virtual world, decompile it, use it as a launching point for creating their
game. It is not the paint, it is not the canvas, it is merely a different style
of brush.
[*] I suspect this could work with any of the languages, actually
(standardizing 'creation' commands would be a big bonus for people who use
multiple languages, though).
-- Kevin
Erik Max Francis
Piouhgd wrote:
> *** Start Sample ***
...
Is this really useful? It's just the same thing, except with more
typing, and in a linear fashion. What advantage does that give you?
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm:+37.20.07/-121.53.38
\
I put away my nine, fool / 'cause I'm colorblind.
/ Ice Cube
Jeff Hatch
Paul F. Snively wrote:
> If your goal is to simplify the creation of objects and their attributes,
> then I think this could be a very useful system.
[snip]
> A concern that I have about the general idea of these kinds of tools,
> however, is that they shield the would-be IF author from the (at least
> currently) inescapable need to either be a programmer in the sense that we
> currently understand that term, or to at least have access to one, to see
> their creative vision come to fruition. Having been the programmer dealing
> with the writer(s) on more than one professional occassion, I can assure
> you firsthand that it's a nerve-wracking experience for all concerned, and
> unfortunately, some would-be authors are likely to throw up their hands in
> despair if they go from something like the above directly into the gaping
> maws of Inform or TADS. :-)
I think it'd be nice to have an easy authoring tool, but it'd be better to have a
tool that leads naturally into a programming language.
For Inscribe (my new system), I'm hoping to make a tutorial "game," or pay
somebody else to make one. A sample transcript alone can't show you how this
would work, but your imagination can fill in some of the details:
>HELLO INSTRUCTOR
The instructor says: "Hello, and welcome to Lesson 5: Object Creation. Let's
trying adding a simple takeable item to this room. Look at the Edit Window.
There's a button at the top of the screen that says 'New Object.' Click on that
button. Okay, have you done that yet?"
>YES
"Now you can see a question mark in the bottom row of the main directory. If you
want to, you can double-click on that to give your object a name. That doesn't
matter yet. Double-click in the column just to the left of the question mark,
where you see the word 'object.' The main directory will disappear, and you'll
see an empty screen. Have you done that?"
>YES
"You're looking at the definition of your new object. Since you haven't said
what class this object is, the object is completely useless. Before it can be
used for anything, you need to say what kind of object you're creating. To do
this, press the 'New Class' button at the top of the screen. Then double-click
on the question mark, rename the new class 'Takeable', and press Enter. Have you
done that?
>YES
The instructor stops and closes his eyes. A look of intense concentration
furrows his brow. "I sense a new takeable object in the game!" he says. "Well
done! Look at the new rows that have appeared in the chart. In the 'Location'
row, the value in the 'Default Value' column is 'null.' Change that value to
'newObjectRoom,' just as you were taught in the last lesson. Remember not to
type any spaces between the words of 'newObjectRoom', and be sure to capitalize
correctly. Have you done that?"
>YES
"Excellent! Now look around the room!"
>LOOK
Object Creation Room
You are in a small, bare room with the Object Creation Instructor. A red button
is on the wall. Your only exit is to the south, back to the Object Editing Room.
There is an [UNNAMED NEW OBJECT] here.
"By the way, you might want to give that object a better name," the instructor
points out. "So, are you ready to learn to create new rooms?"
>TAKE OBJECT
[I don't know the word "object."]
>TAKE TOY
You take the recently renamed toy.
"You've mastered this lesson," says the instructor. "Do you want to go on?"
>LOOK
Object Creation Room
You are in a small, bare room with the Object Creation Instructor. This room
once held a newly-created object, but it's now empty again. A red button is on
the wall. Your only exit is to the south, back to the Object Editing Room.
"Just say 'Yes' when you're ready to go on, or push the red button to restart
this lesson," says the instructor.
>YES
"Then go to the next room!" he says.
A doorway appears in the north wall.
[Your score has just gone up by five points.]
* * *
Such a tutorial would be more difficult than Leah's tool at first, but could lead
smoothly into "real" programming.
-Rúmil
Paul F. Snively
In article <6nn6m1$8...@newsops.execpc.com>, "David A. Cornelson"
<dcorn...@placet.com> wrote:
>1) Writers write. They type. They like to type. I remember how popular Word
>Perfect 5.1 for DOS was/is (believe it or not). People that make their
>living at the keyboard don't like to take their hands off of the keyboard.
>My point? Typing things, even repeating things, is not a major issue with
>many writers. Only people that write code, especially OO programmers, think
>about reducing repetition. Writers generally don't care about this sort of
>thing.
I don't recall saying anything about the amount of typing involved in
Lelah's hypothetical system; having programmed two adventure games for a
living, I'm well aware of the amount of typing involved even when the
system is heavily object-oriented!
The specific concern that I expressed was that of "combinatorial
explosion," and in Lelah's example, it's coupled with something even worse:
an unbounded universe being created. Now, realistically, I know it's not
unbounded. But there's a definite potential problem with trying to
elucidate all of the possible "forks" (sporks?) in the game in advance of
knowing what all of the objects in the game are.
I was really trying to make two points in one, and failing at both: one
point was that spelling each and every little thing out, as opposed to
constructing classes of objects that share some amount of state and
behavior, might be intractable in a pragmatic sense as opposed to a
theoretical sense. The second point was that since state is involved, the
approach would likely tend to introduce subtle, hard-to-track-down-and-fix
bugs, e.g. what would happen in the given example were a player to "look
behind booth" prior to turn number three.
>2) An interview format could be broken down into common interactive fiction
>objects as we programmers know them. A menu could be created to help the
>writer, such as:
>
>a) Create a Location
>b) Create a Door
>c) Create a Container
>d) Create a Supporter
>e) Create a Weapon
>
>..the list is endless, but this is where Lelah's idea has a tremendous
>amount of merit. These 'interviews' with the writer could be extensible. As
>time goes on, the list of common objects grows to 100's and 1000's with
>varying methods and resulting actions all defined by asking the writer a
>list of key questions.
It's hard to know what to say about this. Of course the interviews could be
extensible. Of course it's possible to ask the writer yes/no and
fill-in-the-blank questions. However, I question whether this technique
could be used to construct methods. Arguments to methods, yes; methods
themselves, probably not. But then, if I understand your thesis correctly,
you're suggesting that given a sufficiently rich framework of objects and
methods, filling in the arguments might be sufficient for many purposes,
and I don't disagree with that.
>3) We're the programmers. Given the simple task of writing up a script for
>one object would be both challenging and rewarding. Then we get a sort of
>compromise. On the one hand, many have said, if you don't want to code, then
>get someone else to do it for you. On the other hand,
>writers/non-programmers have stated that this removes their creative
>ownership.
Have any of our writer friends really said that? If so, I'm curious as to
what makes them feel that way. Specifically, I've always understood that,
as the programmer, my job is precisely to help the writer realize their
script. Granted, sometimes I have had to explain to the writer why it isn't
possible to program exactly what they want, but then the result is a
discussion as to how we can best accomplish their intent given the
constraints of technology. The whole process is to support their creative
vision!
>By creating these scripts, we make a small coding contribution to
>other peoples games without stepping in and writing the actual story, which
>is their domain.
That's exactly one of the reasons that object-oriented programming is
invaluable in IF: it allows an author to put together a new story out of
essentially "prefab" objects that provide some aspect(s) of what the story
requires.
>This idea has a great deal of merit. Don't look at Lelah's idea as a
>concrete example, but as she said, an impression. Imagine a system that a
>true writer interacts with by selecting base objects, actions, events,
>interactions, and add the aspect of programmers creating more and more of
>these base items and you have a viable alternative to programming
>interactive fiction.
I seem to recall saying that the idea has merit. I offered some (hopefully
constructive) criticism, not to discourage Lelah, but quite the contrary:
in the hope that it would prove useful to her in progressing from a rough,
impressionistic idea to a more fully-fleshed and increasingly precise one.
>Hey, isn't Mike Berlyn advertising a new library that gives you the ability
>to have an NPC roam around a game? Isn't this a leap forward in IF?
I don't know. What are the parameters of the wandering? Is it always, and
only, random, or is it possible to provide a set of conditions that cause
the NPC to select one direction over another for any given location? I may
be missing something, but this doesn't sound like much to me. The random
case basically goes like this: install a timer/daemon/whatever your
favorite system uses to execute code at every turn/basic unit of time that
does the following:
with NPC
get list of exits in location
pick list member at random
go through exit
That's all there is to the wandering salesma... er, NPC.
Now, granted, if the above were a method on an NPC object, perhaps called
"wander," then Lelah's system could at some point ask "What do you want to
add?" and she could type "NPC," and the system could ask "Is there anything
you want the NPC to do on every turn?" and Lelah could type "wander."
>This
>sounds an awful lot like a script to me.
Sounds like a method of an object to me, but I suspect that we're now
splitting semantic hairs. Besides, I think you mistakenly believe me
hostile to Lelah's idea merely because I criticized it. As Alan Kay said
when asked why he was so critical of the Macintosh: "Because it's the first
computer worth criticizing." ;-)
>Jarb
Paul
Paul F. Snively
In article <359f9c7...@news.nu-world.com>, l...@nu-world.com (Lelah
Conrad) wrote:
>This was an unspoken assumption in my proposal. I would rather work
>through a list of prompts, all the while focusing on the writing, even
>if it was very tedious, than have to think also about the program
>itself and what it is doing. When I have to think about the program,
>my concentration on the story is then broken.
I think the idea that there's a firm distinction between "program" and
"story" is itself problematic in IF. It would be interesting to know, e.g.
whether Marc Blank, David Lebling, Stu Galley, or any of the other early
Infocom folks made such a distinction. One problem that I've always
encountered in dealing with writers from non-IF genres is convincing them
that it's really not simple, and perhaps not even desirable, for their
story to have a beginning, middle, and end in the sense that there's no
guarantee that the player is going to do what they want when they want
him/her to. An IF title before the player begins playing it bears a
striking resemblance to the scene in "The Truman Show" in which Christof
has everyone and everything go to their initial poses, and we're treated to
a still shot in which businesspeople are frozen mid-stride on the sidewalk,
the clock on the belltower is frozen in time, etc. The world has, in an
important sense, an existence independent of the player. The world exists
to react to the player (and, if you have timers/daemons/whatever, to act
proactively as well). Since the objects define the visible world (that is,
generate text in text-based IF, or cause multimedia things to happen as in
Myst and the like), it's hard to say exactly where the line between "story"
and "program" gets drawn.
>I know that geniuses like Plotkin (and others) can "walk and chew gum"
>at the same time, and are extremely talented because of that ability.
>To use a sports analogy, some people are physically gifted and have
>mastered a sport at the highest levels of peak performance. Others may
>have a disability, and play wheelchair basketball or compete in the
>special olympics. Maybe a simplified writing program would be like a
>wheelchair in a race -- it would change the nature of the
>participation somewhat but it would still allow people to compete, and
>to focus on the fun of the sport itself.
As I said in my initial reply, I already see value in forking descriptions
ensuring that everything that should have a description does. Obviously,
we'd all like for such a tool to do even more, and I don't have any doubts
that it *can* do more. It's just a question of striking the appropriate
balance between addressing the needs of a writer vs. the needs of a
programmer, an age-old and unfortunate conflict that in the early days of
IF was resolved by the (simple?) expedient of having the programmers also
be writers. 1/2 ;-)
>Believe it or not :) I do understand that it is adding interactivity
>to objects that makes IF what it is. And your comment here (and the
>later one about a "combinatorial explosion") highlight what I think
>of as the 3 dimensional nature of objects. I've been contemplating
>poor Baby Joey's spork for a couple of days (it's your fault, Paul!),
>since you wrote your objections even to the problem of moving the
>spork.
Realistically it probably wouldn't be a problem, but it's the sort of
niggling thing that playtesters love (and are paid ) to point out: it's
possible for the world to be in an inconsistent state, where "look behind
booth" before three moves have gone by issues a non-sequitur, in the
literal sense of "out of sequence."
My desire wasn't to nitpick about Baby Joey's spork; on the contrary, my
point was that *even something as trivial as that event* constitutes a game
state change (for example, if the player saves the game on turn one or two
and then restores it and immediately looks behind the booth, the verbiage
about "where Baby Joey threw his spork" shouldn't be there, and neither
should a spork, but a saved game at any point after that should show the
verbiage and the spork, unless the spork has been moved). I don't (yet!)
have any concrete suggestions as to how to allow the writer to specify such
things; I only wanted to point out that the issue exists, and comes up much
earlier even in conceptualizing the process than any of us would like.
>All I can imagine is that somehow perhaps the writer could be
>prompted for, or allowed to specify, an "action dimension" for
>objects, in which the author specifies with what or with whom this
>object could interact, and a resultant game state if it did so. If no
>special action dimension is needed (ie in programming terms, code
>specific to that item) then the program would default to the generic
>types of responses already available in TADS/Inform when that object
>is used. (I know this is too vague.)
Not at all; it's exactly as vague as it needs to be at this stage in the
discussion.
>Lelah
Paul
David A. Cornelson
Paul F. Snively <ch...@mcione.com> wrote in message
chewy-ya02408000...@news.mci2000.com...
I'm not criticizing anyone. I'm trying to elaborate what I think Lelah is
trying to say because I believe I'm someone that understands both sides of
this reoccuring thread better than anyone else. I'm both a writer and a
programmer, but probably feel more comfortable writing fiction, than
interactive fiction, if that makes sense. I know Inform fairly well now, but
I believe my interest has become more focused on helping others learn how to
create IF, than to actually create IF myself. Well, that's not entirely true
because I'm working on several games at the moment, but because they take so
long to write and code, I want to be involved on a daily basis, and this has
become my holy grail, so to speak.
I believe many of your ideas are sound, but the problem that remains is that
the people with the ability to solve this problem staunchly prefer to keep
interactive fiction to themsleves, in the programming world.
Jarb
Paul F. Snively
In article <6npe6j$3...@newsops.execpc.com>, "David A. Cornelson"
<dcorn...@placet.com> wrote:
>I'm not criticizing anyone. I'm trying to elaborate what I think Lelah is
>trying to say because I believe I'm someone that understands both sides of
>this reoccuring thread better than anyone else.
And modest, too! ;-)
With all due respect, computer programming as we know it today has been
around for almost 40 years, and IF in one form or another has been around
for almost 30. During this period of time, very many very smart people have
tried to make computers more accessible to non-programmers, whether for the
purpose of entertainment or other purposes, while others have concentrated
specifically on the goal of allowing the computer to be a more effective
vehicle for storytelling. There aren't any silver bullets here, and it's
not for lack of trying.
>I'm both a writer and a
>programmer, but probably feel more comfortable writing fiction, than
>interactive fiction, if that makes sense.
Perfect sense. It's far easier to be a writer of non-interactive fiction
than of interactive fiction, if for no other reason than that the former
form is very ancient, whereas the latter form is relatively novel (note:
cultural anthropologists, please spare me your cant about how bards would
tailor their tales in response to the audiences' reactions; I'm well aware
and speaking of something quite different. Thank you.)
>I know Inform fairly well now, but
>I believe my interest has become more focused on helping others learn how to
>create IF, than to actually create IF myself. Well, that's not entirely true
>because I'm working on several games at the moment, but because they take so
>long to write and code, I want to be involved on a daily basis, and this has
>become my holy grail, so to speak.
Well, great. The more the merrier.
>I believe many of your ideas are sound, but the problem that remains is that
>the people with the ability to solve this problem staunchly prefer to keep
>interactive fiction to themsleves, in the programming world.
Not true, otherwise this conversation wouldn't be taking place. Many of us
who have studied Computer Science and Artificial Intelligence are motivated
precisely by the desire to make the full expressive power of the computer
available to everyone, not just programmers, and this remains a dream for
us. The problem that we find ourselves faced with is when someone insists
that this or that radically simplified approach would be a good step to
take. It might be in the short term, or if we expect the non-programmer to
settle for some (generally trivial) subset of the expressive power that
programming affords us programmers. But when we programmers point out,
sometimes impatiently because we've tried to explain over and over again,
that we're not really doing creative people any favors by saying "sure, you
can create IF; just put on this nice, comfy straitjacket," the conspiracy
theory is that we programmers want to "keep interactive fiction to
ourselves," when the reality is that some of us are simply taking an
uncompromising stance with respect to expressive power: we're unwilling to
insist that non-programmers accept limitations that we ourselves are
unwilling to accept.
My position is that I want a non-programmer to be able to create a Zork, an
Unnkulian, etc. but as a student of Computer Science, Knowledge
Representation, Cognitive Science, Computational Linguistics, and the like,
and a professional developer of two pieces of interactive fiction, I don't
(yet?) know how to make this possible without either the writer becoming a
programmer or handing the writer a straitjacket that will severely limit
their ability to create the kind of featureful IF that aficionados have
come to expect. And I've been thinking about the problem to one degree or
another for over a decade.
Now, as I've written elsewhere, allowing a non-programmer to create a Zork
or Unnkulian may not be an appropriate goal; maybe a non-programmer will
settle for (a lot) less. This is why I think Lelah's idea is basically
sound and good. But even if it were built, it would rapidly become apparent
that titles built with it couldn't compare to those developed by
programmers, a fact that would, in some people's minds, reinforce the
erroneous belief that "the programmers want to keep IF to themselves." This
observation alone is sufficient disincentive for me personally to put much
energy into simplifying the IF authoring process.
>Jarb
Paul
David A. Cornelson
><dcorn...@placet.com> wrote:
>
>And modest, too! ;-)
Well, I'm not as well-schooled as you are but then again, you're the first
person I recall on the thread that has tried to write a cognitive reason for
the difficulty in creating a non-programming interface for creating IF. I
just meant I've been the only programmer that has taken the side of the
non-programmer. I didn't mean to be boastful.
>
>With all due respect, computer programming as we know it today has been
>around for almost 40 years, and IF in one form or another has been around
>for almost 30. During this period of time, very many very smart people have
>tried to make computers more accessible to non-programmers
I'd argue that these 'experts' as you put it, have not sat down with a group
of writers and tried to build an interface that they would be able to use.
I'm sure these 'experts' have been trying to build HAL or something close to
it. That, to me, is not the answer. I believe that AI will come out of
someone developing a base learning device that needs to be fed information
for years and years before it becomes realtively useful. You're not going to
build it in a day and not on one algorithm.
This is the wrong path for IF. We have already come to the conclusion that
the method of puzzle building is relatively static. It's the implementation
of these 'methods' that can be changed. I'd argue that the writer controls
the implementation and we need to create an interface that will help them do
this without writing code.
>My position is that I want a non-programmer to be able to create a Zork
>Unnkulian, etc.
Again, begin with a simple foundation that works. A foundation that is
immediately and automatically extensible. If you build something that is
easy to use and extensible, then you have begun to create what Lelah and I
have in our minds. If you try to build HAL, right from the start, you will
be overwhelmed and as you said, you just won't even try. But if you try to
build the part of HAL that understands the fundamentals of an IF world, such
as directions, light/darkness, object handling, etc., then you're on a track
that can succeed.
Think like a writer first and a programmer second. That is the most
important piece missing from the current tools.
Jarb
Doeadeer3
>From: "David A. Cornelson" <dcorn...@placet.com>
>Date: Mon, Jul 6, 1998 11:49 EDT
>. I
>just meant I've been the only programmer that has taken the side of the
>non-programmer. I didn't mean to be boastful.
Well, that's not exactly true. I have supported the idea also.
I don't think IF has to remain in the lofty tower of the highly skilled
programmer.
However, as a creative person AND a programmer I can see the difficulties. It
COULD be done. But doing it WELL is the difficult part.
And frankly, it would take a better programmer than I. I could write a front
end that writes objects, even some timing mechanisms, but not a front end that
writes specialized objects and routines.
But that doesn't mean I wouldn't like to see someone else try. Frankly, I
would.
:-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Eric O'Dell
>Think like a writer first and a programmer second. That is the most
>important piece missing from the current tools.
It's thinking that writing and programming are somehow separable in IF
that guarantees this will probably go nowhere. It's like arguing that
color mixing is a distraction from brushwork in oil painting.
The recurring suggestion that elitist programmers are deliberately
withholding a solution to the problem, aside from being a cheap shot
hardly worth the distinction of a response, conveniently sidesteps the
enormous technical barriers that exist and which have been enumerated
more than once. It also conceals what I am increasingly coming to see
is the real problem here, which is that elitist "writers" consider
programming to be inconsequential technical dirty work unworthy of
their serious artistic attention.
All of which raises the question of what sort of art is likely to
emerge from the efforts of "artists" who consider fully half of the
art form under consideration to be a burden to be avoided and scorned
along with its practitioners.
I've been a writer, painter, draughtsman, and programmer for my entire
adult life, and I have never found any of these pursuits to be more or
less artistic than the others. Art isn't in the medium, it's in the
care, devotion, inspiration, and sheer backbreaking effort that goes
into the act creating a thing of awe and beauty (or horror). The goal
of the artist ought not to be to stand in front of his creation and
say, "This was an easy thing to do," but to say, "I have poured into
this the best that I was capable of." Ease of technique is a product
of mastery, and mastery is not easy.
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
Greg Ewing
David A. Cornelson wrote:
>
> Think like a writer first and a programmer second. That is the most
> important piece missing from the current tools.
Perhaps the question to ask is: How exactly *does*
a writer (who isn't also a programmer) think?
Going by Lelah's example, it seems she would like
to make a "first pass" through the game in a fairly
linear fashion, sketching out the main plot line
(the "thinking like a writer" phase), then go back
and fill in all the loose ends left behind (the
"thinking like a programmer" phase).
Would that qualify as "writer first and programmer
second"?
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
David A. Cornelson
Doeadeer3 <doea...@aol.com> wrote in message
199807061805...@ladder03.news.aol.com...
>>From: "David A. Cornelson" <dcorn...@placet.com>
>>Date: Mon, Jul 6, 1998 11:49 EDT
>
>>. I
>>just meant I've been the only programmer that has taken the side of the
>>non-programmer. I didn't mean to be boastful.
>
>Well, that's not exactly true. I have supported the idea also.
Sorry. I stand corrected. There are two of us.
Jarb
Paul F. Snively
<dcorn...@placet.com> wrote:
>Well, I'm not as well-schooled as you are but then again, you're the first
>person I recall on the thread that has tried to write a cognitive reason for
>the difficulty in creating a non-programming interface for creating IF.
I think most programmers have a pretty good intuition as to why it's hard,
but find it extremely difficult, if not impossible, to articulate even to
their own satisfaction, let alone the satisfaction of anyone outside their
immediate community. Let's face it: being a programmer is quite akin to
being a doctor or lawyer in terms of specialized vocabulary.
>I
>just meant I've been the only programmer that has taken the side of the
>non-programmer. I didn't mean to be boastful.
Since your first sentence is patently false, it's more difficult to take
the second one seriously. I'll give you the benefit of the doubt, though.
>I'd argue that these 'experts' as you put it, have not sat down with a group
>of writers and tried to build an interface that they would be able to use.
I didn't say "experts;" I said "very many very smart people." Some of them
haven't even been programmers: Don Norman wrote "The Design of Everyday
Things," and a lot of people I worked with at Apple--for some of whom it
was their job, for some of whom it wasn't--tried to apply these principals
as widely as possible.
But we're talking about programming, so do a search for AgentSheets, or see
if you can still download the freeware version of Prograph from
<http://www.pictorius.com>, or go read, e.g. "Programming by Example," or
do a web search for that phrase. Search for "Programmer's Apprentice," too.
I think Cocoa is still available from Apple.
>I'm sure these 'experts' have been trying to build HAL or something close to
>it.
Some have. Most haven't. Most have tried to create something like Lelah's
effort, only to find that even the most trivial cases, such as making the
right object appear in the right place at the right time, takes a kind of
structured expression that most writers seem to have rather severe
difficulty adapting to.
>That, to me, is not the answer. I believe that AI will come out of
>someone developing a base learning device that needs to be fed information
>for years and years before it becomes realtively useful. You're not going to
>build it in a day and not on one algorithm.
<http://www.cycorp.com>
<http://www.u.arizona.edu/~pollock/>
Not only is no one arguing with you, the current state of the art in AI
research rather strongly agrees with that point of view.
>This is the wrong path for IF. We have already come to the conclusion that
>the method of puzzle building is relatively static.
Who's "we," in this context? I sure as hell haven't come to this conclusion.
>It's the implementation
>of these 'methods' that can be changed. I'd argue that the writer controls
>the implementation and we need to create an interface that will help them do
>this without writing code.
I still don't know what you mean by "writing code." I offered some pointers
above to programming systems that don't need their users to "write code"
(their users end up manipulating graphical objects on the screen instead of
"writing code"). My only claim is that you can't do Zork-style IF without
programming; I'm completely agnostic on what form that "programming"
could/should take. I've also said that if you relax the constraint of the
results being "Zork-style," then all sorts of possibilities open up and
probably even have value, Lelah's proposed tool being a good example, and
certainly more thought through and carefully structured than 99% of the
proposals that have appeared here.
>Again, begin with a simple foundation that works. A foundation that is
>immediately and automatically extensible.
Immediately and automatically by whom?
>If you build something that is
>easy to use and extensible, then you have begun to create what Lelah and I
>have in our minds.
You'll have to be more specific, because Inform or TADS are easy to use and
extensible... for me.
>If you try to build HAL, right from the start, you will
>be overwhelmed and as you said, you just won't even try.
Uh, no. That's not the problem, nor what I said. What I said was that some
of us *have* tried, and produced tools that are either used internally at
one company or another or are available to the general public. We're
painfully aware of the shortcomings of the tools; we've interacted daily
with the writers, artists, musicians, producers, etc. who are using our
tools. They aren't nameless or faceless--most often they work in the next
cubicle and are our friends with whom we socialize outside of work. So
there's personal, as well as professional, incentive for us to reach them
with our tools.
But we generally fail, and because we know these people, we know that it's
not because they are inherently stupid or have a learning disability or any
such nonsense--we know the problem is that our tool doesn't work the way
they do, it imposes too many restrictions, it's not fluid or dynamic
enough, it doesn't know enough to be wise enough for a word to be
sufficient. The tool is not succinct--quite the opposite; *someone* has to
spell out every last little thing in painstaking detail. Our friends and
coworkers don't mind doing that, or at least think they don't; they just
mind doing it in what might as well be Swahili. Unfortunately, one aspect
of what makes programming look like Swahili to most people is that
practically no other human beings (apart from the physicists) are
accustomed to working at such an excruciatingly low level of abstraction.
We computer scientists keep raising the level of abstraction, yes, but
building a piece of software is *still* like building the Golden Gate
Bridge, one atom at a time.
>But if you try to
>build the part of HAL that understands the fundamentals of an IF world, such
>as directions, light/darkness, object handling, etc., then you're on a track
>that can succeed.
*sigh* Thanks, kemo-sabe. As if I've never done exactly that before.
Unfortunately, this shows both ignorance of what I have and have not done,
and an incredible level of naivete' about what's "fundamental."
>Think like a writer first and a programmer second. That is the most
>important piece missing from the current tools.
Unfortunately, what *typically* happens with this approach is that a
variety of things that *aren't technically feasible* somehow become
requirements. I'll continue to think in terms of what's currently
technically possible and then think about how to construct a usable
interface to that for the sake of non-programmers, I think. Besides, I've
had good exchanges with Lelah, who is a self-admitted non-programmer, so I
think I'll continue to let those who identify as "writers" think like
writers and I'll continue to think like a programmer, since I know I'm good
at that. ;-)
>Jarb
Paul
okbl...@usa.net
ch...@mcione.com (Paul F. Snively) wrote:
>
> With all due respect, computer programming as we know it today has been
> around for almost 40 years, and IF in one form or another has been around
> for almost 30.
30? "Collossal Cave" is closer to 25, ain't it? The 350 pt. version is ca.
1976, I thought.
> Now, as I've written elsewhere, allowing a non-programmer to create a Zork
> or Unnkulian may not be an appropriate goal; maybe a non-programmer will
> settle for (a lot) less. This is why I think Lelah's idea is basically
> sound and good. But even if it were built, it would rapidly become apparent
> that titles built with it couldn't compare to those developed by
> programmers, a fact that would, in some people's minds, reinforce the
> erroneous belief that "the programmers want to keep IF to themselves." This
> observation alone is sufficient disincentive for me personally to put much
> energy into simplifying the IF authoring process.
Wouldn't most of us here prefer *more* power rather than greater simplicity?
Maybe not. I could stand a little more of both but if someone came up with a
workable NPC system, I'd tolerate a lot of awful things to work with it.
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Andrew Plotkin
> The recurring suggestion that elitist programmers are deliberately
> withholding a solution to the problem,
I don't really think that that's been suggested. It's easy to condense
and exaggerate the real frustration that comes out here from
non-programmers and beginning programmers.
> [...]
> It also conceals what I am increasingly coming to see
> is the real problem here, which is that elitist "writers" consider
> programming to be inconsequential technical dirty work unworthy of
> their serious artistic attention.
Erm, maybe. Not in those terms, though. Yeah, we're all arrogant
elitist snots, but we agree to pretend otherwise. :)
People don't understand fields they're not in. They partially understand
fields that they're novices in. And so on.
Understanding comes with practice. And I don't just mean that the more you
program, the more programming problems you can solve. I also mean that the
more you program, the more you understand what kind of problems are hard,
or easy, and what kind of problems you can solve.
On a slightly different note: I have a horrible feeling that Lelah first
needs a Beginner's Inform Front-End Front-End, which turns her sample
transcript into a tool that can take said transcript and turn *that* into
a text game...
The fact that it's not that easy, is pretty much my point here.
Abstractly speaking.
Concretely speaking, when I consider this problem (and Lelah's
transcript), I think: If I tried to do that, I would wind up with a tool
that did more harm than good. It would not let people write good games,
and it would distract them from learning to write games for however long
it was until they gave up and threw the tool across the room.
Footnote: I do not think nobody should try this.
Second footnote: Yes, I think this is a general problem of Microsoft's
"wizard" approach. One in a long line of ways MS has made computers alien
to most people.
Third footnote: If you wish to argue about the second footnote, please
put "off-topic" in the subject line.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
The Tripods
wrote:
Have you read "About Face: The Essentials of User Interface Design" by
Alan (Father of VB) Cooper? If so, did anything he said seem relevant
to your work with inform?
>Third footnote: If you wish to argue about the second footnote, please
>put "off-topic" in the subject line.
Hm.
>--Z
C'ya,
RudeJohn
"I'm rude. It's a job."
Francis Irving
wrote:
>>Second footnote: Yes, I think this is a general problem of Microsoft's
>>"wizard" approach. One in a long line of ways MS has made computers alien
>>to most people.
>
>Have you read "About Face: The Essentials of User Interface Design" by
>Alan (Father of VB) Cooper? If so, did anything he said seem relevant
>to your work with inform?
I've read it, and it is an excellent book. However, I don't think
that it helps here.
He really kills particular paradigms - Save As (programs should
instead save as you type, and have a "mark important version" type
version control system built in), and winging error dialogs for
example.
This would be useful for designing a GUI for Inform, and lots of the
points Cooper makes do indicate that wizards are horrible, but this
doesn't really suggest a practical alternative.
The book does make you think harder about user interfaces. Do you
have any particular insights in mind with respect to IF?
Francis.
Home: fra...@pobox.co.uk Web: www.meta.demon.co.uk
David A. Cornelson
>On Mon, 6 Jul 1998 10:49:29 -0500, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
>>Think like a writer first and a programmer second. That is the most
>>important piece missing from the current tools.
>
>that guarantees this will probably go nowhere. It's like arguing that
>color mixing is a distraction from brushwork in oil painting.
>
>hardly worth the distinction of a response, conveniently sidesteps the
>enormous technical barriers that exist and which have been enumerated
>is the real problem here, which is that elitist "writers" consider
>programming to be inconsequential technical dirty work unworthy of
>their serious artistic attention.
No, no, no. There is no conspiracy. Jeez.
Sigh. I am not explaining myself very well so this is my fault. Let's try
again. Programming is inherently a method of breaking all subject matter
down to it's logical components, whether it be relational or
object-oriented. My point has always been that if you try to build an
interface or langauge for writers that starts out with this premise you will
just build another Inform or TADS. However, if you start the building and
design process from a language perspective, you might just come out with
something altogether different.
An example, and I'll be the first to admit I cannot figure out a way to do
this either.
I broke down the Inform language into a relational diagram, in fact I
created a database that could store all of the information down to code
level. I need to work on the model some more, but I believe I can break down
the language even further to a relational model.
The problem is, the grammar library and structure. I have yet to figure out
a way to translate the grammar library into a relational model. I think this
is the problem with all of our IF tools. This is the lone exception where
even an object-oriented design was unreachable where our sentence structure
is concerned.
We talk and write beyond the simple structure of a relational or oo design.
But there is a logic to it. The problem is that we haven't been able to
break this logic down far enough.
I'm sure there's a white paper out there somewhere that has mathematically
defined our language to some degree, but I believe that's what we need to
begin understanding how to create an interface that is based on OUR
language, not on the computers.
I don't believe that AI is the answer. That is a different problem. We're in
the business or art of language translation, not artifical intelligence.
When we get to a point where we can build a language parser that understands
more complex sentences, then we're moving closer to my goal, which is true
interaction with a computer.
I think this is a little clearer, but probably not.
Jarb
Brandon Van Every
Eric O'Dell wrote in message <35a19e95.109830125@news>...
>On Mon, 6 Jul 1998 10:49:29 -0500, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
>>Think like a writer first and a programmer second. That is the most
>>important piece missing from the current tools.
>
>It's thinking that writing and programming are somehow separable in IF
>that guarantees this will probably go nowhere. It's like arguing that
>color mixing is a distraction from brushwork in oil painting.
Well, in some sense it is, and some people do sketches first because of it.
>All of which raises the question of what sort of art is likely to
>emerge from the efforts of "artists" who consider fully half of the
>art form under consideration to be a burden to be avoided
I dunno, take a look at 20th century art for analogues. Some not so good,
some very good.
I suggest the following method, an absolutely program-free way to prototype
a work of IF.
1) devise a backstory for your work of IF.
2) make a FAQ and post it to Usenet in semi-appropriate groups.
3) send e-mails back and forth to your players about what happened.
I have produced buckets of material that I would have been too lazy and
unfocused to produce otherwise. In fact, the story has developed a life of
its own. As far as the mid-game is concerned, it's now writing itself. The
big challenge is how it's all going to end. I don't know what it's all
going to mean, or what it's all going to say.
Cheers,
Brandon Van Every
Brandon Van Every
David A. Cornelson wrote in message <6ntddh$g...@newsops.execpc.com>...
>
>The problem is, the grammar library and structure. I have yet to figure out
>a way to translate the grammar library into a relational model. I think
this
>is the problem with all of our IF tools. This is the lone exception where
>even an object-oriented design was unreachable where our sentence structure
>is concerned.
Well hey here are a couple of "radical" ideas. Yes I can sense you
steadying your egg-throwing hands:
1) screw parsers. Make it graphical, like Myst / Riven / King's Quest.
2) screw parsers. Make it textual but multiple choice, like
Choose-Your-Own-Adventure.
Some people like to work in particular media (i.e. grammar parser) because
they enjoy it, despite the fact that it's difficult for most people to work
with. People who insist on revelling in complexity generally don't come up
with solutions that are viable for the rest of us. Said as someone who has
come up with a lot of complicated solutions for a lot of things.
Cheers,
Brandon Van Every
Iain Merrick
> David A. Cornelson wrote in message <6ntddh$g...@newsops.execpc.com>...
>
> >The problem is, the grammar library and structure. I have yet to figure out
> >a way to translate the grammar library into a relational model. I think
> this
> >is the problem with all of our IF tools. This is the lone exception where
> >even an object-oriented design was unreachable where our sentence structure
> >is concerned.
>
> Well hey here are a couple of "radical" ideas. Yes I can sense you
> steadying your egg-throwing hands:
>
> 1) screw parsers. Make it graphical, like Myst / Riven / King's Quest.
> 2) screw parsers. Make it textual but multiple choice, like
> Choose-Your-Own-Adventure.
I don't think those are really two different alternatives, they're
independent choices. (This is constructive criticism rather than
egg-throwing, hopefully).
In a conventional adventure game, you have the stuff the player sees
(the text) and the stuff that goes on behind the scenes (the game
mechanics).
Your first suggestion really says, `replace the text the player sees
with graphics'. I don't think that makes things any easier, since most
people find it much easier to write text than to create graphics. If you
want graphics as good as those in _Riven_, you need expensive computers
and highly skilled artists. For fantastic text, you just need one person
[*].
Your second suggestion says `drastically simplify all the stuff behind
the scenes', which could apply to either text games or adventure games.
This is more relevant, but I think the choose-your-own-adventure style
is perhaps a bit _too_ simplisic.
I've just realised that there _is_ something of an overlap between
graphics and CYOA, which is as you say, `screw the parser': either way,
you no longer need to add your own vocabulary to the parser. But surely
just adding new nouns and even simple verbs to the parser is easy
enough? Or could be made easy with a nice friendly interface?
As far as I can see, the real question is this: is there a useful
paradigm somewhere between CYOA and arbitrary programming? (In terms of
both flexibility and ease of use?)
--
Iain Merrick
[*] It helps, of course, if that one person happens to be called `Graham
Nelson'.
Lelah Conrad
wrote:
>The recurring suggestion that elitist programmers are deliberately
>withholding a solution to the problem, aside from being a cheap shot
>hardly worth the distinction of a response, conveniently sidesteps the
>enormous technical barriers that exist and which have been enumerated
>more than once. It also conceals what I am increasingly coming to see
>is the real problem here, which is that elitist "writers" consider
>programming to be inconsequential technical dirty work unworthy of
>their serious artistic attention.
[Eric, you seem to take offense easily. I do understand that there
are technical barriers. Also, I am not an "elitist writer", since I
have only a couple of publications to my name (and one chicken-comp
game! heh).
The reason I wrote the proposal I did was because a programmer
challenged me via private email to stop complaining and write out what
I would like to see (this was after an earlier thread arguing about
syntax and logic). So I did spend time doing this, though much to my
chagrin that person never even responded to my work! Also, I am well
aware that I would look like a fool posting such a thing to raif, but
I'm old enough now to not mind looking foolish so much any more.]
But what I really wanted to do was offer you this analogy: in my
profession, teahing reading to learning disabled (and other) kids, I
know something about how difficult it is to actually succeed. People
who come in from the outside do not understand, and do not appreciate
the level of technical knowledge and skill necessary to get such a kid
reading. Over many years many outsiders have screamed about why
Johnny can't read, (and of course it still goes on, just like here)
but what I want to say is that in *response* to that kind of
screaming, the field moved to focus on some types of problems over
others, and put their research there. Really, to me, that's the value
of outsiders. They (sometimes) at least let people who are really
deep in the forest know which trees they'd like looked at! That's
all.
Lelah
PS To any newbies who are following these convoluted threads: I
recommend taking a look at ALAN. I just worked through the new
tutorial, which is great, and the syntax seems less convoluted than
TADS. I've now got two games going, one in ALAN and one in TADS, to
compare their ease of use. (And yes I know you supposedly can't do as
much in ALAN!)
Trevor Barrie
>>Think like a writer first and a programmer second. That is the most
>>important piece missing from the current tools.
>
>It's thinking that writing and programming are somehow separable in IF
>that guarantees this will probably go nowhere. It's like arguing that
>color mixing is a distraction from brushwork in oil painting.
I've always thought that writing and programming in IF were analogous to
writing and drawing in comics. They are separable, but you can make a good
case that the best works are produced when one person is doing the whole
show.
Lelah Conrad
wrote:
>On a slightly different note: I have a horrible feeling that Lelah first
>needs a Beginner's Inform Front-End Front-End, which turns her sample
>transcript into a tool that can take said transcript and turn *that* into
>a text game...
(Shamefacedly) Now I feel REALLY foolish. :)
Lelah
Andrew Plotkin
> Well hey here are a couple of "radical" ideas. Yes I can sense you
> steadying your egg-throwing hands:
>
> 1) screw parsers. Make it graphical, like Myst / Riven / King's Quest.
> 2) screw parsers. Make it textual but multiple choice, like
> Choose-Your-Own-Adventure.
>
> Some people like to work in particular media (i.e. grammar parser) because
> they enjoy it, despite the fact that it's difficult for most people to work
> with.
You're equating grammar parsing with the hard part of the problem (so to
speak) here, which I think isn't right. Grammar is *a* hard part of Inform
game design, but not the only hard part. (A reasonable, high-quality
Inform game can be built using only the default grammar and actions.)
I haven't seen a CYOA which was, well, interesting at all -- the genre
just doesn't seem to be very involving. (Are there any IF author wannabes
who are willing to cast their ideas in a CYOA form? The tools are out
there, but nobody's using them, which should tell us something.)
As for graphical games, I don't think they're much simpler to build than
text IF -- and I'm not talking about the artistic task. The code inside
Myst is just as much programming as that inside Zork.
> People who insist on revelling in complexity generally don't come up
> with solutions that are viable for the rest of us.
I'm not sure what you mean here.
(A.k.a "I think you're being gratuitously provocative and meaningless
here, but I'll give you more rope rather than making an issue of it." :-)
Darin Johnson
> >Have you read "About Face: The Essentials of User Interface Design" by
> >Alan (Father of VB) Cooper? If so, did anything he said seem relevant
> >to your work with inform?
...
> The book does make you think harder about user interfaces. Do you
> have any particular insights in mind with respect to IF?
Really? My biggest gripe with VB is that it appeared to have been
written by someone that cared little for efficient user interfaces
(it's as if it's ok to constantly scroll through a property list, as
long as you don't have to typea ny code).
--
Darin Johnson
da...@usa.net.delete_me
wo...@one.net
Hi Lelah,
>>On a slightly different note: I have a horrible feeling that Lelah first
>>needs a Beginner's Inform Front-End Front-End, which turns her sample
>>transcript into a tool that can take said transcript and turn *that* into
>>a text game...
>
>(Shamefacedly) Now I feel REALLY foolish. :)
Why? :) You're just beginning to see the scope of the problem, is all.
Let me ask you, would you be willing to learn an existing language?
If, for instance, you had a good tutorial? Inform comes with a pretty
good one, and as part of my own efforts to create a beginners library
I'm including about 90% more comments than code... <grin>
And I disagree with Andrew about MS Wizards. :) They're a wonderful
idea, especially when you can look at what they produce and begin to
work through the *why* of what they actually do. I learned a great
deal of Access 2.0 from those wizards.
If you're willing to scale back the domain of your proposted writing
tool I see one huge benefit from something like it. The "wandering
around" portion sounds marvelous.
It would be very handy to draw out a map (on paper), give the rooms
names, and then use some kind of tool to say "Ok, start at "Kitchen".
W="Living Room", E="Window", U="Chimney", and so on. Then if you say
"Go N" it says "Kitchen". You could then "paint" the long description,
sounds, smells, etc.
Notice I'm saying nothing about objects and actors, just rooms. Right
now in conjunction with Universe I'm writing the game "Thief's Quest".
A room painter would come in mighty handy...especially considering
there are hundreds of rooms. I'll see if I can't add something like it
to Ravel...
Once you've painted your scenery then you could use a second tool to
add static objects, and "movable" objects. At this stage forget about
making them do anything, all you want to do is put them in the game,
give them sensory descriptions and (depending on the library in use) a
few basic things like weight or bulk.
The problem with these tools of course is that they would have to be
tied (at the very least) to a given language, and probably to a
specific library within that language.
And even this is going to take some pretty substantial programming,
perhaps even database capabilities.
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
John Francis
>I'm not criticizing anyone. I'm trying to elaborate what I think Lelah is
>trying to say because I believe I'm someone that understands both sides of
>I believe many of your ideas are sound, but the problem that remains is that
>the people with the ability to solve this problem staunchly prefer to keep
>interactive fiction to themsleves, in the programming world.
Thus demonstrating a definite lack of understanding (which goes nicely with
the lack of humility shown in the first paragraph).
To produce a good piece of IF requires skill in both programming and writing.
IF can be produced by a programmer lacking good writing skills, but the end
result will not be a good piece of IF (see, for example, almost anything by
our friend Rybred Celsius). There are some tools (all, incidentally, written
by programmers) which attempt to provide a simpler interface to writing IF.
So far no particularly good games have come from these systems, either. But
if we have the temerity to suggest that this might be because to produce a
good piece of IF requires a less constrained environment, and it's impossible
to produce something with the power or flexibility of TADS or Inform without
ending up with similar levels of complexity, we get accused of exclusivity.
There's a reason why some people end up as programmers, and others end up as
writers; it's where our skills lead us. Why is it so hard to accept the fact
that to produce a good piece of IF requires ability in both fields.
It certainly is possible to provide a simplified interface to automate many
of the more repetitive tasks. This has been suggested many times in the past,
but has aways been countered with the argument that this only handles simple
stuff. When you get to the more complicated (and, by common assumption, more
interesting) parts of the game you still will need something with the same
power and flexibility as a traditional programming language. so far nobody
has come up with a feasible alternative approach. Accuse us of exclusitivity
if you wish. But until you can suggest a viable alternative, don't be too
surprised if we accuse you of pie-in-the-sky wishful thinking. Crying
"There *has* to be a better way!" isn't enough.
I've often thoughty about producing a RAD tool for IF development. But the
problem is that I would produce a tool that *I* would want to use. I don't
think it would be the sort of tool a non-programmer would be happy with.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
Trevor Barrie
wrote:
>Well hey here are a couple of "radical" ideas. Yes I can sense you
>steadying your egg-throwing hands:
>
>1) screw parsers. Make it graphical, like Myst / Riven / King's Quest.
>2) screw parsers. Make it textual but multiple choice, like
>Choose-Your-Own-Adventure.
>
>Some people like to work in particular media (i.e. grammar parser) because
>they enjoy it, despite the fact that it's difficult for most people to work
>with.
Well, I for one would prefer to play/write parser-based text adventures
because I know from experience how much more frustrating the various
graphical adventure interfaces are to use. Do others have a different
experience?
Erik Max Francis
> Now... _perhaps_ this tool could be made, but quite frankly, I'd
> rather it
> didn't, because any such language would by necesity have to be turing
> complee.
> and if you could make a turing complete language which didn't require
> programming, then, quite frankly, I'm out of a job, because no one
> would need
> computer programmers any more [1].
I'm a professionally-employed programmer as well, so my job would be at
risk as well.
The way I look at it is, though, the task of "programming without
actually having to learn how to program" would be at least as
complicated as the simplest Turing-complete programming language. That
is, you've gained nothing, except a new way to express a programming
language.
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm:+37.20.07/-121.53.38
\
I put away my nine, fool / 'cause I'm colorblind.
/ Ice Cube
L. Ross Raszewski
erky...@netcom.com (Andrew Plotkin) wrote:
>
> On a slightly different note: I have a horrible feeling that Lelah first
> needs a Beginner's Inform Front-End Front-End, which turns her sample
> transcript into a tool that can take said transcript and turn *that* into
> a text game...
>
> Abstractly speaking.
>
I's started to bother me that if the "we wanna write good IF without
programming" people get their way, there will have to be a system which can,
without any programming, produced a work as complex as a good piece of IF.
Now... _perhaps_ this tool could be made, but quite frankly, I'd rather it
didn't, because any such language would by necesity have to be turing complee.
and if you could make a turing complete language which didn't require
programming, then, quite frankly, I'm out of a job, because no one would need
computer programmers any more [1].
>footnote 1
Before you tell me I'm a programmer, and therefore don't understand, I
started out as a writer. Only a writer. Exclusively a writer. for most of the
first 17 years of my life I wanted to be a writer. When I started wriing IF,
I did it as a writer. I used AGT. But I found I couldn't, as a writer, make a
game that was as good as I wanted it to be. I learned how to program (and
lemme tell you, learning how to use AGT like it was a real language is one
hell of an experience, though (AGT fans rejoice) it's not impossible. (ANd to
the naysayers, the most complex thing I ever did in AGT was probably this: I
coded a camera with a shoulder strap. When it was carried in the hand, it
added to the volume total and weight totalt that you were allowed to carry.
when worn over the shoulder, it only added to the weight total. THe camera
could also take pictures, and be reloaded an infinite number of times buy
buying more film.) And once I learned how to program,I never turned back.
Being a natural jack of all trades (I confised bmy highschool guidance
councillor by completing the requirements for a mathematics, science, and
social sciences emphasis -- it's so rare that anyone bothered to complete any
one of them)I suddenly realized , "Hey! I can write AND use my math skills
at the same time. I was in heaven. And now, a fairly last minute decision, I
am studying computer science. I am also writing short stories. If you want
to write _good_ IF, there _isn't_ another way. If you want to write bad IF,
you'll get no help from me.
>footnote 2
Footnote 1 was long, wasn't it?
>footnote 3
Now you're just trying to read all the footnotes to look for hidden messages,
aren't you?
Matt Kimball
: fra...@ncgraphics.co.uk (Francis Irving) writes:
:> >Have you read "About Face: The Essentials of User Interface Design" by
:> >Alan (Father of VB) Cooper? If so, did anything he said seem relevant
:> >to your work with inform?
: ...
:> The book does make you think harder about user interfaces. Do you
:> have any particular insights in mind with respect to IF?
: Really? My biggest gripe with VB is that it appeared to have been
: written by someone that cared little for efficient user interfaces
: (it's as if it's ok to constantly scroll through a property list, as
: long as you don't have to typea ny code).
Indeed. I find it difficult to reconsile some of the UI design
decisions of VB with Cooper's excellent book. And although I dislike
VB on multiple levels, (depending on the job, I'll choose Perl or Tcl
instead if I want an interpreted procedural language), I did find the
book to be very good. Good UI design is very hard, and the book
provides lots of things to think about for the novice like me.
--
Matt Kimball
mkim...@xmission.com
Eric O'Dell
<dcorn...@placet.com> wrote:
>We talk and write beyond the simple structure of a relational or oo design.
>But there is a logic to it. The problem is that we haven't been able to
>break this logic down far enough.
>I'm sure there's a white paper out there somewhere that has mathematically
>defined our language to some degree, but I believe that's what we need to
>begin understanding how to create an interface that is based on OUR
>language, not on the computers.
>I don't believe that AI is the answer. That is a different problem. We're in
>the business or art of language translation, not artifical intelligence.
>When we get to a point where we can build a language parser that understands
>more complex sentences, then we're moving closer to my goal, which is true
>interaction with a computer.
It's not the logic --- Noam Chomsky and others have offered various
schemes for encoding the syntax of natural language; in fact, unless
I'm remembering incorrectly, the BNF formalism we use today to specify
new programming languages was originally intended to be used to
analyze natural language.
The problem isn't in the logic at all; we've had _that_ problem licked
for years. It's that human language is ambiguous, relies heavily on
context and metaphor and connotation, and parsing is primarily
dependent on the semantic value (meaning) of the tokens (words) and
not on the syntax. Machine processing syntax _is_ a matter of logic,
and we've actually taken great strides forward in that area in recent
years. (If you're interested, look at PRECCX or ANTLR, which offer
LL(k) parsing that allows much more flexible syntax than you can
easily get with the LALR(1) tools used to develop languages like C.)
But determining the semantic value of tokens in natural language
requires _understanding_, and the process of understanding meanings
involves a complex web of non-rational, i.e. non-logical, processes
that we are only beginning to understand. Recent work with brain
imaging confirms this --- in the case of the human brain, semantics
and even syntax are analyzed by means of cascading interreactions
between neurons, not logic. Insofar as human languages are a natural
outgrowth of human brains, they are structurally dependent upon
non-logical processes in the underlying brain. It is debatable whether
computers, which are all logic and nothing else, can ever come to
emulate anything as different from transistors as a mesh of neurons.
The problem _is_ one of artificial intelligence, and the two big
surprises medical researchers have presented us with are that A) while
the faculty of logic does have a physical basis, our language and much
of the rest of our thinking depends upon other faculties, and B) most
of the assumptions we have cherished about how we think are wrong.
Paul F. Snively
>30? "Collossal Cave" is closer to 25, ain't it? The 350 pt. version is ca.
>1976, I thought.
Yes, but some lower-point versions go back a good five years prior.
>Wouldn't most of us here prefer *more* power rather than greater simplicity?
More power than a Turing-equivalent programming language provides? What
does that mean?
>Maybe not. I could stand a little more of both but if someone came up with a
>workable NPC system, I'd tolerate a lot of awful things to work with it.
Well, what features would make an "NPC system" more workable for you?
>[ok]
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Paul
Paul F. Snively
<dcorn...@placet.com> wrote:
>I'm sure there's a white paper out there somewhere that has mathematically
>defined our language to some degree, but I believe that's what we need to
>begin understanding how to create an interface that is based on OUR
>language, not on the computers.
>
>I don't believe that AI is the answer. That is a different problem. We're in
>the business or art of language translation, not artifical intelligence.
>When we get to a point where we can build a language parser that understands
>more complex sentences, then we're moving closer to my goal, which is true
>interaction with a computer.
What's amusing about this is that what used to be called Natural Language
Processing and these days is called Computational Linguistics has
historically been considered *the* canonical AI task. FWIW, Zork was born
at MIT's AI Lab, and was written in a dialect of Lisp, the canonical AI
programming language. Today we have Inform, whose syntax is derived from C
but whose semantics (by virtue of generating Z-code) are derived from the
MDL dialect of Lisp.
There are more than white papers, by the way, providing extensive lexicons
of English for computational use. Computational Linguistics systems to be
aware of include Nigel and Penman at ISI, and I forget the names, but the
automated translation systems from Carnegie Mellon. FUF is an excellent
system for experimenting with Functional Unification grammars, and Surge is
its (large) grammar for English.
Most IF systems would probably benefit a great deal from something as
simple as Xerox's POST, a Part Of Speech Tagger for English that would help
disambiguate, e.g. whether "can" in a sentence was used as a noun, a verb,
a helper, etc.
Going back to Carnegie Mellon, there's another parser for sentence
structure whose name escapes me offhand that would almost certainly work
well for IF endeavors.
>I think this is a little clearer, but probably not.
It's clearer, but it's also clearer where some of your most flawed
assumptions are. Go take a harder look at AI in general, and Knowledge
Representation and Computational Linguistics in particular.
>Jarb
Paul
David A. Cornelson
robbj95.899857211@octarine...
>"David A. Cornelson" <dcorn...@placet.com> writes:
>
>On what basis do you believe that it is possible to develop a language
>translator - a system which understands complex sentences - without
>AI? What approach would you take? I admit that I have a rather
>limited knowledge of natural language processing and computer science
>generally, but if I were to attempt to build such a system (and wanted
>to get beyond limitations of templating for this problem), I would take
>an AI approach. Though difficult, it honestly seems simpler than the
>problem would be without AI.
Use Case Scenarios. By building a huge library of usage, we could begin to
do things on a higher level. Admittedly, I'm no expert on AI or Langauge
parsing, but I believe in solving problems in small bits. So, we start by
doing things the hard way and we create a huge library of objects with usage
rules and somewhere down the road another programmer looks at all of it and
says, "Hey, there's a better way to do this.", but until we build a
prototype, we really can't see the problems.
I think this is why the reocurring theme is that to build a friendly
non-programming interface would be 'impossible' or 'too hard'.
As for how I would personally do it, I keep this thread alive because I like
the topic and I'm continually going back to it on my own. I've partially
designed about 100 languages and interfaces to solve this problem and to
date, all of the naysayers are right. So I'm trying to prove that I can do
it because, well, it's there.
Jarb
David A. Cornelson
6nu5p6$a1...@fido.engr.sgi.com...
>In article <6npe6j$3...@newsops.execpc.com>,
>the lack of humility shown in the first paragraph).
I resemble that remark. (;
>To produce a good piece of IF requires skill in both programming and
writing.
Again, it's a tool issue. I can completely write an interactive fiction game
in a design format with all of the text and logic in english. I could hand
it to a programmer and they could write it in Inform (well, so can I, and I
plan to do so).
But my point is that I can 'design' an interactive game without a
programming tool.
It requires no programming skills whatsoever to create a good piece of
interactive fiction. You need to understand the nature of the standard IF
interface and how to write in that 'form', just as you would write poetry in
it's multiple forms. The logic of your story can be written in english.
The form that I use is similar to a transcript of a played game. Don't
misunderstand what I am saying either. I understand the difficulties. I
understand that my transcript is written based on known assumptions from the
Inform language.
But that doesn't change my argument.
Jarb
Irene Callaci
Dungeon on a PDP-11, I couldn't believe I could "communicate"
with a machine in my own language. I decided right then and
there to learn how to program. Odd as it may seem, I found
that my writing skills improved as I learned how to program,
because each word/command must actually *do* something, and
it must do it precisely. Vagueness is a killer, both in
programming and in writing.
irene
On Wed, 08 Jul 1998 03:14:22 GMT, L. Ross Raszewski
<rras...@hotmail.com> wrote:
[snip]
okbl...@usa.net
> <http://www.u.arizona.edu/~pollock/>
>
The latter link is quite interesting--I only got a hint from the Cycorp link
about what it might have to do with the question, though.
okbl...@usa.net
"Brandon Van Every" <vane...@blarg.net> wrote:
>
> 1) screw parsers. Make it graphical, like Myst / Riven / King's Quest.
> 2) screw parsers. Make it textual but multiple choice, like
> Choose-Your-Own-Adventure.
>
Already been done.
Actually, I guess it's fair to say if the idea is to make IF possible for
non-programmers, graphical is an easier way to go.
If we're trying to advance the art, getting rid of the parser means closing
off the possibility of "natural" interaction, both with the computer (through
voice processing) and the NPCs (through free dialogue).
okbl...@usa.net
Darin Johnson <da...@usa.net.removethis> wrote:
>
> Really? My biggest gripe with VB is that it appeared to have been
> written by someone that cared little for efficient user interfaces
> (it's as if it's ok to constantly scroll through a property list, as
> long as you don't have to typea ny code).
>
I believe the book was written with the knowledge that VB was not an ideal
tool.
John Francis
But ... That doesn't fully specify the game. Nobody is denying that a
natural language (such as English) is sufficiently powerful to describe how
you want the game to behave. The problem is that English is not sufficiently
precise. By the time you add the necessary formalism to eliminate ambiguity
you end up with a programming language, not a natural language.
As for using a transcript-style definition: are you prepared to enumerate
all possible variations explicitly? If so, then you just end up with a
branching decision-tree. If not, then you need some shorthand way of
grouping multiple nodes together, or factoring out subsets of the text.
Then you are getting closer to abstract data structures; something that
doesn't really have a natural language counterpart.
The problem, really, is that there are two parts of creating a game:
design and implementation. A natural language may be appropriate for
the design phase, but eventually you have to get down to implementation.
At that point you either hand the design to a programmer, or you recast
the game in a form acceptable to a computer. Computers can't handle the
ambiguities, implicit assumptions, etc. inherent in a language designed
for communicating with intelligent entities.
Programming is difficult precisely because computers are very stupid.
(Computer: a machine capable of making millions of mistakes a second).
You can't tell a computer "It's _obvious_ what you need to do here";
nothing is 'obvious' to a computer. If you don't spell out all the
cases, and tell it what to do for each case, then it will end up doing
something you didn't expect it to do. Something you or I would never
do because it is patently stupid, perhaps. But computers can't make
those kind of value judgements.
okbl...@usa.net
>
> Yes, but some lower-point versions go back a good five years prior.
Huh. I thought the original was from 1973. Hardly matters.
> >Wouldn't most of us here prefer *more* power rather than greater simplicity?
>
> More power than a Turing-equivalent programming language provides? What
> does that mean?
Greater abstraction and comprehensive libraries, apparently. All
Turin-equivalent programming languages may be ultimately equal in what can be
accomplished using them but they are not equally powerful. (Power involves a
time factor.) It is faster to do some things in some languages than others,
and on some platforms.
> >Maybe not. I could stand a little more of both but if someone came up with a
> >workable NPC system, I'd tolerate a lot of awful things to work with it.
>
> Well, what features would make an "NPC system" more workable for you?
That's not a short question from any technical standpoint. But if I saw a
system that contained built-in structures or support for: intentions, habits,
aesthetic preferences, speech styles, knowledge, communication, defect, and so
on. Just a start on those would be worth a fair amount of effort for me.
David A. Cornelson
chewy-ya02408000...@news.mci2000.com...
>In article <6ntddh$g...@newsops.execpc.com>, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
>>I think this is a little clearer, but probably not.
>
>It's clearer, but it's also clearer where some of your most flawed
>assumptions are. Go take a harder look at AI in general, and Knowledge
>Representation and Computational Linguistics in particular.
Okay.
Jarb
Trevor Barrie
>>Wouldn't most of us here prefer *more* power rather than greater simplicity?
>
>More power than a Turing-equivalent programming language provides? What
>does that mean?
The ability to solve the halting problem. Hey, I wouldn't mind seeing an
IF language that could do that.:)
Paul F. Snively
>In article <chewy-ya02408000...@news.mci2000.com>,
> ch...@mcione.com (Paul F. Snively) wrote:
>>
>> <http://www.cycorp.com>
>> <http://www.u.arizona.edu/~pollock/>
>>
>
>The latter link is quite interesting--I only got a hint from the Cycorp link
>about what it might have to do with the question, though.
The poster I replied to said something about believing that how things
would work "instead of AI" was by developing something that would get to
some kind of "metastable" point, at which it would begin learning on its
own. The Cyc project has, and has always had, precisely that goal:
force-feed it a (very large) ontology for 10 years, then turn it loose on
all the "printed" materials it can get its sensors on to learn more. So the
poster's idea isn't new, and is very definitely contemplated under the
rubric of "AI," at least as Doug Lenat defines the term (and I agree with
him).
>[ok]
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Paul
Paul F. Snively
>In article <chewy-ya02408000...@news.mci2000.com>,
> ch...@mcione.com (Paul F. Snively) wrote:
>> >1976, I thought.
>>
>> Yes, but some lower-point versions go back a good five years prior.
>
>Huh. I thought the original was from 1973. Hardly matters.
Exactly. Gimme some margin for error. ;-)
>> More power than a Turing-equivalent programming language provides? What
>> does that mean?
>
>Greater abstraction and comprehensive libraries, apparently. All
>Turin-equivalent programming languages may be ultimately equal in what can be
>accomplished using them but they are not equally powerful. (Power involves a
>time factor.)
That's not how most CS folks use the term "power," although we all know
that performance matters.
>It is faster to do some things in some languages than others,
>and on some platforms.
Sure, but it seems like all the languages I know are within an epsilon of
each other in performance modulo the state of the art in compiler
technology for their major class (functional, dynamic object-oriented,
procedural, etc.)
>That's not a short question from any technical standpoint. But if I saw a
>system that contained built-in structures or support for: intentions, habits,
>aesthetic preferences, speech styles, knowledge, communication, defect, and so
>on. Just a start on those would be worth a fair amount of effort for me.
Yeesh. You managed to come up with a pretty good list of AI-complete
features. ;-)
TenthStone
>
> Paul F. Snively <ch...@mcione.com> intoned noiselessly:
> >David A. Cornelson <dcorn...@placet.com> typed:
> >
> >And modest, too! ;-)
>
> Well, I'm not as well-schooled as you are but then again, you're the first
> person I recall on the thread that has tried to write a cognitive reason for
> the difficulty in creating a non-programming interface for creating IF. I
> just meant I've been the only programmer that has taken the side of the
> non-programmer. I didn't mean to be boastful.
Hmm... That's not really very fair. And it IS rather boastful, as you
make it
sound as if you alone have valiantly defended the art of IF against the
horrid forced of evil, in the form of programming. But we'll leave
that,
and get on.
> >With all due respect, computer programming as we know it today has been
> >around for almost 40 years, and IF in one form or another has been around
> >for almost 30. During this period of time, very many very smart people have
> >tried to make computers more accessible to non-programmers
>
> I'd argue that these 'experts' as you put it, have not sat down with a group
> of writers and tried to build an interface that they would be able to use.
> I'm sure these 'experts' have been trying to build HAL or something close to
> it. That, to me, is not the answer. I believe that AI will come out of
> someone developing a base learning device that needs to be fed information
> for years and years before it becomes realtively useful. You're not going to
> build it in a day and not on one algorithm.
The last statement is obvious, but that's not the point. And I'm not
sure
that this hypothetical AI would require years of information. More
likely,
the AI would simply require human contact to understand humans. Oh, and
where
was the word 'expert' used? I probably just missed it.
TENTH, DISABLE QUIBBLING
Hmm... Very few people are attempting to create a truly advanced AI.
For most
uses, all that is required is a simplistic set of methods that handles
movement,
speech, stimuli-response, et cetera. And in case you hadn't realised
it, most
current tools don't require a great deal of programming. Take a fairly
complex example, like a computer (heh). An old model, which runs off of
floppy
disks.
The room is thus initialized (in TADS, which may/may not be more
concise):
computerroom: room
sdesc = "Computer Room"
ldesc = "The room looks like some sort of twisted interpretation of
The
Lurking Horror. Part of the room is the computer lab at which
you've
spent so many hours, and the rest is a combination between the
sewers and
a strange dream world. Freaky. All there is of the lab is one
computer,
but not one of the pretty little terminals like you remember:
this is a
snarling monster (not literally) with a disk drive marked
'Insert Disk,
Press Power Button'. Sadly, the part of the computer lab with
the
exit out is covered in goo."
north = {
if (computer.ison) return doneroom;
else return nil;
}
;
This is about as simple as it can get. A GUI could make it easier, of
course,
but it cannot well become far simpler. I can see a dialog with text
boxes for
the codename ("computerroom"), the room title ("Computer Room"), and the
room description ("The room &c"), with the ten directions (as defined by
TADS,
N,S,E,W,NE,SE,NW,SW,U,D,Enter,Leave) given a simple triad of drop-downs:
Go to [location, where the pulldown provides a list of defined
locations;
alternatively, some sort of map] if [condition, by default "true"] is
met,
otherwise go to [location, by default "nowhere"]. All this really does
is
eliminate keywords such as "sdesc" and "nil". A map could be used
as a centralized interface for the tool, I suppose, and when the user
has finished
carefully setting up the graphical aspects of the room, the tool could
write
a description purely based on the items defined... sort of an AutoCAD
approach
to IF programming. This would be far more appropriate for a graphical
game.
In the interests of time and length, I'm skipping the remnant of the
code for my example.
What I'm trying to say, albeit at length and indirectly at that, is that
simpler
tasks are well taken care of in the current tools. More difficult tasks
DO
take a good deal of programing, and for good reason. Most of that
programming is
event-handling and case-selection. That is, when someone pushes the
power button
on the above-mentioned computer, the computer has to determine whether a
disk is in the floppy drive so it knows what to do.
> This is the wrong path for IF. We have already come to the conclusion that
> the method of puzzle building is relatively static. It's the implementation
> of these 'methods' that can be changed. I'd argue that the writer controls
> the implementation and we need to create an interface that will help them do
> this without writing code.
Maybe my perspective is biased, but the diificulties in writing code
seem to me
to be greatly exaggerated. Really, think about it. Consider the
computer example.
How would you write out clear directions on what the computer should do
when its power
button is pushed? In all likelihood, something to the effect of "Check
to see if I'm
turned on. If I am, turn off. If I'm not, check to see if I'm plugged
in. If I am,
check to see if there's a disk in the drive. If there is, run the
program on the disk.
If not, check to see if there's a hard disk to run from. If so, run the
program on
THAT disk. If not, print an error message asking for a program to
run." The code
for that would be (again, in TADS):
harddisk = nil
isRunning = nil
ison = nil
verDoPush( actor ) = {}
doPush( actor ) = { // This just defines a synonym.
self.doPress( actor );
}
verDoPress( actor ) = {}
doPress( actor ) = {
if (self.ison) {
self.ison := nil;
self.isRunning := nil;
}
else {
if (powercord.pluggedin) {
self.ison := true;
if (diskdrive.disk != nil) {
self.isRunning := true;
diskdrive.disk.runProgram;
}
else {
if (self.harddisk) {
self.isRunning := true;
self.runProgram;
}
else "System error: invalid program disk";
}
}
}
}
This is not difficult programming. It's just a simple consideration of
nearly all possibilities (the computer parts could be disconnected),
which
is part of good IF writing. Yet this is perhaps the most complicated
part
of the computer code.
> >My position is that I want a non-programmer to be able to create a Zork
> >Unnkulian, etc.
In order to make the program, the writer MUST be a programmer. It may
not be
an advanced work of programming, but that's what it is. Even these
simple,
theoretical tools you speak of count as programming tools. I don't
consider
a VB programmer to be less a programmer than an ASM programmer, even
though
the ASM is certainly harder. Complaining that the programming is
impossible
doesn't help anyone, and wishing for a tool that sounds like it would
complicate
the simple tasks in exchange for marginally easier completion of basic
interactions... doesn't seem worthwhile.
> Again, begin with a simple foundation that works. A foundation that is
> immediately and automatically extensible. If you build something that is
> easy to use and extensible, then you have begun to create what Lelah and I
> have in our minds. If you try to build HAL, right from the start, you will
> be overwhelmed and as you said, you just won't even try. But if you try to
> build the part of HAL that understands the fundamentals of an IF world, such
> as directions, light/darkness, object handling, etc., then you're on a track
> that can succeed.
How would one extend this? I'd like to know; it sound suspicious llike
what
would be necessary would be hundreds of libraries (of CODE; what
horror!)
that each simplified the production of one particular item. I don't
doubt your good
intentions, but I do doubt the feasibility. I also strongly feel that
most
of the current tools, once learned, fulfill both of the requirements
you've
set out: extensible, because they utilise an actual programming
language;
and easy-to-use, because their languages are relatively small, concise,
and
self-explanatory. Heck, I find myself wishing the general-use
programming languages
I commonly use had the features I find in TADS.
> Think like a writer first and a programmer second. That is the most
> important piece missing from the current tools.
The only solution I can see for completely avoiding code while producing
a worthy product is to write it out of paper and pay someone else to
program it.
I'd love to hear what you have to say.
> Jarb
--------------------------------
The Imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com
mcc...@musashi.gsgis.k12.va.us
okbl...@usa.net
> poster's idea isn't new, and is very definitely contemplated under the
> rubric of "AI," at least as Doug Lenat defines the term (and I agree with
> him).
>
Gotta agree with you there. If it couldn't learn on its own it wouldn't be
intelligent, would it? Of course, in theory, you ought to be able to feed a
machine appropriate dictionaries and let it take off from there, no? In
theory, that set could even actually be pretty small.
Though, now that I think about it, the real limitation on such a system would
be the unavailability of first-hand observed data. The system would have no
way of evaluating "The sky is green" versus "The sky is blue". Maybe "solving
AI" has to wait until the hardware guys can come up with a system whereby a
machine can evaluate arbitrary data by experimentation.
okbl...@usa.net
> that performance matters.
>
I thought VB proved that performance didn't matter. ;-)
>
> Sure, but it seems like all the languages I know are within an epsilon of
> each other in performance modulo the state of the art in compiler
> technology for their major class (functional, dynamic object-oriented,
> procedural, etc.)
>
"Platform" is probably a better term than "language" really. That is, the
shoulders on which we stand when we begin writing IF.
Example: All the current IF-specific languages have container classes, which
is good. It keeps you from having to build your own. What they don't have is
any way to communicate to the writer/programmer (wrogrammer? priter?) what
implications having a container, say a breadbox, has in your game world. The
player may now attempt to put every object in the game in the container, so
how are you going to handle it? Does each object have a size? A weight? Are
you going to implement this in terms of inches and pounds (centimeters and
grams) or is everything going to be "bigger than a breadbox" or "smaller than
a breadbox", or is there going to be a list of items that the breadbox will
take (implying the breadbox is the ultimate arbiter of what it contains), or
is "breadboxability" going to be a feature of every object (implying that
every object determines for itself whether or not it will go into the
breadbox), or some combination of these things?
Combinatorial explosions indeed. I think the *only* thing capable of handling
the combinatorial explosions created by a computer program is another computer
program.
>
> Yeesh. You managed to come up with a pretty good list of AI-complete
> features. ;-)
>
I'm not suggesting, however, that it would have to be perfect. A good paradigm
would do. For example, say there was a system of communication that looked
something like:
statement:
intent
tone
content
written representation
verbal representation
The breakdown would be something like: The person making the statement intends
to fool you by making you think he's on your side, so his tone is a false
sweetness, and the content of the statement is that he's at your command. The
written representation is "When you say 'jump', I say 'How high?'" but he's a
southerner (Southern US) so he says "When you say 'jump', ah seh 'Ha ha?'".
I make this last distinction because some prefer to write "He speaks with a
heavy southern drawl" and write "Sure enough!" where others prefer to say
"Sho' nuff!" It also makes it possible (at some far distant point) to
generate the speech.
Now, even if you had to generate all the written/verbal representations
yourself and map them to content, I think a system that at least provided a
mechanism for you to do something like:
NPC.Speak(intent, tone, content).WrittenRepresentation;
and returned with one (possibly semi-random from a selection) text field that
conveyed all of the above, would be worth some serious investigation.
A dynamic NPC knowledge-base would be cool, particularly if it had "lie"
capability. So that the NPC could honestly impart bad information.
Of course, all of the current IF language paradigms put the text in with the
code and my friend has thoroughly disabused me of the idea that this is a Good
Thing.(TM) It does seem to be limiting.
okbl...@usa.net
tba...@ibm.net (Trevor Barrie) wrote:
>
> The ability to solve the halting problem. Hey, I wouldn't mind seeing an
> IF language that could do that.:)
>
The "halting problem"?
L. Ross Raszewski
okbl...@usa.net wrote:
>
> Of course, all of the current IF language paradigms put the text in with the
> code and my friend has thoroughly disabused me of the idea that this is a Good
> Thing.(TM) It does seem to be limiting.
It certainly is. But, OTOH, good text that isn;'t built into the code is an
AI-complete problem. Have a look at hte sample output of the OZ project
programs, or, better yet, have a look at erazmatron's answer to it. The
simple fact is, that trying to have the computer generate the text for you on
the basis of, say, intent, tone, and content, is, using modern systems gonna
give you:
"It's over there" bob says angrily
"it's over there" bob says politely
"it's over there" bob says shiftily.
Text that sounds good -- and that's what I _think_ most of us are after, is
not gonna be written by machine for some time yet
Jonadab the Unsightly One
>
> At the risk of making a bunch of people really mad (oh what the heck,
> this is usenet, right? :), I am going to point out that this example
> above is, to me, why syntax is a serious problem. The above does not
> look like writing, to a writer, even though, in fact, it is writing.
Of a sort.
> You have written out a series of coded symbols, somewhat in
> mathematical format, to get a computer to do what you want it to do.
> I wrote my *original* proposal in response to an argument with someone
> about syntax, and it was written in response to the question, well,
> how would you like it to *look*? In the introduction to my proposal,
> when I wrote that the user would not need to learn "programming", I
> was referring to the above sort of abstracted mathematics-looking
> programming. However, it should go without saying that even what I
> tried to write is a form of "programming", i.e. instruction giving) --
> I was rather more concerned that the process of the programming
> involve more words and fewer math-style symbols,
Oh, CoBOL ;-)
> so that the user
> would not have to constantly endure the kind of translation-stress
> that such symbols like the piece above cause some of us.
There will be a certain amount of that with words, as well, though,
if they perform mathematical functions.
> I think maybe there is some sort of difference between those who have
> a high tolerance for extreme abstraction (or reduction to the smallest
> symbolic component) and those who maybe might like things to remain
> closer to the ordinary English language domain
>
> *****even if the English language domain that it remains in is
> highly structured, and is not really true, ambiguous, messy,
> Turing-equivalent English*****.
Make location called "diner" and described as "insert
room description here...".
Make person called "baby joey" in location "diner" and
described as "insert NPC description here"
and (if "baby joey" is holding "spork") picking at
random each turn (with a 30 percent chance) whether
to perform "throw spork", otherwise performing
"baby joey default".
Make action called "baby joey default" described as
"insert action description here" and
doing nothing.
Make action called "throw spork" described as "insert
action description here" and moving "spork"
to "booth".
Make object called "spork" belonging to "baby_joey".
Something like that?
Heh, then I write class notes about non-computer stuff like,
~((love>faith)-->(love>truth))?
Which rougly translates to the following:
Why does it not follow that if love is greater than
faith (I Cor 13) that it must be greater than truth?
Yes, that's a real example. But I didn't start writing
like that overnight.
Yr. Obd't & Humble Servant,
Jonadab the Unsightly One.
----------------
One of the many uses for peanut butter:
26. Inhale deeply...
(Need more uses? see http://members.kconline.com/kerr/pb.htm)
Send replies to username@isp, where username is jonadab
and isp is bright.net
The zerospam.com address works, but you get an ugly confirmation.
Darin Johnson
> The "halting problem"?
Ie, can you create a program that will take any function definition
and determine of the function will eventually halt or not. Halt means
in any time that's not infinite. It's an unsolveable problem if I
remember. But it is solveable for classes of functions (such as
all those of a fixed length or less).
--
Darin Johnson
da...@usa.net.delete_me
Bradd W. Szonye
>
> Well, I for one would prefer to play/write parser-based text
> adventures because I know from experience how much more frustrating
> the various graphical adventure interfaces are to use. Do others have
> a different experience?
One of the biggest complaints my girlfriend had about IF was the
exacting nature of telling the parser what to do. She's just not a very
good typist (or speller) and became very frustrated with typing things
over and over to hit on the right spelling. Same goes for the somewhat
stilted language that most games expect. She simply expected much more
flexibility in saying what she wanted to do.
An interesting bit: she rather enjoyed I-0 when I would type for her and
read the responses aloud, but became VERY quickly frustrated when she
sat in front of the computer itself. I think the main reasons were:
1. She needed me to translate what she wanted into "Zork-speak."
2. She had trouble with the actual typing.
3. She had the usual problem with reading long text on a screen.
One other interesting bit: She disliked graphical adventures even more
than text IF; she considered the graphical stuff "boring."
--
Bradd W. Szonye
bra...@concentric.net
http://www.concentric.net/~Bradds
My reply address is correct as-is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
Bradd W. Szonye
>
> In article <chewy-ya02408000...@news.mci2000.com>,
> ch...@mcione.com (Paul F. Snively) wrote:
> >
> > <http://www.u.arizona.edu/~pollock/>
> >
>
> I only got a hint from the Cycorp link
I determined, with a little experimentation, that Cycorp is
<www.cyc.com>, whereas <www.cycorp.com> is Cybermall Corporation. How
unfortunate for Cycorp.
Bradd W. Szonye
>
> Make location called "diner" and described as "insert
> room description here...".
>
> Make person called "baby joey" in location "diner" and
> described as "insert NPC description here"
> and (if "baby joey" is holding "spork") picking at
> random each turn (with a 30 percent chance) whether
> to perform "throw spork", otherwise performing
> "baby joey default".
>
> Make action called "baby joey default" described as
> "insert action description here" and
> doing nothing.
>
> Make action called "throw spork" described as "insert
> action description here" and moving "spork"
> to "booth".
>
> Make object called "spork" belonging to "baby_joey".
>
> Something like that?
Oh, my. That DOES look like COBOL. (Not a bad language for what it was
designed to do, by the way).
Iain Merrick
[...]
> Oh, my. That DOES look like COBOL. (Not a bad language for what it was
What, irritate people as much as possible and grind their fingers down
to stubs with endless typing? :)
Andrew Plotkin
> okbl...@usa.net writes:
> > The "halting problem"?
> Ie, can you create a program that will take any function definition
> and determine of the function will eventually halt or not.
...for any possible input.
> Halt means
> in any time that's not infinite.
Right, and you have to return an answer in a finite amount of time. This
is what makes it hard. You can't just *run* the function definition and
see if it halts, because if it never does, you'll never find out.
> It's an unsolveable problem if I remember.
Right.
> But it is solveable for classes of functions (such as
> all those of a fixed length or less).
Well, sort of. This is true only because there are a finite number of
functions of a fixed length or less. Catalog them, put a finite-size array
of booleans in your halting tester, and your program works with a single
lookup! So we know the problem is solvable. The hard step is cataloging
them in the first place.
For example, it's trivial to write a function that runs forever if
Fermat's theorem is true, and halts if not. Determining whether *that*
function halts took centuries of human thought. Many other unsolved
problems are equally hard, and equally easy to write as short functions.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
David Brain
Ross Raszewski) wrote:
> The
> simple fact is, that trying to have the computer generate the text for
> you on
> the basis of, say, intent, tone, and content, is, using modern systems
> gonna
> give you:
>
> "It's over there" bob says angrily
> "it's over there" bob says politely
> "it's over there" bob says shiftily.
Surely any of those alternatives are inherently better than
"It's over there", Bob says.
At least the first way would indicate some sort of basic emotional
changeability of the NPCs even if it was completely bogus.
--
David Brain
London, UK
> Light creates shadow; light destroys shadow. <
> Such is the transience of darkness. <
Brad O`Donnell
> I've always thought that writing and programming in IF were analogous to
> writing and drawing in comics. They are separable, but you can make a good
> case that the best works are produced when one person is doing the whole
> show.
Amen to that!
Collaboration (particularly over the Internet) in comics or IF
has produced results that tend to diverge horribly from the initial
idea, in my experience. Negotiation suffers over the Internet
particularly, because you can't give your conspirators a good, hard
look when they throw a fishbowl into the game, or when they say
"..and I'd like 10 pages of the guy walking in the desert."
The trick to collaboration is to know the strengths and weaknesses
of every member of the team. If a member has no strengths, say
"I'd love your input on the project, perhaps as a betatester."
But maybe I'm just anti-social.
--
Brad O'Donnell
"A story is a string of moments, held together by memory."
michael...@ey.com
Brad O`Donnell <s7...@unb.ca> wrote:
> Trevor Barrie wrote:
>
> > I've always thought that writing and programming in IF were analogous to
> > writing and drawing in comics. They are separable, but you can make a good
> > case that the best works are produced when one person is doing the whole
> > show.
>
> Amen to that!
>
> Collaboration (particularly over the Internet) in comics or IF
> has produced results that tend to diverge horribly from the initial
> idea, in my experience.
Oh, I don't know. Sandman, The Preacher and Hellblazer (when it was written by
Garth Ennis) are are all excellent comics that were produced collaboratively,
and that often display an amazing level of creative symbiosis between artist
and writer.
(Particularly the latter two. The Preacher is a compelling argument that Garth
Ennis and Steve Dillon should get married and somehow have children.)
On the other hand, Todd MacFarlane is an excellent artist, but his writing has
always seemed insipid and sophomoric to me.
On the other other hand, Frank Miller and Bill Seinkewicz write and draw their
own work, and it is nearly impossible to divorce one's conception of the story
from the art that is so integral to it.
And, not everyone has always been happy with every artist that worked on
Sandman.
You really can't draw a definite line. It boils down to finding someone with
whom you share a certain chemistry. Both of you must be agreed upon the idea
and direction of the project from the very start, and each of you must have
respect for the other's vision.
--
--M.
okbl...@usa.net
> AI-complete problem. Have a look at hte sample output of the OZ project
> simple fact is, that trying to have the computer generate the text for you on
> the basis of, say, intent, tone, and content, is, using modern systems gonna
> give you:
>
> "It's over there" bob says angrily
> "it's over there" bob says politely
> "it's over there" bob says shiftily.
>
> not gonna be written by machine for some time yet
Let me be clearer: I totally got the above, and actually the dialogue
generated by my buddy's NPC was, uh, Frankenstienian. (Tarzanian? Movie
versions only. You get the idea.)
What I was referring to was this practice:
: Writeln('Hello, World!');
Pascal here, but nearly universal in programming languages as a first example.
My friend's contention is that it should be:
: Writeln(GreetingText);
Where GreetingText is fetched from a file that is kept logically separate, so
that it can be altered without altering the code.
All the IF languages I've seen insist on the text being in the code.
Understandably. But perhaps not ideally.
[ok]
Trevor Barrie
>> The ability to solve the halting problem. Hey, I wouldn't mind seeing an
>> IF language that could do that.:)
>
>The "halting problem"?
It's a CS thing. Bear with me if you already knew any of this:
A Turing Machine is an abstract model of a computational device; in fact, it's
the most powerful such model devised (in that every other model devised has
been shown to be at best equivalent to a Turing Machine). When we talk about
languages being "Turing equivalent" or "Turing complete", it means that they're
effectively equivalent to a Turing Machine, in terms of the problems they can
solve.
The Turing halting problem is as follows: Construct a Turing machine which,
when given as input a string representing the code for some Turing machine
followed by some other string, determines whether the encoded Turing machine
would ever successfully halt execution when run with that string as input
(say by simply outputting "yes" or "no").
Thing is, it can't be done. I don't recall the exact proof off-hand, but
it uses some neat trick involving self-referentiality to show that if
you had such a machine, you could construct a machine which is logically
impossible.
Consequently, one of the most common ways of proving that a certain
problem can't be solved algorithmically is to show that it reduces to
the halting problem.
Erik Max Francis
> Where GreetingText is fetched from a file that is kept logically
> separate, so
> that it can be altered without altering the code.
This is particularly useful for localization.
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm:+37.20.07/-121.53.38
\
I put away my nine, fool / 'cause I'm colorblind.
/ Ice Cube
Jeff Hatch
> }Yeah, an interesting thing that Turing observed: it's not possible to write
> }a program that will tell you whether or not another program will ever halt
> }or not. That is, it's impossible to write an infinite-loop detector.
> }
> }The proof is by reductio ad absurdum: assume that such a program exists.
> }What happens when you run the program on itself?
>
> It would return "yes". The contradiction requires that another
> program be created:
>
> perverse(program)
> {
> if (program-halts(program)) then while(1); else return;
> }
>
> Now run perverse with itself as input. That creates a contradiction,
> so there must be no such program as "program-halts".
Clarification: There can be no _algorithm_ that can tell whether a program
halts. An algorithm is a program that is guaranteed to halt, no matter what the
input is. The program "program-halts" could exist, but if it did, then it would
itself "crash" when given "perverse" as the argument, thus avoiding paradox.
-Rúmil
Paul F. Snively
>In article <slrn6q79sd...@drollsden.ibm.net>,
> tba...@ibm.net (Trevor Barrie) wrote:
>>
>> The ability to solve the halting problem. Hey, I wouldn't mind seeing an
>> IF language that could do that.:)
>>
>
>The "halting problem"?
Yeah, an interesting thing that Turing observed: it's not possible to write
a program that will tell you whether or not another program will ever halt
or not. That is, it's impossible to write an infinite-loop detector.
The proof is by reductio ad absurdum: assume that such a program exists.
What happens when you run the program on itself?
>[ok]
>
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Paul
Matthew T. Russotto
}
}Let me be clearer: I totally got the above, and actually the dialogue
}generated by my buddy's NPC was, uh, Frankenstienian. (Tarzanian? Movie
}versions only. You get the idea.)
}
}What I was referring to was this practice:
}
}: Writeln('Hello, World!');
}
}Pascal here, but nearly universal in programming languages as a first example.
}My friend's contention is that it should be:
}
}: Writeln(GreetingText);
}
}that it can be altered without altering the code.
Oh, Fortran. :-)
Yeah, there's reasons it's nice to have all the text separate. But
that's not nice to programmers at all. It makes code hard to write
and hard to understand -- take a look at the Fortran ADVENT or DUNGEON
source for examples.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Matthew T. Russotto
}
}>In article <slrn6q79sd...@drollsden.ibm.net>,
}> tba...@ibm.net (Trevor Barrie) wrote:
}>>
}>> The ability to solve the halting problem. Hey, I wouldn't mind seeing an
}>> IF language that could do that.:)
}>>
}>
}>The "halting problem"?
}
}Yeah, an interesting thing that Turing observed: it's not possible to write
}a program that will tell you whether or not another program will ever halt
}or not. That is, it's impossible to write an infinite-loop detector.
}
}The proof is by reductio ad absurdum: assume that such a program exists.
}What happens when you run the program on itself?
It would return "yes". The contradiction requires that another
program be created:
perverse(program)
{
if (program-halts(program)) then while(1); else return;
}
Now run perverse with itself as input. That creates a contradiction,
so there must be no such program as "program-halts".
--
Gunther Schmidl
>> separate, so
>> that it can be altered without altering the code.
>
It's also particularly useful for hacking out the whole game text even
easier than is possible now.
--
+------------------------+----------------------------------------------+
| Gunther Schmidl | "I couldn't help it. I can resist everything |
| Ferd.-Markl-Str. 39/16 | except temptation" -- Oscar Wilde |
| A-4040 LINZ +----------------------------------------------+
| Tel: 0732 25 28 57 | http://gschmidl.home.ml.org - new & improved |
+------------------------+---+------------------------------------------+
| sothoth (at) usa (dot) net | please remove the "xxx." before replying |
+----------------------------+------------------------------------------+
Alan Conroy
>All the IF languages I've seen insist on the text being in the code.
>Understandably. But perhaps not ideally.
Adventure Builder is one authoring system which does keep the text and
the source code separate. Not that you are prevented from mixing in
the text with the code, but it is considered poor programming practice
to do so. This is one of those situations where the feature can be
considered beneficial or not, depending upon your perspective.
Incidentally, the original reason for this was that I had based the
first version of Adventure Builder off of the Adventure and Dungeon
approach, having had the FORTRAN code and data files for both.
However, I later decided to keep it that way because I wanted to be
able to write BIG games, and being able to easily separate out the
declarative and procedural aspects made it easier for a team to work
on a large project. That's also why you can compile multiple object
modules and link them later (though you are not requried to do so).
This approach is also taken by Windows: Theoretically your string
text, bitmaps, menu structures, etc are done in a resource file,
separate from your code. At link time they are bound together into a
single EXE file.
Anyway, I think that this approach is better, overall, then mixing
stuff together like Inform. My apologies to all of you "Informers"
out there, but I cringe every time I see samples of this posted here.
Of course, you could make everyone happy by allowing it to be done
either way.
- Alan Conroy
The views expressed in this post are mine and not necessarily those of my spouse, employer, government, or God.
But then again...
Darin Johnson
> The proof is by reductio ad absurdum: assume that such a program exists.
> What happens when you run the program on itself?
Ah, I remember the proof now. You posit a new program (aka machine),
and call it "H". Its input is a program "P". H does something like:
if (P halts) then
while true advance tape head;
else
halt;
Then you feed H to itself and see what happens!
Since it's absurd to assume that you can tell if H(H) halts or
not, such an algorithm must not exist.
I can't believe undergrads hated this stuff so much.
--
Darin Johnson
da...@usa.net.delete_me
Jonadab the Unsightly One
> }The proof is by reductio ad absurdum: assume that such a program exists.
> }What happens when you run the program on itself?
>
> It would return "yes". The contradiction requires that another
> program be created:
>
> perverse(program)
> {
> if (program-halts(program)) then while(1); else return;
> }
>
> Now run perverse with itself as input. That creates a contradiction,
> so there must be no such program as "program-halts".
Not so. perverse with null input will not terminate (since a null
routine will terminate). Therefore, perverse with itself as input
will pass itself to program-halts as a parameter and program-halts,
lacking a second parameter, could (if it existed -- which it doesn't, but
that's separate from this line of reasoning) correctly determine that with
no input perverse doesn't terminate (how it determines this is the problem)
and therefore return false. The else statement will then bring about a
return. The input to any given function may have a *lot* to do with
whether it terminates or not. (Of course, a well-behaved function will
always terminate, IMO.)
> "Extremism in defense of liberty is no vice, and moderation in pursuit
> of justice is no virtue."
I can agree with the second half of that.
Jonadab the Unsightly One
> Adventure Builder is one authoring system which does keep the text and
> the source code separate. Not that you are prevented from mixing in
> the text with the code, but it is considered poor programming practice
> to do so. This is one of those situations where the feature can be
> considered beneficial or not, depending upon your perspective.
That last sentence is critical. It probably prevented a flame war.
[...]
> This approach is also taken by Windows: Theoretically your string
> text, bitmaps, menu structures, etc are done in a resource file,
> separate from your code. At link time they are bound together into a
> single EXE file.
Except for the VBX files, DLL files, etc, ad nauseam, which are spread
(often) all over the system, making a horrid mess -- but that's Windows for
you. A horrid mess, particularly in terms of directory structure.
I've tried to use two languages that forced the code to be split up
into separate pieces, though neither went so far as to force the
text to be separate. The two were VB and Lingo, and I don't (and won't
likely ever) care for either. In fact, I've firmly decided after the
latter experience not to make myself learn any more languages that
force splitting the code into itty bitty bits. To me, that's as bad
as writing a BASIC program with a goto every fourth line that jumps
all around. You have to crossreference everything mentally in order to
read it. It just doesn't flow. I call it spagetti. I realise it's not
quite the same just separating the text out, since you only get two
pieces, but the two are so interwoven (the text and the code, I mean) that
I think it's a step in that direction. In fact, even the
L__M(##Verb, number) in Inform bothers me. I have to go looking to find
the message. Or, in reverse, if I'm looking to see where the message is
printed, I have to look in L__M first and then go looking for where it's
called. It's totally necessary to allow the library messages to be cleanly
overridden, but it bothers me nonetheless. I don't think I could
effectively use a system that forced *all* the text to be separate from
where it's printed. I'd go nuts.
> Anyway, I think that this approach is better, overall, then mixing
> stuff together like Inform. My apologies to all of you "Informers"
> out there, but I cringe every time I see samples of this posted here.
Inform code used to bother me because of the strange punctuation. Now
I can't figure out what's so strange about it. :-) Inform is the second
computer language in which I've progressed to the point that I can think
in it and write in it, instead of thinking in another language and
translating. (The other was the first computer language I learned,
and until Inform I always thought in *that* while programming anything
complex, and then translated. This may be why I had trouble with C,
since C is totally unlike that language, which I may as well admit
was BASIC.) Now I think in Inform when programming in another language,
and translate as I go. I've even caught myself thinking in Inform about
non-computer-related things and translating into English, which is just a
little bit scary.
> Of course, you could make everyone happy by allowing it to be done
> either way.
Or you could make everyone mad by allowing it to be done either way. I'm
not sure which would happen. Probably some of both. People would
definitely get mad when forced to read code from someone of the opposite
persuasion, but I'm not sure how often that would happen in practice,
except with short snippets on raif when something's wrong.
Jonadab the Unsightly One
Darin Johnson wrote
> Ah, I remember the proof now. You posit a new program (aka machine),
> and call it "H". Its input is a program "P". H does something like:
> if (P halts) then
> while true advance tape head;
> else
> halt;
>
> Then you feed H to itself and see what happens!
But, since H requires a function P as input, and that function P must not
require such (since, given the definition of H, none is given), then you
cannot (under that definition) pass H to itself, unless there's some
way to assume a null input function.
Andrew Plotkin
> Darin Johnson wrote
> > Ah, I remember the proof now. You posit a new program (aka machine),
> > and call it "H". Its input is a program "P". H does something like:
> > if (P halts) then
> > while true advance tape head;
> > else
> > halt;
> >
> > Then you feed H to itself and see what happens!
> But, since H requires a function P as input, and that function P must not
> require such (since, given the definition of H, none is given), then you
> cannot (under that definition) pass H to itself, unless there's some
> way to assume a null input function.
Erm, no. The test "halts" is not "does P() halt?", but "does P(x) halt for
every x?" So P *does* take an input; in fact the entire class of functions
we're discussing here are the functions that take one input, and return a
boolean.
(The type of the input is not important, as long as it can be coded as an
integer. In fact, it might as well be a string. When we say to call H(P),
where P is another function, we just write P's source code in ASCII, and
feed that string into H.) (Integers work equally well -- a string is just
an arbitrary-sized integer anyhow.) (It doesn't have to be *source* code
either -- it could be compiled binary code -- doesn't matter. They're all
computer languages of one sort or another.)
Here's a more precise statement of the Halting Problem:
Posit a function Halts, whose input is a function and whose output is a
boolean, which accomplishes:
Halts(F) returns true if F(x) halts for all x
false if F(x) loops infinitely for any x
Posit further that Halts(x) halts for all inputs x.
(We want a function which determines whether other functions halt, and
does so without itself getting stuck.) Is this possible?
Following is a (somewhat drawn-out) proof that it's not possible.
(Shortest one I could come up with -- sorry. :-)
------------
Say such a function Halts() exists, and halts for all inputs x.
Now write a function Paradox():
Paradox(F):
let J be the function:
"J(x): if F(x) then return true, else loop forever";
if Halts(J) then
return false;
else
return true;
Remember, we're representing functions as long ASCII strings, so building
J is trivial -- just a couple of string concatenations onto the beginning
and end of the string F.
The first thing to note is that this function Paradox() always halts.
This is because it only calls strcat() and Halts(), and neither of those
functions can loop forever. Certainly the functions F and J might
sometimes loop forever, but Paradox(F) doesn't actually *call* F or J; it
only manipulates their text and passes them to other functions. So don't
go giving me guff about "what it Paradox(x) gets stuck." :-)
Now we call Paradox(Paradox). What does this do? First it constructs J,
which is
J(x):
if Paradox(x) then
return true;
else
loop forever;
Then it tests whether J halts for all inputs x. Does it?
Assume J halts for all inputs. Then in particular, J(Paradox) halts. How
can this be? By the definition of J, it's only possible if
Paradox(Paradox) returns true. But by the definition of Paradox, *that's*
only possible if Halts(J) returns false. And we just assumed that J halts
for all inputs.
Assume J loops forever for some input x. By the definition of J, this is
only possible if Paradox(x) returns false. But *that's* only possible if
Halts(J) returns true. And we just assumed that J does not halt for at
least one input.
So whatever J does, we have a contradiction. Therefore our original
assumption -- that Halts() is possible -- is proved false. Whenever you
try to write such a function, either it will give the wrong answer for
at least one input, or it will loop forever for at least one input.
End proof. Whew. (This post took me *way* too long to write, and I had to
dig up my copy of Hopcroft & Ullman from that CTY class... I'm so
embarrassed.)
okbl...@usa.net
tba...@ibm.net (Trevor Barrie) wrote:
>
> It's a CS thing. Bear with me if you already knew any of this:
Explanation appreciatd. (Thanks to others who responded, too.)
Sort of like the classic "proving a program is correct".
okbl...@usa.net
Yep. It's also useful for moving from a static, constant format to something a
little more sophisticated. Sometimes programmers use in-program text as a Q&D
solution for some problem (say, printing out error messages) and then
ultimately find themselves requiring something a little more sophisticated. If
the text is kept logically separate from the code (regardless of whether the
text is actually stuffed into the code by the program during compile) then the
means of integrating that text into the program can go from "stuff it into the
code" (for speed and simplicity) or "fetch it from this database".
okbl...@usa.net
russ...@wanda.pond.com (Matthew T. Russotto) wrote:
>
> Yeah, there's reasons it's nice to have all the text separate. But
> that's not nice to programmers at all. It makes code hard to write
> and hard to understand -- take a look at the Fortran ADVENT or DUNGEON
> source for examples.
Just because the principle has been applied badly in the past does not mean
that the principle itself is flawed.
Besides, I don't WANNA look at the Fortan ADVENT. I did that ONCE, because I
couldn't figure out how to get the emerald, and that was enough. :-)
okbl...@usa.net
al...@accessone.com (Alan Conroy) wrote:
>
> Adventure Builder is one authoring system which does keep the text and
> the source code separate. Not that you are prevented from mixing in
> the text with the code, but it is considered poor programming practice
> to do so. This is one of those situations where the feature can be
> considered beneficial or not, depending upon your perspective.
>
Interesting! It's refreshing to see something that isn't based on a "C-like"
sytnax, actually. I'd like to give this a closer look, but so far I'm
finding the various files and such confusing. I haven't figured out how to
run a game, etc.
okbl...@usa.net
"Gunther Schmidl" <sot...@xxx.usa.net> wrote:
>
> It's also particularly useful for hacking out the whole game text even
> easier than is possible now.
On the contrary, it becomes very easy to encrypt the file, and to change the
encryption on the file (so that any game could use any kind of encryption
scheme it wanted, regardless of the fact that it was built using a particular
tool).
How do TADS and Inform encrypt texts? (Do they at all?) I can't even imagine
how an author could begin to encrypt them without help from the compiler.
Matthew T. Russotto
Jonadab the Unsightly One <jon...@zerospam.com> wrote:
}Matthew T. Russotto wrote
}
}> }The proof is by reductio ad absurdum: assume that such a program exists.
}> }What happens when you run the program on itself?
}>
}> It would return "yes". The contradiction requires that another
}> program be created:
}>
}> perverse(program)
}> {
}> if (program-halts(program)) then while(1); else return;
}> }
}>
}> Now run perverse with itself as input. That creates a contradiction,
}> so there must be no such program as "program-halts".
}
}Not so. perverse with null input will not terminate (since a null
}routine will terminate). Therefore, perverse with itself as input
OK, make it
perverse(program, input) and
program-halts(program, input),
and pass perverse(perverse, perverse).
(which is what I wanted in the first place, and what everyone else
understood -- hey, have you passed a Turing Test lately?)
}> "Extremism in defense of liberty is no vice, and moderation in pursuit
}> of justice is no virtue."
}
}I can agree with the second half of that.
You prefer extremism in pursuit of justice to extremism in defense of
liberty, then?
--
Matthew T. Russotto russ...@pond.com
Andrew Plotkin
> In article <eaAp1.1271$pc.13...@newsread.com>,
> russ...@wanda.pond.com (Matthew T. Russotto) wrote:
> >
> > Yeah, there's reasons it's nice to have all the text separate. But
> > that's not nice to programmers at all. It makes code hard to write
> > and hard to understand -- take a look at the Fortran ADVENT or DUNGEON
> > source for examples.
> Just because the principle has been applied badly in the past does not mean
> that the principle itself is flawed.
Hm. One of the underpinnings of the Inform approach is that an "action"
(in the general sense of "something happens") can be a string or a piece
of code. These are logically completely equivalent; you can always replace
string (in that context) with a piece of code that generates a string.
For example, an object can have a description property such as "It's a
tall blue box". If you later add a light on top which can be either on or
off, you change this (in place) to
[ print "It's a tall blue box";
if (self.lit_up) print " with a flashing light on top.";
else print " with a dull bulb on top.";
];
(Ignoring the Inform mess with newlines, rtrue, and string-statements --
which is intended to make this easier, and probably does once you learn
it, but probably isn't the absolutely ideal approach. :-)
I like this -- in IF programming -- because it allows you to start with
simple behavior, and extend it later. A thing-that-happens is a small,
self-contained object, and you can change it from a static message to
arbitrarily complex behavior without going outside that context.
If you want to separate code and text, how do you get the same
interchangeability of static and dynamic? If you see what I mean.
Jonadab the Unsightly One
> Erm, no. The test "halts" is not "does P() halt?", but "does P(x)
> halt for every x?"
Oh, that's altogether different.
So, then, *is* it possible to construct a function that safely
(in finite time) determines whether any (finite length)
function halts for any particular possible input?
Yr. Obd't & Humble Servant,
Jonadab the Unsightly One.
----------------
One of the many uses for peanut butter:
32. If you have pimples spread it on your face overnight
as an acne treatment to clear up the complexion.
Andrew Plotkin
> > Erm, no. The test "halts" is not "does P() halt?", but "does P(x)
> > halt for every x?"
> Oh, that's altogether different.
> So, then, *is* it possible to construct a function that safely
> (in finite time) determines whether any (finite length)
> function halts for any particular possible input?
No, that's not possible either.
(You're really asking whether you can construct a halting tester for
functions of *no* arguments, as opposed to one for functions of *one*
argument, which was what I described in my previous post. Obviously a
function F(x) and a particular input A makes a no-argument function
defined as "F(A)".)
Unfortunately my head hurts from this morning, and the proof eludes
me. :)
Lemme get some evil microwave popcorn and think about it...
TenthStone
I don't know exactly why, but what the heck.
Later on in writing this reply, I decided that I'd go ahead and post the
same thing to USENET. So you'll be the first to read my reply, by about
half an hour or so.
Lelah Conrad wrote:
>
> On Thu, 09 Jul 1998 16:12:44 -0400, TenthStone <mcc...@erols.com>
> wrote:
>
> >(Some code deleted)
> >
> >This is not difficult programming. It's just a simple consideration of
> >nearly all possibilities (the computer parts could be disconnected),
>
> At the risk of making a bunch of people really mad (oh what the heck,
> this is usenet, right? :), I am going to point out that this example
> above is, to me, why syntax is a serious problem. The above does not
> look like writing, to a writer, even though, in fact, it is writing.
Ah, so your complaint is that programming is not viewer-intuitive enough,
right? Fair enough. I suppose someone could write a more heavily parsed
language, but expansion of it would still require something only distantly
resembling code. For example,
("code" begin)
Define an object "button":
Call this button "power button", and describe it as "The button is on the
front panel of the computer, and gives no clues as to whether the computer
is on or off." Affix this button to the computer.
If the button is pushed or pressed:
If the computer is on, then turn off the computer.
If the computer is off and the power cord is plugged in:
Turn on the computer.
Check if there is a disk in the disk drive. If so, run the program
on that disk; otherwise:
Run the program on any hard disk present inside the computer. If
there is no hard disk there, notify the player "Invalid System or No
Disk Present".
Define the regular transitive verb "to turn off":
Set the "on" property of the direct object to "false".
Define the regular transitive verb "to turn on":
Set the "on" property of the direct object to "true".
(code end)
This is really the closest thing to a pure-written language I can come
up with. All this means is that the "coded symbols" are different, and
that the compiler has more work cut out for it.
The big problems are thus: How does one form an equivalent of a pause
in speech? (I used identation) How does one handle things that don't
mean anything to a computer (i.e. "to turn off"? (I had the resort to the
non-intuitive use of properties) How does one handle conjugation?
(in this case, both defined verbs happened to be regular, which just means
that somewhere some library has to tell the compiler that a "regular"
verb suffixes an "s" in the 1st-person singular, an "ing" in the present
participle, and an "ed" in the simple past and the past participle.)
Furthermore, this code is far bulkier than TADS.
> You have written out a series of coded symbols, somewhat in
> mathematical format, to get a computer to do what you want it to do.
> I wrote my *original* proposal in response to an argument with someone
> about syntax, and it was written in response to the question, well,
> how would you like it to *look*? In the introduction to my proposal,
> when I wrote that the user would not need to learn "programming", I
> was referring to the above sort of abstracted mathematics-looking
> programming.
I know what you mean (although I missed that post -- damn vacation), but
the simple truth is that even this "mathematics-looking" programming
eases the task enormously (I don't miss memory allocation one whit)
and that most things that we consider obvious mean absolutely nothing to
a computer.
> However, it should go without saying that even what I
> tried to write is a form of "programming", i.e. instruction giving) --
> I was rather more concerned that the process of the programming
> involve more words and fewer math-style symbols, so that the user
> would not have to constantly endure the kind of translation-stress
> that such symbols like the piece above cause some of us.
Do you think my second attempt really helped that much? Remember that
that's still not much of the game. Code files for this language would
be enormous -- and enormously complex. I think that even if such a
language were perfectly implemented, most people would immediately
complain about the amount of typing it entailed. Heck, I know I would.
> I think maybe there is some sort of difference between those who have
> a high tolerance for extreme abstraction (or reduction to the smallest
> symbolic component) and those who maybe might like things to remain
> closer to the ordinary English language domain
Yes, in fact there is. Jungian theory entails just such a dichotomy
(although nothing is quite that concrete in Jung), between those
that conceptualise and those who anchor in facts (not a perfect
description, but it works for one line). The Briggs sisters knew
this as "Sensation vs. Intuition".
> *****even if the English language domain that it remains in is
> highly structured, and is not really true, ambiguous, messy,
> Turing-equivalent English*****.
Trust me, that's how it would be.
> Please note that last comment, because I think that my point has been
> mistaken, even possibly by David Cornelson here. As I have said in
> earlier posts about syntax and logic, I think I can think step by step
> and logically -- I just have a harder time than you do in looking at
> all those symbols and keeping them straight.
I certainly can't hold that against you.
> (One reason I'm off learning ALAN now, btw. )
Have fun.
-- Tenthstone
-- TenthStone
tenth...@hotmail.com mcc...@erols.com a987...@titan.vcu.edu
Matthew T. Russotto
}In article <eaAp1.1271$pc.13...@newsread.com>,
} russ...@wanda.pond.com (Matthew T. Russotto) wrote:
}>
}> Yeah, there's reasons it's nice to have all the text separate. But
}> that's not nice to programmers at all. It makes code hard to write
}> and hard to understand -- take a look at the Fortran ADVENT or DUNGEON
}> source for examples.
}
}Just because the principle has been applied badly in the past does not mean
}that the principle itself is flawed.
The principle wasn't applied badly there. Granted, the various
calculated GOTOs don't make things any easier, but that's a separate
problem from not being able to figure out which code prints what
message.
Darin Johnson
> So, then, *is* it possible to construct a function that safely
> (in finite time) determines whether any (finite length)
> function halts for any particular possible input?
It is undecidable (ie, not computable) whether a TM halts on a given
input. It's also undecidable whether a TM halts on any input
whatever.
The wording is somewhat vague, so let me clarify. To be computable, a
function must halt on *every* possible input (that is, it must
actually compute the answer for all inputs). There are three
functions here, none of which are computable:
Halt1(TM) - computes whether TM halts on all inputs (the classic
halting problem).
Halt2(TM) - computes whether TM halts on at least one input.
Halt3(TM,x) - computes whether TM halts on input x.
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
> How do TADS and Inform encrypt texts? (Do they at all?) I can't even imagine
> how an author could begin to encrypt them without help from the compiler.
"Encrypt" is probably the wrong word. They compress the text.
The end result is something that can't be easily read by players,
so it's possible to consider it encryption as well. The Fortran
Dungeon encrypts text, since it does so merely to make them
unreadable without saving any space.
The methods are somewhat convoluted. The Z-Machine is easiest to
understand, because it's been described in English already (see some
docs on Z-Machine format for details). TADS hasn't been described
that way, so you have to decipher the code (which I haven't yet done).
--
Darin Johnson
da...@usa.net.delete_me
Matthew T. Russotto
Darin Johnson <da...@usa.net.removethis> wrote:
}okbl...@usa.net writes:
}
}> How do TADS and Inform encrypt texts? (Do they at all?) I can't even imagine
}> how an author could begin to encrypt them without help from the compiler.
}
}"Encrypt" is probably the wrong word. They compress the text.
TADS does not compress the text, it merely encrypts it.
TenthStone
> Collaboration (particularly over the Internet) in comics or IF
> has produced results that tend to diverge horribly from the initial
> idea, in my experience. Negotiation suffers over the Internet
> particularly, because you can't give your conspirators a good, hard
> look when they throw a fishbowl into the game, or when they say
> "..and I'd like 10 pages of the guy walking in the desert."
Hey, I liked King's Quest V. Sure, the desert may have gotten annoying after
awhile, but I thought it was a good puzzle notwithstanding.
(Tenth, he may no know what you're talking about. It's probably coincidence)
Oh.
Jonadab the Unsightly One
> (which is what I wanted in the first place, and what everyone else
> understood -- hey, have you passed a Turing Test lately?)
My college roommate told my I was half human, half vulcan, and half
integrated circuit. Sorry. I have a tendency to take everything literally
whenever possible.
> }> "Extremism in defense of liberty is no vice, and moderation in pursuit
> }> of justice is no virtue."
> }
> }I can agree with the second half of that.
>
> You prefer extremism in pursuit of justice to extremism in defense of
> liberty, then?
*sigh*. I already almost started a flamewar by saying I don't believe in
human rights as such. Do I also have to say I don't think too much
liberty is a good thing?
Jonadab the Unsightly One
>
> How do TADS and Inform encrypt texts?
Don't know about TADS, but I assume it does. I don't think AGT does,
but I'm not sure.
The z-machine (and therefore Inform) stores text in a semi-compressed
format. It's a bit complicated (for gory details, see Specifications of
the Z-Machine), but it amounts to storing (IIRC) four characters in three
bytes (except for characters outside the standard alphabet, which take
more). So it's quite encrypted, but anyone who knows the scheme can write
a program that drags it out.
> (Do they at all?) I can't even imagine
> how an author could begin to encrypt them without help from the compiler.
Well, if all the text were separate you could just XOR it with some
constant. Quite easy, actually. I've done that with the high-score board
files in QTetris (which is rather silly since the source code is totally
visible to the user, but I did it for hack value).
If you are especially interested, the source for QTetris is available from
this page:
http://www.bright.net/~jonadab/software.htm#Tetris
There are other ways to encrypt, too. Huffman trees work pretty well, and
they have a side effect of (sometimes greatly) reducing the storage space.
Difficulty, of course, depends on your language and system. I wouldn't
want to have to do it in Inform, much as I like Inform. Fortunately, it's
built in.
Jonadab the Unsightly One
Andrew Plotkin demonstrates brilliance again:
>
> Hm. One of the underpinnings of the Inform approach is that an "action"
> (in the general sense of "something happens") can be a string or a piece
> of code. These are logically completely equivalent; you can always
> replace
> string (in that context) with a piece of code that generates a string.
>
> For example, an object can have a description property such as "It's a
> tall blue box". If you later add a light on top which can be either on or
> off, you change this (in place) to
>
> [ print "It's a tall blue box";
> if (self.lit_up) print " with a flashing light on top.";
> else print " with a dull bulb on top.";
> ];
Of course, *much* more complex examples are possible. My project
(Diary ...) contains an NPC with a short_name routine which alternately
(mostly randomly, but some game state goes into this, too) calls
him any of the following:
an old man
the old man
the grandfatherly old man
the ancient gentleman
the forgetful gent
the old gent
the ancient gent
the kindly old man
[and quite a few more...]
It works piecemeal. First it prints the appropriate article (which is part
of the short name because he's proper (for other reasons, and also because
I wanted to handle the article myself)). Then it checks the game's state
to see if any special adjectives (e.g. "kindly") are in order, then (if
not) it picks at random whether to use a random adjective (from a list).
Finally it decides whether to call him "gent", and if so whether to stop
there or to append "le", and if it gets to the end it calls him "man".
When you start doing that sort of thing in any language that splits the
text off separate, you're going to have a very serious mess, unless there's
something major I'm missing.
> (Ignoring the Inform mess with newlines, rtrue, and string-statements --
> which is intended to make this easier, and probably does once you learn
> it,
Yes. Once you know the difference between
{ "Text"; } and { Print "Text^"; } and
{ Print "Text"; rtrue; } and { Print "Text"; }
in your sleep, (since the first and last are by far
the most common), it is a *very* easy system to
use. I'll concede it has a learning curve and
should probably be addressed sooner in the DM
(like before any of those forms are actually used,
perhaps? My $.02).
> but probably isn't the absolutely ideal approach. :-)
The absolutely ideal approach is to have the computer read
my mind. I expect that won't happen soon.
> I like this -- in IF programming -- because it allows you to start with
> simple behavior, and extend it later.
Which is perfect for the "pile of hacks" that IF is.
Andrew Plotkin
Ok, the proof for "halts with a given argument":
Posit a function Halts, whose input is a function and a generic argument,
which accomplishes:
Halts(F, a) returns true if F(a) halts
false if F(a) loops infinitely
Say such a function Halts() exists, and halts for all inputs x.
Now write a function Paradox():
Paradox(F):
let J be the function:
"J(x): if F(x) then return true, else loop forever";
if Halts(J, Paradox) then
return false;
else
return true;
The rest of the proof goes through pretty much unchanged.
Gunther Schmidl
>> (in finite time) determines whether any (finite length)
>> function halts for any particular possible input?
>
It is possible if you introduce the concept of oracle turing machines (OTM).
Then you'll see that the halting problem is one of the simpler
"undecideable" (for lack of the correct word) problems out there - it's
actually solveable with just one OTM. Now, things like the the Emptiness
Problem, the PCP, ... :-)
--
+------------------------+----------------------------------------------+
| Gunther Schmidl | "I couldn't help it. I can resist everything |
| Ferd.-Markl-Str. 39/16 | except temptation" -- Oscar Wilde |
| A-4040 LINZ +----------------------------------------------+
| Tel: 0732 25 28 57 | http://gschmidl.home.ml.org - new & improved |
+------------------------+---+------------------------------------------+
| sothoth (at) usa (dot) net | please remove the "xxx." before replying |
+----------------------------+------------------------------------------+
Neil K.
> okbl...@usa.net writes:
>
> > How do TADS and Inform encrypt texts? (Do they at all?) I can't even
imagine
> > how an author could begin to encrypt them without help from the compiler.
>
> "Encrypt" is probably the wrong word. They compress the text.
For what it's worth, TADS doesn't compress text at all, although later
versions store the game file in a format that compresses well with
standard compression tools. From the source:
Name
fioxor.c - file i/o encryption (XOR) routine
Function
Encrypts/decrypts a block of memory using a simple function that
generates a stream of pseudo-random characters and xors them with
a data block. Used to hide the data within a game object. This
is a terribly insecure code, intended only to slow down would-be
prying eyes. Fortunately, it isn't obvious what the plaintext is,
so the simplicity of the encryption algorithm should be offset
somewhat by the obscurity of the unencrypted data.
- Neil K.
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
L. Ross Raszewski
erky...@netcom.com (Andrew Plotkin) wrote:
> okbl...@usa.net wrote:
> > In article <eaAp1.1271$pc.13...@newsread.com>,
> > russ...@wanda.pond.com (Matthew T. Russotto) wrote:
> > >
> > > Yeah, there's reasons it's nice to have all the text separate. But
> > > that's not nice to programmers at all. It makes code hard to write
> > > and hard to understand -- take a look at the Fortran ADVENT or DUNGEON
> > > source for examples.
>
> > Just because the principle has been applied badly in the past does not mean
> > that the principle itself is flawed.
>
> (in the general sense of "something happens") can be a string or a piece
> of code. These are logically completely equivalent; you can always replace
> string (in that context) with a piece of code that generates a string.
>
> For example, an object can have a description property such as "It's a
> tall blue box". If you later add a light on top which can be either on or
> off, you change this (in place) to
>
> [ print "It's a tall blue box";
> if (self.lit_up) print " with a flashing light on top.";
> else print " with a dull bulb on top.";
> ];
>
> which is intended to make this easier, and probably does once you learn
>
> I like this -- in IF programming -- because it allows you to start with
> self-contained object, and you can change it from a static message to
> arbitrarily complex behavior without going outside that context.
>
> If you want to separate code and text, how do you get the same
> interchangeability of static and dynamic? If you see what I mean.
>
> --Z
>
Well, I've found that these days I'm doign a lot of separating hte code out
to a separate file -- not because it makes programming "easier" or "better",
(it doesn't) but because I need the space. It's really fairly trivial, in
inform, to interchange a string and a routine even if the string is defined
elsewhere:
file: Text.psy
Constant TARDIS_TX "It's a tall blue box.";
file: Tardis.psy !version 1
...
description TARDIS_TX;
!version 2
description [; print (string) TARDIS_TX; if (self has light) print "A light on
top is flashing.";];
In and of itself, I would never do this, but if, say, I had several objects
which produced the same text, but which were otherwise too dissimilar to
benefit from class inhertitance, I would probably define the repeated text as
a string constant. (Ways to save a couple of K when writing a really long
game would be a good and worthwhile thread for someone to start up here.)
Andrew Plotkin
> >> So, then, *is* it possible to construct a function that safely
> >> (in finite time) determines whether any (finite length)
> >> function halts for any particular possible input?
> >
> >No, that's not possible either.
> It is possible if you introduce the concept of oracle turing machines (OTM).
As I recall, that's the approach where you say "assume you have a magic
oracle in a black box, which can answer halting questions correctly, and
it's hooked up to the serial port..." Right?