Infocom commands
Gabe McKean
high-quality authoring systems out there (i.e.. TADS, Inform, Hugo)? Using
one will take care of a lot of 'drudgery' that goes into writing IF,
including implementing the 'standard' verbs.
Mikael
verbs/commands. What verbs/commands should I use? I figured the best
solution would be to copy the commands that are used in Infocom games.
Does anyone have a list of them?
Regards
Michael Lonc
David Welbourn
Spellbreaker, I'm ashamed to say that at one point I tried a brute force
method (using a crossword finishing dictionary) to learn much of its
vocabulary, at least up to 5-letter words. These are *some* of the words
Spellbreaker recognizes; hope it helps:
A (article), D (down), E (east), G (again), I (inventory), L (look), N
(north), Q (quit), S (south), T (time), U (up), W (west), Y (yes), Z (wait).
AM, AN, AQ (the earth cube), AT, AZ, BQ (the water cube), BZ, CQ (the air
cube), CZ, DQ (the fire cube), DZ, EQ (the dark cube), EZ, FQ (the nil
cube), FZ, GO, GQ (the light cube), GZ, HI, HQ (the soft cube), HZ, IN, IQ
(the bone cube), IS, IT, IZ, JQ (the change cube), JZ, KQ (the time cube),
KZ, LQ (the string cube), ME, MQ (the magic cube), MY, NE, NO, NW, OF, ON,
SE, SW, TO, UP, ZM (zorkmids).
AIR, ALL, AND, ARE, ARM, ASK, BAG, BAT, BED, BOX, BUT, BUY, CUT, DIG, DOT,
EAT, EFT, EGG, EYE, FAT, FIT, FIX, FLY, FOR, FUR, GET, GOD, HER, HIM, HIT,
HOP, HUT, ICE, JAB, KEY, LAY, LID, LIE, LIT, LOW, MAN, MAW, MUD, NAP, NEW,
OAK, OFF, OLD, ONE, OUT, PAT, PAY, PET, PRY, PUT, RAP, RED, ROC, RUB, RUG,
RUN, RYE, SAY, SEA, SET, SIP, SIT, SOD, THE, TIE, TUG, WHO, YES, ZIP.
AREA, ARMS, BABY, BLOW, BOOK, BARE, BERG, BIRD, BURN, BURY, BUSH, BITE,
BOTH, BLUE, CUBE, COIN, CALL, CELL, CLOG, COPY, CAST, CAVE, DRAG, DAMN,
DAMP, DUMP, DOOR, DARK, DIRT, DUST, DIVE, DOWN, EYED, EXIT, EAST, FLAT,
FACE, FUCK, FEED, FEEL, FREE, FLIP, FILL, FILM, FANG, FIND, FLOE, FOOD,
FROG, FROM, FIRE, FORD, FISH, GRAB, GILT, GOLD, GRUE, GIVE, GAZE, HEAD,
HIDE, HUGE, HALL, HELP, HOLD, HOLE, HAND, HINT, HARD, HERE, HURL, IDOL,
IRON, INTO, JUMP, JUNK, KICK, KILL, KNOB, KISS, LEAD, LEAN, LEAP, LOAF,
LOCK, LIFT, LAND, LINE, LONG, LOOK, LURK, LAVA, MELT, MASS, MIST, MOSS,
MOVE, NOPE, NEST, NEWT, OKAY, OPAL, OPEN, OVER, OGRE, ONTO, PLAY, PICK,
POET, PAIR, POKE, PILE, PULL, PUMP, POOL, PIPE, PUSH, PATH, PLUG, POUR,
QUIT, QUIZ, READ, RISH, ROCK, RIDE, RUIN, ROLL, RUNE, ROOF, ROOM, RARE,
REST, RISE, ROSE, SLAY, STAB, SACK, SHED, STEP, SIGN, SKIP, SPIN, SWIM,
SALT, SELF, SELL, SOME, SAND, SEND, SHOP, SHOW, SNOW, SHUT, SAVE, THAW,
TOAD, TRAP, THEM, THEN, TREE, TWIN, TAKE, TALK, TALL, TELL, TIME, TINY,
TARN, TURN, TOSS, UGLY, WEAR, WHAT, WADE, WEED, WAIT, WAKE, WALK, WALL,
WILY, WEST, WITH, WAVE, YELL, YOUR, YAWN.
AGAIN, ALARM, AWAKE, ABOUT, ALONG, APPLY, BLACK, BLANK, BOARD, BREAD, BREAK,
BEING, BLIND, BRIEF, BAKER, BELOW, BLOCK, BROWN, BURIN, BURLY, BATHE, BRUSH,
CHASE, CRACK, CHECK, CHICK, CLIFF, CLIMB, CLOSE, CLOUD, CROSS, CARRY, CORAL,
CATCH, CHUNK, COUNT, CRUDE, DRINK, DIMLY, DROOL, DIRTY, DUSTY, ERASE, EMPTY,
EARTH, ENTER, FIELD, FRESH, FIGHT, FAIRY, FLOOR, FIRST, GRASS, GUANO, GUARD,
GREEN, GUILD, GROUP, HELLO, INPUT, INSET, KNIFE, KNOCK, LEARN, LEAVE, LABEL,
LIGHT, LOOSE, LARSE, LATCH, LEVEL, LOWER, MUDDY, MAGIC, MANSE, MONEY, MOSSY,
MOUTH, NORTH, OFFER, PLACE, PLAIN, PLANT, PRESS, PUFFY, POINT, PRICE, PRINT,
PARTY, PASTE, PATCH, PITCH, POUCH, PRUNE, QUERY, REACH, RAISE, REPLY, ROUSE,
RAZAR, SCALE, SCALY, SHAKE, SHARD, SHARP, SLASH, SMALL, SMASH, SNAKE, STAND,
STARE, SHEER, SLEEP, SMELL, SPELL, STEEL, SHIFT, SLICE, SLIDE, SLIME, SNIFF,
SPILL, SWING, SOLID, SPLIT, SANDY, SCORE, SHOOT, SHORT, SHOUT, SHOVE, SMOKE,
STONE, SUPER, SCREE, SURLY, SOUTH, STUFF, SEVER, THANK, TRACK, TRADE, TRAIL,
TEETH, THONG, TROOP, THROW, TASTE, TOUCH, TRUNK, TOWER, UNDER, USING, UNTIE,
UNZIP, VAULT, WEDGE, WHERE, WRECK, WHIRL, WHITE, WRITE, WATCH, WATER, WOVEN,
YOUNG.
-- David Welbourn
Gabe McKean
versatile tool. However, once you get into TADS or Inform, you'll find that
they are versatile too, they're just specialized to work in the field of IF.
If you're so lazy, as you put it, why do you think it will be easier to
write your own parser than to learn how to use an existing one? If you want
your parser to be high-quality, I think you'll find it will be a LOT of
work. Another issue is portability: unless you plan on using nothing but
ANSI C, your game won't be very portable. Whereas, if you use one of the
major parsers, it can be easily ported to any machine which has an
interpreter written for it.
If you're still interested in doing this, for the challenge of it or
whatever, then I wish you luck. I'm just trying to let you know that an
easier way exists. Here's a list of the default verbs used in TADS, many of
which are synonyms:
inspect, examine (also abbreviated 'x'), look at, look ('l), look around,
look through, look behind, ask, tell, follow, dig, dig in, jump, jump off,
jump over, push, press, attach, connect, wear, put on, don, drop, put down,
take off, doff, open, close, put, place, take, get, pick up, remove, look
in, look on, screw, unscrew, turn, rotate, twist, switch, flip, activate,
turn on, switch on, deactivate, turn off, switch off, sit, sit on, sit in,
sit down, lie, lie on, lie in, lie down, get out, get off, get in, get into,
get on, board, again ('g', repeats last command), wait ('z'), inventory
('i'), break, ruin, destroy, attack, kill, hit, climb, eat, consume, drink,
give, offer, pull, read, throw, toss, stand on, stand, stand up, get up,
show, clean, say, yell, shout, move, fasten, buckle, buckle up, unfasten,
unbuckle, plug, unplug, type, lock, unlock, detach, sleep, poke, jab, touch,
search, knock, center.
And of course you also have the movement directions. Most games use only a
subset of these verbs, but then many games also add their own verbs. If you
want your parser to be general purpose you should probably use most or all
of these, but if you want to specialize it for your game then just pick the
ones you need for it.
Mikael
why should I? There is nothing one can do using Inform that one can not do
using C. Sure, Inform or TADS may be better suited for the task, but I still
think (without beeing an expert on neither of them) that C is much more
powerfull and versatile than any text adventure creation system.
Regards
Michael Lonc
Gabe McKean <gmc...@wsu.edu> skrev i
diskussionsgruppsmeddelandet:881es1$8gq$1...@leopard.it.wsu.edu...
Mikael
Choosing between C and Inform or TADS or any other text adventure creation
system is like choosing between Spanish and Esperanto. On the one hand there
is a language spoken by hundreds of millions of people with a long tradition
and a rich litterature. On the other hand there is a language spoken by an
extremely limited number of people with no literary tradition to speak of. I
woudn't mind learning Spanish but I would consider learning Esperanto a
waste of time and effort.
There are other similarities between text adventure creation systems and
Esperanto. Inform and TADS are, not unlike Esperanto, "synthetic" languages
created with a specific task in mind. Outside of that limited task they are
useless. This is another advantage to C; it's a "multi-task" computer
language.
> If you're so lazy, as you put it, why do you think it will be easier to
> write your own parser than to learn how to use an existing one?
I think the difficulties involved in writing a parser "from scratch" have
been somewhat exaggerated. The parser is after all expected merely to
interpret a single line of input into actions. It's not expected to
translate Chinese poetry into English. The reason for exaggerating the
difficulties in writing a parser stem from the fact that many text
adventure writers are content with using text adventure creation systems and
think that using a "low level" computer language like C would require an IQ
of at least 250. They couldn't be more wrong. The power and versatility of C
is mainly due to it's elegance and simplicity (when used correctly).
Regards
Michael Lonc
Gabe McKean <gmc...@wsu.edu> skrev i
diskussionsgruppsmeddelandet:882gal$l24$1...@leopard.it.wsu.edu...
Mikael
th...@my-deja.com
"Mikael" <018-4...@telia.com> wrote:
> Choosing between C and Inform or TADS or any other text
> adventure creation system is like choosing between Spanish
> and Esperanto.
I believe this is a false analogy. You need to use the right tool for
the right job. One could easly make the analogy to cracking nuts.
Sure, you can use a hammer, but it's cleaner and easier to use a
nutcracker. It doesn't take too many nuts to make it worth the effort
to learn to use the right tool. I suspect that the advice already given
here is sound -- that you'd find that the effort required to learn the
commands in TADS would be less than the effort saved by using the right
tool for the job.
I also think you're under some misconceptions about Esperanto.
> On the one hand there is a language spoken by hundreds of
> millions of people with a long tradition and a rich litterature.
> On the other hand there is a language spoken by an extremely
> limited number of people with no literary tradition to speak of.
As one among that "limited number" I will say that you're making it very
tempting to "speak of" the extensive literary tradition of Esperanto -
both original translated - which, while certainly not overtowering that
of Spanish, is certainly something to "speak of."
> I woudn't mind learning Spanish but I would consider
> learning Esperanto a waste of time and effort.
Well, as one who has (and still is) learning Esperanto (I'd estimate my
fluency as just under a 3 on the FSI scale, if you're familiar with
that) of course I disagree. It's certainly no more a waste of time and
effort than writing interactive fiction - which clearly many people
enjoy.
> There are other similarities between text adventure creation
> systems and Esperanto. Inform and TADS are, not unlike
> Esperanto, "synthetic" languages created with a specific
> task in mind.
Is that so? Is TADS any more synthetic than C? What is the "specific
task" for which Esperanto was created? Esperanto was, in fact, designed
to be more easy to learned than other languages, but to suggest that it
was designed for only one task (such as poetry, political discussions,
marriage brokering, or education) indicates a basic misunderstanding of
what Esperanto is. (See www.esperanto.net for info on Esperanto.)
> Outside of that limited task they are useless.
Are we still talking about Esperanto? If so, see above.
> This is another advantage to C; it's a "multi-task" computer
> language.
You don't use a swiss-army knife to chop down trees just because it's
multi-function.
Good luck on your project.
Thomas Alexander
Sent via Deja.com http://www.deja.com/
Before you buy.
Iain Merrick
> To be perfectly honest with you I'm too lazy to learn a new language. And
> why should I? There is nothing one can do using Inform that one can not do
> using C. Sure, Inform or TADS may be better suited for the task, but I still
> think (without beeing an expert on neither of them) that C is much more
> powerfull and versatile than any text adventure creation system.
The main advantage of Alan, Hugo, Inform, TADS and the like is that they
produce a platform-independent game file which can be played on almost
any computer. You can play any Inform game with a single Z-code
interpreter, any TADS game with the TADS interpreter, and so on. (The
same applies to many non-IF languages like Java and Python.)
This has proven to be _much_ more convenient than games written in
native code. Okay, you don't need an interpreter, but if you write a
game in C you'll have to compile and test different versions for all the
different architectures and operating systems your players might be
using. The majority of people use Windows, certainly, but there are
plenty of IFers who use DOS, MacOS, RISC OS, various flavours of Unix...
maybe even Amigas; who knows?
Anyway, the time spent learning an IF language will be a good
investment. You'll have a much better chance of actually writing a
decent game, and it might even improve your programming in general. I
think learning Haskell (a pure functional language) improved my
understanding of C a great deal, for instance, and TADS has informed my
use of object orientation in C++.
Not convinced? If you still have your heart set on C, have a look at
Andrew Plotkin's Glk. If you use the Glk API for all your I/O --
interacting with the player, reading files and so on -- you'll be able
to port your code to many different platforms without too much fuss.
Here's the URL:
http://www.eblong.com/zarf/glk/
--
Iain Merrick
i...@cs.york.ac.uk
Andrew Plotkin
> To be perfectly honest with you I'm too lazy to learn a new language. And
> why should I? There is nothing one can do using Inform that one can not do
> using C.
It is easier to learn Inform than to write an equivalently powerful game
engine yourself. That's why.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Paul O'Brian
> Choosing between C and Inform or TADS or any other text adventure creation
> system is like choosing between Spanish and Esperanto.
> [C is useful because it's widespread, IF languages a waste of time
> because they aren't.]
Well, there you have it. So: enough talk. Write that game in C. If it's a
good as, say, Anchorhead or Losing Your Grip, I assure you you'll get no
complaints about what language it's written in. Well, you may get
complaints from people who have difficulty playing it on their platform,
but I'm sure you'll make the effort to compile it under lots of different
platforms.
Anyway, you've made your stance clear, but I doubt you're going to
convince anybody here with further arguments. You know what would really
prove your point? A good game.
--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
SPAG #19 is here, featuring reviews of 1999 IF competition games and
interviews with the winners, along with news, scoreboard, and more!
Find it at http://www.sparkynet.com/spag
Adam Atkinson
>maybe even Amigas
very much so.
--
Adam Atkinson (gh...@mistral.co.uk)
Poor Impulse Control
L. Ross Raszewski
>
>I think the difficulties involved in writing a parser "from scratch" have
>been somewhat exaggerated. The parser is after all expected merely to
>interpret a single line of input into actions. It's not expected to
>translate Chinese poetry into English. The reason for exaggerating the
>difficulties in writing a parser stem from the fact that many text
>adventure writers are content with using text adventure creation systems and
>think that using a "low level" computer language like C would require an IQ
>of at least 250. They couldn't be more wrong. The power and versatility of C
>is mainly due to it's elegance and simplicity (when used correctly).
>
To say that the difficulties of rolling your own parser have been
exxagerated ignores the fact that we've SEEN games with homebrew
parsers before. Since the "end" of commercial IF, there has not been,
to my knowledge, a single game not written in an IF language whose
parser was on par with that of inform. Most are substantially worse.
And as to the matter of tads or infrom beign "useless" outside their
designed task, well, that's jsut plain wrong. Completely wrong.
Probably couldn't be more wrong. Go look up "turing complete"
somewhere, then download freefall, samegame, space invaderz, or the
Z-code text editor.
--
"You can look but you can't touch; I don't think I like you much." -- Garbage
Jake Wildstrom
Mikael <018-4...@telia.com> wrote:
>I think the difficulties involved in writing a parser "from scratch" have
>been somewhat exaggerated. The parser is after all expected merely to
>interpret a single line of input into actions. It's not expected to
>translate Chinese poetry into English. The reason for exaggerating the
>difficulties in writing a parser stem from the fact that many text
>adventure writers are content with using text adventure creation systems and
>think that using a "low level" computer language like C would require an IQ
>of at least 250. They couldn't be more wrong. The power and versatility of C
>is mainly due to it's elegance and simplicity (when used correctly).
You're just being unjustifiably pigheaded here. "Many" text adventure writers
are quite familiar with C and find it an excellent language for many tasks.
In addition, it would be silly for writer in Inform/TADS to claim that C is
difficult, inasmuch as both languages bear significant syntactic resemblance to
C.
Now, INTERCAL, _that's_ a language you need an IQ of 250 to use.
And as for parser design--again, I think you're a little deluded as to how
difficult it actually can be. Some simple topics to think about:
* scoping: can you "see" a ball in a glass box? Can you touch it? How about
in a metal box? And what if the boxes are open or closed? Can you touch your
nose? Is your nose in your inventory? Can you drop your nose? You can
"get all", but can you "x all"?
* pronouns: If I "pet dog", what does "it" refer to later? How about "him",
"her", or "them"? What do various pronouns refer to when I say "drop the
scissors and the matchbook"? What do pronouns refer to when there
antecedants transform in some way or disappear?
* disambiguation: If I have a tube of nutrient paste and a jar of library
paste, what should "eat paste" do? How about "x tree" in the same room as
one or both of a painting of a tree and an oak tree? If several objects
are identical, how are they distinguished on input?
These all have reasonably straightforward and well-discussed answers. But
writing a system to deal with them all is a real hassle. Take a look at the
library code for inform (ftp.gmd.de/ifarchive/programming/inform6/library/*.h).
It is long and complicated, and is so for a reason--parsing is hard.
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
Magnus Olsson
Jake Wildstrom <wil...@mit.edu> wrote:
>In article <YIbp4.3336$dT4.20...@newsb.telia.net>,
>Mikael <018-4...@telia.com> wrote:
>>I think the difficulties involved in writing a parser "from scratch" have
>>been somewhat exaggerated. The parser is after all expected merely to
>>interpret a single line of input into actions. It's not expected to
>>translate Chinese poetry into English. The reason for exaggerating the
>>difficulties in writing a parser stem from the fact that many text
>>adventure writers are content with using text adventure creation systems and
>>think that using a "low level" computer language like C would require an IQ
>>of at least 250. They couldn't be more wrong. The power and versatility of C
>>is mainly due to it's elegance and simplicity (when used correctly).
>
>You're just being unjustifiably pigheaded here. "Many" text adventure writers
>are quite familiar with C and find it an excellent language for many tasks.
>In addition, it would be silly for writer in Inform/TADS to claim that C is
>difficult, inasmuch as both languages bear significant syntactic resemblance to
>C.
Indeed.
Look, Mikael, I happen to be a professional software developer. I write
C and C++ for a living. Lots of it. Every day. I've written parsers
before. I've written an adventure game from scratch (OK, it was
in Turbo Pascal, not in C, but that doesn't affect the difficulty
noticeably).
I still think TADS and Inform are better languages for adventure
writing than C.
Now, if you think it's more rewarding to write in C than in TADS
or Inform, please do so. The people who are saying that you should
use one of those languages rather than C are only trying to help,
though they may sound a bit dogmatic.
But please don't give us more of your bogus arguments like
those above, because all you're doing is putting your foot deeper
and deeper into your mouth. In sort, it's painfully obvious that
you're arguing out of ignorance.
Go ahead, write a game in C. It's fun, and in some ways funnier
than writing in TADS or Inform, I'll grant you that. But please
don't try to lecture us on how stupid we are for preferring other
languages until you've gathered enough experience to know what you're
talking about.
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Jim Power
in parsing. Can anyone else think of specific examples?
As for Mikael's arguments, they are specious. Of course, he may be about to create
a truly better parser than inform, but I don't understand his arguments for doing
so. I write in various different languages, but if a library or extension exists
to say, draw three dimensional objects on the screen, I use it if it serves my
purpose. I don't write a new one because I can't also use that library to multiply
matrixes. By analogy, I could mix all my own paints and create all my own brushes
in order to paint a picture. And I will even concede there may be reasons to do so
in some special circumstances. But only if you create something better and more
useful than the store bought products.
BTW, C is a truly horrible language when used for anything other than it's original
intended purpose (intermediate language between application programming languages
and assembler.)
-Jim
Jake Wildstrom wrote:
> In article <YIbp4.3336$dT4.20...@newsb.telia.net>,
> Mikael <018-4...@telia.com> wrote:
> >I think the difficulties involved in writing a parser "from scratch" have
> >been somewhat exaggerated. The parser is after all expected merely to
> >interpret a single line of input into actions. It's not expected to
> >translate Chinese poetry into English. The reason for exaggerating the
> >difficulties in writing a parser stem from the fact that many text
> >adventure writers are content with using text adventure creation systems and
> >think that using a "low level" computer language like C would require an IQ
> >of at least 250. They couldn't be more wrong. The power and versatility of C
> >is mainly due to it's elegance and simplicity (when used correctly).
>
> You're just being unjustifiably pigheaded here. "Many" text adventure writers
> are quite familiar with C and find it an excellent language for many tasks.
> In addition, it would be silly for writer in Inform/TADS to claim that C is
> difficult, inasmuch as both languages bear significant syntactic resemblance to
> C.
>
Mikael
First of all I would like to thank you for your kind permission to let me
write a text adventure in C.
I realize that programming, which for me is merely a plaesant past time
activity, is a matter of life and death for you.
Secondly, I have not called neither you nor anyone else stupid. I advise
you to calm down, take a couple of deep breaths and think before you accuse
someone of libel.
Finally, you seem to treat C and Inform as being on equal footing. While C
is a computer language in it's own right Inform is not. The difference
between them is that C is Turing complete while Inform is not.
It amazes me that a professional programmer is ignorant of one of the most
fundamental concepts of programming.
Regards
Michael Lonc
Magnus Olsson <m...@bartlet.df.lth.se> skrev i
diskussionsgruppsmeddelandet:884nid$rlc$1...@bartlet.df.lth.se...
> In article <38a5deca$0$22...@senator-bedfellow.mit.edu>,
Jake Wildstrom
Mikael <018-4...@telia.com> wrote:
>Secondly, I have not called neither you nor anyone else stupid. I advise
Dunno. You made a blanket statement about IF programmers, calling us ignorant
of C. That's not quite calling us stupid, but it is unflattering (and false).
>Finally, you seem to treat C and Inform as being on equal footing.
They're not "on equal footing" as such because they're designed for different
purposes. It's really apples and oranges here.
>While C
>is a computer language in it's own right Inform is not.
I'm not quite familiar with your definition of "computer language".
>The difference
>between them is that C is Turing complete while Inform is not.
Nor with your definition of "Turing complete". Examples, please? Besides the
Z-machine's built-in memory limitations (a moot point after Inform is able
to reliably compile to the Glulx format), it's certainly Turing complete.
I'm really not sure you're familiar enough with Inform (or TADS) to reliably
assess its limitations. Both statements you made above are demonstratably
false.
Gevan
You have however explained how we exaggerate the difficulty of writing
a text adventure parser to the current standard through ignorance of
the power and flexibility of a "real" programming language, which most of
us apparently have not had the fortune to use. I'm sure you can see
how somebody who makes their living in the software industry could
take offence at that.
>Finally, you seem to treat C and Inform as being on equal footing. While C
>is a computer language in it's own right Inform is not.
Most people distinguish between "programming language" and "general
purpose programming language". Inform is certainly a computer language
in its own right (and is also demonstrably more general purpose than
you seem to think).
>The difference between them is that C is Turing complete while Inform
>is not.
This suggests that you either haven't been reading the replies to your
posts on this subject, or that you are ignoring them, as a number of
people have pointed out to you that Inform is Turing complete in the
same practical sense (i.e., ignoring requirements of infinite storage)
that C is. Do you have some reason to believe that they are incorrect?
Magnus Olsson
>
>First of all I would like to thank you for your kind permission to let me
>write a text adventure in C.
(...)
>Secondly, I have not called neither you nor anyone else stupid.
(...)
>I advise
>you to calm down, take a couple of deep breaths and think before you accuse
>someone of libel.
(...)
>Finally, you seem to treat C and Inform as being on equal footing. While C
>is a computer language in it's own right Inform is not. The difference
>between them is that C is Turing complete while Inform is not.
>It amazes me that a professional programmer is ignorant of one of the most
>fundamental concepts of programming.
<< plonk >>
Adam J. Thornton
Mikael <018-4...@telia.com> wrote:
>Finally, you seem to treat C and Inform as being on equal footing. While C
>is a computer language in it's own right Inform is not. The difference
>between them is that C is Turing complete while Inform is not.
>It amazes me that a professional programmer is ignorant of one of the most
>fundamental concepts of programming.
Please prove that Inform is not Turing-complete.
I believe that you are mistaken.
Adam
P.S. FOAD, YPW. HTH, HAND.
--
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
David Glasser
> In article <0Gnp4.590$Ph6.17...@newsa.telia.net>,
> Mikael <018-4...@telia.com> wrote:
> >Finally, you seem to treat C and Inform as being on equal footing. While C
> >is a computer language in it's own right Inform is not. The difference
> >between them is that C is Turing complete while Inform is not.
> >It amazes me that a professional programmer is ignorant of one of the most
> >fundamental concepts of programming.
>
> Please prove that Inform is not Turing-complete.
Well, it obviously isn't, because it doesn't allow infinite storage, but
I can't think of any computer language/OS/hardware combination that is
technically Turing-complete.
(So Mikael is still ignorant of one of the most fundamental concepts of
intelligence, which is not being a complete moron.)
--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
"So, is that superior artistry, or the easy way out?"
--TenthStone on white canvases as art, on rec.arts.int-fiction
Adam J. Thornton
David Glasser <gla...@iname.com> wrote:
>Adam J. Thornton <ad...@princeton.edu> wrote:
>> In article <0Gnp4.590$Ph6.17...@newsa.telia.net>,
>> Mikael <018-4...@telia.com> wrote:
>> >Finally, you seem to treat C and Inform as being on equal footing. While C
>> >is a computer language in it's own right Inform is not. The difference
>> >between them is that C is Turing complete while Inform is not.
>> >It amazes me that a professional programmer is ignorant of one of the most
>> >fundamental concepts of programming.
>> Please prove that Inform is not Turing-complete.
>Well, it obviously isn't, because it doesn't allow infinite storage, but
>I can't think of any computer language/OS/hardware combination that is
>technically Turing-complete.
Sigh. Let me try that again:
Please demonstrate that Inform is not Turing-complete, while C is. Or,
failing that, that there exists some meaningful sense in which C is closer
to Turing-completeness than is Inform.[0]
>(So Mikael is still ignorant of one of the most fundamental concepts of
>intelligence, which is not being a complete moron.)
Hear, hear.
Adam
[0] "Because I assert that it is" is not, for the purposes of this
discussion, meaningful.
John W. Kennedy
> Choosing between C and Inform or TADS or any other text adventure creation
> system is like choosing between Spanish and Esperanto. On the one hand there
> is a language spoken by hundreds of millions of people with a long tradition
> and a rich litterature. On the other hand there is a language spoken by an
> extremely limited number of people with no literary tradition to speak of. I
> woudn't mind learning Spanish but I would consider learning Esperanto a
> waste of time and effort.
In context, this argument is ridiculous. C has many portability
problems, and requires a recompile (and, frequently, substantial
modification, even if pure ANSI) for every different architecture and
operating system. Inform binaries can run as-is on almost any modern
computer, from Palm Pilots to SGI 2000's, and substantially the same is
true of TADS.
> There are other similarities between text adventure creation systems and
> Esperanto. Inform and TADS are, not unlike Esperanto, "synthetic" languages
> created with a specific task in mind. Outside of that limited task they are
> useless.
I can't speak to TADS, but several non-adventure programs have been
written in Inform, including clones of Tetris and Robots and a tutorial
including a small implementation of the Scheme (a LISP derivative)
programming language.
It's a bad analogy, too. Esperanto has a great many faults (it's far
too Indo-European, and has phonetics that only a Slav could think easy
to pronounce), but it is _not_ intended for specialized use. It is, at
least in intent, a fully functional quasi-natural language for written
and spoken communication among humans, and possesses a native
literature. I'll choose Loglan (
http://www.halcyon.com/loglan/welcome.html ) over Esperanto any day, but
not on that issue.
> This is another advantage to C; it's a "multi-task" computer
> language.
Not if ones first language is English. There are damned few multi-task
programming languages (Ada and PL/I are the only well-established ones I
can name).
> I think the difficulties involved in writing a parser "from scratch" have
> been somewhat exaggerated. The parser is after all expected merely to
> interpret a single line of input into actions.
A simple parser is relatively trivial, of course. But in the jargon of
adventure writing, "parser" means "parser and dynamic disambiguator",
and that is damned difficult. Unless you are actually involved in
artificial-intelligence research, I doubt you're aware of the magnitude
of the problem. Are you capable of creating a SHRDLU clone in C -- in
many respects a far simpler task?
> It's not expected to
> translate Chinese poetry into English. The reason for exaggerating the
> difficulties in writing a parser stem from the fact that many text
> adventure writers are content with using text adventure creation systems and
> think that using a "low level" computer language like C would require an IQ
> of at least 250. They couldn't be more wrong. The power and versatility of C
> is mainly due to it's elegance and simplicity (when used correctly).
Has the penny not yet dropped that TADS and Inform were created by
people expert enough to write compilers in C?
I would add adventure-game writing also requires extensive world
modeling, a task to which C++ (or Objective C, or Java) is far better
suited than true C is.
--
-John W. Kennedy
-rri...@ibm.net
Compact is becoming contract
Man only earns and pays. -- Charles Williams
mathew
> Jake's comments were truly useful. I have been amazed at the difficulties
> involved in parsing. Can anyone else think of specific examples?
There are many classic examples of the difficulties of parsing English.
One I particularly remember from AI lectures was "long term car park
courtesy car pick up point" -- a sign found at an airport. Imagine
trying to get your parser to cope with commands like
> park at long term car park
> go to long term car park courtesy car pick up point
There are also many phrases that have similar form, but slightly
different meanings which can't be worked out without some kind of
real-world knowledge. For example, consider the difference between
"goat milk" and "cat milk"...
> BTW, C is a truly horrible language when used for anything other than it's
> original intended purpose (intermediate language between application
> programming languages and assembler.)
I must respectfully disagree -- C is a horrible language even when used
for its original intended purpose. (I speak as someone who's written
quite a lot of it over the years.)
mathew