Parsers

111 views
Skip to first unread message

John Fred Connors

unread,
Aug 8, 1999, 3:00:00 AM8/8/99
to
I have been reading the recent thread about programming
languages and parsing with some interest. I guess there
are many langauages that could be used for IF, the
most popular being LISP/SCHEME, C++ or Java, which is
pretty much sensible.

This isn't to add any more comment to the language war,
but to point out that there are many parser building
tools in complier - construction land. Bison, Jack, Jack,
Antlr, whatever. Why cannot these be used to construct
IF parsers? What is special about the IF parser that
it needs specialised code?

Just wondering..!

John Fred
http://www.yagc.demon.co.uk


Andrew Plotkin

unread,
Aug 8, 1999, 3:00:00 AM8/8/99
to

YACC and its derivatives are designed to deal with computer languages.
Computer languages are designed to be elegant, simple, and unambiguous.

IF-English is, um... not. :-)

In fact, it's simple in the ways that computer languages are complex, and
vice versa. There are no recursive syntax structures, which is what formal
grammars and compiler-compilers are really good at. It's just "verb noun"
and "verb noun preposition noun", and similar patterns, all of strictly
limited length. But the elements require all sorts of hairy, game-related,
and ad-hoc disambiguation.

There's also the code-building model. When you're writing a game, you're
constantly adjusting and tweaking the parser, *and* everything the parser
is integrated with. If you used an existing, stand-alone program such as
YACC, you'd have to re-run it constantly. You'd really want to integrate
it with the IF development tool; but this is a nuisance.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Steve Feil

unread,
Aug 9, 1999, 3:00:00 AM8/9/99
to
John Fred Connors wrote:
>
> I have been reading the recent thread about programming
> languages and parsing with some interest. I guess there
> are many langauages that could be used for IF, the
> most popular being LISP/SCHEME, C++ or Java, which is
> pretty much sensible.
>
> This isn't to add any more comment to the language war,
> but to point out that there are many parser building
> tools in complier - construction land. Bison, Jack, Jack,
> Antlr, whatever. Why cannot these be used to construct
> IF parsers? What is special about the IF parser that
> it needs specialised code?
>
> Just wondering..!
>
> John Fred
> http://www.yagc.demon.co.uk

Use inform6


here is why...

I worked on a software project that involved parsing computer
languages, actually hardware description languages. A fellow
programmer worked with the parser, and I helped him a bit.

The classic Unix model for parsing is to use two programs called lex
and Yacc to create a 'C' program that does the parsing. You can use
Lex with out Yacc but Yacc depends on Lex. Using Lex without Yacc
will only separate out words. The free software foundation has there
implementation of Lexx and Yacc called Flexx and Bison. To be a
hair-splitter Lexx and Yacc are programs that come with a Unix system
when you buy the OS and are owned by the company which supplies your
Unix (ie sun,IBM,HP,etc ). Most people use the words Flexx and Lexx
interchangeably along with Yacc and Bison. I believe you can get a
version of Flexx and Bison for non-Unix systems(win/DOS).

The newer way of doing computer language parsing is with a program
called Antlr which works in a single step. There is a version of Antlr
that produces C code and one that works with Java.

In the project that my office worked on, we started using Bison then
we switched to using Antlr, because there where places that Bison just
could not figure out how to parse correctly (the other guy knows
more about the nature of this that I do). In that since Antler is more
advanced than Yacc.

I'm not sure if Lexx or Antler is very fitting to parsing a a human
like language. Both are designed to parse a highly structured,
higher-ark-tical(sp?) and recursive language. Thing of it like
this...

To parse 'C' you would define a_block_of_code. Then you would would
define things that could be found in a_block_of_code like
a_while_block and an_if_block a_for_block. You would say that
an_if_block contains an_expression_block followed by a_block_of_code
then possibly ('else' statement followed by
a_block_of_code). Note the second a_block_of_code is present if and
only if the 'else' statement is present.

You should then see that the 'if' statement could contain a block of
code that contains another 'if' statement that has a block of code
after the 'else' statement. This could be continued for any number of
times. Thus the recursive nature of computer languages, that Lexx and
antler are designed to work with. Human languages just don't have this
level of structure.

I feel that the inform6 library is better suited to parsing human
languages. If you are bound and determined to use C/C++ without
resorting to a text adventure language I thing antler would be better
than yacc.


========================================================================
Steven Feil | Gram-pa, back at the turn of the .~.
Programmer/Developer | century, why did people use an /V\
sf...@io.com | operating system, when they were not // \\
| allowed to see the source code? (X_X)
========================================================================

Knight37

unread,
Aug 10, 1999, 3:00:00 AM8/10/99
to

John Fred Connors <jo...@yagc.demon.co.uk> wrote

> I have been reading the recent thread about programming
> languages and parsing with some interest. I guess there
> are many langauages that could be used for IF, the
> most popular being LISP/SCHEME, C++ or Java, which is
> pretty much sensible.

> This isn't to add any more comment to the language war,
> but to point out that there are many parser building
> tools in complier - construction land. Bison, Jack, Jack,
> Antlr, whatever. Why cannot these be used to construct
> IF parsers? What is special about the IF parser that
> it needs specialised code?

Ok, I hate to answer a question with a question, but why
would an aspiring adventure writer want to rewrite a parser,
when several people have already put a lot of blood, sweat,
and tears into abstracting this away from the IF authoring
process by making IF specialized lanaguages available to
use (for free I might add)? I mean, I can understand why
a *programmer* might want to do it just for shits and
giggles, otherwise we'd probably never have these free IF
languages, but I can't understand why someone who is
primarily interested in writing IF would want to waste their
time on this. Reinventing the wheel, yada, yada, yada.

Aside from that, I think that IF languages do more than
simply provide a parser library. I mean, if that's all they
did, then yes, it would be better for a C programmer to go
ahead and use C and find a parser library for C rather than
to have to spend time learning a new language. But IF
languages add a LOT of IF-specific help to the programmer,
like daemons, and object behavior, and navigation, etc.
A C programmer would have to code all of this by hand.
Furthermore, I feel that the syntax of IF languages is more
intuitive for writing IF than C or other general purpose
languages would be. If you want a room you use a ROOM
command or something similar. If you want an object you
use an OBJECT command, and maybe give it a CONTAINER
attribute or whatever. Obviously actual syntax varies from
IF language to IF language, and some are more intuitive
than others, but they are all suited for writing IF.

Of course, a third reason is that IF languages are generally
easier to learn and use for novices than general purpose
languages. I've seen a lot of people who can't program
write IF reasonably well. Of course, it might be somewhat
helpful to know programming first, but it does not appear
to be a requirement. I also think "the big 3" IF languages
provide enough functionality to do nearly anything an IF
author would want to do, and to make it easier to do this
than it would be in a general-purpose language.

Knight37


Jon Zeppieri

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
Ooh. Ooh. Let me in on this.

In article <omXr3.91$M7....@news.flash.net>,


"Knight37" <goo...@blue.net> wrote:
>
> Ok, I hate to answer a question with a question, but why

> would an aspiring adventure writer want to rewrite a parser...
[snip]
> I mean, I can understand why a *programmer* might want to do it...
[snip]

These are *not* disjoint sets. The best IF writers (in my experience,
of course) tend to be very skilled programmers. There aren't many
reasons to reinvent the wheel, but an IF system is not a wheel. It's
one of those big, confusing movie computers from the early eighties with
lots of flashing lights and steel toggles. Now *there's* something that
could stand to be re-invented -- at least a baker's dozen times.

>
> Aside from that, I think that IF languages do more than
> simply provide a parser library. I mean, if that's all they
> did, then yes, it would be better for a C programmer to go
> ahead and use C and find a parser library for C rather than
> to have to spend time learning a new language. But IF
> languages add a LOT of IF-specific help to the programmer,
> like daemons, and object behavior, and navigation, etc.

No. IF *languages* do not provide these things. Libraries, written
*in* those languages provide these things. What IF languages do provide
is syntactic sugar. This is not an insult; it is nice to have terse
syntax for commonly used features of a language. Personally, I don't
consider this a big deal either way. The difference between:

Verb 'stand'
* -> Exit
* 'up' -> Exit
* 'on' noun -> Enter;

and

Verb standVerb = new Verb("stand",
new Pattern(exitAction),
new Pattern(exitAction, {isLiteral("up")}),
new Pattern(enterAction,
{isLiteral("on"), isNoun()}));

[or whatever -- this is a contrived example]

...is simply a matter of verbosity, and I don't have carpal tunnel
(yet).

And (getting back to the original point), quite frankly, implementing
things like daemons is almost trivial. The parser and its interaction
with the "world" is easily the most complex part of an IF system.
Note that a parser generator like yacc is more or less useless in this
case. I think that Zarf already made this point, though.

> A C programmer would have to code all of this by hand.
> Furthermore, I feel that the syntax of IF languages is more
> intuitive for writing IF than C or other general purpose
> languages would be. If you want a room you use a ROOM
> command or something similar. If you want an object you
> use an OBJECT command, and maybe give it a CONTAINER
> attribute or whatever. Obviously actual syntax varies from
> IF language to IF language, and some are more intuitive
> than others, but they are all suited for writing IF.

Yes. The syntax is more appropriate to the task.

>
> Of course, a third reason is that IF languages are generally
> easier to learn and use for novices than general purpose
> languages. I've seen a lot of people who can't program
> write IF reasonably well.

I haven't. I don't say this to be a jackass; it's just been my
experience. [Putting on my asbestos suit -- good for the lungs, you
know...] Graphical, whiz-bang IDEs, promising a point-and-click
interface to writing IF will not produce anything of value. Apologies
to anyone who has written such a system. I would love to be proven
wrong. But this isn't your point, I know. You mean that languages like
Inform or TADS are simpler to learn that general purpose languages.

