Parsers
John Fred Connors
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
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
>
> 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?
>
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
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
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
> 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
> 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
> 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
> >> 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
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
> 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
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
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
> 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
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"?
> >
> >
> > 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
"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
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
>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
> 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
> > > ((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
> 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
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
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
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
>> 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
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.
>>
>
>All the ones I've written.
There's a thought - writing a LISP engine through a GUI. Mmmmm.
regards, ct
Daniel Barkalow
> 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
> 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
> 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
[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
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
> >
> > 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
> 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
> 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
>> you propose makes a good base for a new IF development environment
>> that will be easier to learn than Inform or TADS?
>
> 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
>
> Apology: this post is SO off-topic (well, for the current thread),
> but...
>
> 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.
>
> 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.
>
> 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
>
> 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.
>
> 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
>
> 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
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
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
>
> 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
> 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
> 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
"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
> 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
> 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
Daniel Barkalow <iabe...@iabervon.mit.edu> wrote:
>
> 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
"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
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
>In article <tzDs3.368$Yp....@news.flash.net>,
> "Knight37" <goo...@blue.net> wrote:
>> you propose makes a good base for a new IF development environment
>> that will be easier to learn than Inform or TADS?
>
>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
[...]
> 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
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
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
>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.
>
>>
>> Rock = ClassItem("rock,stone","small,gray,grey")
>> Rock.AdjectivePhrase = "small gray"
>> Rock.NamePhrase = "rock"
>> Rock.StartingLocation = StartCliff
>> Rock.Bulk = 1
>> Rock.Weight = 10
>
>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
> 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
"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
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
[python]
>>> Rock = ClassItem("rock,stone","small,gray,grey")
>>> Rock.AdjectivePhrase = "small gray"
>>> Rock.NamePhrase = "rock"
>>> Rock.StartingLocation = StartCliff
>>> Rock.Bulk = 1
>>> Rock.Weight = 10
>>
>>layer, perhaps, so that you could at least get by without typing 'Rock.'
>>all the time?
You may prefer this (regular Python, no preprocessing needed):
class Item:
def __init__(nouns, adjectives, **properties):
<constructor code here>
StartCliff = <whatever>
Rock = Item('rock,stone', 'small,gray,grey',
AdjectivePhrase = 'small gray',
NamePhrase = 'rock',
StartingLocation = StartCliff,
Bulk = 1,
Weight = 10)
If I wanted to write an IF system in Python I'd see what can be stolen
from POO, a Python MUD.
--
Darius Bacon http://www.smop.com/darius
Knight37
<okbl...@my-deja.com> wrote
> "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.
Well, this is his text I was referring to...
> The GUI would simply be an application that allowed you to structurely
> modify the database.
It doesn't have to be GUI, but it does have to be an application of
some sort, and how good that is will be the limiting factor of how
successful a relational database implmentation of IF format would be.
Knight37
Knight37
<okbl...@my-deja.com> wrote
> 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%." :-)
Oh yeah. So that must be why games are always at least 80% overdue
when they are finally released, or maybe they're on time, but they're
only 92% finished or so (more likely). :)
Knight37
David Cornelson
news:enGt3.176$a%2....@news.flash.net...
[See old ideas of mine at http://www.placet.com/int-fiction/vinform]
Let's stay theoretical. In the system that I have in my head, the author
would not need to know where or how the data is stored. The author only
needs to know the language. The language has a compiler and an interpreter.
The compiler/interpreter translates to and from the database. This is almost
the same as a multi-tier application model. You have the database, the data
access layer, the business logic layer, and the user interface. Zarf has
already built from a similar with glk and now glulx. His design is perfectly
useful in this sense. The only difference is that instead of storing the
information in _only_ a text file, an author has the _option_ of loading it
into my GUI and therefore, into the underlying database.
One of the roadblocks to this is that we would have to haggle on a format
for the text version of the data (code) to be spewed out by the GUI. No one
would use a program that couldn't cleanly translate the information into
readable code. But again, in my GUI, there would likely be 'overrides' at
every turn. You would be able to block off sections of code and tell the GUI
that it belongs in a certain place and requires certain things. The
compiler/interpreter would automatically build the codebase properly from
these and other data-driven entities.
This is not a light undertaking, but a reasonable user interface could be
built for more than 50% of the authors out there - I'd even go as high as
80% but the cross-platform issue is a pretty big one. Eventually, Java will
be an legitimate programming language without the speed problems that it has
now.
I hear arguments but there is a simple way to deal with all of them. When I
build a system the very first thing that gets discussed and written down are
the _requirements_. All of the arguments for and against a GUI IF system
would start with a list of requirements. To date they would seem to be:
1) Textual programming override at any point in the program so that lower
level or more complex algorithms are available.
a) This is a design issue - the GUI can be designed with this in mind.
2) Cross Platform
a) Java?
3) Backwards compatible
I would build the system off of a current language, such as Inform, TADS, or
Hugo. With the help of Graham Nelson, Andrew Plotkin, and/or Kent Tessman, a
conversion of the current compiler to java classes would be necessary. This
would be the 'business logic' layer. Then a translation class would be
created to make the code functional to the GUI. The GUI would read this
translation from the relational database. When someone runs the program, the
database is translated to the VM and executed. The VM version (.z5) is the
deliverable.
My fourth cent.
Jarb
Andy Leighton
>Andy Leighton wrote:
>> 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?
It is a little more syntax yes, but I don't find the Rock. prefixes
get in the way. As a developer in a number of languages I tend to
just tune them out.
>> 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.
I don't quite follow your argument here. Take the C standard for example,
it defines a syntax and a standard library. If you write a program which
uses syntax not allowed by the standard you are no longer writing in C.
For example C++ style comments in C programs (at least until the FDIS for
C9X is approved).
>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.
Yep - can see that.
>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.
Save/restore/undo are really important features for lots of programs :-)
Seriously the python systems for writing IF is relatively immature,
certainly nowhere like the 5 or so years of development Inform and TADS
have had. However I feel that python offers a lot that the other systems
don't, and I hope to produce a game which will prove this - however don't
hold your breath, I have only just started to look at IF again.
In the past I have written IF in Basic, Quill, C, and Inform.
R. Alan Monroe
>conversion of the current compiler to java classes would be necessary. This
>would be the 'business logic' layer. Then a translation class would be
>created to make the code functional to the GUI. The GUI would read this
>translation from the relational database. When someone runs the program, the
>database is translated to the VM and executed. The VM version (.z5) is the
>deliverable.
"business logic"... "deliverable"... Dude, where do you work? Does
your boss have pointy hair? :^)
Don't take this as me being against some good IF hacking, though :^)
Have fun
Alan
wo...@one.net
>> 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%." :-)
I hear that. :) The hard part is documenting the system, I'm creating
documentation for new game authors and I'm finding myself creating
massive amounts of comments for the programs, a technical manual, and
a "How to create an adventure in PAWS" manual.
I'm finding that I can't get too far ahead on any one piece, it's
easier to keep them in sync. But it takes about 3 times as long...
John W. Kennedy
>
> 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?
LISP-like languages have been used for IF. All of Infocom's classic
games were written in a 2nd-generation LISP derivative called ZIL, which
in turn derived from MDL.
But as to the YACC family, although I have seen it done -- somewhere,
once, in the 80's, I can't remember where -- it isn't really very
effective. A good IF parser has to include a dynamic disambiguator and
implied-object engine. The part of IF parsing that YACC can do is
trivial, and fitting the other functions into the YACC-generated code is
distinctly awkward.
Actually, a LEX-type program based on finite-state machines would be
more to the point.
--
-John W. Kennedy
-rri...@ibm.net
Compact is becoming contract
Man only earns and pays. -- Charles Williams
wo...@one.net
Hi Knight37,
>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.
Well, in PAWS for instance the parser is provided, along with the game
logic cycle, so you're no worse off than in TADS or Inform. in effect
Python is the language and PAWS is the "system", so really PAWS is an
IF language.
Coding IF in PAWS feels a lot like Hugo or TADS, except Python doesn't
require block definition syntax like TADS and has a better "feel" in
my opinion than any of the OOP IF-languages I've played with.
On top of which Python has a lot of nifty high-level data structures
built in, like dictionaries and lists. (I *love* lists and
dictionaries! :))
>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.
Python is already available for *EVERY* platform now extant, with the
possible exception of the TI-99 and CP/M machines. :) This includes:
MS-DOS, Windows 3.x, 9x, NT, CE, OS/2, MacIntosh, Amiga, Psion, BeOS,
Linux, UNIX (many flavors), QNX, VMS (DEC VAX computers), VxWorks
(embedded systems, like VCRs!), and Acorn RISC-OS.
And get this, as long as you're running version 1.52 or later of
Python, you're *binary compatible*. Of course, recompiles are
automatic if you include your game in source form, just have the user
run the game normally, and it recompiles automatically, in fact the
player won't even be aware the compilation happened!
How's that for cross-platform? :)
>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.
I think PAWS has a significant advantage, especially for new game
authors. Python syntax is straightforward, blocks are based on an
outline-style indentation. Python does a huge amount of work for you,
with the ability to manipulate strings, lists, and tuples built
directly into the language, using the same operators.
Python is OOP, has list and dictionary native operations which map
almost one-for-one with IF needs. Python operators are easily
extensible to new data types, and Python isn't even hard to learn.
Coupled with an engine and library that do most of the work for the
author it's certainly as easy to learn as TADS or Inform, if not as
simple as Alan.
If you'd like to see Python directly, check out www.python.org
wo...@one.net
Hi Andy,
>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.
I don't currently default the NamePhrase and AdjectivePhrase. But it
wouldn't be difficult to add NamePhrase/AdjectivePhrase default
capability to ClassBaseObject, in fact I think I might do that,
perhaps making the NamePhrase the first noun in the argument list and
the AdjectivePhrase the first adjective in the adjective list.
And yes, there's a ClassBasicThing in the Universe library that
contains many methods and properties, such as MoveInto() and
ContentWeight(). In fact there are 40 methods and over 30 properties
in the ClassBasicThing() class. All other classes are derived from it,
they add their own methods and properties.
The majority of those methods, of course, won't be used by the game
author directly (although they could be if desired). Most are used by
the game system to handle line of sight, weight, bulk, and other
"natural laws".
>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.
Actually, it isn't that complex. :) A PAWS game will consist of 4
files with .pyc extensions, PAWS.pyc, Universe.pyc, MYLib.pyc, and
MYGame.pyc.
PAWS.pyc is the game engine, Universe.pyc is the system library. These
two files are always the same, and can be shared unchanged between
multiple games.
MYLib.pyc is the actual game you write, you'll name it appropriately
(Thief's Quest for example might be TQLib.pyc).
MYGame.pyc is the main game logic loop, you copy it from the template
file provided and change one or two lines. For example, in Thief's
Quest it's called TQ.pyc.
You can create a batch/script file to run it, but normally you'd run
it with the command:
python TQ
or whatever your particular OS requires.
wo...@one.net
Hi Iain,
>But each instance variable is more fiddly to declare than it would be in
>TADS. It's essentially the same, just more syntax. No?
Syntax is negotiable in Python. :)
You can create methods that pretty much define objects the way you'd
rather. In fact Python is fully interpreted, allowing you to put some
code in a string and execute it!
Despite its verbosity, this syntax appeals to me because I'm aiming
PAWS at novice users. Although not quite as concise as it might be,
the syntax is very clear, english like (more or less) and easy to
remember.
>Don't you distinguish between the written syntax and the stuff that the
>language actually lets you do -- the runtime system? I normally do.
Python is fully interpreted, in fact you can execute code created on
the fly if you like. This might not be a "best practice" :) but under
some conditions its the only solution.
So if I understand you correctly, the answer is no. :)
>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.
Here's a room definition for a typical room:
BeechCopse = ClassOutside()
BeechCopse.HasBeechTree = TRUE
BeechCopse.HasForestPath = TRUE
BeechCopse.NamePhrase = "Beech Copse"
BeechCopse.SetDesc("L","""
You are in a copse of beech trees. Unlike most
of the pine forest
that you've seen, these trees are more widely
spread, allowing more
light to penetrate. Their limbs start close to
the ground, some not
more than five feet up. Under the trees are
years of accumulated
fallen leaves, making a rich mulch. The only
path out of the copse
leads to the northwest.
""")
BeechCopse.SetDesc("Odor","You can smell the faint but sharp odor of
leaf mulch.")
BeechCopse.SetDesc("Sound","The air is cheerful with birdsong.")
Please ignore the spacing, Agent doesn't like to display wide lines.
:)
However, when properly spaced out, there are only 7 lines of code (not
counting the multiple line long description). When you add the map:
BeechCopse.Map = {North: DeepForest2,
Northeast: DeepForest2,
East: DeepForest6,
Southeast: SouthWall1,
South: SouthWall1,
Southwest: SouthWall1,
West: DeepForest2,
Northwest: A3WayPath,
Up: UpATree,
BeechTree: UpATree,
Down: "The ground is in the way."}
You have a complete room description, in a fairly concise compact
form.
>Saving the entire state would work, I suppose, since most people have
>massive hard disks these days. That seems a little inelegant, though. :)
Inelegant but simple. :) Also, there's a binary mode for pickling that
can compress the file. But, as you said, hard disk space is seldom a
problem.
>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.
Actually, I haven't implemented the save/restore capability yet, but
there's a pickle module that saves objects to a file, this module is
already part of the Python system. A simple scan through the object
directory and voila!
Although I haven't played with the pickle module much, if any Python
folks are listening I wouldn't take some code amiss! :)
wo...@one.net
Hi Iain,
>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.
The semi-colon on the end of each line, the opening and closing curly
brace for block definitions come to mind. :)
In Python blocks are indented, a block ends when the next line is
"undented", it works a lot like MS Word's outline command. Lines end
at the end of the line, though you can continue a line with a
backslash (\) character if you need to.
Triple-quoted text (multi-line text between """ symbols) can be
continued without any special characters, this is good for room
descriptions and the like, also no special end of line syntax is
needed when continuing a list, dictionary, or tuple definition between
lines (see the map example at the bottom of this post).
>> 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?
Actually, this is a "complete" definition, PAWS normally defaults
anything with some neutral definition (The rock has no smell, It feels
like an ordinary rock to me, etc). Out of the box PAWS supports all 5
senses, the example shows every property set rather than defaulted.
As for a preprocessor layer, no, I'm afraid not. But you can define
methods for the base object to allow you to create any definition
methodolgy you prefer. Also, an editor with cut and paste helps
tremendously. :)
>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.)
Actually, there isn't a huge distinction in Python between source code
and run-time code. The code sample *is* defining an object that
becomes part of the "compiled" (byte-code interpreted) file.
All you're really doing is creating an object from a predefined class,
then changing individual properties. So if your class is fairly
specific, as in this example:
DeepForest3 = ClassForest()
which defines a "forest" room completely, except for a map. The map
looks like this:
DeepForest3.Map = {North: NorthWall2,
Northeast: NorthWall2,
East: DeepForest4,
Southeast: DeepForest,
South: DeepForest,
Southwest: DeepForest,
West: MapleStand,
Northwest: NorthWall2}
Notice there's no definition for up or down, this is handled by
creating a default map for the class ClassForest. Also excuse the
spacing, it works using a fixed-width font. :)
And yes, dictionaries do use curly braces... :)
Here's a map with complaints built in:
BirchGrove.Map = {North: DeepForest2,
Northeast: DeepForest2,
East: DeepForest2,
Southeast: DeepForest2,
South: DeepForest2,
Southwest: DeepForest2,
West: DeepForest2,
Northwest: A3WayPath2,
Up: "There are no climbable trees here.",
Down: "You can not go down."}
You can use triple quoted text in a dictionary for multiple line
complaints. In fact Python is almost as loosely typed as TADS, the
only difference really is that Python makes a much stricter
distinction between classes and objects than TADS does.
Larry Smith
> wo...@one.net wrote:
> > 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?
Pascal & Modula used to support the "with" statement that served
this purpose:
Rock = ClassItem("rock,stone","small,gray,grey")
with Rock do
AdjectivePhrase = "small gray"
NamePhrase = "rock"
StartingLocation = StartCliff
Bulk = 1
Weight = 10
SetDesc("Feel","""
It weighs about a pound, and is smooth like a rock
from a stream, but not polished. It's a typical
rock.
""")
end
This construct was removed from Oberon (Oberon used WITH
as a type test) because it was noticed that re-compiling
a with-block using different global declarations could
cause an inadvertant change in semantics. For example,
if the user added a global "Bulk" variable (if we resolve
globals first) or if we had a global Bulk variable but
removed the Bulk instance var from Rock (if we resolve
globals second). Either way we've silently introduced
an error with a simple recompilation of unchanged code.
Oberon simply required the user add the "Rock." wherever
it was needed. The overhead for this is not high, and
it does enhance readability.
--
.-. .-. .---. .---. .-..-. | Never, ever underestimate
| |__ / | \| |-< | |-< > / | the power of stupid people
`----'`-^-'`-'`-'`-'`-' `-' | in large groups.
My opinions only. |
okbl...@my-deja.com
wo...@one.net wrote:
>
> I hear that. :) The hard part is documenting the system, I'm creating
> documentation for new game authors and I'm finding myself creating
> massive amounts of comments for the programs, a technical manual, and
> a "How to create an adventure in PAWS" manual.
>
> I'm finding that I can't get too far ahead on any one piece, it's
> easier to keep them in sync. But it takes about 3 times as long...
I'm looking forward to see what you've come up with. Python has often
been mentioned here as a good candidate for IF and I'd like to see an
actual implementation.
Iain Merrick
[...]
> >> 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.
> >
> >language actually lets you do -- the runtime system? I normally do.
>
> it defines a syntax and a standard library. If you write a program which
> uses syntax not allowed by the standard you are no longer writing in C.
> For example C++ style comments in C programs (at least until the FDIS for
> C9X is approved).
What I was sort of trying to get it is that, for instance, modern Pascal
is roughly as powerful as C. On the mac at least, you can write
essentially the same kinds of programs in either language and get
essentially the same code. Linking C modules and Pascal modules within a
single program is trivial.
The real difference is that Pascal's syntax is absolutely horrible -- in
my opinion. But it does have a few nice features: for instance, a WITH
block will avoid the 'Rock.' problem discussed elsewhere in this thread.
(This found its way into Modula-*, as has also been mentioned.)
So I tend to think of C and Pascal being, in some woolly sense, 'the
same language'. They're both procedural, statically typed, use manual
memory allocation, usually compile to native code and so on.
As for syntax additions, I've written a lot of stuff in pure ANSI C as
well as C with useful extensions, such as C++ comments. Are these the
same language? Well, yes and no. The syntax is different, but the stuff
you can actually do is the same. It's easy to translate the 'enhanced'
variant back into pure ANSI C.
What I hadn't realised is that the Python runtime system includes a
Python compiler and interpreter. Obviously this makes things a bit
muddier.
--
Iain Merrick
i...@cs.york.ac.uk
Jurgen Lerch)
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.,
[...]
> 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.
What about PROLOG?
Ad Astra!
JuL
--
ler...@uni-duesseldorf.de / Realität ist eine Krücke für diejenigen,
Jürgen ,,JuL'' Lerch / die mit der Fantasie nicht zurechtkommen
http://www-public.rz.uni-duesseldorf.de/~lerchj/
J. Holder
> DeepForest3.Map = {North: NorthWall2,
> Northeast: NorthWall2,
> East: DeepForest4,
> Southeast: DeepForest,
> South: DeepForest,
> Southwest: DeepForest,
> West: MapleStand,
> Northwest: NorthWall2}
In your system, is it possible for the target of a map to be a function,
as long as the function returns a location?
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
<jholder> do you like FreeBSD?
<hal> I need to get the ISDN line running so that I will tell it to pass over
me and replace my SuSE box with FreeBSD.
Ross Presser
Lerch).wrote.posted.offered:
>Saluton!
>
>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.,
>[...]
>> 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.
>
>What about PROLOG?
>
> Ad Astra!
> JuL
>
I'm waiting for a BeFunge version of Adventure. :) Hey, they did Wumpus
in BeFunge....
Erik Max Francis
> I'm waiting for a BeFunge version of Adventure. :) Hey, they did
> Wumpus
> in BeFunge....
What people with free time won't do ...
--
Erik Max Francis | icq 16063900 | whois mf303 | email m...@alcyone.com
Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | Thu 1999 Aug 19 (24%/948) | &tSftDotIotE
__
/ \ What a crime to waste [youth] on children.
\__/ George Bernard Shaw
wo...@one.net
Hi Okblacke,
>I'm looking forward to see what you've come up with. Python has often
>been mentioned here as a good candidate for IF and I'd like to see an
>actual implementation.
I'm actually working on it fairly steadily now, so it should be Real
Soon Now. The current version lacks save/replace capabilities, combat
services, and a few other niceities. But as soon as I have a more or
less feature complete beta I'll upload it to ftp.gmd.de which should
hopefully be in a couple of months.
Matt Ackeret
plus garbage collection) built in that _looks_ like C or C++ (with the addition
of the regular expression syntax)?
No, I don't mean just using some regular expression libraries with C.
I really like some features of Perl, but it looks like gibberish. I realize
a lot of people say that about C, but C just "seems" perfect. (And it _wasn't_
the first structured high level language I programmed in either.. Pascal was..)
I've been on this quest for a while but it seems like none exists..
--
mat...@area.com
Erik Max Francis
> Are there any languages with the features of Perl (mostly string
> manipulation,
> plus garbage collection) built in that _looks_ like C or C++ (with the
> addition
> of the regular expression syntax)?
>
> No, I don't mean just using some regular expression libraries with C.
Get those (standard under most Unixes), implement a suballocator that is
hooked into all the template classes you want to use for generic data
structures, and off you go.
David Given
ler...@uni-duesseldorf.de (J"urgen Lerch) writes:
[...]
> What about PROLOG?
Prolog *might* make a good IF language. I don't know. Even after my
university course on it, I still don't understand it, and I don't know
anyone who does (except my university logic lecturer[1], but noone
understood *him*).
Is anyone here actually fluent in it?
[1] He actually wrote Mac applications in it. Yes, GUI and all. Brrrr.
--
+- David Given ---------------McQ-+
| Work: d...@tao-group.com | Disclaimer: We have no wish to offend you
| Play: dgi...@iname.com | unless you're a twit.
+- http://wired.st-and.ac.uk/~dg -+
Albert Yi
group and deserves a proper response.
>Are there any languages with the features of Perl (mostly string
>manipulation, plus garbage collection) built in that _looks_ like C
>or C++ (with the addition of the regular expression syntax)?
>
>No, I don't mean just using some regular expression libraries with
>C.
>
>I really like some features of Perl, but it looks like gibberish. I
>realize a lot of people say that about C, but C just "seems"
>perfect. (And it _wasn't_ the first structured high level language
>I programmed in either.. Pascal was..)
>
>I've been on this quest for a while but it seems like none exists..
C++? With the modern library you can easily do string manipulation.
Garbage collection is a bit messy, but possible. Do research on
smart pointers and the like.
--
Albert (TheCheeseMan) (Baud Bard)
http://home.earthlink.net/~thecheezeman
http://conceptual.virtualave.net
ICQ: 14617788
"I don't know why I did it,
I don't know why I enjoyed it,
and I don't know why I'll do it again."
- Bart Simpson
Adam J. Thornton
>In article <7ph4bc$b...@poseidon.rz.uni-duesseldorf.de>,
> ler...@uni-duesseldorf.de (J"urgen Lerch) writes:
>[...]
>> What about PROLOG?
>Prolog *might* make a good IF language. I don't know. Even after my
>university course on it, I still don't understand it, and I don't know
>anyone who does (except my university logic lecturer[1], but noone
>understood *him*).
>Is anyone here actually fluent in it?
Phil Goetz is, if he's still around.
His Ph.D. thesis was, IIRC, about using PROLOG for an IF system.
Or if it wasn't his thesis, then it was certainly something he worked on in
graduate school.
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Fraser Wilson
Albert Yi <theche...@earthlink.net> wrote:
>C++? With the modern library you can easily do string manipulation.
>Garbage collection is a bit messy, but possible. Do research on
>smart pointers and the like.
C++ is very ... well, Seleucid for want of a better analogy. Ada has
remarkable string manipulation features, but I don't think that this
really counts toward ease of IF language creation.
Writing a garbage collector in any of the Pointers-must-be-free! languages
would be a painful process. In practice, smart pointers are sufficient,
as you imply. However, my wish list for an IF language certainly includes
a laid-back attitude toward lists, recursion and higher-order functions.
In particular, I want this: subset = [x | x <- super, x > 0].
Fraser.
Michael Brazier
>
> Writing a garbage collector in any of the Pointers-must-be-free! languages
> would be a painful process. In practice, smart pointers are sufficient,
> as you imply. However, my wish list for an IF language certainly includes
> a laid-back attitude toward lists, recursion and higher-order functions.
> In particular, I want this: subset = [x | x <- super, x > 0].
What does that last mean in English? If it's formal math notation, I'd
guess "subset is all x such that x belongs to super and is greater than
0".
--
Michael Brazier
"Like every book I never wrote, it is by far the best book I have ever
written."
-- G. K. Chesterton, _The Everlasting Man_
Fraser Wilson
>Is anyone here actually fluent in it?
Yes (or at least I used to be), but I've never written IF in it. There
would be many advantages ... IF is a matter of checking things against
other things, and Prolog is great at that. For example, finding out if
a room is lit reads very naturally:
islit (R) :- light_source (R).
islit (R) :- contains (R, Object), light_source (Object).
islit (R) :- contains (R, Object), transparent (Object), islit (Object).
islit (R) :- contains (R, Object), container (Object), open (Object),
islit (Object).
"An object is lit if it's a light source, it (directly) contains an
object which is a light source, or it contains an object which is transparent
and that object contains a light source, or ..."
This sort of world-modelling logic is a doddle.
Fraser.
Fraser Wilson
Michael Brazier <mbra...@argusinc.spamaway.com> wrote:
>> In particular, I want this: subset = [x | x <- super, x > 0].
>What does that last mean in English? If it's formal math notation, I'd
>guess "subset is all x such that x belongs to super and is greater than
>0".
You see? That's why Haskell is such a beautiful language ... it does
what it says it does, rather than doing lots of other things which
end up (maybe) giving you the result you wanted.
OK, so "subset" and "super" were fairly broad hints. But still.
In a more IF context, you'd be taking a subset of all objects such that,
I don't know, visible was true, or that were containers, that sort of
thing. Explicitly coding the loop is not only somewhat indirect, but
doesn't work for infinite lists, and screws up any lazy evaluation you
might have been trying to do.
Fraser.
Erik Max Francis
> Fraser Wilson wrote:
>
> > In particular, I want this: subset = [x | x <- super, x > 0].
>
> What does that last mean in English? If it's formal math notation,
> I'd
> guess "subset is all x such that x belongs to super and is greater
> than
> 0".
Presumably. With set theory and predicate logic, one would write his
statement as
subset = { x : x in super & x > 0 },
where `:' is either a colon or a vertical stroke, `in' is the "is an
element of" symbol (a stylized rounded epsilon), and `&' is either an
ampersand or a wedge pointing upward.
Problem is, of course, doing that kind of high-level stuff is not too
easy :-).
--
Erik Max Francis | icq 16063900 | whois mf303 | email m...@alcyone.com
Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
USA | Fri 1999 Aug 20 (27%/948) | &tSftDotIotE
__
/ \ All bad poetry springs from genuine feeling.
\__/ Oscar Wilde
wo...@one.net
Hi J,
>In your system, is it possible for the target of a map to be a function,
>as long as the function returns a location?
It should be, a dictionary can contain a function reference. At the
present time the Travel() function doesn't support function objects,
only object references and strings, but it would probably take only 3
lines of code to accomodate the change.
Iain Merrick
[...]
> You see? That's why Haskell is such a beautiful language ... it does
> what it says it does, rather than doing lots of other things which
> end up (maybe) giving you the result you wanted.
Urgh. Yes, well, _sometimes_ it does.
Other times the type system gets in the way and complains that you're
unifying infinite types, or you have a one-line function with
half-a-dozen zips and folds and filters and your brain starts going all
wibbly...
I'd be interested to see an IF language written in Haskell or some
similar language. I suspect that it would be rather painful, since
functional languages aren't great for stateful calculations and 95% of
IF programming involves managing state.
Okay, so you can handle state in Haskell with monads. I even know people
who understand how monads work, but these are some of the people who
_designed_ Haskell. :) Mere mortals like me have a bit more trouble.
I think a language like Scheme -- mostly functional but with dynamic
typing and impure I/O when you need it -- is probably a better bet for
IF. But feel free to prove me wrong.
--
Iain Merrick
i...@cs.york.ac.uk
Jonadab the Unsightly One
> 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.
You want to know what makes a language easy to learn?
One thing: a good manual. There is no substitute for a good
manual. Of all the languages I've ever used, there are only
two I really love, and those are the two for which I
have an excellent manual. (In one case it is hardback, and in
the other case it is electronic, but it's the content that
matters, as well as the way in which the content is organised.)
Now, I'll grant that it's possible to devise a pathological
language for which a good manual would not make it easy to
learn. (Machine code is probably an excellent example.) But
the exact nature of the language is far less important for
learning (to me anyway) than the quality of the manual. I
had a MUCH easier time ("night and day" is a phrase that
comes readily to mind) learning 8086 assembler than C++. Is
it easier to learn? I doubt it. I had a halfway decent
textbook for 8086 assembler, and I had nothing (but Borland's
help system) when trying to learn C++ (originally; I've since
found some slightly better materiels, but still nothing
that resembles a good manual).
We're off the subject of parsers now.
-- jonadab
I've given up spamblocking; it wasn't working all that
well anyway; my email address is now correct in the headers.
Jonadab the Unsightly One
> 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.
Such juxtaposition of utter nonsense (everyone just like you
*indeed*) with such good sense...
> ....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 keep meaning to try it out...
> I *have* seen point-and-click, non-textual "programming" systems.
Two words: Visual Basic.
(Yeah, yeah, it's got some textual scripting capabilities. But it's
designed to be point-and-click primarily, and the textual programming
just feels retrofitted to me.)
> 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*.
It sounds awful. Did it use flowcharts too?
Jonadab the Unsightly One
> A text interface does not impose a bias.
No, a text interface does impose a bias; it's simply not as
obvious as the bias in a graphical interface. But some commands
are easier to type than others, et cetera.
> The most
> flexible MIDI sequencer I've ever used was called Dr. T's KCS.
Have you ever seen the Midi Disassembler/Assembler?
Jonadab the Unsightly One
> There's a thought - writing a LISP engine through a GUI. Mmmmm.
A clone of emacs written entirely in Lingo, anyone?
Jon Zeppieri
jon...@bright.net (Jonadab the Unsightly One) wrote:
>
> You want to know what makes a language easy to learn?
>
> One thing: a good manual.
[Humming the theme song to "Different Strokes"]
You know, the only programming language I ever learned by reading a
manual was M68k assembly. [And, really, how else can one learn
assembly?]
It's not that I don't ever refer to manuals. But I pretty much always
learn programming languages from examples.
Fraser Wilson
Iain Merrick <i...@cs.york.ac.uk> wrote:
>Okay, so you can handle state in Haskell with monads. I even know people
>who understand how monads work, but these are some of the people who
>_designed_ Haskell. :) Mere mortals like me have a bit more trouble.
This is what happens to me; I say "you know, whenever I look at using
Haskell for project X, I get undone by the problem of carrying all that
state around" and people say "Use monads" and nod wisely.
>I think a language like Scheme -- mostly functional but with dynamic
>typing and impure I/O when you need it -- is probably a better bet for
>IF. But feel free to prove me wrong.
Lately, I've cheated by putting some Good Bits from Haskell on a standard
object hierarchy idea. The impurity hurts though. If I can give up caffiene
and nicotine, I can surely give up state!
Fraser.
(it's just a state of mind)
Jonadab the Unsightly One
> > You want to know what makes a language easy to learn?
> >
> > One thing: a good manual.
>
> [Humming the theme song to "Different Strokes"]
>
> You know, the only programming language I ever learned by reading a
> manual was M68k assembly. [And, really, how else can one learn
> assembly?]
>
> It's not that I don't ever refer to manuals. But I pretty much always
> learn programming languages from examples.
A good manual contains multitudes of examples.
I thought everyone knew that.
Knight37
Jonadab the Unsightly One <jon...@bright.net> wrote
[snip]
> I had a MUCH easier time ("night and day" is a phrase that
> comes readily to mind) learning 8086 assembler than C++. Is
> it easier to learn? I doubt it. I had a halfway decent
> textbook for 8086 assembler, and I had nothing (but Borland's
> help system) when trying to learn C++ (originally; I've since
> found some slightly better materiels, but still nothing
> that resembles a good manual).
I consider 8086 assembler to be much, MUCH easier than C++.
Of course, it's harder to program anything worthwhile in it.
Go figure.
:)
Knight37
John Elliott
>I consider 8086 assembler to be much, MUCH easier than C++.
>Of course, it's harder to program anything worthwhile in it.
>Go figure.
Euurgh. 8086 is horrible - not only the icky segmented architecture, but
the fact that when you see
MOV AX,THING
you don't know (without grubbing around for the definition of THING)
if it's loading AX with a constant or a variable.
Now, Z80. That's easy.
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)