IF is as easy to program as it will ever get.
Erik Hetzner
IF is as easy to program now as it will ever be, or:
The Need for Technical Competence in IF Implementing
[a short treatise on IF tools]
As of late I have noticed the complaints of people who feel that they
have the right to be able to write interactive fiction without the
technical competence necessary to implement it, and that /we/, as
implementors, are at fault for not providing them with good enough
tools them to use, magic tools that would understand what they want to
write plain English and create a game from this description.
It is almost as if an interested young photographer told his teacher,
`I know what I want the pictures to look like, and I want a camera
that will allow me to take pictures just how I want them, by reading
my thoughts. I don't want to have to deal with all of this shutter
speed, film speed, f-stop stuff.'
As we all know, of course, this camera pretty much exists. An
autofocus camera, it costs little and takes decent snapshots. No
professional photographer would use one for an important shot. These
cameras take mostly the right pictures, but one is never sure, and one
doesn't have the precision control a more complicated manual camera
has.
The comparison is, I think, apt. We have some tools that resemble an
autofocus camera, which are capable of producing rather simple games.
They may not be as ubiquitous as an autofocus camera, because there is
little demand for people to create quick and dirty interactive
fitction to record moments of their life, as people do with cameras.
Creating a decent work of if is a time-consuming, engrossing,
/professional/ task. It requires a certain amount of techinal
competence for the same reason feature length movies are not shot on
cheap camcorders: by using more professional and complicated tools,
better works are created.
Certain things, of course, can be made easier. We don't program in
assembly, because it's easier to use a more high-level language with
an existing library of useful functions and objects. But at a certain
point, simplifing a task takes away an implementors control. And when
you take away too much control, you end up with an inferior product.
The solution is, I believe, obvious. Collaboration. A screenwriter
may not understand the subtelties of operating a camera, but this
doesn't matter. The screenwriter understands how a film looks to the
viewer, and how to create compelling characters. A writer of IF must
understand similar things: he must understand how to create a
compelling story, how to stop progress and allow a player to explore,
what sort of things a player might try, how to describe an area, how
to create a compact map, etc. None of these require technical
competence, just an understanding of narrative and of the medium. An
implementor can take all of these ideas and words and put them
together, using appropriate commands and algorithms. This is an
implementor's job. At present, these two jobs are typically done by
the same person, but it doesn't have to be this way.
But to those who wish to write without technical knowledge I say:
fine. First, understand the medium. If you can't do this, you'll
never write a decent piece of interactive fiction, and you're wasting
your time. If you're not willing to learn how to implement, find an
implementor. There's nothing to be ashamed of here; if you can
provide a decent script, a decent implementor can turn the work into a
work of IF in less time than it will take you learn a new language.
If you wish to learn how to implement, this is fine as well. But be
sure that you learn it well enough to do it competently, because poor
implementation can be as annoying as an unsteady, out-of-focus camera
shot. Implementing is a fun and enjoyable task, but if you're not willing
to put in the time to learn how to do it properly, there's plenty of
others willing to work with you if you have a good idea.
Related links:
The IF Collaborators List
http://homepages.ihug.co.nz/~daleys/ifcollab.html
[Check this out. There are many many programmers, some of whom should
be competent.]
---- Erik Hetzner ---- drunk up all of my money
er...@cafe.berkeley.edu that I borrowed every time
David A. Cornelson
Erik Hetzner <er...@cafe.berkeley.edu> wrote in message
6mpfh1$l75$1...@agate.berkeley.edu...
>
>But to those who wish to write without technical knowledge I say:
>fine. First, understand the medium. If you can't do this, you'll
>never write a decent piece of interactive fiction, and you're wasting
>your time. If you're not willing to learn how to implement, find an
>implementor. There's nothing to be ashamed of here; if you can
>provide a decent script, a decent implementor can turn the work into a
>work of IF in less time than it will take you learn a new language.
Short-sighted. Take, for instance, the autofocus camera. I just happen to
know a professional photographer and he now uses 90% of the time, an
autofocus camera. Why? Because he says he used to 'miss' shots that he saw
and could never get his camera 'set' correctly in time for the shot. He says
that now he gets great shots more often using an autofocus camera. And there
is no deterioration of picture quality.
I disagree with this treatise. There _is_ a way to develop non-programming
tools that help people write interactive fiction. It's just that the
majority of the people that have the ability to do so are biased against it
because they feel comfortable with the way things stand.
I believe in problem-solving. If enough people cry out for a tool, then
someone should stand up and say, "I don't understand this, but I'm going to
try and figure this out for these people."
Whatever. I've given up on this topic and I'm a good enough programmer to
write my own games. But eventually someone will create a tool that helps
writers/non-programmers and all of you naysayers are _still_ going to insist
that it's 'not the same' and that it somehow 'isn't good enough' to create
viable interactive fiction.
Whatever.
Jarb
Lelah Conrad
On 23 Jun 1998 23:59:29 GMT, er...@cafe.berkeley.edu (Erik Hetzner)
wrote:
>As of late I have noticed the complaints of people who feel that they
>have the right to be able to write interactive fiction without the
>technical competence necessary to implement it, and that /we/, as
>implementors, are at fault for not providing them with good enough
>tools them to use, magic tools that would understand what they want to
>write plain English and create a game from this description.
>
This is a misunderstanding on your part on a couple of levels. First
and most important, nobody is asking you or anybody who believes that
it cannot be done to develop these tools. The recurrence of the topic
is more of an indicator of level of interest in it. There are some
people who seem to be interested in working on this or at least
discussing this -- and that's okay.
Second, the continuing development of tools in the professions is of
course not magic at all. For instance, _professional_ photographers
(to use your analogy) of the last century might consider modern
cameras "magic", and yet they are merely better tools, whether they be
complex SLR's or autofocus cameras. Either type would probably
delight our ancient professional daguerrotypist! (Come to think of
it, it's possible that the current state of tools in most professions
would seem like magic to earlier practitioners.)
Third, (you refer to writing IF as being a professional task) I can
only really count 2 "professional" IF writers at this time: Mike
Berlyn and Gerry Kevin Wilson, both of whom will be publishing under
the auspices of Cascade Mountain Publishing in the near future.
Conversely, even if hobbyists in a field don't use the finest
equipment available, the work produced is not necessarily of the
lesser quality your post implies it must be.
Fourth, as to the "right" to write IF without technical competance: I
think the _writing_ is the pre-emininent technical component.
Everything else is susidiary. I don't really care how many
trickily-programmed puzzles a game has in it -- I am more interested
in what a story has to say, how it describes a world, how much I can
relate to the characters, how exciting the plot is, etc.
>... simplifing a task takes away an implementors control. And when
>you take away too much control, you end up with an inferior product.
We are not seeking to simplify the _task_, which is the writing, we
are looking for better tools, tools that will make focusing on the
writing a little easier. This fact is missed over and over again by
the naysayers here. I suspect that better tools in many fields
(computer databases in law, diagnostic and surgical tools in
medicine, sophisticated machine tools in manufacturing, etc.) have
allowed practitioners to have _more_ control over the product, and a
better product to boot. And lest someone retort that these tools must
be understood by the practitioner -- well, think again. That doctor
doesn't know how that laser tool operates, they :) just know that it
does.
>The solution is, I believe, obvious. Collaboration.
Collaboration can be a good thing, if it works for you. However, many
IF writers prefer to maintain artistic control, which to them means
doing the programming also.
Finally, I would like to suggest that perhaps we should develop some
sort of bracketed heading for these discussions, e.g. [Simpler IF] or
[IF Writing Tools] or something, so that people who are tired of
hearing about it can just avoid the topic. This topic really seems to
irritate some people. (As witness also my personal email.) But it
interests _me_. In short, I disagree with the thesis in your subject
line.
Lelah
Jeff Hatch
Erik Hetzner wrote:
> IF is as easy to program now as it will ever be, or:
> The Need for Technical Competence in IF Implementing
>
> [a short treatise on IF tools]
The problem, I think, is that there's no popular system that allows easy
construction of a simple game for the uninitiated and still has a robust
programming language for the experienced. Because of this, neophytes must be
encouraged to immediately venture into the daunting world of compilers and
declarative syntax.
-Rúmil, biased
Eric O'Dell
On Wed, 24 Jun 1998 22:20:08 GMT, l...@nu-world.com (Lelah Conrad)
wrote:
>Fourth, as to the "right" to write IF without technical competance: I
>think the _writing_ is the pre-emininent technical component.
>Everything else is susidiary.
I have to agree with what you say, though probably not with what you
mean. Learning a programming language, especially the relatively easy
special-purpose languages common to the IF arena, is no great
technical task --- there are only a few dozen "words" in most modern
languages, and their syntax can usually be specified in under ten
pages of text. Which is why the complaints against the existing
languages don't win much sympathy from programmers.
It *is* the storytelling that is the difficult part. But in IF, the
storytelling isn't just the prose. The algorithms one builds with the
programming language are also part of the story. In straight prose,
you would have to describe, in English or some other natural language,
the behavior and appearance of the things and actions in the story. In
IF, prose is still used in a descriptive role, but (particularly for
actions and behaviors) the burden of description is carried by the
code.
>We are not seeking to simplify the _task_, which is the writing, we
>are looking for better tools, tools that will make focusing on the
>writing a little easier. This fact is missed over and over again by
>the naysayers here.
On the contrary, we get the point, which is that the writing
_includes_ the programming in IF, just as stage directions are an
integral part of a play, which is probably the form of literature
closest to IF. Coding isn't just some distraction from the art, it is
an integral part of the art.
> And lest someone retort that these tools must
>be understood by the practitioner -- well, think again. That doctor
>doesn't know how that laser tool operates, they :) just know that it
>does.
Poor example. Even a cursory examination of modern medical practices
will reveal that doctors are notoriously prone to maiming and
misdiagnosing their patients with all the newfangled medical gadgetry.
At least some of this is attributable to their equally notorious
disdain for technology and knowledge of their tools. How often do you
see x-ray machines, ultrasound scanners, etc., used by specialized
technicians with minimal medical backgrounds while doctors with actual
medical knowledge leave the room to attend to the "real" work of
medicine? It probably helps their medicine as much as a disdain for
programming helps an IF writer.
--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_ |
+-------------------------------------------------------------------+
Eric O'Dell
>I disagree with this treatise. There _is_ a way to develop non-programming
>tools that help people write interactive fiction. It's just that the
>majority of the people that have the ability to do so are biased against it
>because they feel comfortable with the way things stand.
On the contrary, programmers as a group are characteristically
disinclined to leave things the way they are if there is potential for
improvement. We have programming languages in the first place because
programmers got tired of punching in raw machine code in binary. Text
editors, IDE's, object orientation, and visual programming tools arose
from the same impulse.
The sort of problems under discussion here have been the subject of
academic and commercial research for many decades now, consuming
hundreds of millions of dollars and the time of many of the best and
brightest computer scientists. It isn't apathy on the part of
programmers, it's the difficulty of what is essentially an AI problem,
and it's not unique to IF.
Greg Ewing
David A. Cornelson wrote:
>
> I disagree with this treatise. There _is_ a way to develop non-programming
> tools that help people write interactive fiction. It's just that the
> majority of the people that have the ability to do so are biased against it
> because they feel comfortable with the way things stand.
Various non-programming IF authoring tools have been
built, but in all cases so far have been severely
restricted in the scope of game behaviour they are
capable of creating.
It's not that we think it's impossible for such a
tool to exist, it's just that we don't see how to
build one, and so far nobody has been able to tell
us how.
If you have any ideas in that direction, we'd be very
interested to hear them!
--
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
Thomas Nilsson
Eric O'Dell wrote:
>
> It *is* the storytelling that is the difficult part. But in IF, the
> storytelling isn't just the prose. The algorithms one builds with the
> programming language are also part of the story. In straight prose,
> you would have to describe, in English or some other natural language,
> the behavior and appearance of the things and actions in the story. In
> IF, prose is still used in a descriptive role, but (particularly for
> actions and behaviors) the burden of description is carried by the
> code.
>
How true. It is the difficulty in the writing which prohibits many of us
becoming IF authors. And it is also true that the writing includes the
algorithms etc. and thus could be said to include the programming.
But in my book this is not *all* of the programming that we usually do.
IT does not necessarily mean thta it has to include:
for i=0 to length(list)
if list[i].a > x then
sum = sum + list[i].a
end if
end for
What we should strive for is support for "programming" but on a level
where an *author* can do it:
sum all list.a where a > x
sort list after a.
if exists list.a > x ...
(Note! this is only examples of the level of the support which I think
an author would like, not an actual existing language or suggestion for
one)
I think we all would like to see this level of abstraction for the
things we commonly do. After all what are libraries for. Where these
features readily available in a IF system for common IF programming
chores I suspect we would se more focus on the writing, both the prose
and the programming parts of it.
Thomas
--
"Little languages go a long way..." (ThoNi of SoftLab in 1985)
------------------------------------------------------------------------
Thomas Nilsson Phone Int:(+46)13235704 Nat:013-235704
SoftLab Mobile: 070-5617541
Datalinjen 1, S-583 30 LINKÖPING E-mail: th...@softlab.se
SWEDEN http: www.softlab.se, www.rational.com
Brandon Van Every
Thomas Nilsson wrote in message <35920CEA...@softlab.se>...
>Eric O'Dell wrote:
>>
>> It *is* the storytelling that is the difficult part. But in IF, the
>> storytelling isn't just the prose. The algorithms one builds with the
>> programming language are also part of the story. In straight prose,
>> you would have to describe, in English or some other natural language,
>> the behavior and appearance of the things and actions in the story. In
>> IF, prose is still used in a descriptive role, but (particularly for
>> actions and behaviors) the burden of description is carried by the
>> code.
>>
>
>How true. It is the difficulty in the writing which prohibits many of us
>becoming IF authors. And it is also true that the writing includes the
>algorithms etc. and thus could be said to include the programming.
Well I'm of the school that a multiple choice quiz or Choose Your Own
Adventure book is still Interactive Fiction. Some people just like to make
their storytelling job harder than it has to be.
Cheers,
Brandon Van Every
Thomas Nilsson
Brandon Van Every wrote:
<about IF authoring to include programming>
> Well I'm of the school that a multiple choice quiz or Choose Your Own
> Adventure book is still Interactive Fiction. Some people just like to make
> their storytelling job harder than it has to be.
>
Yes, there is a whole spectrum of IF here, from the simple "select one
of a small number of preprogrammed continuations" to the
"simulationist/tiny-physics" class.
I agree that it doesn't have to be a complete simulation of the universe
to be IF, or even good or excellent IF. Much can be done with simple
means. However, to make a story that somehow is more than a simple
selection you need *some* form of logic and the specification of that
can only be made in two ways:
- a built in mechanism in the authoring system
or
- "programmed"
There are of course no systems which are entirely one or the other
(except possibly for plain general programming languages, which could be
counted into the second class...).
So I am arguing that:
1) You need to be able to specify some logic ("program") to make good
IF
2) The programming facilities of a IF authoring system does not have to
have full "general" power
3) The programming facilities should appeal to authors, not general
programmers, and make the part of their authoring that is
"programming" as simple as possible
/Thomas
David A. Cornelson
Eric O'Dell <eod...@pobox.com> wrote in message 3593abf1.301974976@news...
>On Tue, 23 Jun 1998 23:03:01 -0500, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
>On the contrary, programmers as a group are characteristically
>disinclined to leave things the way they are if there is potential for
>improvement. We have programming languages in the first place because
>programmers got tired of punching in raw machine code in binary. Text
>editors, IDE's, object orientation, and visual programming tools arose
>from the same impulse.
>
>The sort of problems under discussion here have been the subject of
>academic and commercial research for many decades now, consuming
>hundreds of millions of dollars and the time of many of the best and
>brightest computer scientists. It isn't apathy on the part of
>programmers, it's the difficulty of what is essentially an AI problem,
>and it's not unique to IF.
Okay. I'm not suggesting we need the computer to write the code for us. I'm
suggesting, and I believe Lelah Conrad is too, that we need something
'above' the level we currently have for writing IF. Not a new language or
libraries of code, but a tool that simplifies the process of doing the work.
If you've ever used MS-Access, you'll notice it has various ways to get you
to write queries and code. I'm saying that something similar could be
accomplished for an IF language.
I've played with the two little Inform IDE's and one is on the right track
and the other one (the html editor type interface) is way off the track. If
you can break down the language into a relational view, non-programmers can
'view' things as they relate to each other. This, to me, is not only
possible, but for the non-programmer, a truly helpful tool.
Look at IBM's VisualAge for Java. It has removed your need to know where the
files are on your computer as well as created wizards to make graphical
beans out of the java library without writing one single line of code. This
helps people solve the problem of creating a program, without forcing them
to understand the 'mechanics' of Java. You still need to write code at some
point, but it helps you there too by having help at every turn on exactly
how to do so, including line by line syntax checking.
We're not suggesting we need the 'HAL' of IF. We just want VisualAge for
Inform or TADS.
Jarb
MP0werd
The Magic Camera unvieled....
HYPERCARD
It's got automatic focus, precision focusing, 20x lens, what more could you
ask for?
HC is a programming environment, a database environment (databases are great
for adventure programming), a multimedia environment. HC programs are called
stacks. These stacks are divided into cards. The cards can be drawn on, buttons
can be added, text fields can be put here and there, it's like visual basic on
steroids. Each of these objects (Stack, Cards, Fields, Buttons, etc) can be
scripted (programmed) in an easy language called HyperTalk. A twelve year old
could learn hypertalk in a month. There are canned scripts that you can choose
from that play sounds, play quicktime movies, go to different cards, the works.
What you may find amazing however is that
MYST WAS MADE IN HYPERCARD !!!
The Myst stack contained cards for every view that you could see. On those
cards were buttons that link to other cards and activate a visual effect to
make it look like your turning right or left or up or down. The motion such as
buttons being pushed or wheels being spun are actually quicktime movies. So if
MYST and RIVEN are the greatest games, then hypercard must be the greatest
gamemaker.
At present, hypercard does have some lousy limitations...
No built in support for color (although it can be added)
32k limit
Cannot acess toolbox
limited to Macintosh (best computer) platform
Language is emulated (not compiled)
Apple is going to go public with HYPERCARD v3.0 hopefully in a few months.
This program will not only do away with all of the above limitations but it
will introduce a totally new aspect to programs (stacks)...
STACKS WILL BE QUICKTIME MOVIES!
able to be run from any application that is able to run QT movies. Platform is
no longer a problem, interactivity will have been taken to a greater scale,
hypercard will thrive once more!!!
(I do sound like a lunatic for a while there)
I truly love hypercard, and I hope you all will experience authoring stacks. I
tell you, it's much better than C.
_______
/ _ _ \____/ "... And the circle closed."
-/ | | \__ _/ Last line of Contact
| | | | (The book, not the movie)
| | | | 3.141592654
Eric O'Dell
On Thu, 25 Jun 1998 16:36:49 +0200, Thomas Nilsson <th...@softlab.se>
wrote:
>So I am arguing that:
>
>1) You need to be able to specify some logic ("program") to make good IF
Agreed.
>2) The programming facilities of a IF authoring system does not have
> to have full "general" power
This is self-evident, if the existing systems are any indication.
However, as soon as you depart from general-purpose, low-level
programming capabilities, you begin to restrict the possibilities.
Many, perhaps most, programmers will never notice or need general
purpose tools, but others will. There are a lot of things that could
be done with IF that cannot be done --- at least not with acceptable
efficiency --- using TADS/Inform/Hugo/Alan.
>3) The programming facilities should appeal to authors, not general
> programmers, and make the part of their authoring that is
> "programming" as simple as possible
Insofar as it would take programmers to create such a tool, it would
take a pretty compelling reason to motivate one to do so. No one is
presently making any money off of this. (Although it's worth noting
that StoryHarp, which makes a stab in the direction of substantial
ease-of-use, is profit driven.) And speaking only for myself, I am
unconvinced that the current systems are preventing very much *good*
IF from being created. If anything, they present more of a bar to
larger and more complex IF.
Lelah Conrad
>Okay. I'm not suggesting we need the computer to write the code for us. I'm
>suggesting, and I believe Lelah Conrad is too, that we need something
>'above' the level we currently have for writing IF. Not a new language or
>libraries of code, but a tool that simplifies the process of doing the work.
Exactly, Jarb.
In fact, I have sent a proposal along these lines (e.g., "what
we writers would like to see on our screen for us to respond to") to
one of the persons on this list who is both a programmer and who has
objected to my posts, and am waiting a response as to whether it is
even possible. It is an idea for an interface that would sit on top
of say TADS or Inform, the way that Windows actually sits on DOS, but
that makes it easier to interact with. It involves a program that
offers the writer a sequence of yes/no questions, space for entering
text, and an idea about popup menus for places where the writer must
choose e.g. what type or types of an item something is. It also takes
something of the "author as God" approach which has been mentioned
elsewhere -- the game is written as though it is being played, from
the point of view of who you are, what space you're in, what happens
there, etc. and then you write through the branches and the
consequences one by one.
Before you throw tomatoes -- believe me, I know my limitations
as a programmer (er, nonprogrammer!.:) That is why I have referred the
idea to someone who can tell whether it looks like a viable approach.
Also, I am well aware that there is no money in the creation of that
type of tool or any other (unless MAYBE some educational publisher
could be encouraged to use it as part of its writing software
offerings -- because I'm a teacher I see lots of ed software blow by).
Finally, again, I'm not insisting someone here create such a thing.
At this point I'm just wondering whether it is even possible.
Lelah
Maybe I'll post the sample I wrote here later, if there's interest.
Eric O'Dell
>I've played with the two little Inform IDE's and one is on the right track
>and the other one (the html editor type interface) is way off the track. If
>you can break down the language into a relational view, non-programmers can
>'view' things as they relate to each other.
As I've stated previously, I'm fully in agreement with you on the
subject of IDE's and related tools for visualizing software
components. Where we disagree, apparently, is with respect to language
design. IMHO, any further specialization in language constructs and
libraries is going to assist novices only at the expense of being an
enormous, inflexible pain to even slightly more experienced users.
The sole exception to this that I can think of would be a language
with a bi-level syntax --- essentially a general, lower-level language
with a sophisticated higher-level macro language. There is,
unfortunately, not a lot of pre-existing research on the subject, and
the compiler tools necessary to implement really high-level syntax are
relatively new. It'll take time.
>This, to me, is not only
>possible, but for the non-programmer, a truly helpful tool.
This, however, seems to be a pernicious and persistent misconception.
There are no non-programmers producing IF. Even if one starts as a
non-programmer, one must become a programmer to write IF. I'm
beginning to think that the term "interactive fiction" is a poor
choice of words, since it seems to imply that IF is fiction with some
nonessential code tacked on, when it is in fact the code that is its
distinguishing characteristic in comparison to other forms of prose.
Brandon Van Every
MP0werd wrote in message
>
> At present, hypercard does have some lousy limitations...
> No built in support for color (although it can be added)
> 32k limit
> Cannot acess toolbox
> limited to Macintosh (best computer) platform
> Language is emulated (not compiled)
Try Macromedia Director instead. Less disadvantages, more real-world use.
Cheers,
Brandon Van Every
David A. Cornelson
Eric O'Dell <er...@gadgetguru.com> wrote in message
359374bf...@enews.newsguy.com...
>On Thu, 25 Jun 1998 09:45:12 -0500, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
> Where we disagree, apparently, is with respect to language
>design. IMHO, any further specialization in language constructs and
>libraries is going to assist novices only at the expense of being an
>enormous, inflexible pain to even slightly more experienced users.
I never said anything about specialization or new constructs. Inform and
TADS, as far as I'm concerned, are perfect the way they are.
>This, however, seems to be a pernicious and persistent misconception.
>There are no non-programmers producing IF.
Depends on your definition of a programmer. I am a programmer, although I
believe too much is made of programming since it's just a method of giving a
computer instructions. Any language, with the right interpreter (compiler)
could be used to create programs. Of course the right interpreter for
English hasn't appeared quite yet.
My definition of a non-programmer is someone that does not have any reason
in their life to write programs. In the case of IF, they are sort of stuck,
because they like the form of IF, but to get their thoughts into that form,
they need to learn how to write code. It is my suggestion that these sort of
people are completely ignored where development of new technologies and
tools are concerned.
It's my guestimate that there are a couple of thousand RAIF viewers or more.
Only a small handful have spent the time and energy to look for Inform or
TADS and began to struggle with those languages.
Most of these people that love the medium are simply watching from the
sidelines until a method for them to become a part of this process is
invented or discovered.
My theory of course. I could be completely whacked.
To repeat a point to death. Many of us are here because we like to write and
we like the form of IF. At the same time, coding our ideas seems almost
archaic. We believe there should be tools that ask us the right questions or
lay things out in such a way, that we can ignore syntax, constructs,
do-loops, switch statements, classes, etc. and concentrate on our story.
You are correct. There are no non-programmers in the IF world. This is
exactly the problem. Why shouldn't there be a tool that gives the
non-programmer the ability to write IF? I am not convinced that this is an
impossible task.
Jarb
John Francis
In article <35920CEA...@softlab.se>,
Thomas Nilsson <th...@softlab.se> wrote:
>
>What we should strive for is support for "programming" but on a level
>where an *author* can do it:
>
> sum all list.a where a > x
> sort list after a.
> if exists list.a > x ...
(Well, the last one sounds a bit clumsy, but ...)
One really good thing about this is that the statements in the language
have the same sort of 'feel' as commands in a typical IF game.
This means that a non-programmer only has to learn one sort of 'style'.
My fear is that we would end up with something that looked too much
like COBOL :-)
--
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.
Doeadeer3
>From: l...@nu-world.com (Lelah Conrad)
>Date: Thu, Jun 25, 1998 12:53 EDT
>Finally, again, I'm not insisting someone here create such a thing.
>At this point I'm just wondering whether it is even possible.
Yes, it is quite possible to do. A front end that would, say, let one set up
the map (name rooms, pick directions), characters, takeable objects, etc.
I have even thought about doing it. But frankly, it would be a monumental
programming task (for me) and I don't have the time (especially since there is
NO money in it).
And then there is another question -- what platform? A front end would have to
be machine specific. So that would mean we would need versions for different
machines. The beauty of Inform and Tads now is that they are cross-platform.
Also it would still be necessary to do some programming because no front end
could anticipate the various special objects and routines that people would
want to create.
No automating tool I have ever seen (for example, Paradox has a automator)
meets all requirements dictated by the program (game) , so delving into code
will always be necessary.
However, despite all this, I can see the need. Thinking of a good game,
plotting it out, planning puzzles and writing descriptions could all be done by
people who can't program. So non-programmers could write good games, if they
could program or had a decent front end.
Someday someone will probably do it.
Maybe Rumil is doing it now.
:-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Eric O'Dell
What you are suggesting is indeed possible, but it would require the
implementor of the tool to design a fairly inflexible framework to
present to the user, much as if you were restricted to only the
standard library in TADS. Obviously, the "standard library" for such a
tool would be much larger than the ones that come with actual
programming tools, but if you ever came up against the need for an
object that wasn't in the standard library (i.e., that couldn't be
created by simply parameterizing an existing object), you'd have to
change your story to fit the limitations of the tool.
It's been way too damn long since I fiddled with AGT to remember for
sure, but I think it was like that: objects had a more of less fixed
number of properties --- weight, bulk, name, adjective, etc. --- and
that was what you had to work with, period. Of course, AGT did have
some rudimentary programming constructs to work around the inbuilt
limitations, but even then, there was only so much you could do.
The only way I would think such a tool would be worth writing was if
it provided a real, honest-to-goodness programming interface hidden
underneath the component-based top level. One could then use it the
way a lot of (frankly, poor) programmers use Visual Basic, by
constructing programs out of preprogrammed components glued together
with very little original code.
It is worth noting, though, it is often painfully obvious when a
program has been constructed from predesigned components --- a lot of
interface features are only approximate or second-best fits to the
actual problem, and it shows. Or, if the component programmers have
done an exceptionally good job of contingency planning, the interface
looks fine, but the code is bloated and often slow as well.
My interests lie elsewhere, so it won't come from my hand, but the
foregoing is certainly within the technological capabilities of many
programmers. It would, however, not eliminate the necessity of
programming if one wished to go beyond what the original designer
foresaw.
Alan Conroy
On 26 Jun 1998 02:09:08 GMT, doea...@aol.com (Doeadeer3) wrote:
>>From: l...@nu-world.com (Lelah Conrad)
>>Date: Thu, Jun 25, 1998 12:53 EDT
>
>>Finally, again, I'm not insisting someone here create such a thing.
>>At this point I'm just wondering whether it is even possible.
>
>Yes, it is quite possible to do. A front end that would, say, let one set up
>the map (name rooms, pick directions), characters, takeable objects, etc.
Adventure Builder does just this. It actually has two compilers: a
programming language for implementing algorithms and a declarative
language for the things you mention. Under DOS, you just use the one
compiler and ignore the other (ie have a programmer deal with
algorithms). In the IDE, you simply restrict yourself to the
defintions. This easily lends itself to collaboration as both parts
can be developed concurrently by different people.
>And then there is another question -- what platform? A front end would have to
>be machine specific. So that would mean we would need versions for different
>machines. The beauty of Inform and Tads now is that they are cross-platform.
Can't help you there.
- 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
"David A. Cornelson" <dcorn...@placet.com> writes:
> I never said anything about specialization or new constructs. Inform and
> TADS, as far as I'm concerned, are perfect the way they are.
I strongly disagree. There are vast areas of improvement. Both are
too low level in my opinion. However, the improvements I can think of
aren't necessarily those that will attract a nervous novice.
(For instance, it'd be nice to do things like:
foreach item in inventory where item.edible
item->drop;
then it'll be closer. And even that can be lots higher level.)
--
Darin Johnson
da...@usa.net.delete_me
Gunther Schmidl
>(For instance, it'd be nice to do things like:
> foreach item in inventory where item.edible
> item->drop;
>then it'll be closer. And even that can be lots higher level.)
Inform:
objectloop (o in player && o has edible)
move o to location;
(you can also use <<Drop o>>;)
I don't know if something similar exists in TADS, but I'd guess so.
--
+------------------------+----------------------------------------------+
| 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 |
+----------------------------+------------------------------------------+
Simon Tufty Stapleton
al...@accessone.com (Alan Conroy) writes:
> >And then there is another question -- what platform? A front end would have to
> >be machine specific. So that would mean we would need versions for different
> >machines. The beauty of Inform and Tads now is that they are cross-platform.
>
> Can't help you there.
>
Write it in inform. Or TADS.
That is, in fact, only half flippant. I can think of a couple of reasons
why not, but personally don't think they're insurmountable.
Simon
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------
Andrew Plotkin
Gunther Schmidl (sot...@xxx.usa.net) wrote:
> >(For instance, it'd be nice to do things like:
> > foreach item in inventory where item.edible
> > item->drop;
> >then it'll be closer. And even that can be lots higher level.)
> Inform:
> objectloop (o in player && o has edible)
> move o to location;
Oop! This runs into the linked-list complication.
However, I don't think this is representative of Inform. I generally
agree with Gunther's point.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
David A. Cornelson
Eric O'Dell <eod...@pobox.com> wrote in message 3593117b.393518655@news...
>On Thu, 25 Jun 1998 16:08:19 -0500, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
>What you are suggesting is indeed possible, but it would require the
>implementor of the tool to design a fairly inflexible framework to
>present to the user, much as if you were restricted to only the
>standard library in TADS
Why? If you write a front-end to the 'language', then why can't you write a
front-end to the 'extension' of the library?
I agree, by creating the front-end, you lose the ability to open up the
library and make wholesale changes. But in my mind there are only a few
entry points in the Inform libraries that people care about. After that, the
interface that I foresee would allow the user to add classes, objects,
attributes, properties, and globals, but without letting the user know that
that is what they were doing.
I think we're agreeing here, so there is no need to reply.
Heh. Isn't that a postulate? I disagree, therefore I post a reply.
Jarb
Doeadeer3
>nob...@no.bloody.where (Simon "Tufty" Stapleton)
>Date: Fri, Jun 26, 1998 04:14 EDT
>Write it in inform. Or TADS.
>
>That is, in fact, only half flippant. I can think of a couple of reasons
>why not, but personally don't think they're insurmountable
Actually, I suppose that could be possible. Hmmmm. One would have to use a lot
of low level coding (@ read_char, etc.). It would be tough. I was thinking more
of a Windows front end, which would let Mac users (and others) out.
Oh, well, if it is to be done, I leave it to someone else (a better programmer
than I) to do.
:-) Or maybe we will fall in love with Rumil's complier and his supposedly easy
to use front end.
L. Ross Raszewski
In article <6muebr$6...@newsops.execpc.com>,
> exactly the problem. Why shouldn't there be a tool that gives the
> non-programmer the ability to write IF? I am not convinced that this is an
> impossible task.
Because IF _IS_ a programming art. As arrogant as we like to be, and claim
that we are writers, above the lower class programming scum, it cannot be
denied that interactive fiction is a programmign art as much as a
storytelling one. It's akin to wanting to be a painter, but being unwilling
to learn how to use a brush and easel, or wanting to be a writer, but not
wanting to learn the written english language. IF is about programming _EVERY
BIT AS MUCH_ as it is about writing. You CANT write a good IF without
programming, just as you can't take a good photograph without knwoign how to
use a camera. Now, there are tools, things like AGT or storyharp, that can
let you write a game with almost no programming skill, but to write THE KIND
OF IF WE EXPECT, you NEED to program. Writing is only half the art. it is
not, should not be and will not be, all of it. It's what makes IF different
from Static writing, and if we lose that, we've lost IF.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
L. Ross Raszewski
In article <erkyrathE...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:
>
> Gunther Schmidl (sot...@xxx.usa.net) wrote:
> > objectloop (o in player && o has edible)
> > move o to location;
>
> Oop! This runs into the linked-list complication.
>
I don't think it does; the "&& o has edible" should force objectloop to use
the non-optimized form
John Cater
Doeadeer3 <doea...@aol.com> wrote:
:>nob...@no.bloody.where (Simon "Tufty" Stapleton)
:>Date: Fri, Jun 26, 1998 04:14 EDT
:>Write it in inform. Or TADS.
:>
:>That is, in fact, only half flippant. I can think of a couple of reasons
:>why not, but personally don't think they're insurmountable
: Actually, I suppose that could be possible. Hmmmm. One would have to use a lot
: of low level coding (@ read_char, etc.). It would be tough. I was thinking more
My question about writing this system would be, how do you output the code? Since inform doesn't have anything but the @save operator, and I doubt TADS is any better (tell me if I'm wrong, please), how can we generate inform code from within an inform program? Or am I just missing the point here?
katre
Erik Hetzner
Eric O'Dell (eod...@pobox.com) wrote:
: It *is* the storytelling that is the difficult part. But in IF, the
: storytelling isn't just the prose. The algorithms one builds with the
: programming language are also part of the story. In straight prose,
: you would have to describe, in English or some other natural language,
: the behavior and appearance of the things and actions in the story. In
: IF, prose is still used in a descriptive role, but (particularly for
: actions and behaviors) the burden of description is carried by the
: code.
I would argue that the parts of IF are distinct, because of the unique
nature of the medium (or perhaps not so unique). The parts are
(a) the author, and (b) the implementor. The author writes the
work, and must be able to understand the way the medium works.
They are like the author of a screenplay. (There is also
the possibility of the primary author working with another author
who understands the nature of the medium; say a well-respected author,
Gore Vidal, who knows nothing of the medium (I assume), works with,
oh, let's say, me (it's my example and my fantasy :), who understands
the medium (I hope). He does most of the writing, and I explain to him
that this works, this doesn't, you need an item description here, etc).
Now, we have written a work with stage directions, like this:
Now, east of Room x is room y, "You have entered a lovely room. Y?".
The room is filled with poison gas, the player can only see absract
shapes moving about. If the player stays in for 2 turns, he dies.
"You have died." (see note (45), player death).
Or however. Perhaps a standard pseudo-code could evolve. But the
author(s) send this to the implementor, who turns the pseudo-code into
/real/ code. This is what they know, how to make a computer understand
something. Perhaps they also write, it doesn't matter; the point is,
they are able to perform his vital ask.
: On the contrary, we get the point, which is that the writing
: _includes_ the programming in IF, just as stage directions are an
: integral part of a play, which is probably the form of literature
: closest to IF. Coding isn't just some distraction from the art, it is
: an integral part of the art.
See above.
---- Erik Hetzner ---- drunk up all of my money
er...@cafe.berkeley.edu that I borrowed every time
Andrew Plotkin
Erik Hetzner (er...@cafe.berkeley.edu) wrote:
> I would argue that the parts of IF are distinct, because of the unique
> nature of the medium (or perhaps not so unique). The parts are
> (a) the author, and (b) the implementor. The author writes the
> work, and must be able to understand the way the medium works.
> They are like the author of a screenplay. (There is also
> the possibility of the primary author working with another author
> who understands the nature of the medium; say a well-respected author,
> Gore Vidal, who knows nothing of the medium (I assume), works with,
> oh, let's say, me (it's my example and my fantasy :), who understands
> the medium (I hope). He does most of the writing, and I explain to him
> that this works, this doesn't, you need an item description here, etc).
This view seems hopeless idealized to me. Rather along the lines of "Ok,
I'll decide what to paint, and you get the colors on the canvas, and
together we'll make some really moving artwork."
There are times, when I'm working on IF, that I'm wholly a writer or
wholly a programmer. These are *rare*. And they usually last no more than
a few paragraphs of writing, or a half-screen of code. Then some issue
comes up that involves the "other" kind of thinking.
More normally, each sides informs the other -- no pun intended -- in
continuous and fruitful crosstalk.
If I were "just the programmer", I'd constantly be asking questions of the
writer, and involving her in decisions, and making suggestions about how
to write stuff that works well in the program. I bet, by the end, she'd
be nearly as familiar with the technical issues as I was. And vice versa
about design issues.
Jonadab
> MP0werd wrote in message
> >
> > At present, hypercard does have some lousy limitations...
Brandon Van Every suggested
>
> Try Macromedia Director instead. Less disadvantages, more
> real-world use.
>
Ugh. I've used that. It's great for doing slightly souped-up slideshows,
but I wouldn't want to program in it. My experiences with Lingo were no
better than my experiences with CoBOL.
----------------
One of the many uses for peanut butter:
161. Do an Andy Wahol tribute; Paint 30 jars of
peanut butter, 300 times.
(Need more uses? see http://members.kconline.com/kerr/pb.htm)
Send replies to username@service, where username is jonadab
and service is zerospam.com
Visit Jonadab's Domain: http://www.bright.net/~jonadab/
Andrew Plotkin
L. Ross Raszewski (rras...@hotmail.com) wrote:
> In article <erkyrathE...@netcom.com>,
> erky...@netcom.com (Andrew Plotkin) wrote:
> >
> > Gunther Schmidl (sot...@xxx.usa.net) wrote:
> > > objectloop (o in player && o has edible)
> > > move o to location;
> >
> > Oop! This runs into the linked-list complication.
> I don't think it does; the "&& o has edible" should force objectloop to use
> the non-optimized form
Oh, yeah. That's probably right.
However, it's still a rather icky low-level issue that Inform hackers
need to know about.
However, I still think it's a fairly exceptional thing in the Inform ouvre.
Julian Fleetwood
[The values of HyperCard]
This brings back memories! When I was in primary school (Australian school,
age 12) I loved using HyperCard because it was so simple! Soon I introduced
a couple of friends to the system and once the school got a copy of
HyperCard 2.0, we grabbed the programmers reference and started producing
some cool games. The biggest game we managed to create fitted on two high
density disks and used sounds and animation, and all in all was a very a
rewarding experience.
In short, HyperCard is a wonderful program and an excellent introduction to
programming (much more friendly than BASIC).
Julian Fleetwood
--
Keen supporter of the 'Train Spotting as an Olympic sport' campaign
Home Page: http://www.tip.net.au/~mfleetwo/index.htm
Interactive Fiction Dimension: http://www.tip.net.au/~mfleetwo/if/if.htm
Comic Book Guy Page: http://www.tip.net.au/~mfleetwo/cbg/comic.htm
Doeadeer3
>From: John Cater <ka...@blah.ml.org>
>Date: Fri, Jun 26, 1998 14:31 EDT
>My question about writing this system would be, how do you output the code?
I don't know the exact command but there is a @stream_output or something (I am
writing this on the fly, so I haven't looked it up). Anyway any stream can be
redirected to whatever out put. So a stream can be redirected to a file instead
of to disk. So, yes, it could be done, but it would be very tedious to code and
actually another "language" would be a lot easier to use for creating a front
end. Like C, C++, or Visual C. They would much better at manipulating the
output file.
:-)
David A. Cornelson
L. Ross Raszewski <rras...@hotmail.com> wrote in message
6n0s90$p2o$1...@nnrp1.dejanews.com...
I absolutely, positively disagree. I can write, in english, the entire text
and logic of a game without writing one single line of code. In fact, I've
done it. I currently have two games completely written in english that I
have yet to take the time to either code, or hand off to someone else to
code. But essentially, the ideas of the story and plot and player
interaction are all written down.
Here is where you;re confused. You assume that the only way for me to get
this text of mine into a z-machine format is by using an Inform-like
language. I strongly disagree. I believe that a tool can be developed that
would allow me to write the way I have in my word processor and compile it
into z-code.
I agree that this is an art form but I disagree that programming has
anything to do with it. Programming is our current, weak method of
communicating with a computer.
Jarb
Doeadeer3
>From: doea...@aol.com (Doeadeer3)
>Date: Sat, Jun 27, 1998 03:12 EDT
>So a stream can be redirected to a file instead
>of to disk.
I hate having to correct my own posts. :-) I hit the send key too quick, I
meant to say redirected to a file instead of to the screen.
Andrew Plotkin
Doeadeer3 (doea...@aol.com) wrote:
> >From: doea...@aol.com (Doeadeer3)
> >So a stream can be redirected to a file instead
> >of to disk.
> I hate having to correct my own posts. :-) I hit the send key too quick, I
> meant to say redirected to a file instead of to the screen.
Unfortunately, in the Z-machine, this is not true. A stream can be
directed to *memory* instead of the screen. Then you can save a portion
of memory. But that means you can't create files bigger than 64K, or
rather whatever portion of 64K your Z-code program leaves free.
Yeah, Glk fixes this. :)
Jonadab
Darin Johnson <da...@usa.net.removethis> wrote in article
> (For instance, it'd be nice to do things like:
> foreach item in inventory where item.edible
> item->drop;
> then it'll be closer. And even that can be lots higher level.)
>
If (player hasnt hungry)
{ MakeMultiObj(edible in player, o); <<Drop o>>; }
Or, how about
If the player isn't hungry, drop all edible objects;
! Drop takes a multiheld token, so only
! held items are dropped.
Laurel Halbany
On 26 Jun 1998 18:37:21 GMT, er...@cafe.berkeley.edu (Erik Hetzner)
wrote:
>I would argue that the parts of IF are distinct, because of the unique
>nature of the medium (or perhaps not so unique). The parts are
>(a) the author, and (b) the implementor.
I would argue that the roles are not so distinct. Some of the writing
of IF, unlike fiction, involves an appreciation of the way that the
code is going to work, for example.
>He does most of the writing, and I explain to him
>that this works, this doesn't, you need an item description here, etc).
>Now, we have written a work with stage directions, like this:
Of course, this means that Vidal will be constantly hopping around
providing solutions to *your* vision, rather than your vision being
affected ahead of time by knowing the constraints of your work.
okbl...@usa.net
In article <6n0s90$p2o$1...@nnrp1.dejanews.com>,
L. Ross Raszewski <rras...@hotmail.com> wrote:
>
> BIT AS MUCH_ as it is about writing. You CANT write a good IF without
> programming, just as you can't take a good photograph without knwoign how to
> use a camera. Now, there are tools, things like AGT or storyharp, that can
> let you write a game with almost no programming skill, but to write THE KIND
> OF IF WE EXPECT, you NEED to program. Writing is only half the art. it is
> not, should not be and will not be, all of it. It's what makes IF
different
> from Static writing, and if we lose that, we've lost IF.
>
Just to clarify, I think disagreements arise because of disputes about what
constitutes "programming". If we say "Programming is the act of creating a set
of instructions to a computer to make it perform a task" then we end up with a
sufficiently broad definition of programming to say "Yes, you're right. No
matter what, IF will never be free of programming."
However, "real" programmers define programming as giving a set of
instructions to a computer at the same or lower level than they usually
operate at. :-) This allows the VB programmers to sneer at the macro writers
while the C programmers are sneering at them. (Real assembly programmers
don't sneer, they just LDZ IP. :-)
I don't believe *anyone* is suggesting that we remove the essential
decision-making aspect from IF. I'm going out on a limb on this one, but I
think that, on the other hand, *everyone* agrees that the decision-making
aspect of IF could be raised from worrying about Inform's linked-list quirks
to concentrating on elements that more directly impact the reader.
A certain degree of minutiae will always remain, but it need not predominate.
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Paul F. Snively
In article <6n2623$r...@newsops.execpc.com>, "David A. Cornelson"
<dcorn...@placet.com> wrote:
>I absolutely, positively disagree. I can write, in english, the entire text
>and logic of a game without writing one single line of code. In fact, I've
>done it. I currently have two games completely written in english that I
>have yet to take the time to either code, or hand off to someone else to
>code. But essentially, the ideas of the story and plot and player
>interaction are all written down.
It's extraordinarily unlikely--I'll refrain from saying "impossible,"
tempting though that is--that your English prose is specific enough to,
say, hand off as-is to a programmer and allow that programmer to implement
precisely the game you wrote without further communication and
clarification between yourself and the programmer.
>Here is where you;re confused. You assume that the only way for me to get
>this text of mine into a z-machine format is by using an Inform-like
>language. I strongly disagree. I believe that a tool can be developed that
>would allow me to write the way I have in my word processor and compile it
>into z-code.
That's called "solving the natural language problem," and is a class of
problems that we computer science types refer to, tongue firmly in cheek,
as "AI-complete," meaning that it would, in the general case, require full
human-level intelligence to solve the problem.
People have been trying to get computers to understand plain __________
(where __________ has taken on the values of "English," "Russian," and
"Japanese," if not more) for as long as there have been computers. Most
respectable computer scientists think it's impossible. A tiny handful of
still-respectable computer scientists think it'll happen, but no time in
the predictable future. The remainder are considered crackpots.
>I agree that this is an art form but I disagree that programming has
>anything to do with it. Programming is our current, weak method of
>communicating with a computer.
It's extremely unlikely, given what a computer *is* (that is, a largeish
collection of things called "gate devices" that all obey the principles of
Boolean algebra) that we'll be able to communicate in any significantly
different way with computers when we want them to do stuff for us. We can
raise the level of abstraction (as we have, e.g. in going from machine
language to assembly language, assembly language to FORTRAN, FORTRAN to
Lisp, etc.) and we can address different kinds of problems (how do you
program a computer that has multiple processors?) but expecting that the
computer will eventually understand English is a pretty far-fetched
hypothesis these days... and expecting that even a highly-skilled writer of
English will be able to express game logic sufficiently precisely for a
computer to implement is even more so.
>Jarb
Paul
Brian Yap
Greg Ewing wrote:
>
> David A. Cornelson wrote:
> >
> > I disagree with this treatise. There _is_ a way to develop non-programming
> > tools that help people write interactive fiction. It's just that the
> > majority of the people that have the ability to do so are biased against it
> > because they feel comfortable with the way things stand.
>
> Various non-programming IF authoring tools have been
> built, but in all cases so far have been severely
> restricted in the scope of game behaviour they are
> capable of creating.
>
> It's not that we think it's impossible for such a
> tool to exist, it's just that we don't see how to
> build one, and so far nobody has been able to tell
> us how.
>
> If you have any ideas in that direction, we'd be very
> interested to hear them!
<snip>
I have only come across this new group about an hour ago. Here is how I
think you should write a program to take the programming out of
interactive fiction games.
This is my untested hypothesis.
Let me start with some background: I come from a world of role-playing
games like AD&D and such. I have been writing games for campaigns and
conventions for over 20 years (makes me feel old).
I have used the following terms, game author for people who write
scenarios. Game world author for people who develop game worlds. The
scenarios are developed to work inside the worlds.
In a non-computer role-playing game the author of a module is supplied
with a game world by some game world author, and lots of background
material. I think that the computer game should provide this level of
information, though the game I am developing actually lets that author
get at this level.
The sheer scope and complexity in a base game world is mind-boggling.
Yet it is this complexity that allows the game author to forget the
mechanics of the world and get on with writing a good game.
I think that a problem in the games I have seen to date is that they try
to codify the game world into objects that are written in a specific
programming language. What is needed is to abstract this level so that
it is done in data. Then all you are left with is a bunch of simple
objects that look like nodes in a tree. A codification language (is YUCC
the right term?) can then be used. The language I am looking at is the
JAVACC development, though there are lots of others.
This still ends up with "code", but at a more generic level. To make a
more plain english language parser would only take more effort.
here is an example of what I have been looking at in a HTML markup style
of format:
<Categories>
<RootThing>
</RootThing>
<PhysicalThing>
<parent>RootThing</parent>
<characteristic>
BoundingBox
<Float>height</Float>
<Float>width</Float>
<Float>depth</Float>
</characteristic>
</PhysicalThing>
</Categories>
The game world I would propose is then built on the constructs based in
language. The main objects I have suggested to date in my game are:
thing, capability, characteristic and category. These map neatly to
constructs used in the english language (proper nouns, nouns, verbs
etc.) The model looks a bit like:
things can contain things
things can be composed of things (actually 2 relationships)
things can be attached to things
things can have characteristics (the description of a thing, and the
ability to have something done to this thing)
things can gave capabilities (the ability to do something to another
thing)
Things fall into categories, the mapping to nouns, and the source of
templates for the creation of things.
Categories fall into multiple inheritance object trees. I have made a
main tree and used characteristics as an interface as in java to try and
simplify the issue of multiple inheritance. The describe THE WORLD as it
can be.
Things fall into a single tree with cross members (attachments.) This
tree represents the current configuration of the world. It has "the
universe" as it's root. All items are contained within this universe via
a containment relationship.
This then allows the game world author to concentrate on how the world
is put together. An additional level of complexity I have added is that
this view of the world then needs to be translated into a "perceived"
view of the world. This perception can be provided by an games engine,
such as a 3D engine. I have chosen to go down the path of a text world,
leaving room for graphical worlds.
Translations map from a game tree based on containership to on based on
perceptions. Examples of mappings are:
- language based views, I call it a door-way, you call it a portal.
- cultural based perceptions
- physical state based perceptions (or lack there-of)
This allows different types of characters to play in the same game. So
if I am a human, I would see a door as a thing that blocks my way and
view (because it is currently closed), where-as a player playing a ghost
in the same game would see a thin barrier, that can be passed through
but not seen through, and an ant would see an open floor with this
strange object dangling in the sky.
The there would be a language for the game authors. I would propose code
such as "There is a chest in the room in the north-west corner against
the wall." Much friendlier to people who do not know or want to learn
how to program. You could insist that a specific set of grammars was
followed to limit the chance of logically circular sentences.
Where I don't seem to be able to escape code, is when a author wants to
describe a function. This is because you end up needing to write how the
function will world. The JAVACC module allows you to do just this. Once
again there needs to be a friendlier way to write the code. I think that
if people don't realize that they are writing arcane computer code, then
they are actually quite capable of writing code. There needs to be a
syntax like: If the total weight on the trap door is greater than 100
kilograms then the door will open.
I think that this is an acceptable compromise. In most non-computer
role-playing games there is an element of simple descriptive prose to
describe to the players the general environment. I don't think that
authors would balk at the need to include such prose.
Also it the game world is sufficiently developed, the load is taken off
the designers. it is much easier to say, "there is a square room 30
meters across (assumed 3 meter roof), with 6 angry orcs who will attack
on sight", than to write lots of code.
I have a long way to go before any of this will actually work. But I
think it represents a direction in how to program that has merit.
--
http://www.geocities.com/TimesSquare/Castle/5360/gd-index.html
http://wwp.mirabilis.com/8569966
mailto:856...@pager.mirabilis.com
mailto:by...@wr.com.au
Brian Yap
Branko Collin
On Fri, 26 Jun 1998 03:42:05 GMT, eod...@pobox.com (Eric O'Dell)
wrote:
>On Thu, 25 Jun 1998 16:08:19 -0500, "David A. Cornelson"
><dcorn...@placet.com> wrote:
>
>>You are correct. There are no non-programmers in the IF world. This is
>>exactly the problem. Why shouldn't there be a tool that gives the
>>non-programmer the ability to write IF? I am not convinced that this is an
>>impossible task.
>
>implementor of the tool to design a fairly inflexible framework to
>present to the user, much as if you were restricted to only the
[...]
>It is worth noting, though, it is often painfully obvious when a
>program has been constructed from predesigned components --- a lot of
>interface features are only approximate or second-best fits to the
>actual problem, and it shows. Or, if the component programmers have
>done an exceptionally good job of contingency planning, the interface
>looks fine, but the code is bloated and often slow as well.
Maybe it would help if one looked at other problem areas.
Homepages were never meant to be coded by hand in HTML. Tim
Berners-Lee hoped that browser/editors would be made, so that the
person using the browser/editor could make homepages without ever
knowing one HTML-tag. Obviously this has failed. I have yet to see any
HTML-editor that produces 100 % clean, elegant and efficient code.
There are very few HTML-editors that can be used as browsers just as
easily. However, I don't think this is because it would have been
impossible, but rather no-one was interested in developing these
browser/editors.
Another example is the world of vector graphics. Following your model
all artists should make their drawings by programming Postscript by
hand. This is not what has happened: instead, very powerful draw
programs have emerged that give the artist not just a lot of freedom,
but also tools more powerful than they ever had. And yes, the
Postscript produced by Illustrator, Freehand and Corel Draw is bloated
and not always compatible. However, it would seem artists prefer these
faults over writing the Postscript by hand.
--
branko collin, col...@xs4all.nl
i have been in you
you have been in me - f. zappa
Andrew Plotkin
Branko Collin (col...@xs4all.nl) wrote:
> Maybe it would help if one looked at other problem areas.
>
> Homepages were never meant to be coded by hand in HTML. Tim
> Berners-Lee hoped that browser/editors would be made, so that the
> person using the browser/editor could make homepages without ever
> knowing one HTML-tag. Obviously this has failed.
On the other hand, when HTML was designed, it was entirely
non-interactive. The same goes for your later example (PostScript for
image output); the people who use Freehand and other draw programs are
creating non-interactive works.
When people wanted interactive web pages, they had to invent programming
languages.
I would humbly contend that programming is *defined* as the art and
science of specifying an interactive experience. As such, current
programming languages are the available body of experience about how such
problems have been solved in the past.
It is possible that someone will invent an entirely new approach to
specifying interactivity. But no such previous attempt has caught on (and
it's not like nobody has tried.) People always wind up saying either
"Yeah, but it doesn't let me do anything" or "Yeah, but I have to use a
programming language for the other 95% of the work."
Consider *Inform* as an example. For all the "non-programming" aspects of
game design, *Inform is a data format, not a programming language.* You
can define rooms, objects and exits with properties and attributes.
People often talk about writing a front end GUI which makes this task
easier. (I haven't seen PIDE; maybe it is one.)
But nobody *ever* says "Inform is great; I wrote my whole game without
programming." I contend this says something about the task, not about
Inform.
--Z (who writes PostScript code by hand)
HarryH
In article <359626CE...@wr.com.au>, by...@wr.com.au says...
[snip]
>I think that a problem in the games I have seen to date is that they try
>to codify the game world into objects that are written in a specific
>programming language. What is needed is to abstract this level so that
>it is done in data. Then all you are left with is a bunch of simple
>objects that look like nodes in a tree. A codification language (is YUCC
>the right term?) can then be used. The language I am looking at is the
>JAVACC development, though there are lots of others.
>
>This still ends up with "code", but at a more generic level. To make a
>more plain english language parser would only take more effort.
>The there would be a language for the game authors. I would propose code
>such as "There is a chest in the room in the north-west corner against
>the wall." Much friendlier to people who do not know or want to learn
>how to program. You could insist that a specific set of grammars was
>followed to limit the chance of logically circular sentences.
>
>Where I don't seem to be able to escape code, is when a author wants to
>describe a function. This is because you end up needing to write how the
>function will world. The JAVACC module allows you to do just this. Once
>again there needs to be a friendlier way to write the code. I think that
>if people don't realize that they are writing arcane computer code, then
>they are actually quite capable of writing code. There needs to be a
>syntax like: If the total weight on the trap door is greater than 100
>kilograms then the door will open.
What you say makes a lot of sense. Unfortunately it is impossible to achieve
with our current technology. Sure programming needs to be more abstract, but
there in lies the problem.
I choose Inform because it has a built-in library to handle things.
Unfortunately, relying on the library too much brands me a lazy programmer.
On the other hand, if I end up overriding the library most of the time, then
there's still too much work to do. So, what's the solution?
The answer lies in age-old question of Artificial Intelligence. Most
role-playing games have the gamemaster ad-lib the situations as players tries
ridiculous actions. Humans can do that easily because they have common sense.
Computers, on the other hand, needs to be programmed all the way. That's a
lot of work (and resources). I don't know too much about TADS' worldclass
library, but I hear it's too big, slow, and complex.
Therefore, the current workable solution is for the designer to describe the
world in English. Have a programmer translate it to computerese. Betatest it.
Refine it. Repeat until satisfactory. This is really just a simple
collaboration. There are trade-off involved, of course, but that's a topic
for another post.
Another solution probably lies in multiple choice actions. Kind of like
"paranoia" the computer game. A CYOA story.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Roger Carbol
Andrew Plotkin wrote:
> I would humbly contend that programming is *defined* as the art and
> science of specifying an interactive experience. As such, current
> programming languages are the available body of experience about how such
> problems have been solved in the past.
Perhaps, but this just leads to some strange definitions of what an
"interactive experience" is. For example, that program I wrote which
calculates all the prime numbers less than 1000 is "interactive" in
some sense, but probably not in a very useful sense.
.. Roger Carbol .. r...@shaw.wave.ca .. deprogrammed
Erik Hetzner
Julian Fleetwood (mfle...@pcug.org.au) wrote:
: [The values of HyperCard]
: This brings back memories! When I was in primary school (Australian school,
: age 12) I loved using HyperCard because it was so simple! Soon I introduced
: a couple of friends to the system and once the school got a copy of
: HyperCard 2.0, we grabbed the programmers reference and started producing
: some cool games. The biggest game we managed to create fitted on two high
: density disks and used sounds and animation, and all in all was a very a
: rewarding experience.
: In short, HyperCard is a wonderful program and an excellent introduction to
: programming (much more friendly than BASIC).
Brings back memories for me, of my first year of high school, lo those
6 years ago. We began programming simple stacks and games. Later we
discover the magic of buttons with icons, and how we could make them
move around. :) Kind of like sprites, I suppose, only slow. I actually
think we may have been the only people to program arcade games in
HyperCard.
It would probably be a good system for simple graphical adventures,
but it's really that powerful a system; I recall running up against
its limitations quite often.
Speaking of limitations, I've discovered that they're actually quite
useful in learning things. Like when you discover that the language
needs pointers (which I did) but you don't know what they are, or
that other languages have them. Just that you want them. :) I don't,
of course, remember what I needed them for, but I did.
Then you get Pascal, and later abandon it. And then you learn some C,
and fool around with lisp. And then you get Inform, and spend all your
time programming it and forget all other languages. :)
Lelah Conrad
On Sun, 28 Jun 1998 13:51:13 GMT, col...@xs4all.nl (Branko Collin)
wrote:
>Homepages were never meant to be coded by hand in HTML. Tim
>Berners-Lee hoped that browser/editors would be made, so that the
>person using the browser/editor could make homepages without ever
>knowing one HTML-tag. Obviously this has failed. I have yet to see any
>HTML-editor that produces 100 % clean, elegant and efficient code.
>There are very few HTML-editors that can be used as browsers just as
>easily. However, I don't think this is because it would have been
>impossible, but rather no-one was interested in developing these
>browser/editors.
>
I don't know if we're talking about the same things here, but I am
learning a program called NetObjects Fusion 3.0, which expressly
states that you do not have to know any HTML to use it. So far, I
haven't, and the results are quite lovely.
Lelah
(who is *not* saying that the program might not work even better if I
used it in HTML mode -- I'm just not doing that right now.)
Erik Hetzner
Lelah Conrad (l...@nu-world.com) wrote:
: I don't know if we're talking about the same things here, but I am
: learning a program called NetObjects Fusion 3.0, which expressly
: states that you do not have to know any HTML to use it. So far, I
: haven't, and the results are quite lovely.
: Lelah
: (who is *not* saying that the program might not work even better if I
: used it in HTML mode -- I'm just not doing that right now.)
Along the same lines, I am able to write HTML files by hand, but I
also use the W3 consortium's Amaya, which functions as an editor and
a browser, and probably has the best support of style sheets that
I know of. HTML, being a DTD (document type) for SGML, is meant
to be both human-readable and machine-readable/editable. The
lack of decent HTML editors is, I think, not a fault of HTML,
but of people desiging editors, who try to make them look like
a word processor, when they shouldn't be.
Okay, I'm diverging. HTML is a markup language, not a programming
language, and as we can see (somewhat) by the lack of decent editors,
that it is hard enough to write a decent graphical interface to it
(one that produces good, clean, HTML and is easy to use).
We have PostScript front ends, thankfully, but though it is a programming
language, the front ends only allow us the non-interactive features, the
drawing features.
My point is, none of these front ends come close to the complexity of
creating a front-end for, say, Inform.
Of course, if I understand right, this is not what people want, anyhow.
Though frankly I'm no longer sure what people want. :)
Adam J. Thornton
In article <359626CE...@wr.com.au>, Brian Yap <by...@wr.com.au> wrote:
>Greg Ewing wrote:
>The there would be a language for the game authors. I would propose code
>such as "There is a chest in the room in the north-west corner against
>the wall." Much friendlier to people who do not know or want to learn
>how to program. You could insist that a specific set of grammars was
>followed to limit the chance of logically circular sentences.
And once you restrict yourself to logically unambiguous grammars...
Congratulations. You've created a computer language. If its remaining
structure looks faintly like English...
Congratulations. You've just created something a lot like COBOL.
And that, in fact, was the whole *point* of COBOL: to develop a language
expressive enough to allow lots of business-oriented financial-type
calculations, but have a structure and syntax such that the
(non-programmer) manager could read it and make at least
conceptual-overview sense of it.
This was developed, of course, at a time when micromanagement was all the
rage and it was thought that bosses really *would* want to read code.
This is not to say your approach can't work--COBOL's been around 40 years
or more now, will not go away any time soon, and--regardless of what CS
professors and language snobs will say to you--performs admirably in its
target domain. But the gap between natural language and something
unambiguous enough to parse into code is much larger than you're giving it
credit for.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Greg Ewing
Brian Yap wrote:
>
> this view of the world then needs to be translated into a "perceived"
> world
I've pondered the idea of a very physically-based model
underlying an IF system before. I came to the conclusion
that there is a very difficult problem inherent in it:
generating a textual description from the physical model
in such a way that it doesn't sound mechanical and artificial.
I conjecture that this problem is AI-complete.
> The there would be a language for the game authors. I would propose code
> such as "There is a chest in the room in the north-west corner against
> the wall." Much friendlier to people who do not know or want to learn
> how to program. You could insist that a specific set of grammars was
> followed to limit the chance of logically circular sentences.
And there's the rub! I think you'll find that when you come
to specify this "specific set of grammars" precisely enough
to write a parser/compiler/interpreter or whatever for,
you'll find that it's just as finicky about the way you
have to phrase things as any other programming language.
It may be even worse, because it will give the _illusion_
that you can just say what you want in general English,
even though you can't.
I don't mean to dampen your enthusiasm with too much cold
water, but I think you may be underestimating the difficulty
of what you're trying to do.
> it is much easier to say, "there is a square room 30
> meters across (assumed 3 meter roof), with 6 angry orcs who will
> attack
> on sight", than to write lots of code.
None of the existing IF systems require you to write a "lot"
of code for something like this (assuming you already have
an Orc class with an attack-on-sight behaviour coded up and
ready to go).
> I have a long way to go before any of this will actually work. But I
> think it represents a direction in how to program that has merit.
There's rather too much hand-waving in what you have said
so far to pass much comment. Again, let me emphasise that
I don't mean to discourage you from pursuing these ideas.
If anything comes of them, we'll be very interested!
--
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
Greg Ewing
Erik Hetzner wrote:
>
> I recall running up against
> its limitations quite often.
I was quite interested in Hypercard for a while, and
went through many love-hate cycles with it.
I'd keep thinking "Hypercard would be really great
for this!" Then I'd try to actually do it and quickly
revise that to "Hypercard really sucks for this!"
I never did find anything that it really was good
for...
> Like when you discover that the language
> needs pointers
Aye, complete lack of data structures was one of its
biggest problems. The other was its pathological
slowness, at least on the machines of the day.
Laurel Halbany
On 28 Jun 1998 20:52:36 GMT, er...@cafe.berkeley.edu (Erik Hetzner)
wrote:
>My point is, none of these front ends come close to the complexity of
>creating a front-end for, say, Inform.
>
>Of course, if I understand right, this is not what people want, anyhow.
>Though frankly I'm no longer sure what people want. :)
A front end could be useful to programmers as well. I, too, write HTML
by hand, but a basic editor is very nice for avoiding typos and
reminding me if I leave off a bracket somewhere. An Inform front end
would not let me tweak the parser, but it could pop up 'room
templates' (for example) to make sure I don't forget to add light
where I want it, to avoid typos, and to poke me if I write to a
property an object lacks.
Brian Yap
> with our current technology. Sure programming needs to be more abstract, but
> there in lies the problem.
>
> I choose Inform because it has a built-in library to handle things.
> Unfortunately, relying on the library too much brands me a lazy programmer.
> On the other hand, if I end up overriding the library most of the time, then
> there's still too much work to do. So, what's the solution?
>
> The answer lies in age-old question of Artificial Intelligence. Most
> role-playing games have the gamemaster ad-lib the situations as players tries
> ridiculous actions. Humans can do that easily because they have common sense.
> Computers, on the other hand, needs to be programmed all the way. That's a
> lot of work (and resources). I don't know too much about TADS' worldclass
> library, but I hear it's too big, slow, and complex.
>
> Therefore, the current workable solution is for the designer to describe the
> world in English. Have a programmer translate it to computerese. Betatest it.
> Refine it. Repeat until satisfactory. This is really just a simple
> collaboration. There are trade-off involved, of course, but that's a topic
> for another post.
>
> Another solution probably lies in multiple choice actions. Kind of like
> "paranoia" the computer game. A CYOA story.
>
> -------------------------------------------------------
> Of course I'll work on weekends without pay!
> - successful applicant
I agree with the responses.. I am being very pie-in-the-sky. well as an
mad scientist engineer I am not going to give up.
The existing technologies are very limited in processing capacity. My
solution, make a faster computer. Not much help if you are trying to
make a real game that people can play tomorrow. But never-the-less fun
for theorists.
Here are a few things that probably need to be developed before what I
originally suggested will work. (And if you are out there and
cleaver-enough to build this, please do...)
I need a multi-processor computer that process objects - not blasted
instruction codes. These processors need to be configurabally
connectable and synchronisable. The old Transputers from England over a
decade ago are a giant step in the right direction. But I suppose
implementing in hardware is always faster than implementing in software.
(See all those arcade games with hardware implementations of sprites?)
A simpler solution is to separate the processing of the display from the
processing of the data from the processing of the IO. I mean, mainframes
have been doing it for decades. I suppose while the likes of Intel and
Motorola control the PC world this is not likely. Too much profit to be
lost.
People who understand language and the mind need to have better theories
on how to construct rather than just words from the underlying meanings.
What I want to do is work from the ground up with a grand vision. This
makes the whole project very academic. Hopefully there would-be at least
a few practical spin-offs. I have been working on doing this for over 15
years, so another 20 probably isn't a a major problem.
And I agree, the programming effort is still huge. That is life I
suppose when you want to codify the whole universe and everything
contained there in. What I am hoping, and I believe finding, is that
there are simple low-level constructs that repeat. As in chaos-theory,
the world is just a massive iteration on a simple set of underlying
constructs. If only one could see the constructs...
--
http://www.geocities.com/TimesSquare/Castle/5360/
Branko Collin
On Sun, 28 Jun 1998 16:54:31 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
>Branko Collin (col...@xs4all.nl) wrote:
>
>> Maybe it would help if one looked at other problem areas.
>>
>> Berners-Lee hoped that browser/editors would be made, so that the
>> person using the browser/editor could make homepages without ever
>> knowing one HTML-tag. Obviously this has failed.
>
>non-interactive. The same goes for your later example (PostScript for
>image output); the people who use Freehand and other draw programs are
>creating non-interactive works.
>
>When people wanted interactive web pages, they had to invent programming
>languages.
And still they could use the HTML-editor for a large part of the
implementation of their pages.
>Consider *Inform* as an example. For all the "non-programming" aspects of
>game design, *Inform is a data format, not a programming language.* You
>can define rooms, objects and exits with properties and attributes.
>People often talk about writing a front end GUI which makes this task
>easier. (I haven't seen PIDE; maybe it is one.)
>
>But nobody *ever* says "Inform is great; I wrote my whole game without
>programming." I contend this says something about the task, not about
>Inform.
I'd say: let's see what tools there are possible for the
non-programming aspects, after that we'll look further.
>--Z (who writes PostScript code by hand)
I have my PostScript written by programs I wrote.
Andrew Plotkin
Brian Yap (by...@wr.com.au) wrote:
> The existing technologies are very limited in processing capacity. My
> solution, make a faster computer.
>
> A simpler solution is to separate the processing of the display from the
More processing capacity gives you all of that *now*. If you want to
process something higher level than instructions, design a VM, and run it
on a faster machine. If you want separate display processing, put process
management into the OS, design a process/thread API, and run it on a
faster machine.
From where I'm standing, you want Java and X Windows. Even if that's not
exactly what you want, you want OS and language and virtual machine
design.
Hardware will never change how we work with computers, with the sole
exception that more hardware speed makes it possible to have more
interesting OSes and langauges and virtual machines.
--Z
MP0werd
>I never did find anything that it really was good
>for...
Are you kidding, I've found it good for a lot of things. I've made games with
it (XCMD's more than make up for HyperCards speed). I've made text adventure
engines (easy to do because Hypercard knows what a "Word", "Line","Char", and
"Item" are. I've made graphic adventure games, I've made a stack that factors a
trinomial. I've made reports for school that makes my teachers and classmates
eyes pop out. Hypercard is good for pretty much everything. After all, why was
it code-named WildCard
>Aye, complete lack of data structures was one of its
>biggest problems. The other was its pathological
>slowness, at least on the machines of the day.
I agree with the slowness part, but HC 3.0 will remedy that. As for data
structures, HC 3.0 may remedy that but I've found that lack of data structures
is a big help. I don't have to worry about putting a string into an int. I
could make a variable to hold a number but at the spur of a moment, decide it
is more efficient to have it hold text. I wouldn't need to redefine the
variable everywhere. Hypercard could definitely use arrays, but it's easy to
get around that.
_____
/ _ _ \____/ "... And the circle closed."
-/ | | \__ _/ Last line of Contact
| | | | (The book, not the movie)
| | | | 3.141592654
Iain Merrick
Erik Hetzner wrote:
> Julian Fleetwood (mfle...@pcug.org.au) wrote:
> : [The values of HyperCard]
>
> : This brings back memories!
Certainly does. I used to love Hypercard - I wish Apple would finally
come up with a _decent_ update for it. It's horrendously slow on my
PowerMac, but I distinctly remember using it productively on a Classic.
[...]
> I actually
> think we may have been the only people to program arcade games in
> HyperCard.
Hmmm, I thought _I_ was the only person. :)
I started writing a Sonic the Hedgehog-style game once; it was actually
fairly playable until I started putting enemies in - at which point it
started running like treacle and I gave up.
And I wrote a nifty little 'turtle graphics' system which was able to
understand a subset of Logo - it compiled Logo into HyperTalk, believe
it or not.
> It would probably be a good system for simple graphical adventures,
> but it's really that powerful a system; I recall running up against
> its limitations quite often.
I've seen a lot of very, very bad graphical adventures written using
HyperCard. It's not a cheering thought, but perhaps HyperCard is just
_too_ easy to use: it takes so little effort to come up with a stack
that basically works that people don't tend to put in the necessary
effort to make things look nice and work smoothly.
Or to put it another way, HyperCard's advantage is that it doesn't scare
off idiots. Its disadvantage is that it scares off (almost) everyone
else. It shouldn't ought to have to be that way, but...
[...]
> Then you get Pascal, and later abandon it. And then you learn some C,
> and fool around with lisp. And then you get Inform, and spend all your
> time programming it and forget all other languages. :)
That's almost familiar - except I've never gotten into Inform in any of
the odd moments in which I've played around with it. I use a Haskell
interpreter for quick hacks and C++ for real programming. Neither is
much use for IF, though.
--
Iain Merrick
Greg Ewing
MP0werd wrote:
>
> Are you kidding, I've found it good for a lot of things.
I don't mean that there's nothing it's good for, just
that it didn't seem all that good for any of the
things I tried to use it for. I kept getting frustrated
by the knowledge of what it *could* have been but
wasn't.
> I
> could make a variable to hold a number but at the spur of a moment, decide it
> is more efficient to have it hold text.
You're talking about static typing, which is quite a
different issue. It's entirely possible for a language
to be dynamically typed and still have data structures -
e.g. Scheme, Python, TADS.
> Hypercard could definitely use arrays,
and lists, and records, and classes/instances, and...
> but it's easy to get around that.
But you shouldn't *have* to get around it. That's
why I kept getting disillusioned about Hypercard.
Actually, I've just remembered that I *did* have
one success with Hypercard - a documentation stack
for a game I implemented in Think Pascal. In
fairness I have to say that it was reasonably good
for relatively static things like that.
And, to keep this post vaguely on-topic - I did
play around with using it for graphical IF. I
didn't get very far, mainly because I got put off
by the necessity of creating all the artwork, rather
than any limitations of HC.
Maybe I should dig out my effort and make it
available to r.a.i-f'ers?
Joe Mason
Greg Ewing wrote:
>
> I've pondered the idea of a very physically-based model
> underlying an IF system before. I came to the conclusion
> that there is a very difficult problem inherent in it:
> generating a textual description from the physical model
> in such a way that it doesn't sound mechanical and artificial.
> I conjecture that this problem is AI-complete.
I have the same problem with scripted NPC's. Not that I've scripted any
NPC's, mind you, but...
Take Michael from Anchorhead, for instance. He's pretty well-drawn, and
when he's simply sitting there talking back and forth with you he seems
very real. But as soon as he starts to follow you - and worse, in the
intro to day (3?) when he's wandering around the house - he seems very
obviously a computer construct. One of the few NPC's I can name who
NEVER seems like a construct is the Interrogator from Spider and Web,
because he is always micro-managed by the author, never moved by script.
So to conclude - to make NPC's the way I like 'em, you have to write
every move individually. Gack.
Joe
wo...@one.net
Hi Darin,
>I strongly disagree. There are vast areas of improvement. Both are
>too low level in my opinion. However, the improvements I can think of
>aren't necessarily those that will attract a nervous novice.
>
>(For instance, it'd be nice to do things like:
> foreach item in inventory where item.edible
> item->drop;
>then it'll be closer. And even that can be lots higher level.)
You can do this in TADS using #define macros. I have several such FOR
loops. For example:
$for_all_contents
obj.DescribeSelf('SMART');
$end_of_loop;
This loop is used in object methods. It allows you to loop through
Self's contents, assigning the object to the variable obj.
I'm in the process of writing (as the real world permits :) ) a new
library called Universe, which should make it easier for beginners to
do fairly advanced (but oft required) things without too much coding.
It also removes a lot of the syntax sugar TADS requires.
#define (athough having two really annoying bugs) is extremely useful.
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
Dan Shiovitz
In article <359c0922...@news.one.net>, <wo...@one.net> wrote:
>
>Hi Darin,
[..]
>I'm in the process of writing (as the real world permits :) ) a new
>library called Universe, which should make it easier for beginners to
>do fairly advanced (but oft required) things without too much coding.
>It also removes a lot of the syntax sugar TADS requires.
Excellent. Good idea.
>#define (athough having two really annoying bugs) is extremely useful.
I haven't come across them. What are they?
>Wolf
--
Dan Shiovitz || d...@cs.wisc.edu || http://www.cs.wisc.edu/~dbs
"...Incensed by some crack he had made about modern enlightened
thought, modern enlightened thought being practically a personal buddy
of hers, Florence gave him the swift heave-ho and--much against my
will, but she seemed to wish it--became betrothed to me." - PGW, J.a.t.F.S.
Codeboy
<SNIP>
>><dcorn...@placet.com> wrote:
>>
>>>You are correct. There are no non-programmers in the IF world. This is
>>>exactly the problem. Why shouldn't there be a tool that gives the
>>>non-programmer the ability to write IF? I am not convinced that this is
an
>>>impossible task.
>>
>>What you are suggesting is indeed possible, but it would require the
>>implementor of the tool to design a fairly inflexible framework to
>>present to the user, much as if you were restricted to only the
>>standard library in TADS.
>[...]
</SNIP>
I differ from the above opinion. I think you can make a limited system (like
a standard library or a "canned bag of tricks") that can grow as your
software grows over time. Take for instance HTML. In the first rev, HTML 1.0
was pretty weak. Yet, modern web browsers can read HTML 1.0, as well as 2.0,
and 3.0, and 4.0, and so on. And if you tried to load an HTML 4.0 file in a
1.0 rev web browser, what you often get about 80% of the time is that at
least the file sort of loads and sort of is readable--just minus a bunch of
new features. The web browser idealogy is to ignore <TAGS> it doesn't
understand and keep on moving along. Then, a great counsel of web elders
convenes meetings and invents new tags for the masses.
Let's say for instance that you make an IF game where the only puzzles in it
are that you are required to have something in your hands in order to
progress into certain rooms. There would not be any actors in this
game--merely player and locations. Pretty limited, huh? Game would kind of
be predictable and suck, right? But that would be a start. You could release
that as maybe a 1.0 version. Let's say that this game didn't use z-files,
but used object files that sort of looked like HTML. Now, on the 2.0
version, you could add more tags that supported new kinds of puzzles. And
3.0, you would add even more tags. And so on.
In that kind of system, non-programmers could learn to write these special
HTML-like IF files pretty easily--just as non-programmers today sit down and
write web pages. Heck--even my seven year old daughter writes web pages.
Moreover, you could make an IDE for non-programmers to combine elements into
these IF files just as Front Page Express is a nice IDE for making HTML
files and requires little to no knowledge of HTML. Sure, it's limiting, but
over time you can add more and more canned puzzles until you have a great
system.
I not only speak from theory on this, but I am actually implementing this in
VB5 with its new objects and classes. I am making a 1.0 IF game interpreter
and an IDE for non-programmers to make these games. They can only snap
together a few puzzles, but over time, I should be able to make 2.0 IF game
interpreters and add more puzzles. However, I can tell you that my 1.0
interpreter supports a lot of the most common puzzles you see in Inform
games. So, a 2.0 interpreter and beyond should be able to process some
pretty complex games after awhile. My system is not ready for alpha yet, but
is called WinTangent and its "z-files" are called TAN files. My TAN files
look like HTML, but have the option of being encrypted or not to prevent
users from ruining the fun.
--
Mike McKee
mckeeSP...@ntwrks.com
You know what to do to reply.
Derek Haslam
[attribution gone to pot]
> >>>You are correct. There are no non-programmers in the IF world. This is
> >>>exactly the problem. Why shouldn't there be a tool that gives the
> >>>non-programmer the ability to write IF?
There are no non-programmers in the IF world for the same reason that there
are no non-publishers in the book publishing world.
The tools to write IF are the tools to write books: pencil & paper, word
processor or the equivalent. The tools to make fiction readable are
publishing houses, bookshops and the rest. The tools to make fiction
interactive are computer programs and software distributors.
Writing IF programs is as different from writing books as creating computer
graphics is different from creating oil paintings or photographs, and note
that computer graphics can be printed out to *look like* photographs and
maybe even oil paintings.
Think about it.
Joyce.
--
__ __ __ __ __
/ \ | ||__ |__)/ | | |_ Derek Haslam Joyce Haslam
\_\/ |__||__ | \\__ |__| __| Acorn Computer Enthusiasts
\ dljh...@argonet.co.uk
Mastery of the rules is a pre-requisite for creatively breaking them.
Jenny X
On Fri, 3 Jul 1998 12:37:05 -0400, "Codeboy" <sup...@remedy.com>
wrote:
>I differ from the above opinion. I think you can make a limited system (like
>a standard library or a "canned bag of tricks") that can grow as your
>software grows over time. Take for instance HTML. In the first rev, HTML 1.0
>was pretty weak. Yet, modern web browsers can read HTML 1.0, as well as 2.0,
>and 3.0, and 4.0, and so on. And if you tried to load an HTML 4.0 file in a
>1.0 rev web browser, what you often get about 80% of the time is that at
>least the file sort of loads and sort of is readable--just minus a bunch of
>new features. The web browser idealogy is to ignore <TAGS> it doesn't
>understand and keep on moving along. Then, a great counsel of web elders
>convenes meetings and invents new tags for the masses.
The comparison between HTML and a real programming language is
virtually meaningless. HTML is a simple document markup language with
some formatting information grafted on top. It does not support any of
the elements of a procedural programming language --- no loops, no
conditionals or flow control, not even variables. It's not even very
good at the limited task it was designed to perform, and it cannot
even compare to real languages designed to support document markup and
layout like TeX, Lout, and PostScript. You can write actual programs
in TeX, for example; there is even a BASIC interpreter written in TeX.
You can't write any kind of program in HTML.
When processing a markup language like HTML, you can gleefully ignore
tags and still produce readable output, at least most of the time. You
can do this because the job performed by the language is a simple one,
and most HTML markup is window dressing anyway. A procedural language
is another matter altogether. Any object not understood by the
interpreter would have to be ignored, as would any otherwise compliant
object containing a few non-compliant elements. A programmer using the
system would have to design to the lowest common denominator, using
more recent additions to the standard solely for non-essential items,
much as webmasters today typically code down to the Netscape 3.0 or
even 2.0.
It could be done, but it's hard to imagine that the results would be
worth looking at. It'd be like the difference between a picture made
with oil paints and a picture made with rubber stamps.
Lelah Conrad
On Sat, 04 Jul 1998 04:13:08 GMT, Jen...@nowhere.com (Jenny X) wrote:
>It could be done, but it's hard to imagine that the results would be
>worth looking at. It'd be like the difference between a picture made
>with oil paints and a picture made with rubber stamps.
(You may be right about the HTML aspect you were talking about, I
wouldn't know, BUT)
I'd rather have a picture by Picasso made with rubber stamps than an
oil painting painted by a nonartist. I think you left out the key
factor here.
Lelah
Erik Max Francis
Lelah Conrad wrote:
> I'd rather have a picture by Picasso made with rubber stamps than an
> oil painting painted by a nonartist. I think you left out the key
> factor here.
But an artist trying to oil paint with chalk isn't going to work.
--
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
Erik Max Francis
Jenny X wrote:
> The comparison between HTML and a real programming language is
> virtually meaningless. HTML is a simple document markup language with
> some formatting information grafted on top.
Thank you. Those that insist that HTML composition is "programming"
need to firmly smacked on the ass.
Paul F. Snively
In article <6nn597$6...@newsops.execpc.com>, "David A. Cornelson"
<dcorn...@placet.com> wrote:
>I believe you're saying the same thing others have said, that IF without
>programming is not IF.
Well, it's currently true that "IF," as I think there's a consensus view on
this newsgroup as to the definition of, without "programming" is not "IF."
I think the problem arises because there's no similar consensus on this
newsgroup as to what "programming" means or, perhaps more accurately, might
mean were someone to devote sufficient energy to it.
>I keep asking "Why" and when I get this sort of "Because" answer, I shake my
>head. This is not a reason, this is some analogy for "things are the way
>they are, because they are the way they are."
>
>Hmmm. Lets all go back to Assembler....
Your comment--reflecting the fact that we in Computer Science have enjoyed
much rapid progress in raising the level of abstraction at which we can
program computers--is valid, but I think misses the point that many writers
don't appear to be able to program a computer at *any* of the currently
easily accessible levels of abstraction, assembly language or otherwise.
Without falling into the time-honored trap of attempting to compress some
40 years of Computer Science history into a single netnews posting, suffice
it to say that *given the current state of the art in programming
technology* it's not possible to create "IF" as we understand the term from
examples such as the Zork trilogy without programming.
But this is probably not an interesting conclusion--some people have
indicated a willingness to sacrifice *large* amounts of expressive power
(in the programming sense, not the creative writing sense) in order to have
*any* level of access to the IF authoring process, even if it's simply not
possible to express the same level of programmatic behavior as in the Zorks
etc. Once this is understood, I believe it can lead to profitable
discussions as to how this might be accomplished, such as the one currently
taking place on the "[Lelah's Beginner's IF Writing Tool]" thread.
>Jarb
Paul
Paul F. Snively
In article <na.41007a4861....@argonet.co.uk>, Derek Haslam
<dljh...@argonet.co.uk> wrote:
Hi Joyce!
>I have spent *hours* over the last four years just translating a piece of IF
>from one computer program to another. I do not think that a pile of chips
>could do the job at all.
Actually, it could--there are programs that translate other programs from
one language to another all the time.
>Look at how far we are from mechanical translation
>between human languages: we're still at the stage where putting "The spirit
>is willing but the flesh is weak" from English to another language and back
>results in "The wine is good but the meat is rotten".
Two problems: one, you assume that computerized translation of a computer
program from one programming language to another is more complex than
computerized translation from one human language to another (it's not--far
from it), and you assume that the state of computerized translation from
one human language to another is exactly where it was circa 1965 or so,
when the specific example of going from English to Russian and back to
English that you cited took place (it's not).
Besides, ask an English-speaking human being who's never encountered this
phrase of Jesus' (good luck finding this person!) what it means and see how
well the human being fares! The example actually shows how good the
translation software was in an important sense: it was internally
consistent with respect to context ("wine... meat"), although it had gotten
the (metaphysical) context wrong.
>Joyce.
Paul
Darin Johnson
ch...@mcione.com (Paul F. Snively) writes:
> Well, it's currently true that "IF," as I think there's a consensus view on
> this newsgroup as to the definition of, without "programming" is not "IF."
> I think the problem arises because there's no similar consensus on this
> newsgroup as to what "programming" means or, perhaps more accurately, might
> mean were someone to devote sufficient energy to it.
That's true. I think part of the problem may be that some
non-programmers don't know what programming is, and assume that
there's an easier way. Programming languages are written by people
who already know programming languages, and one might draw the
conclusion that this perpetuates their difficulty. Much like text
commands versus GUI perhaps.
> Your comment--reflecting the fact that we in Computer Science have enjoyed
> much rapid progress in raising the level of abstraction at which we can
> program computers--is valid, but I think misses the point that many writers
> don't appear to be able to program a computer at *any* of the currently
> easily accessible levels of abstraction, assembly language or
> otherwise.
Once you've got the abstraction, programming in any language is vastly
simplified. This is the biggest difference between people that dabble
in programming, and programmers that make a long career or hobby of
it, is that the dabblers haven't picked up on the abstraction.
> But this is probably not an interesting conclusion--some people have
> indicated a willingness to sacrifice *large* amounts of expressive power
> (in the programming sense, not the creative writing sense) in order to have
> *any* level of access to the IF authoring process, even if it's simply not
> possible to express the same level of programmatic behavior as in the Zorks
> etc.
What I think would be useful, is for some of these non-programmers to
actually give concrete examples of what they might like to do in terms
of an IF creation system. Ie, really spell it out, with detail, and
then those of us with interpreter/compiler writing experience can look
at it. Then with give and take on both sides, something better could
arise. Instead, I hear examples of someone just wanting to write in
plain English and let the system figure out the details.
A real example will need more than room and item descriptions. For
instance, full express, in any manner you want, the White House in
Zork, including the mailbox, kitchen, attice, rug, lamp, and trophy
case. For simplicity, just shorten the room and item descriptions to
single lines. Also assume there is no predefined rug template to use,
but you can assume a predefined food, lightsource, and container
templates.
When someone gets that far, then it's time to distill things.
(and many real computer languages were thought up in a similar
manner: think how you want to make a program look, then create
a language that lets you do it)
--
Darin Johnson
da...@usa.net.delete_me
Lelah Conrad
On Mon, 06 Jul 1998 21:47:55 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>What I think would be useful, is for some of these non-programmers to
>actually give concrete examples of what they might like to do in terms
>of an IF creation system. Ie, really spell it out, with detail, and
>then those of us with interpreter/compiler writing experience can look
>at it. Then with give and take on both sides, something better could
>arise. Instead, I hear examples of someone just wanting to write in
>plain English and let the system figure out the details.
>
Well, I tried, in another thread. I was trying to simplify the input
format to a yes/no or multiple choice format for object attributes. I
wasn't trying to make the system handle any old English but to rather
provide a reduced subset of questions for the author to answer. This
construct lacked (proabably not solely) the ability to allow for the
interaction of objects/actors (e.g. an action dimension for objects
that need special code to relate them to actions and each other). My
whole idea was not based on recreating the wheel but rather sticking
such a system on top of an existent system. As wolfone said
elsewhere, vaguely like a microsoft wizard.
Lelah
The IF Wizard
version 1.0
> [start typing]
Wizard of Frobozz says, "Hey, it looks like you're trying to create a
dungeon there!"
>um, not exactly
"But really, I can help you. All you need is a few good spells, some
treasures...let me show you how to do it."
>no, really, it's okay...
Wizard of Frobozz makes newbie writer disappear completely.
Paul F. Snively
<da...@usa.net.removethis> wrote:
>That's true. I think part of the problem may be that some
>non-programmers don't know what programming is, and assume that
>there's an easier way.
I treat this as a foregone conclusion--I literally don't see how any other
conclusion could be reached based on the content of most of the postings on
the subject.
>Programming languages are written by people
>who already know programming languages, and one might draw the
>conclusion that this perpetuates their difficulty. Much like text
>commands versus GUI perhaps.
This does indeed seem to be the assumption--even on the part of some other
people who claim to be programmers! To the extent that this assumption
carries with it the tacit notion that we programmers just don't realize how
much non-programmers would appreciate an easier way to program, it's naive;
to the extent that it carries with it the tacit assumption that we
programmers are unwilling to expose the secrets of our art to the unwashed
masses, it's offensive.
>Once you've got the abstraction, programming in any language is vastly
>simplified. This is the biggest difference between people that dabble
>in programming, and programmers that make a long career or hobby of
>it, is that the dabblers haven't picked up on the abstraction.
I used to think that lots of people had trouble with abstraction, but I no
longer think that's the case. Instead most people seem unable or
unwilling--and probably more the latter than the former--to cope with the
zero-margin-for-error attention to picayune detail that in the final
analysis has little or nothing to do with reaching the goal at hand that
currently characterizes programming. The analogy that comes to mind for
writers would be requiring them to design their own fonts and realize them
as movable type in order to write.
>What I think would be useful, is for some of these non-programmers to
>actually give concrete examples of what they might like to do in terms
>of an IF creation system. Ie, really spell it out, with detail, and
>then those of us with interpreter/compiler writing experience can look
>at it. Then with give and take on both sides, something better could
>arise. Instead, I hear examples of someone just wanting to write in
>plain English and let the system figure out the details.
Ironically, there's another thread about Lelah Conrad's initial idea for an
IF authoring "front end," if you will, to Inform and/or TADS, that has the
unusual characteristics of offering a non-trivial concrete example of
desired use, a high degree of structure to the interaction, and some clever
tidbits such as annotating alternatives to be dealt with in user input with
1), 2), ... so that the system could parse them and ask further questions
about the alternatives. In short, Lelah's a lot less guilty of the kind of
handwaving "just make it work!" that normally accompanies these kinds of
proposals and has left, it seems, most programmers feeling somewhat
embattled and cynical towards our writer friends, who are, after all, our
creative brothers and sisters.
>A real example will need more than room and item descriptions. For
>instance, full express, in any manner you want, the White House in
>Zork, including the mailbox, kitchen, attice, rug, lamp, and trophy
>case. For simplicity, just shorten the room and item descriptions to
>single lines. Also assume there is no predefined rug template to use,
>but you can assume a predefined food, lightsource, and container
>templates.
>
>When someone gets that far, then it's time to distill things.
Admittedly, Lelah's system *as it's been initially described* lacks much
beyond changing descriptions based on the passage of time, but that may
only be because it's an initial thought that can be readily expanded upon,
assuming that Lelah ever again develops enough guts to follow up. You may
wish to seek out her description and comment on it in light of what you
suggest here.
>(and many real computer languages were thought up in a similar
>manner: think how you want to make a program look, then create
>a language that lets you do it)
That's frequently how computer language *syntax* is arrived at. Semantics,
wellllllllllll... sometimes a whole different ball game, sometimes not.
>--
>Darin Johnson
>da...@usa.net.delete_me
Paul
Paul F. Snively
Conrad) wrote:
>Well, I tried, in another thread.
And did a very creditable job, speaking from a programmer's point of view!
I apologize if that sounds condescending; suffice it to say that I know
that, were I to propose some kind of IF aesthetic to the writing community,
I have no doubt I could not do so as well as you have proposed a
simplification of the programming process.
>I was trying to simplify the input
>format to a yes/no or multiple choice format for object attributes. I
>wasn't trying to make the system handle any old English but to rather
>provide a reduced subset of questions for the author to answer. This
>construct lacked (proabably not solely) the ability to allow for the
>interaction of objects/actors (e.g. an action dimension for objects
>that need special code to relate them to actions and each other).
I only wanted to point that out in the context of the spork issue, and, as
I've written before, that was only to demonstrate that IF is basically
about (programmatically speaking) objects changing state, which arises
under even the most trivial circumstances, so you should at least
contemplate what, if anything, you'd like your system to do about it. Note
that "nothing" is a perfectly acceptable answer.
>My
>whole idea was not based on recreating the wheel but rather sticking
>such a system on top of an existent system. As wolfone said
>elsewhere, vaguely like a microsoft wizard.
As long as it isn't a paperclip with an attitude, that's fine.
>Lelah
>
>The IF Wizard
>version 1.0
>
>> [start typing]
>
>Wizard of Frobozz says, "Hey, it looks like you're trying to create a
>dungeon there!"
>
>>um, not exactly
>
>"But really, I can help you. All you need is a few good spells, some
>treasures...let me show you how to do it."
>
>>no, really, it's okay...
>
>Wizard of Frobozz makes newbie writer disappear completely.
Oh yeah, that's it. IF would be so much better if you pesky writers would
just disappear. ;-)
Paul
Andrew Plotkin
> >Once you've got the abstraction, programming in any language is vastly
> >simplified. This is the biggest difference between people that dabble
> >in programming, and programmers that make a long career or hobby of
> >it, is that the dabblers haven't picked up on the abstraction.
>
> I used to think that lots of people had trouble with abstraction, but I no
> longer think that's the case. Instead most people seem unable or
> unwilling--and probably more the latter than the former--to cope with the
> zero-margin-for-error attention to picayune detail that in the final
> analysis has little or nothing to do with reaching the goal at hand that
> currently characterizes programming.
This is interesting. I also tend to phrase the problem in terms of
abstraction.
The picayune detail problem is... not necessarily low-level. You have to
pay attention at the higher levels of abstraction as well. It's not so
much detail as thoroughness: covering every case.
Then I think that thoroughness means attention to promises and
guarantees, at every level. And that's abstraction again.
Norman Ramsey
Thomas Nilsson <th...@softlab.se> wrote:
>What we should strive for is support for "programming" but on a level
>where an *author* can do it:
>
> sum all list.a where a > x
> sort list after a.
> if exists list.a > x ...
Functional languages have been doing this sort of thing for years.
I can't resist writing two of these in Standard ML (I don't know what
the third one means):
foldl op + 0 (filter (fn item => item.a > x) list)
`test for a > x'
`list where a > x'
`sum all'
if List.exists (fn item => item.a > x) list ...
`text for a > x'
`exists an element satisfying the test'
It's a fairly small step from this to add some `syntactic sugar',
e.g.,
sum ((select all item where item.a > x) list)
if (exists item where item.a > x) list then ...
It would be very cool if somebody were to port (say) the Inform
library to one of the functional languages to see just how well this
might work out...
Darin Johnson
> >(and many real computer languages were thought up in a similar
> >manner: think how you want to make a program look, then create
> >a language that lets you do it)
>
> That's frequently how computer language *syntax* is arrived at. Semantics,
> wellllllllllll... sometimes a whole different ball game, sometimes not.
Depends upon the languages. Lisp, Prolog, Smalltalk all probably
started based upon the desired semantics, and the syntax followed.
Fortran started as "I'm sick of assembler, can't we write a program to
do that for us"? I think most of the languages that were "new" ways
of thinking (and not just furtherance of ideas), started as ideas
about semantics rather than syntax.
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
> The picayune detail problem is... not necessarily low-level. You have to
> pay attention at the higher levels of abstraction as well. It's not so
> much detail as thoroughness: covering every case.
Part of the problem, especially with IF, is first in realizing what
the cases really are. Ie, what happens when the player sticks the
spork in the light socket that was intended only for a lightbulb;
preventing the player from sticking the guard in the light socket
to get rid of him; etc.
Murphy's law is important for programmers.
--
Darin Johnson
da...@usa.net.delete_me
Matt Ackeret
MP0werd <mp0...@aol.com> wrote:
> At present, hypercard does have some lousy limitations...
> No built in support for color (although it can be added)
Nope, the GS version has color.
> 32k limit
> Cannot acess toolbox
> limited to Macintosh (best computer) platform
Nope, there's a GS version, available on Apple's FTP site..
--
mat...@area.com
Paul F. Snively
Plotkin) wrote:
>This is interesting. I also tend to phrase the problem in terms of
>abstraction.
>
>The picayune detail problem is... not necessarily low-level. You have to
>pay attention at the higher levels of abstraction as well. It's not so
>much detail as thoroughness: covering every case.
Hmmm. I think this is an example of you saying "tomayto" while I say "tomahto."
>Then I think that thoroughness means attention to promises and
>guarantees, at every level. And that's abstraction again.
Again, I think the issue may not even be whether we say "abstraction" or
"details," but the extent to which the "abstractions" or "details" are or
are not perceived by the person manipulating them to be "directly related"
to building their story.
>--Z
>
>--
>
>"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
>borogoves..."
Paul
Paul F. Snively
n...@labrador.cs.virginia.edu (Norman Ramsey) wrote:
[Lots of good observations about functional programming elided]
Wow, Norman Ramsey! Fancy meeting you here!
Yes, it *would* be interesting to have the Inform library, e.g. in Standard
ML or Haskell. When will you write them? ;-) I imagine right after you're
done with the New Jersey Machine Code Toolkit and noweb. Fabulous pieces of
work, by the way!
Ob. rec.arts.int-fiction reference: one nice thing about functional
programming is that you can build large, complex systems by gluing small,
simple components together and have some assurrance that the cognitive load
will remain managable and you won't get bitten by unpredictable
side-effects. Elsewhere I offered a pointer to a visual language called
Prograph. Not only is Prograph visual (by which I mean that programming is
done by drawing pictures), but it is also a functional language to the
extent that there's an emphasis on dataflow (operations take data in and
spit data out) as opposed to control flow.
Paul
Paul F. Snively
<da...@usa.net.removethis> wrote:
>Part of the problem, especially with IF, is first in realizing what
>the cases really are. Ie, what happens when the player sticks the
>spork in the light socket that was intended only for a lightbulb;
>preventing the player from sticking the guard in the light socket
>to get rid of him; etc.
Exactly; this is part and parcel of the "combinatorial explosion" problem
that I've written about elsewhere: dealing with what happens when you
multiply the number of verbs by the number of direct objects by the number
of indirect objects in the game to arrive at the number of cases that you
have to deal with, even if "dealing with them" consists of letting them
default.
>Murphy's law is important for programmers.
Murphy was an optimist.
Iain Merrick
If I remember correctly, Lisp wasn't originally intended as a
programming language, just as a nice notation for reasoning about
programming (based on Church's 'lambda calculus').
John McCarthy, as a demonstration of his new notation, wrote down a Lisp
expression for evaluating Lisp expressions. Then some bright spark
realised that by writing a small program to interpret a tiny subset of
Lisp, this system could be used to create an entire Lisp interpreter
practically from thin air... and so it came to pass.
I can't remember where I heard/read that anecdote, but I'm sure it was
something along those lines. It strikes me now that this is a bit like
the creation of the Infinite Improbability Drive in _The Hitchhiker's
Guide To The Galaxy_...
--
Iain Merrick
okbl...@usa.net
ch...@mcione.com (Paul F. Snively) wrote:
>
> This does indeed seem to be the assumption--even on the part of some other
> people who claim to be programmers! To the extent that this assumption
> carries with it the tacit notion that we programmers just don't realize how
> much non-programmers would appreciate an easier way to program, it's naive;
> to the extent that it carries with it the tacit assumption that we
> programmers are unwilling to expose the secrets of our art to the unwashed
> masses, it's offensive.
>
Actually, I appreciate your responses in this thread because I have a friend
who has been working on-and-off on "making programming easier" (primarily for
programmers :-))for going on 20 years and fairly consistently for the last
five. I think his basic premise is sound* but I also know that arriving at
various theories and testing them out has taken huge amounts of his time.
He's sort of working on what I would call a "unified field theory" of
programming so that you could actually abstract the decision making up to a
level where a "non-programmer" is doing it. It's still programming but the
user isn't necessarily going to perceive it as such. The finer the control
desired, however, the more like programming it's going to get.
A "good" system of IF would have a set of (customizable) defaults for
everything and allow tailoring of specific items. If this were going to
happen it would probably require a common platform and the combined efforts
of everyone here.
[ok]
*I'm trying to get him to apply it to IF :-) He once designed an
English-language parser with a single NPC so that a person could interact
with a single, computer generated character and it was pretty good!
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Darin Johnson
> If I remember correctly, Lisp wasn't originally intended as a
> programming language, just as a nice notation for reasoning about
> programming (based on Church's 'lambda calculus').
True. And lambda calculus is not important because of syntax, but
because of semantics. It was the semantics that allowed one to
write an expression evaluator.
--
Darin Johnson
da...@usa.net.delete_me
David Rush
> John McCarthy, as a demonstration of his new notation, wrote down a Lisp
> expression for evaluating Lisp expressions. Then some bright spark
> realised that by writing a small program to interpret a tiny subset of
> Lisp, this system could be used to create an entire Lisp interpreter
> practically from thin air... and so it came to pass.
>
> I can't remember where I heard/read that anecdote, but I'm sure it was
> something along those lines. It strikes me now that this is a bit like
> the creation of the Infinite Improbability Drive in _The Hitchhiker's
> Guide To The Galaxy_...
Given the amazing number of improbable things that Lisp has
spawned, I might venture to argue that Lisp *is* the Infinite
Improbability Language.
david rush
--
And IF *has* been done in it, too. Has anyone ever played dunnet?
David Rush
> Greg Ewing wrote:
> >
> > I conjecture that this problem is AI-complete.
>
> I have the same problem with scripted NPC's. Not that I've scripted any
> NPC's, mind you, but...
>
> obviously a computer construct. One of the few NPC's I can name who
> NEVER seems like a construct is the Interrogator from Spider and Web,
> because he is always micro-managed by the author, never moved by script.
And he micro-manages *you*. God! How I hated that game (Sorry,
Andrew..."Weather" seems pretty cool). In fact that micro-management
makes him seem even more artificial to me. The script is *continually*
in your face. If you deviate from it, you die, or, like Bill Murray in
"Groundhog Day", you are doomed to repeat the same irritatingly short
sequences of action ad nauseum.
Personally, I really think that some form of goal-based specification
is going to be the answer for good NPCs. Once I get past my current
set of delivery deadlines, I intend to put some serious effort into
this.
david rush
--
And I thought that "Groundhog Day" was perhaps the most affecting movie
I've seen since "Platoon".
Arcum Dagsson
mp0...@aol.com (MP0werd) wrote:
> >I never did find anything that it really was good
> >for...
>
> Are you kidding, I've found it good for a lot of things. I've
made games with
> it (XCMD's more than make up for HyperCards speed). I've made text adventure
> engines (easy to do because Hypercard knows what a "Word", "Line","Char", and
> "Item" are. I've made graphic adventure games, I've made a stack that
factors a
> trinomial. I've made reports for school that makes my teachers and classmates
> eyes pop out. Hypercard is good for pretty much everything. After all, why was
> it code-named WildCard
>
> >Aye, complete lack of data structures was one of its
> >biggest problems. The other was its pathological
> >slowness, at least on the machines of the day.
>
> I agree with the slowness part, but HC 3.0 will remedy that. As for data
> structures, HC 3.0 may remedy that but I've found that lack of data structures
> is a big help. I don't have to worry about putting a string into an int. I
> could make a variable to hold a number but at the spur of a moment, decide it
> is more efficient to have it hold text. I wouldn't need to redefine the
> variable everywhere. Hypercard could definitely use arrays, but it's easy to
> get around that.
>
> _____
> / _ _ \____/ "... And the circle closed."
> -/ | | \__ _/ Last line of Contact
> | | | | (The book, not the movie)
> | | | | 3.141592654
I admit Hypercards slowness gets me ticked off a bit, but I once wrote a
subset of Logo in it, so I certainly wouldn't write it off as not being
good for anything...
--
--Arcum Dagsson
"Sometimes it's better to light a flamethrower than curse
the darkness."
--Terry Pratchett
"Men At Arms"
Paul F. Snively
<ku...@bellsouth.net> wrote:
>Iain Merrick <i...@cs.york.ac.uk> writes:
>> John McCarthy, as a demonstration of his new notation, wrote down a Lisp
>> expression for evaluating Lisp expressions. Then some bright spark
>> realised that by writing a small program to interpret a tiny subset of
>> Lisp, this system could be used to create an entire Lisp interpreter
>> practically from thin air... and so it came to pass.
>>
>> I can't remember where I heard/read that anecdote, but I'm sure it was
>> something along those lines. It strikes me now that this is a bit like
>> the creation of the Infinite Improbability Drive in _The Hitchhiker's
>> Guide To The Galaxy_...
Probably Richard Greenblatt.
>Given the amazing number of improbable things that Lisp has
>spawned, I might venture to argue that Lisp *is* the Infinite
>Improbability Language.
>
>david rush
>--
>And IF *has* been done in it, too. Has anyone ever played dunnet?
Or Zork? Or, for that matter, *any* Infocom game prior to Activision's
"Spycraft: The Great Game?"
Paul
Paul F. Snively
>Actually, I appreciate your responses in this thread because I have a friend
>who has been working on-and-off on "making programming easier" (primarily for
>programmers :-))for going on 20 years and fairly consistently for the last
>five. I think his basic premise is sound* but I also know that arriving at
>various theories and testing them out has taken huge amounts of his time.
Well, thanks. I sometimes get impatient because people think there's some
sort of Holy Grail that we programmers are jealously guarding, when the
reality is that I believed in the personal computer revolution and have
been watching it stagnate because the real power of
computing--programming--is so inaccessible, and it breaks my heart.
>He's sort of working on what I would call a "unified field theory" of
>programming so that you could actually abstract the decision making up to a
>level where a "non-programmer" is doing it. It's still programming but the
>user isn't necessarily going to perceive it as such.
Exactly. I think this is how it will be in the long run: it won't be
programming as we know it today.
>The finer the control
>desired, however, the more like programming it's going to get.
Possibly.
>A "good" system of IF would have a set of (customizable) defaults for
>everything and allow tailoring of specific items. If this were going to
>happen it would probably require a common platform and the combined efforts
>of everyone here.
And then some, I think!
>[ok]
>
>*I'm trying to get him to apply it to IF :-) He once designed an
>English-language parser with a single NPC so that a person could interact
>with a single, computer generated character and it was pretty good!
Computational Linguistics keeps getting better and better all the time, so
there's hope yet.
>-----== Posted via Deja News, The Leader in Internet Discussion ==-----
>http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Paul
Iain Merrick
> Iain Merrick <i...@cs.york.ac.uk> writes:
>
> > If I remember correctly, Lisp wasn't originally intended as a
> > programming language, just as a nice notation for reasoning about
> > programming (based on Church's 'lambda calculus').
>
> True. And lambda calculus is not important because of syntax, but
> because of semantics. It was the semantics that allowed one to
> write an expression evaluator.
Um, yes, of course. But it was still an imaginative leap - which seems
obvious now - to use the lambda calculus _directly_ for actual
programming. (Or very nearly directly, in the form of Lisp.)
okbl...@usa.net
> sort of Holy Grail that we programmers are jealously guarding, when the
> reality is that I believed in the personal computer revolution and have
> been watching it stagnate because the real power of
> computing--programming--is so inaccessible, and it breaks my heart.
>
I feel your pain.<g>
> And then some, I think!
I wonder how much support one could get for a project such as this....
>
> Computational Linguistics keeps getting better and better all the time, so
> there's hope yet.
>
And it'll end up being the most convoluted, bizarre, complex code ever
written, I imagine. And then what will happen? People will complain because
the machine misunderstood something, even though a human being would make the
same mistake in the same context--because, hey, people aren't that clear when
they speak. (But it'll still be the computer's fault. :-))
[ok]
Jeff Hatch
> Would anyone else like some sort of Visual system for IF programming?
> You know, something that tells you immediately when it looks as though
> *whoops* you've forgotten that semi-colon. Maybe a quick object-hopper.
> Anyone working on something like that?
More or less. My "Inscribe" editor allows me to edit one function at a
time. When I finish editing a function, I click the Compile button, and
the first error gets highlighted. For instance, when I compiled the
following code snippet:
if (a == 1) {
a = b - 1
b = a + 1
}
my compiler highlighted everything from the number "1" at the end of the
second line to the letter "b" at the beginning of the third line and said:
"Tokens not separated by an operator." The error message may not make sense
to you, but you would probably notice quickly that the highlight connected
two different lines and say, "Oops, I forgot the semi-colon."
My editor isn't compatible with any other authoring systems, though, so it
won't be much use until I finish the entire package.
-Rúmil
Jeff Hatch
> A "good" system of IF would have a set of (customizable) defaults for
> everything and allow tailoring of specific items. If this were going to
> happen it would probably require a common platform and the combined efforts
> of everyone here.
Don't most systems do that? Can you clarify?
-Rúmil, confused
okbl...@usa.net
> > A "good" system of IF would have a set of (customizable) defaults for
> > everything and allow tailoring of specific items. If this were going to
> > happen it would probably require a common platform and the combined efforts
> > of everyone here.
In article <35A583D5...@hatch.net>,
Jeff Hatch <je...@hatch.net> wrote:
> Don't most systems do that? Can you clarify?
The key word in my statement is "everything". A more traditional work of IF
would have to be done by eliminating items, probably.