But I don't agree. Syntactic sugar makes a language easier to use, not
to learn. Consistency and *semantic* simplicity make a language easier
to learn.

For the most part, general purpose languages tend to be more consistent
and semantically simpler than (good) IF authoring languages. This is
because a specialized language is going to have specialized semantics --
which is all well and good if it does what you want. But don't tell me
it makes the language easier to learn, 'cause I'm not buying it.

-jaz

> Of course, it might be somewhat
> helpful to know programming first, but it does not appear
> to be a requirement. I also think "the big 3" IF languages
> provide enough functionality to do nearly anything an IF
> author would want to do, and to make it easier to do this
> than it would be in a general-purpose language.
>
> Knight37
>
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Alex Warren

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
On Wed, 11 Aug 1999 04:47:22 GMT, Jon Zeppieri pondered:

> Graphical, whiz-bang IDEs, promising a point-and-click
> interface to writing IF will not produce anything of value. Apologies
> to anyone who has written such a system.

I have written such a system, and as far as I know there are absolutely no other
systems available at present which have such a point-and-click editor (at least,
not to any great extent) - so where is your evidence that "writing IF [in such a
system] will not produce anything of value"?

--
Alex Warren · ICQ: 4043750 · http://come.to/axe · http://come.to/perdition
email: my name, followed by an at, then writeme dot com (From: address is fake)

Andrew Plotkin

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
Alex Warren <S...@the.sig.com> wrote:
> On Wed, 11 Aug 1999 04:47:22 GMT, Jon Zeppieri pondered:
>
>> Graphical, whiz-bang IDEs, promising a point-and-click
>> interface to writing IF will not produce anything of value. Apologies
>> to anyone who has written such a system.
>
> I have written such a system, and as far as I know there are absolutely no other
> systems available at present which have such a point-and-click editor (at least,
> not to any great extent) - so where is your evidence that "writing IF [in such a
> system] will not produce anything of value"?

Because I presume (and it *is* presumption) that everyone in the universe
is just like me. And I know I can't produce anything of value with such a
thing.

....No, I don't mean that too seriously. But there *is* that Inform IDE --
I've never seen it go, since it's a Windows program, but I've never heard
anyone else swear it made their life easier either.

I *have* seen point-and-click, non-textual "programming" systems. Usually
intended as deliberate puzzles, such as the logic-gate toolkit in the old
Robot Odyssey game. Good as entertainment, but not for getting real work
done.

I once used a point-and-click Pascal development system. Still a textual
programming language underneath, but you built loops, if-statements, and
so on by selecting them from menus. It was *awful*.

I designed a entirely graphical system myself, for creating ripply marble
patterns (and so on.) That's a strictly limited domain -- but even there,
I ran into real scalability problems and annoying boundaries to
expressiveness, before I shelved the project. (I'd like to pick it up
again, but, well, I'd like to pick up all sorts of things again.)

Andrew Plotkin

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
Jon Zeppieri <97...@my-deja.com> wrote:
> For the most part, general purpose languages tend to be more consistent
> and semantically simpler than (good) IF authoring languages. This is
> because a specialized language is going to have specialized semantics --
> which is all well and good if it does what you want. But don't tell me
> it makes the language easier to learn, 'cause I'm not buying it.

Would you buy that a good IF language (*including* its library) is easier
to learn than a general purpose language (*including* an equivalently
powerful IF support library, written in that language)?

Alex Warren

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
On 11 Aug 1999 13:57:35 GMT, Andrew Plotkin pondered:

> >> Graphical, whiz-bang IDEs, promising a point-and-click
> >> interface to writing IF will not produce anything of value. Apologies
> >> to anyone who has written such a system.
> >
> > I have written such a system, and as far as I know there are absolutely no other
> > systems available at present which have such a point-and-click editor (at least,
> > not to any great extent) - so where is your evidence that "writing IF [in such a
> > system] will not produce anything of value"?
>
> Because I presume (and it *is* presumption) that everyone in the universe
> is just like me. And I know I can't produce anything of value with such a
> thing.
>
> ....No, I don't mean that too seriously. But there *is* that Inform IDE --
> I've never seen it go, since it's a Windows program, but I've never heard
> anyone else swear it made their life easier either.

All down to the specific implementation, surely? You can't just dismiss *ALL*
graphical editors just because there was one, once, that wasn't so popular!

I've never seen this Inform IDE but my guess is that if it didn't catch on, it
was because it was awkward to use - more awkward to use than just tapping in
code. But then, individual preference comes in - I expect that most people in
this newsgroup are of the
like-getting-stuff-done-really-fast-and-ain't-scared-of-the-keyboard brigade,
with a head full of keyboard shortcuts and a good head for programming. More
novice users much prefer the
i-can-see-what-i-need-on-the-screen-so-all-i-have-to-do-is-click-it variety and
so a visual editor is going to appeal more to this kind of person, and they'll
be able to create games much quicker in this more friendly environment. I expect
a lot of newcomers to computers and Windows etc. would find it pretty much
impossible to get started with an IF system if they have to do loads of coding
and looking up of commands and syntax in reference manuals - there must be a
huge gap in the market for a nice friendly game editor, which is why I created
QDK.


> I once used a point-and-click Pascal development system. Still a textual
> programming language underneath, but you built loops, if-statements, and
> so on by selecting them from menus. It was *awful*.

But then, only because you were used to tapping out the raw Pascal code anyway,
I should imagine. Imagine if you had no knowledge of Pascal whatsoever, and you
had this kind of system where you could just click what you wanted - a godsend,
at least until you got to know the language, I should imagine.

> I designed a entirely graphical system myself, for creating ripply marble
> patterns (and so on.) That's a strictly limited domain -- but even there,
> I ran into real scalability problems and annoying boundaries to
> expressiveness, before I shelved the project. (I'd like to pick it up
> again, but, well, I'd like to pick up all sorts of things again.)

Annoying boundaries only exist if the editing software isn't flexible enough. If
you allow the more advanced users to add raw code somehow, as in practically any
HTML editor (and indeed in my own QDK), these boundaries of the editing software
shouldn't present a problem.

okbl...@my-deja.com

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
In article <7orvke$6...@dfw-ixnews11.ix.netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>
> Would you buy that a good IF language (*including* its library) is
> easier to learn than a general purpose language (*including* an
> equivalently powerful IF support library, written in that language)?
>

Ah, quite to the point.

In theory, not necessarily. In practice, without a question.

In order for the theoretical to come about, however, you'd need learning
tools which focussed on
learning-the-language-by-programming-IF-using-this-library.

And when you were done, while the student would have learned the
language and the IF library, he would be deficient in all the other
areas of programming in that language (in particular, the often massive
and non-IF-related libraries that go along with programming these days).

You get into a gray area very quickly, since you could argue both that a
person who could only program IF in C didn't really know C and that a
person who can't program anything *but* IF in Inform didn't really know
Inform.

The absence of general purpose languages being used to build IF should,
perhaps, be considered evidence to support the basic thesis though.
--
[ok]

Jon Zeppieri

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
In article <7orvke$6...@dfw-ixnews11.ix.netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:

> Would you buy that a good IF language (*including* its library) is
easier
> to learn than a general purpose language (*including* an equivalently
> powerful IF support library, written in that language)?
>

> --Z

Maybe. (Damn, I love equivocation.)

Really, though, it depends on what you want to do. If the current
libraries are sufficient for your task, then sure. I'm no glutton for
punishment, and I have plenty of work to do. But one of the major
reasons I want to write IF libraries in a general purpose language (I
haven't gotten very far) is to be able to use the rich set of language
and library features -- non IF-related features -- already available.

Let's say I wanted an NPC to play a game of chess against the player.
Each time it is the NPC's turn, he thinks; this might take awhile; in
game time, it really *ought* to take more than one move (unless they're
playing blitz, or something). That is, you don't want the player to sit
there, waiting for a prompt to reappear. You also don't want the
computer to stop processing, though, or else the NPC's move will be
*very* weak. Concurrency would be rather useful in this case.

Basically, you don't *need* a lot of features to write IF, but it's
always nice to have them around.

-jaz

Jon Zeppieri

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
In article <37b16c78...@read.news.global.net.uk>,

S...@THE.SIG.COM (Alex Warren) wrote:
> I have written such a system, and as far as I know there are
absolutely no other
> systems available at present which have such a point-and-click editor
(at least,
> not to any great extent) - so where is your evidence that "writing IF
[in such a
> system] will not produce anything of value"?

1. ...what Zarf said.
2. As I said in my original post: I look forward to someone proving me
wrong. That could only mean good things.
3. If you want an actual *argument*, here it is:

There are severe limits to what can be accomplished in a GUI (at least,
a familiar, window-based GUI) without either making things more
difficult than they actually are or seriously straining the graphical
metaphor. Here's a problem that's more difficult than it might
immediately appear: how would you go about building the boolean
expression

((A v B) ^ C)

using a GUI?

Knight37

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to

Jon Zeppieri <97...@my-deja.com> wrote

> Ooh. Ooh. Let me in on this.
>
> In article <omXr3.91$M7....@news.flash.net>,
> "Knight37" <goo...@blue.net> wrote:
> >
> > Ok, I hate to answer a question with a question, but why
> > would an aspiring adventure writer want to rewrite a parser...
> [snip]
> > I mean, I can understand why a *programmer* might want to do it...
> [snip]
>
> These are *not* disjoint sets.

Well duh. Did I ever say they were?

> The best IF writers (in my experience, of course) tend to be very
> skilled programmers.

I'd probably go along with that too. I go along with that because
IF has its roots in the programming community, people who have done
more than one work of IF tend to be better at it, and after you've
done a few IF's, you ARE a programmer.

> There aren't many
> reasons to reinvent the wheel, but an IF system is not a wheel. It's
> one of those big, confusing movie computers from the early eighties with
> lots of flashing lights and steel toggles. Now *there's* something that
> could stand to be re-invented -- at least a baker's dozen times.

By this you're suggesting that there is a real need to reinvent
the parser when an IF author is attempting to code a new game?

> > Aside from that, I think that IF languages do more than
> > simply provide a parser library. I mean, if that's all they
> > did, then yes, it would be better for a C programmer to go
> > ahead and use C and find a parser library for C rather than
> > to have to spend time learning a new language. But IF
> > languages add a LOT of IF-specific help to the programmer,
> > like daemons, and object behavior, and navigation, etc.
>
> No. IF *languages* do not provide these things. Libraries, written
> *in* those languages provide these things.

Oh boy. Thanks for pointing that one out. It really matters so
much.

> What IF languages do provide is syntactic sugar.

Syntactic "sugar" as you call it, is a major improvement in
my eyes. You may not think so, others think it means a great deal.

> Verb 'stand'
> * -> Exit
> * 'up' -> Exit
> * 'on' noun -> Enter;
>
> and
>
> Verb standVerb = new Verb("stand",
> new Pattern(exitAction),
> new Pattern(exitAction, {isLiteral("up")}),
> new Pattern(enterAction,
> {isLiteral("on"), isNoun()}));
>
> [or whatever -- this is a contrived example]
>
> ...is simply a matter of verbosity, and I don't have carpal tunnel
> (yet).

Yes, it's a matter of verbosity and readability. The former is
MUCH clearer to me if I'm reading it. Not to mention takes less
time to type. I think that's a significant advantage.

> And (getting back to the original point), quite frankly, implementing
> things like daemons is almost trivial. The parser and its interaction
> with the "world" is easily the most complex part of an IF system.
> Note that a parser generator like yacc is more or less useless in this
> case. I think that Zarf already made this point, though.

All of the other things besides the parser that IF languages
(and their libraries, sheesh), are major time savers, not to
mention cut out a lot of complexity for the novice.

> > Of course, a third reason is that IF languages are generally
> > easier to learn and use for novices than general purpose
> > languages. I've seen a lot of people who can't program
> > write IF reasonably well.
>
> I haven't.

I said "reasonably". I should have been more clear. I meant that
IF languages are easier to learn for writing IF than general
purpose programming languages are. In other words, a novice
programmer can get more IF written faster by choosing an IF
language than by trying to code the thing in a general purpose
language. And again, by "language" I'm including standard
libraries associated with those languages too, of course.

> Graphical, whiz-bang IDEs, promising a point-and-click

> interface to writing IF will not produce anything of value.

I don't know if I'd go so far as to say that. I have yet to
see any good IF produced by any current offerings of that
kind of interface. I'm not an oracle, though. It's the
"will not" that I don't necessarily agree with. I won't say
you're wrong, either, though.

> But this isn't your point, I know. You mean that languages like
> Inform or TADS are simpler to learn that general purpose languages.

Actually I was thinking that they're easier to learn IF writing
in. Not programming in general. I mean, if I take a complete
novice. I put Inform in front of him. Or I put Borland C++ in
front of him. I think I'll get a work of IF out of him a lot
sooner if I gave him Inform. Call me crazy.

Knight37


Alex Warren

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
On Wed, 11 Aug 1999 22:36:33 GMT, Jon Zeppieri pondered:

> In article <37b16c78...@read.news.global.net.uk>,
> S...@THE.SIG.COM (Alex Warren) wrote:
> > I have written such a system, and as far as I know there are
> absolutely no other
> > systems available at present which have such a point-and-click editor
> (at least,
> > not to any great extent) - so where is your evidence that "writing IF
> [in such a
> > system] will not produce anything of value"?
>
> 1. ...what Zarf said.
> 2. As I said in my original post: I look forward to someone proving me
> wrong. That could only mean good things.

Hopefully it won't be too long... (well, I only just released 1.0 Beta 2, we
have to give these things time <g>)

> 3. If you want an actual *argument*, here it is:
>
> There are severe limits to what can be accomplished in a GUI (at least,
> a familiar, window-based GUI) without either making things more
> difficult than they actually are or seriously straining the graphical
> metaphor. Here's a problem that's more difficult than it might
> immediately appear: how would you go about building the boolean
> expression
>
> ((A v B) ^ C)
>
> using a GUI?

Depends on what that would mean to the program that would run the resulting
source file. Assuming it would just mean ((A union B) intersection C) and
nothing more interesting, it could be done a number of ways. Of course, it's
never going to be as quick as it is for a clued-up programmer who can of course
just type ((A v B) ^ C) - but then nothing is ever as quick with a GUI as it is
with a good old keyboard.

Still, you could create a "Boolean Expression Builder", in which you could add
the brackets and the symbols to the above - wouldn't be too intuitive or
user-friendly though, but still possible.

Better, I'd use a similar "actions" system to the one I use in QDK - the
author/programmer/whoever gets a list of actions, maybe like "intersection",
"union", "put the previous result into a variable" etc. Each of these has a
parameter that the author/programmer types in.

For ((A v B) ^ C), they would:

- Select "union", and enter two parameters - A and B
- select "put the previous result into a variable" and enter one parameter, X or
something similar.
- Select "interesction" and enter two parameters, X and C.

The above is of course very artificial, but then so was the original question.
So, it can be done and it wouldn't be too hard to implement or for a
programmer/author to use, in theory anyway. Of course, many people do prefer to
code - visual editors can be useful, but they're not to everybody's taste, and
this is demonstrated by the fact that although Beta 1 of QDK has been available
for two months now, it seems there are more people still coding than there are
using the visual editor. I still have plenty of hope for it though!

David Cornelson

unread,
Aug 11, 1999, 3:00:00 AM8/11/99
to
Alex Warren <S...@THE.SIG.COM> wrote in message
news:37b60058...@read.news.global.net.uk...

> On Wed, 11 Aug 1999 22:36:33 GMT, Jon Zeppieri pondered:
>
> > In article <37b16c78...@read.news.global.net.uk>,
> > S...@THE.SIG.COM (Alex Warren) wrote:
> > > I have written such a system, and as far as I know there are
> > absolutely no other
> > > systems available at present which have such a point-and-click editor
> > (at least,
> > > not to any great extent) - so where is your evidence that "writing IF
> > [in such a
> > > system] will not produce anything of value"?
> >
> > 3. If you want an actual *argument*, here it is:
> >
> > There are severe limits to what can be accomplished in a GUI (at least,
> > a familiar, window-based GUI) without either making things more
> > difficult than they actually are or seriously straining the graphical
> > metaphor. Here's a problem that's more difficult than it might
> > immediately appear: how would you go about building the boolean
> > expression
> >
> > ((A v B) ^ C)
> >
> > using a GUI?
>
> Depends on what that would mean to the program that would run the
resulting

Crap crap crap....

A GUI IF system would never be reduced to implementing an interface for this
type of condition. You would simply have an expression evaluator that
determined TRUE, FALSE, or possibly UNDEFINED. Assuming in the example below
that IF and [IS TRUE] [IS FALSE] [UNDEFINED] are part of the GUI interface,
then {expression} is whatever legitimate expression available to any common
programming language. {action} is the result taken if the condition is met
or not met.

[IF] {expression} [IS TRUE] {action}
[IF] {expression} [IS FALSE] {action}
[IF] {expression} [IS UNDEFINED] {action}

In my example, {expression} could point to another function altogether. So
you could theortically have:

[IF] {LionsAttack()} [IS TRUE] {PLAYER.AddHit();}

In my mind, a GUI won't write complex algorythms for you. You'll still need
to eventually progress to a point where you know how to create very complex
decision processes. But as a beginner and intermediate developer, you could
'lean' on the GUI to help you make good programming decisions. Then, as you
get better with the language, your expressions get more complex and then you
start clicking the checkbox next to GUI field that allows you to just write
the code instead of relying on the builtin mechanisms.

I write user interfaces for a living and although I've come around to
Plotkins thinking to some degree (IF is a very complex artform that requires
both writing and programming skills and _nothing_ will change that) I _do_
believe that an effective GUI could be designed and created.

I also know that I couldn't do it without the cooperation of zarf or someone
like him. So it's one of life's little conundrums. I understand the GUI part
of it and Plotkin knows the guts. Together we could do it, but one of us
feels a zealous disbelief in the result and the other simply doesn't have
the time.

I'm sorry - but in my mind I picture a 'drop-down' or 'pull-down' list of
all of my objects, properties, and attributes in the proper places and that
would be cool. I think Java boy was close (don't remember what he called his
system) but he seems to have disappeared.

My two cents.

Jarb

Jon Zeppieri

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
In article <NFms3.406$%Y3....@news.flash.net>,

"Knight37" <goo...@blue.net> wrote:
> >
> > These are *not* disjoint sets.
>
> Well duh. Did I ever say they were?
>

...? I must have missed the point your were trying to make, then.
Sorry.

> > There aren't many
> > reasons to reinvent the wheel, but an IF system is not a wheel.
It's
> > one of those big, confusing movie computers from the early eighties
with
> > lots of flashing lights and steel toggles. Now *there's* something
that
> > could stand to be re-invented -- at least a baker's dozen times.
>
> By this you're suggesting that there is a real need to reinvent
> the parser when an IF author is attempting to code a new game?
>

Now you're missing *my* point. If you think my paragraph means what you
said....well, then we aren't speaking the same language. And it is
beginning to feel that way, like a contorted Wittgenstinian example.

> > > Aside from that, I think that IF languages do more than
> > > simply provide a parser library. I mean, if that's all they
> > > did, then yes, it would be better for a C programmer to go
> > > ahead and use C and find a parser library for C rather than
> > > to have to spend time learning a new language. But IF
> > > languages add a LOT of IF-specific help to the programmer,
> > > like daemons, and object behavior, and navigation, etc.
> >
> > No. IF *languages* do not provide these things. Libraries, written
> > *in* those languages provide these things.
>
> Oh boy. Thanks for pointing that one out. It really matters so
> much.
>

[Resisting the urge...]

Of course it matters. This thread is about parsers (and now, more
generally, IF libraries) written for general-purpose languages, right?
My point is that all of these nifty things like daemons and navigation
(I'll leave out "object behavior," because I'm not entirely sure what
you mean by that) -- which you are claiming as virtues of IF-specific
languages -- are really libraries. And why can't they be implemented
just as well in a general purpose language? And if they are implemented
as well in a general purpose language, will the result *really* be
harder to learn than Inform or TADS? These are the questions I'm
interested in.

> > And (getting back to the original point), quite frankly,
implementing
> > things like daemons is almost trivial. The parser and its
interaction
> > with the "world" is easily the most complex part of an IF system.
> > Note that a parser generator like yacc is more or less useless in
this
> > case. I think that Zarf already made this point, though.
>
> All of the other things besides the parser that IF languages
> (and their libraries, sheesh), are major time savers, not to
> mention cut out a lot of complexity for the novice.
>

I'm beginning to get the sense that you think I'm arguing something that
I'm not.

I am NOT saying that a new IF author should first create his/her own IF
system (unless, of course, he/she wants to). I AM saying that IF
libraries for a general purpose language would be desirable -- for me,
as well as others. And I AM speculating that they might even be easier
to learn for novices -- but I am NOT claiming this as revealed truth. I
AM claiming that general purpose languages, in general (i.e. not
necessarily for the purpose of writing IF), are almost certainly easier
to learn than IF-specific languages. I really do believe this. BUT,
for the *express* purpose of writing IF, an IF-specific language *may
be* easier -- I don't really think it is, but I do acknowledge the
possibility.

I hope my argument is now less offensive to you.

> > But this isn't your point, I know. You mean that languages like
> > Inform or TADS are simpler to learn that general purpose languages.
>
> Actually I was thinking that they're easier to learn IF writing
> in. Not programming in general. I mean, if I take a complete
> novice. I put Inform in front of him. Or I put Borland C++ in
> front of him. I think I'll get a work of IF out of him a lot
> sooner if I gave him Inform. Call me crazy.

Like I said, it may be the case that IF languages are easier to learn
for writing IF -- but I do not consider this necessarily true. If that
sounds funny, let me retreat to what was probably the most important
point I made in my previous post:

IF languages (yes, with libraries) are *certainly* easier to *use* for
IF programming. That does not mean that they are easier to learn. And
yes, I do think this is a very real and important distinction.

And I'm (of course) not talking about handing a novice Borland C++ and
saying, "Go write some IF." I'm talking about handing a novice a SANE
language with reasonable semantics *and* a set of well designed, well
documented IF libraries and sending him off.

Handing a novice C++ would be like telling him to go fuck himself. In
East Timor.

Jon Zeppieri

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Apology: this post is SO off-topic (well, for the current thread),
but...

In article <7orvgf$6...@dfw-ixnews11.ix.netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:

> I *have* seen point-and-click, non-textual "programming" systems.
Usually
> intended as deliberate puzzles, such as the logic-gate toolkit in the
old
> Robot Odyssey game. Good as entertainment, but not for getting real
work
> done.

You know, my parents bought me Robot Odyssey for my Apple //c years and
years ago. And I loved that game. And for years I figured that nobody
else had ever even heard of it. But these days, references to it keep
popping up all over the net.

I never finished it (for which I consider myself an abject failure).
Never got past the "minefield."

Anyway...

Joe Mason

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
>You know, my parents bought me Robot Odyssey for my Apple //c years and
>years ago. And I loved that game. And for years I figured that nobody
>else had ever even heard of it. But these days, references to it keep
>popping up all over the net.

When I was in grade 3 or thereabouts, my school got a shipment of Apples
with a box of games, and they set them up in a big room and cycled classes
through it for an hour a day for a week. (I guess they passed it on to
another school after that.) I remember seeing people playing one of the old
Ultima's, Load Runner, Paperboy - but I always grabbed Robot Odyssey.

Never got too far. Of course, I only had a week. But I whenever I hear the
term "flip-flop", I still get a picture of an Apple II graphic in my mind,
because that's where I first encountered the term.

(Nowadays it's also accompanied by a crazed voice screaming, "IT WORKS
FLIP-FLOP!")

Joe

Erik Max Francis

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Joe Mason wrote:

> I remember seeing people playing one of
> the old
> Ultima's, Load Runner, Paperboy - but I always grabbed Robot Odyssey.

Would someone give a brief description of this game? Sounds
interesting.

--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon@efnet / finger m...@members.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
__ USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
/ \__ \
\__/ \ / I want to know God's thought; the rest are details.
\__/ / Albert Einstein

Alex Warren

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
On Wed, 11 Aug 1999 22:31:27 -0500, David Cornelson pondered:

> > > ((A v B) ^ C)
> > >
> > > using a GUI?
> >
> > Depends on what that would mean to the program that would run the
> resulting
>
> Crap crap crap....

Only "crap" that I was challenged to demonstrate...

> In my mind, a GUI won't write complex algorythms for you.

Certainly not. Possible, but very awkward. But then, how many IF games need many
very complex algorithms?

> I'm sorry - but in my mind I picture a 'drop-down' or 'pull-down' list of
> all of my objects, properties, and attributes in the proper places and that
> would be cool. I think Java boy was close (don't remember what he called his
> system) but he seems to have disappeared.

Is QDK not similar to this vision?

Mark J Musante

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Erik Max Francis (m...@alcyone.com) wrote:
> Joe Mason wrote:
>
> > I remember seeing people playing one of
> > the old
> > Ultima's, Load Runner, Paperboy - but I always grabbed Robot Odyssey.
>
> Would someone give a brief description of this game? Sounds
> interesting.

You control robots in a maze. You can program them by wiring gates
together (and, or, etc). Each robot, which are square, has four sensors
to tell whether it's bumped into a wall, and four directional jets to
move it around. Also and antenna and a transmitter to communicate with
other robots (or a remote control).

You can also make simple chips in the chip lab. Each chip has 8 pins
and you can create a little circuit within it.

It was an interesting little game. I've not seen its like again.


-=- Mark -=-

Jon Zeppieri

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
In article <37B28304...@alcyone.com>,

Erik Max Francis <m...@alcyone.com> wrote:
> Joe Mason wrote:
>
> > I remember seeing people playing one of
> > the old
> > Ultima's, Load Runner, Paperboy - but I always grabbed Robot
Odyssey.
>
> Would someone give a brief description of this game? Sounds
> interesting.

It's the best educational game I've ever played. The premise is kind of
silly: you're some guy who, one night, mysteriously falls into this
underground society, peopled by robots. You start off, I believe, in a
junk yard, where you find three discarded robots and a toolkit of
digital logic parts. All of the puzzles in the game revolve around
actually programming your robots, using the tooklit, to solve some
problem. There are five levels to the game, and it gets quite
difficult. I even remember the box (which is almost certainly still
sitting around my parents' house) bragging that less than five percent
of the people who played the game ever solved it.

Jon Zeppieri

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
In article <37b2aa9...@read.news.global.net.uk>,

S...@THE.SIG.COM (Alex Warren) wrote:
> On Wed, 11 Aug 1999 22:31:27 -0500, David Cornelson pondered:
>
> > > > ((A v B) ^ C)
> > > >
> > > > using a GUI?
> > >
> > > Depends on what that would mean to the program that would run the
> > resulting
> >
> > Crap crap crap....
>
> Only "crap" that I was challenged to demonstrate...

Yes :)

It actually had to do (in my mind) with a project that I'm supposed to
implement at work -- which is a graphical fontend to a (database) query
engine, in which building expressions is the name of the game.

Here's the catch: the client is a web browser, so we're limited to the
expressiveness of HTML. Ouch.

Jake Wildstrom

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
In article <FGCn4...@world.std.com>,

Mark J Musante <olo...@world.std.com> wrote:
>You control robots in a maze. You can program them by wiring gates
>together (and, or, etc). Each robot, which are square, has four sensors
>to tell whether it's bumped into a wall, and four directional jets to
>move it around. Also and antenna and a transmitter to communicate with
>other robots (or a remote control).

You fail to mention how INSANELY DIFFICULT it is. The first level is easy. The
second level has maybe one or two slightly challenging puzzles. The third level
has a couple of moderately challenging puzzles and one seriously obnoxious
cooperation puzzle. The fourth level has four puzzles, at least two of which
are quite difficult (it's possible to beat the High Voltage puzzle by dumb
luck and/or patience). As for the fifth level.... well, what I saw of it was
pretty damn wierd and quite unlike the other four. But I never made it very far
(hell, I never even beat the 4th level, just went on without completing
everything. Damn that Force Field puzzle!).

>It was an interesting little game. I've not seen its like again.

Nor I. I suggested, non-facetiously, to my 9th grade computer science teacher
(teaching us Boolean algebra and circuitry), that we should just get a bunch of
Apple emulators and work in Robot Odyssey.

Incidentally, the GUI, which everyone is (ostensibly) discussing, is not
original to Robot Odyssey. The Learning Company's previous circuitry game,
Rocky's Boots, featured a similar working environment, but with fewer gates and
without the solderpen.

+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+

Andrew Plotkin

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Alex Warren <S...@the.sig.com> wrote:
>> In my mind, a GUI won't write complex algorythms for you.
>
> Certainly not. Possible, but very awkward. But then, how many IF games need many
> very complex algorithms?

All the ones I've written.

The majority of the game code isn't complex; small fragments are, well,
programming. Programming gets arbitrarily complex.

ct

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
In article <7ouj3r$8...@dfw-ixnews17.ix.netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>Alex Warren <S...@the.sig.com> wrote:
>>> In my mind, a GUI won't write complex algorythms for you.
>>
>> [...] But then, how many IF games need many very complex algorithms?

>
>All the ones I've written.

There's a thought - writing a LISP engine through a GUI. Mmmmm.

regards, ct

Daniel Barkalow

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
On 11 Aug 1999, Andrew Plotkin wrote:

> I *have* seen point-and-click, non-textual "programming" systems. Usually
> intended as deliberate puzzles, such as the logic-gate toolkit in the old
> Robot Odyssey game. Good as entertainment, but not for getting real work
> done.

Damn, now I want to play that again. Ah, well, it's probably not really
as fun as I remember.

> I once used a point-and-click Pascal development system. Still a textual
> programming language underneath, but you built loops, if-statements, and
> so on by selecting them from menus. It was *awful*.

Programming isn't a very graphical task; people don't think about
programs that way, and it's not a very effective way to think about them.
On the other hand, that doesn't mean there aren't tasks which are
graphical. The first thing that comes to mind is graphic design, of
course, but the second that comes to my mind, at least, is architecture.
Long ago, I used a GUI-based thing for designing DooM levels. It was the
best thing since sliced bread, despite being in Windows (which I had to
quit to test the level) and somewhat buggy, occasionally crashing or
causing problems. But I could lay out the shape of a map really quickly
with no trouble.

I think the task of making maps for IF is sufficently graphical that a
GUI for that aspect would be worthwhile. You could create rooms, move
them around on the screen (which wouldn't matter for game purposes, but
would give the creator an idea of where things were intended to be),
connect them with passages. Maybe have a built-in editor or the ability
to launch an external editor to type in descriptions and such. Perhaps
have something to display the object tree. Of course, for the complicated
stuff, you'd go back to text. There's no reason the whole game has to be
written in the same system.

-Iabervon
*This .sig unintentionally changed*


Daniel Barkalow

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
On 11 Aug 1999, Andrew Plotkin wrote:

> Would you buy that a good IF language (*including* its library) is easier
> to learn than a general purpose language (*including* an equivalently
> powerful IF support library, written in that language)?

Assuming, of course, that this is for the purpose of doing IF, since
you've got that IF library...

Yes, because of one simple thing: static data. IF games have a ton of
data which gets initialized at the beginning and then modified later.
Dealing with that is a major pain in Java, for instance, which doesn't
have a good way to deal with objects which are essentially unique. C lets
you make them, at least, although not nearly as neatly as Inform. Scheme
would work, but is obscure.

Most lanugages are designed for situations where there isn't much data
built into the program; the program is primarily code. IF is the
opposite; the code is just for the special stuff, and most of the program
is data.

Daniel Barkalow

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
On 12 Aug 1999, Jake Wildstrom wrote:

> Nor I. I suggested, non-facetiously, to my 9th grade computer science
> teacher (teaching us Boolean algebra and circuitry), that we should
> just get a bunch of Apple emulators and work in Robot Odyssey.

Hmm... The Learning Company's still around and making stuff. I wonder if
it'd be possible to get Robot Odyssey from them these days, or if it
would be possible to convince them to do a version for new modern
computers. They seem to have stuff in the Oregon Trail series still...

> Incidentally, the GUI, which everyone is (ostensibly) discussing, is
> not original to Robot Odyssey. The Learning Company's previous
> circuitry game, Rocky's Boots, featured a similar working environment,
> but with fewer gates and without the solderpen.

And without enough components, damn it. Even the last level didn't have
enough stuff, and only earlier levels had some of the places I liked.
Like the alligator, for instance.

I never got a copy of Robot Odyssey myself; I had to play it at the
Science Museam (in Boston, an excellent one), which meant I didn't really
have time to work through as much as I would have liked.

Gene Wirchenko

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Andrew Plotkin <erky...@netcom.com> wrote:

[snip]

>I *have* seen point-and-click, non-textual "programming" systems. Usually
>intended as deliberate puzzles, such as the logic-gate toolkit in the old
>Robot Odyssey game. Good as entertainment, but not for getting real work
>done.

Agreed.

>I once used a point-and-click Pascal development system. Still a textual
>programming language underneath, but you built loops, if-statements, and
>so on by selecting them from menus. It was *awful*.

The point-and-click AND Pascal!

>I designed a entirely graphical system myself, for creating ripply marble
>patterns (and so on.) That's a strictly limited domain -- but even there,
>I ran into real scalability problems and annoying boundaries to
>expressiveness, before I shelved the project. (I'd like to pick it up
>again, but, well, I'd like to pick up all sorts of things again.)

I think I've got that straight: Point-and-click programming
caused you to lose your marbles.

I agree. I program in Visual FoxPro. I'm coding a GUI app.
There is no way I'm getting mixed up with those GUI tools though.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Jake Wildstrom

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
In article <Pine.LNX.3.91.990812...@iabervon.mit.edu>,

Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:
>Hmm... The Learning Company's still around and making stuff. I wonder if
>it'd be possible to get Robot Odyssey from them these days, or if it
>would be possible to convince them to do a version for new modern
>computers. They seem to have stuff in the Oregon Trail series still...

It's been done. The Party line, for unfathomable reasons, is that they have
never produced a game of that name and don't intend to in the future. This
has been used as justification for pirating it to death, which is not
necessarily a bad idea--if there is true abandonware in this world, Robot
Odyssey is it..

>And without enough components, damn it. Even the last level didn't have
>enough stuff, and only earlier levels had some of the places I liked.
>Like the alligator, for instance.

Oh, yes, the gator and punchy-thingy on Level 3. I had forgotten about those. I
always set up the puncher to follow the gator. Cruel and unusual but it worked.

>I never got a copy of Robot Odyssey myself; I had to play it at the
>Science Museam (in Boston, an excellent one), which meant I didn't really
>have time to work through as much as I would have liked.

Damn. They had Robot Odyssey at the MoS once? Cool. Their computer exhibits are
distinctly dated by now--I recall they still have an Apple ][ text-to-speech
system <shudder>.

As for getting Robot Odyssey yourself, grab an emulator, cruise to
ftp.apple.asimov.net, and knock yourself out. <g>

Knight37

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
> > > These are *not* disjoint sets.
> >
> > Well duh. Did I ever say they were?
> >
>
> ...? I must have missed the point your were trying to make, then.
> Sorry.

Oh, sorry. My point was that a person primarily interested in writing
IF will most likely not be interested in writing a parser and/or other
important features of an IF development environment (I'll revert to
using this instead of "language") if there are suitable tools that have
already been written. THAT's what I meant by "reinventing the wheel".
I had said that a programmer might want to do this "for shits and
giggles", but that's not to say that a programmer couldn't also be an
IF author. But in this case that person is putting on their programmer
hat, not their IF author hat. Now, I will acknowledge that a programmer
might be interested in "improving the wheel" for the ultimate purpose
of making IF easier or more powerful or whatever (not just for shits
and giggles).

> Of course it matters. This thread is about parsers (and now, more
> generally, IF libraries) written for general-purpose languages, right?
> My point is that all of these nifty things like daemons and navigation
> (I'll leave out "object behavior," because I'm not entirely sure what
> you mean by that) -- which you are claiming as virtues of IF-specific
> languages -- are really libraries. And why can't they be implemented
> just as well in a general purpose language? And if they are implemented
> as well in a general purpose language, will the result *really* be
> harder to learn than Inform or TADS? These are the questions I'm
> interested in.

I am not sure if they could be implemented as easily in a general-purpose
language but I'd sure like to see a good one developed. I didn't realize
this was where you were heading. Yes, in this case, I think it is
possible to implement a library designed to create IF in a general
purpose language that will be easier to learn and at least as powerful
as Inform or TADS or other IF development environments.

> I'm beginning to get the sense that you think I'm arguing something that
> I'm not.

I think maybe I was. Your most recent message has made your point
abundantly more clear to me.

Lets get more specific then. Which general purpose language would
you propose makes a good base for a new IF development environment
that will be easier to learn than Inform or TADS?

I will agree that if you give the novice a GOOD library of IF
functions to work with in the general purpose language, and it's
well documented, etc, then it should be approximately as easy to
learn as something like Inform or TADS is. I haven't ever seen
such a beast, but I will concede it is possible. I do think that
less complicated IF languages, like ALAN, would be easier to learn
than this. I also think that ALAN is a lot easier to learn than
Inform or TADS, but that's because I personally found it to be a
lot easier. And I am a programmer.

You point though, about syntax being "sugar", is wrong in my
opinion (or maybe I didn't get your point as you meant it).

I think that the simpler the syntax, the easier the language.
That's why Pascal is easier to learn than C. I think that the
syntax for IF languages are designed to make it easy to learn
how to write a work of IF in that language. I think the
general-purpose syntax of a general-purpose language will be a
barrier to the learning process (for writing IF, not in
general). I think it might be possible to overcome that
barrier, though.

I think it might be a lot easier for a person with programming
experience in a general-purpose language to learn how to write
interactive fiction using a GOOD IF library in that language
than it would be for that person to pick up Inform or TADS and
try to learn that.

You'll notice a lot of "I think"'s in this post. After all, if
one is talking about "ease of learning", it depends a lot on
the person doing the learning. It's not exactly something you
can quantify.

Knight37


Chris Landry

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
> I think the task of making maps for IF is sufficently graphical that a
> GUI for that aspect would be worthwhile. You could create rooms, move
> them around on the screen (which wouldn't matter for game purposes, but
> would give the creator an idea of where things were intended to be),
> connect them with passages. Maybe have a built-in editor or the ability
> to launch an external editor to type in descriptions and such. Perhaps
> have something to display the object tree. Of course, for the complicated
> stuff, you'd go back to text. There's no reason the whole game has to be
> written in the same system.

The shape of a map, how everything is connected, yes in my opinion that is perfect for
an IF GUI program. However, it is possible that can cause many falling points for the
GUI because you would have to go back to coding on a textual level -- which I think
everyone agrees that you need to have, you don't have the power and flexibility
otherwise, what you would have is a GUI for AGT. The problems that could arise from
such a GUI are things like coding style. Everybody doesn't write their code in the same
wonderful style, everyone has something that they are used to and sometimes having
differently styled code in their programs is disorienting. I am one of those people.
Especially when it comes to C++, ASM, or Java. Another problem would be the
implementation of doors unless the GUI did that too. Doors would cause people to have
to backtrack in their code and change things the GUI did, if the GUI did them well, it
wouldn't be difficult but if the GUI doesn't write code as readable as a Microsoft
header file, then you're going to have a bit of trouble, especially if you are a novice.
I agree with you, there's no reason that the whole game has to be written in the same
system, but I believe it just makes it easier.

Chris Landry

Daniel Barkalow

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
On Thu, 12 Aug 1999, Knight37 wrote:

> Lets get more specific then. Which general purpose language would
> you propose makes a good base for a new IF development environment
> that will be easier to learn than Inform or TADS?

There's the problem of the vast ammount of static data that is the
interesting part of the program. E.g.,

Room Office
with description "Your office",
n_to Hall,
has light;

is pretty hard to translate into most languages. The only language I know
where this information could be so centralized and readable is Scheme. It
would be possible in C (or C++), but you'd have to put in fields for all
of the properties. Java would just be incredibly painful. I guess BASIC
would put it in data statements.

Scheme is actually plausible, but people tend not to have Scheme
interpreters, and I don't know of a Scheme compiler (which is what you
really want, so you're not distributing the source to players) that
targets a platform-independent result.

Actually... I wonder how hard it would be to write a Scheme to Glulx
compiler... it's a silly idea, but I am going to be a TA for a compilers
course this coming term, and I've got some idea of how to deal with
Scheme.

> I think it might be a lot easier for a person with programming
> experience in a general-purpose language to learn how to write
> interactive fiction using a GOOD IF library in that language
> than it would be for that person to pick up Inform or TADS and
> try to learn that.

I'd agree with that, presuming a general-purpose language suited to the
task. One possibility, of course, would be a general-purpose language for
the code, and another language (or file format) for the piles of data. So
you write the code in C and write a file that contains all the
descriptions and items and locations and stuff.

Andrew Plotkin

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:
> On Thu, 12 Aug 1999, Knight37 wrote:
>
>> Lets get more specific then. Which general purpose language would
>> you propose makes a good base for a new IF development environment
>> that will be easier to learn than Inform or TADS?
>
> There's the problem of the vast ammount of static data that is the
> interesting part of the program. E.g.,
>
> Room Office
> with description "Your office",
> n_to Hall,
> has light;
>
> is pretty hard to translate into most languages. The only language I know
> where this information could be so centralized and readable is Scheme. It
> would be possible in C (or C++), but you'd have to put in fields for all
> of the properties. Java would just be incredibly painful. I guess BASIC
> would put it in data statements.

SML also has pretty good syntax for data. (But then, SML can be described
as "Scheme without the parentheses.")



> Actually... I wonder how hard it would be to write a Scheme to Glulx
> compiler...

Seriously, this was an early goal when I started designing a Z-machine
successor. It shouldn't be impossible.

>> I think it might be a lot easier for a person with programming
>> experience in a general-purpose language to learn how to write
>> interactive fiction using a GOOD IF library in that language
>> than it would be for that person to pick up Inform or TADS and
>> try to learn that.
>

> I'd agree with that, presuming a general-purpose language suited to the
> task. One possibility, of course, would be a general-purpose language for
> the code, and another language (or file format) for the piles of data. So
> you write the code in C and write a file that contains all the
> descriptions and items and locations and stuff.

I worry that that structure *in itself* makes the task much more
difficult. IF languages allow small pieces of code inside large data
structures, because that's the natural arrangement of IF games.

Craxton

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Jon Zeppieri wrote:
>
> Apology: this post is SO off-topic (well, for the current thread),
> but...
>
> In article <7orvgf$6...@dfw-ixnews11.ix.netcom.com>,

> Andrew Plotkin <erky...@netcom.com> wrote:
>
> > I *have* seen point-and-click, non-textual "programming" systems.
> Usually
> > intended as deliberate puzzles, such as the logic-gate toolkit in the
> old
> > Robot Odyssey game. Good as entertainment, but not for getting real
> work
> > done.
>
> You know, my parents bought me Robot Odyssey for my Apple //c years and
> years ago. And I loved that game. And for years I figured that nobody
> else had ever even heard of it. But these days, references to it keep
> popping up all over the net.
>
> I never finished it (for which I consider myself an abject failure).
> Never got past the "minefield."
>

I remember that too! I played it on an Apple II at the library years
ago! I downloaded an emulator copy recently, and got up to the blue grid
in the final level before I stopped playing. It rocks! Lots of fun, and
one of the few "edutainment" games that's actually educational. To beat
the forth level puzzles I had to quasi-cheat- playing around with the
remote and rewiring robots on the fly. (Which is technically legal, but
most of the game's cult fans seem to think it low-class. Ah, well.) The
only problem is that it concentrates all it's difficulty in the last two
levels. A few more levels and a smoother learning curve would have been
appreciated.

-Craxton
--
"All men are sexual. You'd better get used to it." -May Club
Long Live the Hentai Game!

Craxton

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Nick C. wrote:

>
> On Thu, 12 Aug 1999 12:44:01 GMT, Jon Zeppieri wrote:
> >It's the best educational game I've ever played. The premise is kind of
> >silly: you're some guy who, one night, mysteriously falls into this
> >underground society, peopled by robots. You start off, I believe, in a
> >junk yard, where you find three discarded robots and a toolkit of
> >digital logic parts. All of the puzzles in the game revolve around
> >actually programming your robots, using the tooklit, to solve some
> >problem. There are five levels to the game, and it gets quite
> >difficult. I even remember the box (which is almost certainly still
> >sitting around my parents' house) bragging that less than five percent
> >of the people who played the game ever solved it.
>
> I remember this game! I have been trying for years to remember what it was
> called. However, the version I had was for the IBM PC. Does anyone know if
> there was a PC version produced so I can be sure that this is the game I'm
> thinking of?
>

It exists, but suppossedly doesn't run well on modern IBMs. You have to
use a special program to slow down your clock speed, and the soderpen,
for some weird reason, doesn't work at all.

Craxton

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Erik Max Francis wrote:
>
> Joe Mason wrote:
>
> > I remember seeing people playing one of
> > the old
> > Ultima's, Load Runner, Paperboy - but I always grabbed Robot Odyssey.
>
> Would someone give a brief description of this game? Sounds
> interesting.
>

Someone has a small shrine to the game on AOL. Go here:

http://members.aol.com/Fractal101/odyssey.htm

Bob Reeves

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
I had an MS-DOS disk I played on my Tandy 1000 EX for many years. A Pentium
would make it unplayable now. Like other posters, I bogged down trying to
navigate the minefield on Level 4 & now I'll never know what the upper
level looked like.


David Cornelson

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Andrew Plotkin <erky...@netcom.com> wrote in message
news:7ov9ua$p...@dfw-ixnews10.ix.netcom.com...
> Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:
> > On Thu, 12 Aug 1999, Knight37 wrote:
> >
> > <snip>

> >
> > I'd agree with that, presuming a general-purpose language suited to the
> > task. One possibility, of course, would be a general-purpose language
for
> > the code, and another language (or file format) for the piles of data.
So
> > you write the code in C and write a file that contains all the
> > descriptions and items and locations and stuff.
>
> I worry that that structure *in itself* makes the task much more
> difficult. IF languages allow small pieces of code inside large data
> structures, because that's the natural arrangement of IF games.

Data belongs in a database. A language should then be used to read and write
data to the database. I would argue that you all of the current conversation
has been slanted towards making this more language oriented whereas I
believe IF should be data-driven. Place all of the data elements into a
relational database INCLUDING the bits of code. Then you build an
interpreter that understands how to read the database appropriately.

The GUI would simply be an application that allowed you to structurely
modify the database.

My third cent.

Jarb

Jon Petersen

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to
Craxton wrote:
>
> It exists, but suppossedly doesn't run well on modern IBMs. You have to
> use a special program to slow down your clock speed, and the soderpen,
> for some weird reason, doesn't work at all.

I'd advise anyone who wants to relive the glory days of Robot Odyssey to
grab an emulator and play the Apple version.

I recently tried playing it again, but learned that I loved the game
more in theory than in actuality; eleven years after playing it for the
first time, I still suck at it.

Jon


Jim Aikin

unread,
Aug 12, 1999, 3:00:00 AM8/12/99
to

> All down to the specific implementation, surely? You can't just dismiss *ALL*
> graphical editors just because there was one, once, that wasn't so popular!

Actually, there may be an underlying philosophical problem, or
limitation....

I've been using various kinds of music software -- MIDI sequencers, to
be precise -- since the early days of MIDI, which is upwards of 15 years
now (since the Commodore-64 was a cutting-edge computer). Most of them,
these days, are essentially graphics-based editing environments for
multidimensional data arrays. And I can tell you that whenever a
programmer designs a graphic interface for editing, the interface itself
embodies certain assumptions about what the user is going to want or
need to do. Not just assumptions about HOW the user is going to want to
manipulate the data (click and drag vs. whatever) but about what's
important in the data and what's trivial, and what sorts of
manipulations the user is going to want to perform on the important
bits.

As a result, it seems to me that a graphic editing system will ALWAYS be
biased in favor of certain common types of operations, and biased
AGAINST less common, more esoteric types of operations. You can change
the bias by altering details of the interface, but you can't eliminate
the fact that there will be built-in biases. You can bury the bias at a
deeper level by giving the user more and more graphic tools -- but if
you do that, before too very long you end up with a user interface
that's as convoluted and confusing as a plain old text interface.

A text interface does not impose a bias. It just lays all the data out
in front of you and allows you to do with it what you will. The most
flexible MIDI sequencer I've ever used was called Dr. T's KCS. It ran on
the Atari ST, and it was designed for flexibility, NOT for graphic ease
of use. In general, KCS imposed an absolute minimum of assumptions about
how you were going to want to manipulate your data. The tools, and there
were some very sophisticated tools, were logic-based, not
graphics-based.

Graphic-based programming tools (or for that matter, dialog-box-based
tools like those in Visual C++, which set up a complex application
framework with a few clicks) are wonderful things, don't get me wrong.
But after you set up the framework of your program, if you want to do
anything truly personal, you're almost certainly going to have to sit
down and start writing text code.

The one exception I can think of is David Zicarelli's Max programming
environment, which is used for creating apps that process incoming MIDI
data in real time. It's truly graphics-based, and it's truly flexible.
I'm going to have to think a bit about why Max gets away with violating
this principle, and how its design could be applied to IF programming.

I will say that having done both, I'd rather write text code than
program in Max. Complex Max objects tend to look like rats' nests. They
give a whole new meaning to the term 'spaghetti code'.

--Jim Aikin

Paul Guertin

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
Jon Zeppieri <97...@my-deja.com> wrote:

> You know, my parents bought me Robot Odyssey for my Apple //c years and
> years ago. And I loved that game. And for years I figured that nobody
> else had ever even heard of it. But these days, references to it keep
> popping up all over the net.

It was one of the best-kept secrets of the Apple II world, I guess
because it was marketed as an educational game. It is in my top 5
list of best Apple II programs of all time (others are Gutenberg Sr.
(word processor), MuMath (symbolic algebra program), Merlin Pro
(assembler), and Ultima 5 (RPG)).

Honorable mentions: GPLE, AppleWorks, GraForth, Archon, Locksmith,
The Bard's Tale II.

Paul Guertin
p...@sff.net

Jon Zeppieri

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
In article <tzDs3.368$Yp....@news.flash.net>,

"Knight37" <goo...@blue.net> wrote:
> Lets get more specific then. Which general purpose language would
> you propose makes a good base for a new IF development environment
> that will be easier to learn than Inform or TADS?

Good question. Some people have already mentioned Scheme, and I can
only agree -- with one caveat (which, happily, pertains to another
matter in this post). Scheme is very consistent, has simple but
powerful semantics, and it encourages good programming style. AND, you
can statically layout complex data structures using literal (quoted)
notation. Scheme also has extremely simple syntax -- the "other matter"
I mentioned -- but its simplicity is sometimes annoying. I agree with
you that good syntax can help to make a language easier to learn.
Definitely. Sometimes, though, simple syntax isn't the best.
Especially considering the Inform verb example: the syntax there is not
particularly simple, but it is terse and powerful -- and, as you pointed
out, fairly readable, too.

ML was also mentioned. I really like ML. I mean, I *really* like ML.
(Not that I've used it in ages.) But I think it would scare the hell
out of a non-programmer. Actually, I think it would scare the hell out
of a lot of programmers, too. But there's just something fundamentally
cool about a statically typed language which tells *you* the types,
rather than the other way around. Scheme is probably much easier to
implement than ML. Not that there aren't enough implementations (free
implementations) available, but if you wanted to target the Glulx
Machine (is it the G-Machine? still the Z-Machine? the Z^2-Machine?)...
Then you could implement ML in Scheme.

Clearly, I need sleep.

Adam C. Emerson

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
Mark J Musante <olo...@world.std.com> wrote:
> You control robots in a maze. You can program them by wiring gates
> together (and, or, etc). Each robot, which are square, has four sensors
> to tell whether it's bumped into a wall, and four directional jets to
> move it around. Also and antenna and a transmitter to communicate with
> other robots (or a remote control).

> You can also make simple chips in the chip lab. Each chip has 8 pins


> and you can create a little circuit within it.

> It was an interesting little game. I've not seen its like again.

Well actually, I did see something vaguely similar (though vastly
inferior) called Rocky's Boots.

--
Adam C. Emerson aeme...@atdot.org
http://www.calvin.edu/~aemers19
What about the new 16-bit computers, like the Lisa and Fortune? Even
with the Winchester backup, they're no match for the Uzi.

Daniel Barkalow

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
On Fri, 13 Aug 1999, Jon Zeppieri wrote:

> Definitely. Sometimes, though, simple syntax isn't the best.
> Especially considering the Inform verb example: the syntax there is not
> particularly simple, but it is terse and powerful -- and, as you pointed
> out, fairly readable, too.

Scheme does let you define new syntax, using a powerful macro facility
that I don't really understand. Presumably a proper IF library for Scheme
would include nice verb-creation syntax (e.g.). The macro facility is
rather obscure and complex, but does exist.

okbl...@my-deja.com

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
> I think the task of making maps for IF is sufficently graphical that a
> GUI for that aspect would be worthwhile. You could create rooms, move
> them around on the screen (which wouldn't matter for game purposes,
> but would give the creator an idea of where things were intended to
> be), connect them with passages.

Heh. I remember drawing maps for Advent. No matter how I tried, I
couldn't make the maps look like something other than spaghetti.

I'm actually among those that believe a GUI or 2-way GUI/IDE could work
but I think more useful effort would be to build tools to
help manage combinatorial explosion and synonyms.
--
[ok]

okbl...@my-deja.com

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
In article <7ovj3n$bd4$1...@bgtnsc03.worldnet.att.net>,

"David Cornelson" <dcorn...@worldnet.att.net> wrote:
>
> Data belongs in a database. A language should then be used to read and
write
> data to the database. I would argue that you all of the current
conversation
> has been slanted towards making this more language oriented whereas I
> believe IF should be data-driven. Place all of the data elements into
a
> relational database INCLUDING the bits of code. Then you build an
> interpreter that understands how to read the database appropriately.
>
> The GUI would simply be an application that allowed you to structurely
> modify the database.
>
> My third cent.
>
> Jarb

Can I get an "AMEN"????

wo...@one.net

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to

Hi Knight37,

"Knight37" <goo...@blue.net> wrote:

>Lets get more specific then. Which general purpose language would
>you propose makes a good base for a new IF development environment
>that will be easier to learn than Inform or TADS?

I'm using Python to do that. :) The game engine is finished, the game
library is about 90% finished, and the documentation is coming along
nicely.

As far as syntax, Python doesn't have a lot of the punctuation that
plagues TADS. And object syntax isn't too unweildy, for instance:

Rock = ClassItem("rock,stone","small,gray,grey")
Rock.AdjectivePhrase = "small gray"
Rock.NamePhrase = "rock"
Rock.StartingLocation = StartCliff
Rock.Bulk = 1
Rock.Weight = 10

Rock.SetDesc("Feel","""
It weighs about a pound, and is smooth like a rock
from a stream, but not polished. It's a typical
rock.
""")

Rock.SetDesc("Take","""
The rock emits a bright green flash when you pick
it up, but does nothing else remarkable.
""")

Rock.SetDesc("Taste","""
Yep. Tastes like a rock.
""")

Respectfully,

Wolf

"The world is my home, it's just that some rooms are draftier than
others". -- Wolf

R. Alan Monroe

unread,
Aug 14, 1999, 3:00:00 AM8/14/99
to
In article <7p078p$8s6$1...@nnrp1.deja.com>, Jon Zeppieri <97...@my-deja.com> wrote:
>In article <tzDs3.368$Yp....@news.flash.net>,
> "Knight37" <goo...@blue.net> wrote:
>> Lets get more specific then. Which general purpose language would
>> you propose makes a good base for a new IF development environment
>> that will be easier to learn than Inform or TADS?
>
>Good question. Some people have already mentioned Scheme, and I can
>only agree -- with one caveat (which, happily, pertains to another
>matter in this post). Scheme is very consistent, has simple but
>powerful semantics, and it encourages good programming style. AND, you

And there's always Rebol, which would be good to tinker with, at
least.

Have fun
Alan

Iain Merrick

unread,
Aug 14, 1999, 3:00:00 AM8/14/99
to
wo...@one.net wrote:
[...]

> As far as syntax, Python doesn't have a lot of the punctuation that
> plagues TADS.

What punctuation is this? I don't find TADS annoying in this respect.

Then again, I suppose TADS is C-like and I've been using C for some
time. I'm probably forgetting how difficult it was to learn C in the
first place.

> And object syntax isn't too unweildy, for instance:
>
> Rock = ClassItem("rock,stone","small,gray,grey")
> Rock.AdjectivePhrase = "small gray"
> Rock.NamePhrase = "rock"
> Rock.StartingLocation = StartCliff
> Rock.Bulk = 1
> Rock.Weight = 10
>
> Rock.SetDesc("Feel","""
> It weighs about a pound, and is smooth like a rock
> from a stream, but not polished. It's a typical
> rock.
> """)

[...]

Hmm. To me, that looks _very_ unwieldy. Could you add a pre-processing
layer, perhaps, so that you could at least get by without typing 'Rock.'
all the time?

And this looks like you're creating a new object on the fly. Does this
have to be performed at runtime, or can you create objects during
compilation and embed them in the game file, as Inform and TADS do?

(I'm not trying to put Python down; I'm just curious about its
capabilities.)

--
Iain Merrick
i...@cs.york.ac.uk

Knight37

unread,
Aug 14, 1999, 3:00:00 AM8/14/99
to
> > Data belongs in a database. A language should then be used to read and
write
> > data to the database. I would argue that you all of the current
conversation
> > has been slanted towards making this more language oriented whereas I
> > believe IF should be data-driven. Place all of the data elements into a
> > relational database INCLUDING the bits of code. Then you build an
> > interpreter that understands how to read the database appropriately.
> >
> > The GUI would simply be an application that allowed you to structurely
> > modify the database.
> >
> > My third cent.
> >
> > Jarb
>
> Can I get an "AMEN"????

That depends a great deal on this "GUI", since what Jarb seems to be
describing is an alternative to the virtual machine model that is commonly
used to store game files. Most IF players could care less what format
their game is stored in, as long as they have access to it on their favorite
platforms. And most IF writers could care less about the "gooey details"
of a game file format, so long as it doesn't get in their way of their
creativity. So that leaves the interface for coding this game file format,
which Jarb hasn't really given any concrete details about. I mean, being
able to run some SQL code against my game file would be kinda cool,
but I don't want to try and write the thing in SQL. :)

Knight37


Knight37

unread,
Aug 14, 1999, 3:00:00 AM8/14/99
to

Jon Zeppieri <97...@my-deja.com> wrote

> > Lets get more specific then. Which general purpose language would
> > you propose makes a good base for a new IF development environment
> > that will be easier to learn than Inform or TADS?
>

> Good question. Some people have already mentioned Scheme, and I can
> only agree -- with one caveat (which, happily, pertains to another
> matter in this post). Scheme is very consistent, has simple but
> powerful semantics, and it encourages good programming style. AND, you

> can statically layout complex data structures using literal (quoted)
> notation. Scheme also has extremely simple syntax -- the "other matter"
> I mentioned -- but its simplicity is sometimes annoying. I agree with
> you that good syntax can help to make a language easier to learn.

> Definitely. Sometimes, though, simple syntax isn't the best.
> Especially considering the Inform verb example: the syntax there is not
> particularly simple, but it is terse and powerful -- and, as you pointed
> out, fairly readable, too.
>

> ML was also mentioned. I really like ML. I mean, I *really* like ML.
> (Not that I've used it in ages.) But I think it would scare the hell
> out of a non-programmer. Actually, I think it would scare the hell out
> of a lot of programmers, too. But there's just something fundamentally
> cool about a statically typed language which tells *you* the types,
> rather than the other way around. Scheme is probably much easier to
> implement than ML. Not that there aren't enough implementations (free
> implementations) available, but if you wanted to target the Glulx
> Machine (is it the G-Machine? still the Z-Machine? the Z^2-Machine?)...
> Then you could implement ML in Scheme.
>
> Clearly, I need sleep.

Ok, so we have recommendations for Scheme, ML, Python, and,
what was it, Rebol?

Ok, maybe I'm no programming language connesiur, but I haven't
had any experience with any of those. And I would gander that many
other programmers, probably the majority of programmers, have not
had experience in these languages either. So we're back to having
to learn a new language then, in addition to having to learn an IF
development library and how to code IF. This doesn't seem to be
much of a significant advantage over IF-specific development
environments. In fact, since I don't see a lot of other people on this
newsgroup coding IF in Scheme or Python, etc, I can only assume
that I'd pretty much be on my own when it comes to learning this.

So I really don't see how this is going to be any easier than learning
Inform or TADS or Hugo or ALAN or Quest or whatever. Not to
mention I'm going to loose a big chunk of my audience unless I make
sure that my Scheme, Python, ML, or whatever is ported over to
all the current environments supported by Inform, TADS, Hugo,
etc. Seems like a lot of extra work to me. I mean, we can talk
about theory all day long, but all of this seems rather impractical to
me. Inform is here. Now. And it's not going to stay stagnant while
this yet to be released Scheme library is in development... same
goes for all the other IF development environments. They've got
a big head start on any other proposed environments, and so
there had really better be a SIGNIFICANT learning advantage for
people to want to switch over or start with that rather than what is
currently widely accepted.

Knight37


Andy Leighton

unread,
Aug 15, 1999, 3:00:00 AM8/15/99
to
On Sat, 14 Aug 1999 17:01:38 +0100, Iain Merrick <i...@cs.york.ac.uk> wrote:
>wo...@one.net wrote:
>[...]
>> As far as syntax, Python doesn't have a lot of the punctuation that
>> plagues TADS.
>
>What punctuation is this? I don't find TADS annoying in this respect.
>
>> And object syntax isn't too unweildy, for instance:
>>
>> Rock = ClassItem("rock,stone","small,gray,grey")
>> Rock.AdjectivePhrase = "small gray"
>> Rock.NamePhrase = "rock"
>> Rock.StartingLocation = StartCliff
>> Rock.Bulk = 1
>> Rock.Weight = 10
>
>Hmm. To me, that looks _very_ unwieldy. Could you add a pre-processing
>layer, perhaps, so that you could at least get by without typing 'Rock.'
>all the time?

Well I wouldn't call that too unwieldy - but obviously YMMV.

Even if it is a bit more verbose than you prefer, it doesn't introduce
anything that could confuse the IF author.

Looking at the rock stuff above, bulk and weight might easily be dispensed
with - very few pieces of IF try to model carrying capacity with that
level of detail. The NamePhrase and AdjectivePhrase parts could be
worked out from the object instantiation (although I don't know if wolf's
system does that). Obviously you might need methods such as addSynonymn()
and addAdjective(). I also presume that wolf has methods on objects such
as moveTo() etc.

So it boils down to -
Rock = ClassItem("rock,stone", "small,grey,gray")
Rock.StartLocation = StartCliff
Rock.Desc = ...

Python doesn't include a pre-processor, however you could play with M4
to translate from your syntax to the Python syntax but then you wouldn't
be writing in Python.

>And this looks like you're creating a new object on the fly.

Yep this is creating an object (and assigning various properties) at
runtime. This is pretty much the way you would do it with say C++
or Java as well.

>Does this have to be performed at runtime, or can you create objects during
>compilation and embed them in the game file, as Inform and TADS do?

What advantage do you see that giving you? The only small advantage I
can see is a slight improvement in speed.

I am not sure how the system Wolf is writing works but it is possible
that the game creator could run a python program that creates all the
objects and then pickles (dumps) them to a game file. The game player
would then run the game engine that unpickles (reads) the game file.

--
Andy Leighton => an...@azaal.dircon.co.uk
"... January is your third most common month for madness" - _Sarah Canary_

Iain Merrick

unread,
Aug 15, 1999, 3:00:00 AM8/15/99
to
Andy Leighton wrote:

> On Sat, 14 Aug 1999 17:01:38 +0100, Iain Merrick <i...@cs.york.ac.uk> wrote:

[...]


> >Hmm. To me, that looks _very_ unwieldy. Could you add a pre-processing
> >layer, perhaps, so that you could at least get by without typing 'Rock.'
> >all the time?
>
> Well I wouldn't call that too unwieldy - but obviously YMMV.

[...]


> So it boils down to -
> Rock = ClassItem("rock,stone", "small,grey,gray")
> Rock.StartLocation = StartCliff
> Rock.Desc = ...

But each instance variable is more fiddly to declare than it would be in
TADS. It's essentially the same, just more syntax. No?

> Python doesn't include a pre-processor, however you could play with M4
> to translate from your syntax to the Python syntax but then you wouldn't
> be writing in Python.

Don't you distinguish between the written syntax and the stuff that the
language actually lets you do -- the runtime system? I normally do.

For instance, there are Java compilers these days which don't target the
JVM. A native-code Java compiler will give you (very very roughly)
Objective C with Java syntax.

I'd agree that Python the runtime system might be rather nice for IF.
But as for Python the language, the stuff you actually type in, I'm not
convinced.

> >And this looks like you're creating a new object on the fly.
>
> Yep this is creating an object (and assigning various properties) at
> runtime. This is pretty much the way you would do it with say C++
> or Java as well.

Right.

> >Does this have to be performed at runtime, or can you create objects during
> >compilation and embed them in the game file, as Inform and TADS do?
>
> What advantage do you see that giving you? The only small advantage I
> can see is a slight improvement in speed.

I was mainly thinking of saved positions. These are normally stored as
diffs from the starting position.

When the game file is initially a bunch of objects with certain
properties, it's easy to just compare the current state against the
initial state to decide what needs to go in the save file.

But if the initial game file is a bunch of code which _creates_ all
these objects, you'd just have to store everything in the save file. Or
work out some more fiddly scheme to handle saves.

Saving the entire state would work, I suppose, since most people have
massive hard disks these days. That seems a little inelegant, though. :)

> I am not sure how the system Wolf is writing works but it is possible
> that the game creator could run a python program that creates all the
> objects and then pickles (dumps) them to a game file. The game player
> would then run the game engine that unpickles (reads) the game file.

Right, so it does do pickling. This is pretty essential for saving and
restoring, not to mention undo, but I think it will still be harder to
implement these than you might expect. And these are _really_ important
features for adventure games.

--
Iain Merrick

okbl...@my-deja.com

unread,
Aug 15, 1999, 3:00:00 AM8/15/99
to
In article <Aqkt3.330$E....@news.flash.net>,

"Knight37" <knig...@doesnot.wantspam> wrote:
>
> That depends a great deal on this "GUI", since what Jarb seems to be

I don't think he was specifically relating it to a GUI.

> describing is an alternative to the virtual machine model that is
> commonly used to store game files. Most IF players could care less
> what format their game is stored in, as long as they have access to it
> on their favorite platforms. And most IF writers could care less
> about the "gooey details" of a game file format, so long as it doesn't
> get in their way of their creativity. So that leaves the interface
> for coding this game file format, which Jarb hasn't really given any
> concrete details about.

I think we're still safely in the theoretical. :-)

> I mean, being
> able to run some SQL code against my game file would be kinda cool,
> but I don't want to try and write the thing in SQL. :)

I'll give an "amen" to that, too. :-)

okbl...@my-deja.com

unread,
Aug 15, 1999, 3:00:00 AM8/15/99
to
In article <37b59550...@news.one.net>,

wo...@one.net wrote:
>
> I'm using Python to do that. :) The game engine is finished, the game
> library is about 90% finished, and the documentation is coming along
> nicely.

A friend of mine is fond of saying that programming follows many 90%
rules, one of which is "The first 90% of the job takes 90% of the time,
and the last 10% takes the *other* 90%." :-)

Darius Bacon

unread,
Aug 15, 1999, 3:00:00 AM8/15/99