which IF system has best world model & parser?

276 views
Skip to first unread message

Ed

unread,
Jul 9, 2002, 2:50:15 PM7/9/02
to
I'm looking for opinions on which IF system (for which source code is
available) has the best world model, and which IF system has the best
parser.

Some clarification is in order:

By "best" I mean the most powerful, consistent, robust, and extensible.

My reason for asking is that I'm considering writing a class library (or
set of class libraries) for C# and/or Java to enable those languages to be
used for writing IF. I don't want to reinvent any more wheels than I have
to, so I'd like to take advantage of what's been done before. I plan to
study the source code for one or two existing IF systems as part of the
design process for my own system.

Also, I don't care about graphics, sound, or fancy typography, just a good
solid purely text-based IF system.

Somebody is bound to ask "why write yet another IF system?" My reasons are
personal:

1. I've spent a fair amount of time playing around with Inform, and taken a
close look at TADS and Hugo, and I don't like them. As a software engineer
with 20 years experience, and an admitted language bigot as well, I have a
strong preference for fully object-oriented languages with C-like syntax.

2. I need to become more fluent in C# (currently my favorite language) and
Java (currently my second-favorite language), and this seems like a fun
project to use a learning experience. I'm more interested in the
programming part of the learning experience than in a high-level redesign
of IF world model or parser architecture, hence my original question.

And a few more things...

Yes, I will give credit where credit is due to any systems I "steal" from.

No, I'm not planning on trying to sell this. If it does grow into a usable
system, I plan to share it for free with the IF community.

If someone has already done this, I'd like to hear about it.

-- Ed

wo...@one.net

unread,
Jul 9, 2002, 3:02:36 PM7/9/02
to

Hi Ed <e...@mewsic.SPAMGUARD.com> wrote:

>I'm looking for opinions on which IF system (for which source code is
>available) has the best world model, and which IF system has the best
>parser.

You might take a look at PAWS, it's written in pure Python so
all the source is available. I won't claim it's the best :)
but I'm told the code is easy to follow and it's been
documented to within an inch of its life...

http://w3.one.net/~wolf/PAWS.shtml


Respectfully,

Wolf

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

Neil Cerutti

unread,
Jul 9, 2002, 3:46:09 PM7/9/02
to
In article <Xns924696F5A38E7ed...@199.45.49.11>,

Ed wrote:
> I'm looking for opinions on which IF system (for which source
> code is available) has the best world model, and which IF
> system has the best parser.
>
> Some clarification is in order:
>
> By "best" I mean the most powerful, consistent, robust, and
> extensible.

The problem with this question is that, once you have learned the
object model of an IF system, you have finished learning that
system. In other words, you need to be an expert in every current
IF system to know the answer to your question.

Another problem is, some of the terms you use are too open to
subjective interpretation.

Several systems have been used to write hundreds of playable
games. I see those systems as robust.

Several systems have created huge games. I see those
systems as powerful and extensible.

I'm guessing that you may have different expectations. Mine are
fulfilled.

There is some good news, though. See below.

> My reason for asking is that I'm considering writing a class
> library (or set of class libraries) for C# and/or Java to
> enable those languages to be used for writing IF. I don't want
> to reinvent any more wheels than I have to, so I'd like to take
> advantage of what's been done before. I plan to study the
> source code for one or two existing IF systems as part of the
> design process for my own system.

Here's the good news:

The most popular IF systems, and even the up-and-comers, all have
excellent documentation. You can use those documents to
determine, for yourself, the state of the art in world model.

> Somebody is bound to ask "why write yet another IF system?" My
> reasons are personal:
>
> 1. I've spent a fair amount of time playing around with Inform,
> and taken a close look at TADS and Hugo, and I don't like them.
> As a software engineer with 20 years experience, and an
> admitted language bigot as well, I have a strong preference for
> fully object-oriented languages with C-like syntax.
>
> 2. I need to become more fluent in C# (currently my favorite
> language) and Java (currently my second-favorite language), and
> this seems like a fun project to use a learning experience.
> I'm more interested in the programming part of the learning
> experience than in a high-level redesign of IF world model or
> parser architecture, hence my original question.

Your first reason is unconvincing (Inform and TADS are both
object-oriented and C-like), but your second reason is obviously
compelling.

> And a few more things...
>
> Yes, I will give credit where credit is due to any systems I
> "steal" from.
>
> No, I'm not planning on trying to sell this. If it does grow
> into a usable system, I plan to share it for free with the IF
> community.
>
> If someone has already done this, I'd like to hear about it.

You would think that by now a C-library or C++-library would have
materialized that allowed you to write IF, but I honestly can't
think of one.

If I may suggest, you should consider using Glk for your I/O
layer. This will kill many birds.

--
Neil Cerutti <cer...@trans-video.net>

Tzvetan Mikov

unread,
Jul 9, 2002, 5:46:15 PM7/9/02
to

"Neil Cerutti" <cer...@trans-video.net> wrote in message
news:agfei1$l7p10$1...@ID-60390.news.dfncis.de...

> > If someone has already done this, I'd like to hear about it.
>
> You would think that by now a C-library or C++-library would have
> materialized that allowed you to write IF, but I honestly can't
> think of one.

I asked a question along these lines some time ago (the thread was called
"[Dis]Advantages of IF languages") and eventually became convinced that a
C/C++/C#/Java IF library would be very inconvenient to use, if not outright
impossible.

-tzvetan


Raybert

unread,
Jul 9, 2002, 6:17:19 PM7/9/02
to
Ed wrote:
> I'm looking for opinions on which IF system (for which source code is
> available) has the best world model, and which IF system has the best
> parser.
<snip>

> My reason for asking is that I'm considering writing a class library (or
> set of class libraries) for C# and/or Java to enable those languages to be
> used for writing IF. I don't want to reinvent any more wheels than I have
> to, so I'd like to take advantage of what's been done before. I plan to
> study the source code for one or two existing IF systems as part of the
> design process for my own system.
<snip>

> 2. I need to become more fluent in C# (currently my favorite language) and
> Java (currently my second-favorite language), and this seems like a fun
> project to use a learning experience. I'm more interested in the
> programming part of the learning experience than in a high-level redesign
> of IF world model or parser architecture, hence my original question.
<snip>

> If someone has already done this, I'd like to hear about it.


Hi Ed,

Coincidentally, you & I are in a similar situation.

I'm a SWE with 15 years experience who has been laid off for some
months. I'm also a huge text adventure fan from way back (in fact,
it's what got me interested in programming back in the early 80's).

I recently decided that I should do something constructive while I'm
unemployed. So I decided to start learning Java.

Around the same time I heard about IFComp 2002 and realized that
writing an adventure game would be a great way to learn Java!

I've been working on the game for a few weeks now and it's coming
along pretty well. My parser is now mostly finished and I'm working
on the remaining game infrastructure. I have a game idea from many
years ago that I'm planning to implement with this code.

I'm not writing an IF system though; rather, just a standalone game.
Therefore, the code I'm writing is specific to the game that I plan to
develop. But it is written in Java and is therefore OO and many
components will be re-usable. Perhaps the start of a class library?

I briefly considered writing an IF system, but decided not to. I've
explored TADS in the past and thought it was pretty well done. So, if
I just wanted to develop IF, I would probably use TADS (I haven't
looked at the other IF systems out there though so I can't compare).
My main goal is really to learn Java. I didn't want to commit to too
large of a project and I also didn't want to re-create a perfectly
good wheel (TADS). So I decided to limit my project to just a
standalone game (for now anyway).

This decision led me to some design decisions that do not lend
themselves to an IF system (which needs to be divorced from any
specific game data). For example, things (like vocabulary words, game
objects, game locations, etc.) in my game are identified internally
with constant integer IDs which allow game code to refer to specific
things in a direct and efficient manner. A real IF system would have
to use only runtime object references resolved through a dictionary
and manipulated through an external game script.

A class library or framework is another thing entirely though. Such a
thing would be intended for game developers who wish to work in Java,
rather than a 3GL, such as TADS. I think my classes could be modified
to serve as some basis for a framework or class library. Some
specifics would have to be separated out and the ID system would have
to be re-thought to some degree. But I think it could work.

I've employed some ideas in my parser that I've been carrying around
with me for some years. Since I had already given a lot of thought
over the years about how to parse for text adventures, I was pretty
much able to jump right into the programming. I believe the resulting
parser is about as smart as Infocom's.

I have a lot more work to do yet, but I hope to have a simple game up
and running in the next week. After that, it'll be mostly a matter
populating the game with locations, objects, and verbs.

So, anyway, FWIW... maybe this means we should talk about
collaboration? maybe it's just a curiosity? I dunno... ;)

Good luck with whatever you decide to do.

[ray]

PS: I've found that Java interfaces are very powerful for implementing
special attributes of game objects. (e.g. lockable; openable; etc.)

John

unread,
Jul 9, 2002, 7:20:54 PM7/9/02
to
Ray,

I am interested in what you did for the parsing.

Do you search the input string for verbs, nouns, etc and go from there, or
do you do it a different way?

What kind of commands can you cope with?

For instance, "get the green robe and put it on" ?

John.

"Raybert" <senorv...@yahoo.com> wrote in message
news:c023b4af.02070...@posting.google.com...

Raybert

unread,
Jul 10, 2002, 4:28:56 AM7/10/02
to
"John" <nojgoa...@hotmail.com> wrote in message news:<qdKW8.2205$Kx3....@newsread1.prod.itd.earthlink.net>...

> Ray,
>
> I am interested in what you did for the parsing.
>
> Do you search the input string for verbs, nouns, etc and go from there, or
> do you do it a different way?
>
> What kind of commands can you cope with?
>
> For instance, "get the green robe and put it on" ?
>
> John.

Hi John,

My parser has three stages to it.

The first is the lexical parsing stage, where I extract the words and
look them up in a dictionary to make sure they're known to the game.
I also discard useless words at this time, such as articles (i.e.
"the", "a", "an").

Next is the classify stage, where I try to assign a grammatical type
to each word (verb, noun, adjective, etc.). To do this, I use a
position-dependent algorithm, which I'll describe below.

Last is the "resolve" stage, where I try to resolve the words to
internal game objects (the verb resolves to a verb handler class and
each object to a game object class).

If everything works correctly I end-up with a Command object that
contains references to the verb and object handlers (as well as the
original sentence in case it's needed later).

The rules for the classify stage go something like this:

- the first word is always a verb

- in a simple (verb/noun) sentence, the direct object is always the
last word

- an indirect object can only exist in a prepositional phrase, which
must begin with a preposition; I have a list of prepositions and I
search words #3 through #n-1 for a match; if a prep is found, the word
directly to the left of it is the direct object and the last word in
the sentence is the indirect object

- if a preposition is found in the second position I assume that the
sentence uses the "implied self" form; e.g. in "look at picture" the
direct object is the implied "you" -- i.e. "look you at picture", or,
more properly, "you look at picture" (remember, from English class:
who is doing the looking? "you" :)

- I can also recognize an adverb in the last position; e.g. "turn
light on"

- any noun/object can be preceded by an adjective

After assigning a grammatical type to each word I check to see if I
missed any words; if I did, I assume that the sentence uses a
structure that I don't understand and issue an error message.

This logic allows the following types of sentences:

look
examine the red key
open the wooden door with the gold key
turn the oil lamp on
look at the faded picture
look behind the oil painting

I also provide special support for "and" and "then" (I admit it's been
a while since I played an Infocom game, but I think this is how they
did it):

- AND is used to join multiple direct objects together to all receive
the same action. e.g. take gold key and rock and red ball

- THEN is used to join together multiple verb clauses (sentences).
e.g. "get the green robe THEN put it on" [;)]

AND can be abbreviated with a comma and THEN can be abbreviated with a
period. e.g. "take gold key, rock. open door with key. throw rock"

I handle AND and THEN by generating multiple sentences, internally,
during the classify stage. If THEN is used, the sentence is split at
each THEN. If AND is used, the affected sentence is copied multiple
times and each copy gets one of the objects. Thus, the command
execution stage (which follows the parsing stage) is greatly
simplified: it only has to deal with one verb, one direct object, and
one indirect object.

I also support the special word "it" (as demonstrated above in the
"green robe" example). IT always refers to the direct object in the
previous verb clause. If there was no D.O. in the previous V.C., IT
cannot be resolved and an error results.

I also support the special word "all", which can be used with verbs
like take, drop, put, etc., to manipulate all objects within reach.
(However, ALL isn't resolved in the parser like everything else
mentioned above. I have a dummy object in the game called ALL which
tricks the parser into thinking a normal object has been referenced.)

After writing my earlier post today, I did some thinking and had an
epiphany, of sorts. ;) Briefly, I had been writing bunches of ugly ad
hoc code to validate prepositions and adverbs and I knew deep inside
of me that it was wrong to do it this way. After some thought, I
realized that prepositions and adverbs, although they are technically
different parts of speech, really serve the same purpose in a verb
clause: they modify the verb. Thus, I realized that I could simplify
my logic by calling them "verb modifiers" and treat them very much
like adjectives (which are essentially noun modifiers)!

Adjectives and nouns are paired for processing; i.e. if the user types
"gold key" it can only match an object that has the same noun and
adjective. (However, the game allows the adjective to be omitted if
there's only one "key" available.)

Likewise, verbs and their modifiers should be paired together as well!
Instead of matching just the verb and then writing ugly code to
verify the correctness of the modifier, a verb/modifier pair actually
constitute a unique verb!

For example, "look at picture" and "look behind picture" are both uses
of LOOK. BUT, "look at" and "look behind" are really two very
different things. Therefore, the game should have two separate verbs:
"look at" and "look behind". If verb matching is performed in this
manner, there is no further need to validate the verb modifier.

Another example: "put key in box" and "put key under rock" both use
PUT, but are really two different verbs: "put in" and "put under".

Another example (different sentence form): "turn lamp on" and "turn
lamp off" are two separate verbs: "turn on" and "turn off".

I'm sure that I'm not the first to think of this and some folks who
read this will laugh and say "No shit Sherlock! We knew that all
along!!" Well, good for you. And good for me too because now I know
it too. ;)

Further thinking through of this concept led me to convince myself
that I don't need specific verb handling classes (as I currently
have), but rather, verbs should be implemented within the object/noun
classes (with default processing supplied in the base class).
Furthermore, if the verb/modifier matching is done in the object
classes in this manner, virtually all of my vocabulary will be defined
in a distributed manner within the object classes and my dictionary
can be generated at runtime when the objects are created and
registered. This will allow me to do away with having to predefine a
vocabulary and hand-generate word IDs, etc. When I want to add a new
object to the game, I simply create a new class and specify the verbs
(and verb modifiers) that it will use right there in the new class.
This is much, much simpler than my current program architecture and it
means I have a bunch of new work to do. :)

(IIRC, TADS defines verbs as members of objects and I knew this so I
should have thought of this sooner. But, I'm writing Java code not a
3GL, so it's slightly different. I don't remember how TADS handles
verb modifiers, or if it even does.)

When I wrote earlier to Ed I mentioned that my code uses hard-coded
IDs, etc. But I now have a vision for a new architecture that will
not need anything of the sort and which can be neatly organized into a
generic reusable Java class library. And, believe it or not, the
changes required to my existing code will not be very extensive.

As I said, I have some work to do... ;)

[ray]

Plugh!

unread,
Jul 10, 2002, 4:30:34 AM7/10/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote in message news:<Xns924696F5A38E7ed...@199.45.49.11>...

> I'm looking for opinions on which IF system (for which source code is
> available) has the best world model, and which IF system has the best
> parser.

Despite your previous dislike of TADS 2, the anwer is undoubtedly TADS 3.

Ed

unread,
Jul 10, 2002, 7:57:33 AM7/10/02
to
"Tzvetan Mikov" <ce...@jupiter.com> wrote:
>> You would think that by now a C-library or C++-library would have
>> materialized that allowed you to write IF, but I honestly can't
>> think of one.
> I asked a question along these lines some time ago (the thread was
> called "[Dis]Advantages of IF languages") and eventually became
> convinced that a C/C++/C#/Java IF library would be very inconvenient
> to use, if not outright impossible.

Could you go into more detail, please?

Thanks,

-- Ed

Ed

unread,
Jul 10, 2002, 8:24:57 AM7/10/02
to
NOTE: I suspect this is a topic which has been revisited often. This
message is a response to a remark someone made, and is NOT intended as an
attack on any of the IF systems I mention. I am expressing my own
opinions, and not trying to start a flame war.

In a previous thread ("which IF system has best world model & parser") I
wrote:


>> 1. I've spent a fair amount of time playing around with Inform,
>> and taken a close look at TADS and Hugo, and I don't like them.
>> As a software engineer with 20 years experience, and an
>> admitted language bigot as well, I have a strong preference for
>> fully object-oriented languages with C-like syntax.

Neil Cerutti <cer...@trans-video.net> replied:


> Your first reason is unconvincing (Inform and TADS are both
> object-oriented and C-like),

Okay, here's a laundry list of what I don't like about what seems to be
the "big three" (Inform, TADS and HUGO). I didn't look at any of the
systems which advertised themselves as being GUI- or forms-driven, or
sought to minimize "programming".

All three lack support for floating point.
All three use dynamic rather than static typing.

Inform
Routine definition, using square brackets, is definitely not C-like.
Integers appear to be limited to 16 bits.
The 'for' statement is not C-like.

HUGO
The only data type seems to be 16-bit integers.
Line endings are significant; long lines must be broken up with '\'.
'!' for comments instead of '/* */' and '//'.
Boolean operators are words ('and', 'or').

TADS
Inconsistent use of curly braces.
Non-C-like use of semicolons.
Assignment operator is ':=', not '='.
Local variables must be explicitly declared 'local'.

Please don't tell me I "don't need" floating point or 32-bit integers.
If you don't need them, that's fine. I refuse to get into a religious
war over static vs. dynamic typing; suffice to say that my personal
preference is for static typing because it helps me find more bugs at
compile time.

-- Ed


Ed

unread,
Jul 10, 2002, 8:08:58 AM7/10/02
to
Neil Cerutti <cer...@trans-video.net> wrote:
> The problem with this question is that, once you have learned the
> object model of an IF system, you have finished learning that
> system. In other words, you need to be an expert in every current
> IF system to know the answer to your question.

Well, I was sort of hoping that there might be a person or two out there
who has, in fact, done that research and would be willing to share their
opinions.



> Several systems have been used to write hundreds of playable
> games. I see those systems as robust.

If you're implying that a system is robust because it has been used
widely and successfully, then I disagree with your definition. I use
"robust" to mean something more like "free of bugs" and "handles errors
gracefully". A non-robust system can certainly be used, but the user has
to learn how to avoid breaking it.



> Several systems have created huge games. I see those
> systems as powerful and extensible.

Again, I think I'm using a different definition of "extensible". I mean
that the fundamental capabilities of the game engine and/or language can
be extended. For example, a system may come with support for travelling
north, south, east, west, but not ne, se, sw, and nw; if that system is
extensible, I should be able to add the missing directions. Being able
to create thousands of rooms doesn't make it extensible, by my
definition.



> I'm guessing that you may have different expectations. Mine are
> fulfilled.

Quite so. I am not here to bash the existing systems, or win over anyone
to my point of view.



> The most popular IF systems, and even the up-and-comers, all have
> excellent documentation. You can use those documents to
> determine, for yourself, the state of the art in world model.

This is good to know.



>> 1. I've spent a fair amount of time playing around with Inform,
>> and taken a close look at TADS and Hugo, and I don't like them.
>> As a software engineer with 20 years experience, and an
>> admitted language bigot as well, I have a strong preference for
>> fully object-oriented languages with C-like syntax.
>

> Your first reason is unconvincing (Inform and TADS are both
> object-oriented and C-like),

Oh dear, I'm afraid I really must address this in detail (sigh), but I'll
do it in a separate thread.

> If I may suggest, you should consider using Glk for your I/O
> layer. This will kill many birds.

I've seen Glk described; this sounds like a good idea.

Thanks for the feedback,

-- Ed


Ed

unread,
Jul 10, 2002, 8:27:56 AM7/10/02
to
senorv...@yahoo.com (Raybert) wrote:
> Coincidentally, you & I are in a similar situation.
> I'm a SWE with 15 years experience who has been laid off for some
> months.

I've also been pounding the pavement since March.

> So, anyway, FWIW... maybe this means we should talk about
> collaboration? maybe it's just a curiosity? I dunno... ;)

I'm certainly open to the idea. I'm a lousy correspondent at the best of
times, and I'm in the middle of moving, so if you don't hear from me, feel
free to check in. Remove the spamguard from my e-mail address.

-- Ed

Neil Cerutti

unread,
Jul 10, 2002, 8:47:32 AM7/10/02
to
In article <Xns924752ECDC224ed...@199.45.49.11>,

Ed wrote:
> Neil Cerutti <cer...@trans-video.net> wrote:
>> The problem with this question is that, once you have learned
>> the object model of an IF system, you have finished learning
>> that system. In other words, you need to be an expert in every
>> current IF system to know the answer to your question.
>
> Well, I was sort of hoping that there might be a person or two
> out there who has, in fact, done that research and would be
> willing to share their opinions.

There are some. I know a very few authors have even released
games written in different systems.

The other thing that may stop this thread before much good
discussion ensues is how unwilling this group has been, historically,
to enter into language wars.

>> Several systems have been used to write hundreds of playable
>> games. I see those systems as robust.
>
> If you're implying that a system is robust because it has been
> used widely and successfully, then I disagree with your
> definition. I use "robust" to mean something more like "free
> of bugs" and "handles errors gracefully". A non-robust system
> can certainly be used, but the user has to learn how to avoid
> breaking it.

What I meant is that most of the current, popular systems are
robust enough for the purposes of creating IF games. That isn't
to say that people would not welcome an even *more* robust
system.

>> Several systems have created huge games. I see those systems
>> as powerful and extensible.
>
> Again, I think I'm using a different definition of
> "extensible". I mean that the fundamental capabilities of the
> game engine and/or language can be extended. For example, a
> system may come with support for travelling north, south, east,
> west, but not ne, se, sw, and nw; if that system is extensible,
> I should be able to add the missing directions. Being able to
> create thousands of rooms doesn't make it extensible, by my
> definition.

I agree with your definition.

Most of the IF systems, as you might have guessed, can be easily
extended in ways that were anticipated by the authors. For
example, adding new verbs, actions, objects, and directions (as
above) is very easy with the Inform language and library.

They can also be extended in ways that were not anticipated, but
it's more work. For example, adding useful NPC action handling in
Inform is quite difficult. This is one area where a new system
can make a lot of headway, as far as I'm concerned. But I'm not
really aware of TADS3's capabilities in this area, and HUGO also
made some strides in this direction. There has been a lot of work
done for Inform in this area by 3rd parties, but unfortunately
I'm not that familiar with how they work and I don't think
they've really been used yet.

The most difficult thing to do is not extending the world models,
but when the time comes that you have to violate the world model
For example, in Inform, it's hard to create an object that you
can put things in and on top of, because Inform uses a very
simple object tree to handle containment.

Room <--> Box <--> Apple

The Apple is either in the box or on the box, depending on a
property of the box.

>> I'm guessing that you may have different expectations. Mine
>> are fulfilled.
>
> Quite so. I am not here to bash the existing systems, or win
> over anyone to my point of view.
>
>> The most popular IF systems, and even the up-and-comers, all
>> have excellent documentation. You can use those documents to
>> determine, for yourself, the state of the art in world model.
>
> This is good to know.
>
>>> 1. I've spent a fair amount of time playing around with
>>> Inform, and taken a close look at TADS and Hugo, and I don't
>>> like them. As a software engineer with 20 years experience,
>>> and an admitted language bigot as well, I have a strong
>>> preference for fully object-oriented languages with C-like
>>> syntax.
>>
>> Your first reason is unconvincing (Inform and TADS are both
>> object-oriented and C-like),
>
> Oh dear, I'm afraid I really must address this in detail
> (sigh), but I'll do it in a separate thread.

This type of debate is often found on this newsgroup, and it will
probably be welcome, as long as the discussion remains focused on
the applicability of object-oriented programming concepts to IF.
In other words, pointing out ways in which TADS or Inform are not
fully object oriented will be more useful if the shortcomings you
see can be related to IF development.

There are some old threads on Google where language design for IF
was discussed and argued in depth, and I found it very
interesting.

--
Neil Cerutti <cer...@trans-video.net>

Ed

unread,
Jul 10, 2002, 8:55:10 AM7/10/02
to
pl...@plugh.info (Plugh!) wrote:
> Despite your previous dislike of TADS 2, the anwer is undoubtedly TADS
> 3.

I just looked over the T3 docs, and ... Wow! I think you may be right. T3
seems to fix almost (but not quite) everything I don't like about T2,
Inform and HUGO.

Thanks for bringing this to my attention!

-- Ed

Neil Cerutti

unread,
Jul 10, 2002, 9:26:55 AM7/10/02
to
In article <Xns924755A2D30A1ed...@199.45.49.11>, Ed wrote:
> NOTE: I suspect this is a topic which has been revisited often. This
> message is a response to a remark someone made, and is NOT intended as an
> attack on any of the IF systems I mention. I am expressing my own
> opinions, and not trying to start a flame war.
>
> In a previous thread ("which IF system has best world model & parser") I
> wrote:
>>> 1. I've spent a fair amount of time playing around with Inform,
>>> and taken a close look at TADS and Hugo, and I don't like them.
>>> As a software engineer with 20 years experience, and an
>>> admitted language bigot as well, I have a strong preference for
>>> fully object-oriented languages with C-like syntax.
>
> Neil Cerutti <cer...@trans-video.net> replied:
>> Your first reason is unconvincing (Inform and TADS are both
>> object-oriented and C-like),
>
> Okay, here's a laundry list of what I don't like about what
> seems to be the "big three" (Inform, TADS and HUGO). I didn't
> look at any of the systems which advertised themselves as being
> GUI- or forms-driven, or sought to minimize "programming".
>
> All three lack support for floating point.

There are a few 3rd-party libraries available to help with this.
So there is *some* support.

> All three use dynamic rather than static typing.

Not really. Inform, for example, is in fact statically typed, it
just doesn't do any static checking for you. Basically,
everything is a 16-bit number (or 32-bit number for Glulx) that
operates a lot like a pointer that you dereference with different
operators depending on what it points to. It's a bit like Perl.

If x is a dictionary word:

print (address) x;

If x is a compressed string:

print (string) x;

If x is an object with a short_name property:

print (name) x;

If x is a routine that prints something:

x();

Inform does provide a little bit of RTTI. You can find out if a
value is an Object, a Routine, a String, or none of the
above using the ZRegion routine.

> Inform
> Routine definition, using square brackets, is definitely
> not C-like.

Inform is definitely the least C-like of the three under
consideration. The three-tiered system of using square brackets to
define routine blocks, and curly-brackets to define other code
blocks, and "Object" and ";" for object delimiters is a little
silly.

On the other hand, Inform has a lot of non-C-like syntax that is
really very useful for writing IF. For example, all routines are
an implicit switch (action) statement if you want to treat them
that way. This makes writing before, after, and its ilk very
convenient.

> Integers appear to be limited to 16 bits.

This is a limitation of the virtual machine to which you compile.
If you compile to Glulx, you get 32-bit numbers.

> The 'for' statement is not C-like.

This is a sore spot for a lot of people. However, using the
C-like syntax is accepted and merely generates a warning.

> HUGO
> The only data type seems to be 16-bit integers.
> Line endings are significant; long lines must be broken up with '\'.
> '!' for comments instead of '/* */' and '//'.

'/* */' comments are not good, e.g., x = 5/*b, cannot be nested,
etc. So I'm not surprised some people opted for line comments
only.

> Boolean operators are words ('and', 'or').

They can be words in C, too.

> TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.

This is an option in TADS. You may opt for the C versions of
these operators with a compiler switch.

> Local variables must be explicitly declared 'local'.

You can probably see that I know a lot more about Inform that
about the other languages under discussion. ;-)

--
Neil Cerutti <cer...@trans-video.net>
*** Mischievous glak elves broke into your storage shed and
stole half your food. ***

Matthew Russotto

unread,
Jul 10, 2002, 10:04:59 AM7/10/02
to
In article <agflj7$1...@dispatch.concentric.net>,

Tzvetan Mikov <ce...@jupiter.com> wrote:
>
>I asked a question along these lines some time ago (the thread was called
>"[Dis]Advantages of IF languages") and eventually became convinced that a
>C/C++/C#/Java IF library would be very inconvenient to use, if not outright
>impossible.

A preprocessor could solve the major obstacle (all those one-off objects). But
then it's not really C/C++/C#/Java, I guess..

--
Matthew T. Russotto mrus...@speakeasy.net
=====
Every time you buy a CD, a programmer is kicked in the teeth.
Every time you buy or rent a DVD, a programmer is kicked where it counts.
Every time they kick a programmer, 1000 users are kicked too, and harder.
A proposed US law called the CBDTPA would ban the PC as we know it.
This is not a joke, not an exaggeration. This is real.
http://www.cryptome.org/broadbandits.htm

OKB (not okblacke)

unread,
Jul 10, 2002, 11:45:06 AM7/10/02
to
Neil Cerutti wrote:
> Inform does provide a little bit of RTTI. You can find out
> if a value is an Object, a Routine, a String, or none of
> the above using the ZRegion routine.

Just a little side note: this is really a "fake" mechanism. It doesn't have any internal notion of the
type of anything -- it converts everything to a number and then essentially decides what the type is
based on how big the number is. (That is, it says something like "ok, things with numbers 8000-10000
are objects, numbers 10001-150000 are strings, etc.") This mapping works when you're actually doing
things like metaclass(SomeObj) and metaclass("A string"), but it pays to be careful, because it's possible
for, say, metaclass(13207) to return Routine.

--
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

Ed

unread,
Jul 10, 2002, 12:11:09 PM7/10/02
to
Neil Cerutti <cer...@trans-video.net> wrote:
> The other thing that may stop this thread before much good
> discussion ensues is how unwilling this group has been, historically,
> to enter into language wars.

Well, I was hoping to avoid that. Between well-informed people, language
wars invariably, in my experience, boil down to issues of personal
preference.

>For example, adding useful NPC action handling in
>Inform is quite difficult.

Yes, I discovered that, in detail. :-)

> There are some old threads on Google where language design for IF
> was discussed and argued in depth, and I found it very
> interesting.

I'll look for it.

Thanks again,

-- Ed

John

unread,
Jul 10, 2002, 1:02:10 PM7/10/02
to
Ray

Thankyou for taking the time to make this post. It was very helpful for me.
I have been taking a similar approach using verbs as methods. That made the
most sense to me. I got to the point of splitting sentences and ignoring
"the,an,a" etc. Also implemented "it" much the same way.

My current method of attack is using regular expressions. Currently the
seem to make this very easy and compact. I wonder why there are not
predominantly Perl-based text adventure systems?

I would like to hear from the players in this group to find out if there are
other types of commands that they would deem necessary for an interactive
fiction game:

look
examine the red key
open the wooden door with the gold key
turn the oil lamp on
look at the faded picture
look behind the oil painting

take the book then look at it take the
book. Look at it
take the book and the gold key take the
book, gold key

Possibly also a minimal vocabulary?

You know, this would be awesome to capture somewhere (it its not already),
as a series of test cases for adventures. Maybe have different levels of
functionality. Could set up a simple specific location, maybe from one of
the classic games with a couple of rooms for navigation. It could be like a
hello world of IF? Just a thought.

I am not suggesting that someone else do all the work. I would be quite
willing to help collect all the information together. I would even host the
web pages if we get that far. I just respect the people of this groups
opinions in this regard more than mine for playing these games.

Given the sporadic nature of information related to creating a text
adventure game, I would also likely add help related to that on the site
too. This may go someway to help raise the level of submissions and thus
reduce the 99% crap number !!!! ;-)

John.

"Raybert" <senorv...@yahoo.com> wrote in message

news:c023b4af.0207...@posting.google.com...

Adam Thornton

unread,
Jul 10, 2002, 1:51:54 PM7/10/02
to
In article <Xns924755A2D30A1ed...@199.45.49.11>,

Ed <e...@mewsic.SPAMGUARD.com> wrote:
>NOTE: I suspect this is a topic which has been revisited often. This
>message is a response to a remark someone made, and is NOT intended as an
>attack on any of the IF systems I mention. I am expressing my own
>opinions, and not trying to start a flame war.

OK. In the same sprit:

>Okay, here's a laundry list of what I don't like about what seems to be
>the "big three" (Inform, TADS and HUGO). I didn't look at any of the
>systems which advertised themselves as being GUI- or forms-driven, or
>sought to minimize "programming".
>
>All three lack support for floating point.
>All three use dynamic rather than static typing.

There have been Inform libraries which implement IEEE FP, or at least a
significant subset thereof. I don't know if any such thing has been
done with TADS or Hugo. I'll accept that as you say below, dynamic
vs. static typing is a religious issue with you, but as I don't see why
it matters, I won't comment.

>Inform
> Routine definition, using square brackets, is definitely not C-like.
> Integers appear to be limited to 16 bits.
> The 'for' statement is not C-like.

Routine definition is definitely not C-like. "For" seems pretty C-like
except that it uses colons rather than semicolons as statement
separators, IIRC. Which trips me up every time I start a new Inform
project too.

Integers are 16-bit in Inform-compiling-to-zcode, and 32-bit in Glulx
Inform. I'm pretty sure there are library extensions to give you
arbitrarily-sized integers as well.

>HUGO
> The only data type seems to be 16-bit integers.
> Line endings are significant; long lines must be broken up with '\'.
> '!' for comments instead of '/* */' and '//'.
> Boolean operators are words ('and', 'or').

I don't know Hugo, so I can't comment.

>TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.
> Local variables must be explicitly declared 'local'.

I think the assignment operator is switchable with a pragma, which may
also ameliorate the curly-brace problem. Dunno.

>Please don't tell me I "don't need" floating point or 32-bit integers.
>If you don't need them, that's fine. I refuse to get into a religious
>war over static vs. dynamic typing; suffice to say that my personal
>preference is for static typing because it helps me find more bugs at
>compile time.

It seems to me that what you need is not a new IF development language,
but a preprocessor wrapped around one of the existing ones that sugars
the syntax for you. m4 could probably be applied usefully here.

Adam

L. Ross Raszewski

unread,
Jul 10, 2002, 2:04:01 PM7/10/02
to
On Wed, 10 Jul 2002 12:24:57 GMT, Ed <e...@mewsic.SPAMGUARD.com> wrote:
>
>All three lack support for floating point.

True. Fair comment even.

>All three use dynamic rather than static typing.
>

!!

IF is not well suited to static typing.

>Inform
> Routine definition, using square brackets, is definitely not C-like.
> Integers appear to be limited to 16 bits.

True depending on the platform to which it is compiled. SImilarly, in
C, an integer is limited to 16 bits if your target platform is, say, DOS.

> The 'for' statement is not C-like.
>
>HUGO
> The only data type seems to be 16-bit integers.
> Line endings are significant; long lines must be broken up with '\'.
> '!' for comments instead of '/* */' and '//'.
> Boolean operators are words ('and', 'or').
>
>TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.
> Local variables must be explicitly declared 'local'.

>
>Please don't tell me I "don't need" floating point or 32-bit integers.
>If you don't need them, that's fine. I refuse to get into a religious
>war over static vs. dynamic typing; suffice to say that my personal
>preference is for static typing because it helps me find more bugs at
>compile time.

That's true. It's one of the things PL guys discovered about static
typing. But I don't think it would really be advantageous in an IF
language; it's been discussed recently that in most contexts, you
actually can't statically type; if the input to some routine is an
object typed in by the player, it could be of any class. Obviously,
you could statically type the 'metaclasses' -- constrain variables to
be one and only one of <number>,<object>, <string>, or <routine>,
say. This, of course, would greatly complicate a lot of the
polymorphic properties of, say, inform, unless you always used the
type "thingy", in which case, it wouldn't be very good at catching
errors at compile time.

Also, I notice that the majority of your complaints seem to be "syntax
isn't identical to C". These lagnauges aren't C, and I think it's not
alway fair to make the blanket claim that "all languages should have
identical syntax to C". Perl, Pascal, ML, and SQL don't have the same
syntax as C and this isn't generally taken as a weakness of any
sort. Of course, you're expressing your personal preference ('Why I
don't like them'), but you're doing it in a context where 'what's
wrong with them' is implied.

Robb Sherwin

unread,
Jul 10, 2002, 3:07:07 PM7/10/02
to
On Wed, 10 Jul 2002 17:51:54 +0000 (UTC), ad...@fsf.net (Adam Thornton)
wrote:

>In article <Xns924755A2D30A1ed...@199.45.49.11>,
>Ed <e...@mewsic.SPAMGUARD.com> wrote:
>>HUGO
>> The only data type seems to be 16-bit integers.
>> Line endings are significant; long lines must be broken up with '\'.
>> '!' for comments instead of '/* */' and '//'.
>> Boolean operators are words ('and', 'or').
>I don't know Hugo, so I can't comment.

The last two items stems from the fact that -- as far as I can tell --
one of the main points of Hugo is that the code anyone can generate
with it is extremely readable. To the point of readability, in fact,
being somewhat enforced. I've only been seriously programming on a
regular basis for three or four years now, so I'm still firmly of the
mindset that while it's impressive to have multiple things going on in
any given, single line of code, it doesn't do me much good when trying
to make sense out of it. However, because Hugo demands that you write
your code in such a manner, it puts rookies and veterans on a kind of
equal level. There are some library contributions that were written by
people like Cardinal Teubachs and John Menichelli -- guys who
obviously know what they are doing. I was able to follow along in the
Hugo port of Zork before I really had a grasp of the language, though,
because regardless of how intricate those guys would like (or dislike)
to be, they had to generate output that was quite approachable to my
newb self.

I think the first two parts mentioned in the quoted text above are
that way due to older operating systems and machines still being able
to run Hugo games perfectly well (though I'm not 100% certain that's
it -- Kent would know for sure.) It's never really bothered me,
though, because I'd rather my stuff be accessible to the whole of text
adventure fans regardless of what OS they were running than have some
features that would be cool for the Windows XP and OS-X ports of Hugo
but shut me off from older systems. But Ed's coming into this from the
experiences of someone with a lot more professional experience than I,
and I can absolutely see where he's coming from. His points in this
are well-taken.

Robb
=-=-=-=-=-
Robb Sherwin, Fort Collins CO
Jolt Country BBS: www.joltcountry.com/phpBB2
Reviews From Trotting krips: www.joltcountry.com/trottingkrips

Ed

unread,
Jul 10, 2002, 3:03:10 PM7/10/02
to
ad...@fsf.net (Adam Thornton) wrote:
> There have been Inform libraries which implement IEEE FP, or at least
> a significant subset thereof. I don't know if any such thing has been
> done with TADS or Hugo. I'll accept that as you say below, dynamic
> vs. static typing is a religious issue with you, but as I don't see
> why it matters, I won't comment.

In the spirit of explanation (not argument), the value of static typing is
that you can catch more bugs at compile time, when *all* the code is
processed all at once. For example, if you have a routine which expects a
string, and will fail miserably if it is passed anything else, and you try
to pass it something else, with static typing, the code where you try to
pass it something else will fail to compile. With dynamic typing, the
error won't be found until the code actually executes, and possibly not
until just the right set of circumstances occur, making the bug harder to
track down.

In fairness, dynamic typing has its own advantages.

More about this elsewhere in this thread...

-- Ed

Ed

unread,
Jul 10, 2002, 3:11:44 PM7/10/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
> IF is not well suited to static typing.
> ...

> it's been discussed recently that in most contexts, you
> actually can't statically type; if the input to some routine is an
> object typed in by the player, it could be of any class. Obviously,
> you could statically type the 'metaclasses' -- constrain variables to
> be one and only one of <number>,<object>, <string>, or <routine>,
> say. This, of course, would greatly complicate a lot of the
> polymorphic properties of, say, inform, unless you always used the
> type "thingy", in which case, it wouldn't be very good at catching
> errors at compile time.

I don't see how it would upset polymorphism. I see how it might be
advantageous in an IF system to not statically distinguish between
different classes of objects, but static checking for the "metaclasses", as
you called them (string, integer, float, boolean, array, and object) seems
to me to be highly desirable. Perhaps the problem you're thinking of would
be solved (in a statically typed language) by method overloading.?

> Also, I notice that the majority of your complaints seem to be "syntax
> isn't identical to C". These lagnauges aren't C, and I think it's not
> alway fair to make the blanket claim that "all languages should have
> identical syntax to C". Perl, Pascal, ML, and SQL don't have the same
> syntax as C and this isn't generally taken as a weakness of any
> sort. Of course, you're expressing your personal preference ('Why I
> don't like them'), but you're doing it in a context where 'what's
> wrong with them' is implied.

Yes, in retrospect, "what's wrong with some existing IF languages" wasn't
the best title.

-- Ed

OKB (not okblacke)

unread,
Jul 10, 2002, 3:23:15 PM7/10/02
to
John wrote:

> You know, this would be awesome to capture somewhere (it
> its not already), as a series of test cases for adventures.
> Maybe have different levels of functionality. Could set
> up a simple specific location, maybe from one of the
> classic games with a couple of rooms for navigation. It
> could be like a hello world of IF? Just a thought.

Sounds like Roger Firth's "Cloak of Darkness": http://www.firthworks.com/roger/cloak/

Nikos Chantziaras

unread,
Jul 10, 2002, 3:39:26 PM7/10/02
to
"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924696F5A38E7ed...@199.45.49.11...
> My reason for asking is that I'm considering writing a class library
> (or set of class libraries) for C# and/or Java to enable those
> languages to be used for writing IF. [...]

Since you're using C# and Java, I recommend taking a look at the Tads3
sources. They're written in OO C++. Its world model should be
adaptable to any other OO language.

-- Niko


Nikos Chantziaras

unread,
Jul 10, 2002, 4:08:36 PM7/10/02
to
"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924755A2D30A1ed...@199.45.49.11...

> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO). I didn't look at any of the
> systems which advertised themselves as being GUI- or forms-driven, or
> sought to minimize "programming".
>
> All three lack support for floating point.
> All three use dynamic rather than static typing.

Add the following:
No private/protected members.
No private/protected inheritance.

> TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.

Huh?

> Assignment operator is ':=', not '='.

You can change this:

#pragma C+

This turns on C-operators. ('==' for comparing, '=' for assignments).

> Local variables must be explicitly declared 'local'.

C works the same way, but instead of 'local' you must give a datatype.
Since Tads doesn't support compile-type datatypes, we must use 'local'.

> Please don't tell me I "don't need" floating point or 32-bit integers.
> If you don't need them, that's fine.

This may be a lame answer, but have you considered using fixed-point
numbers?

> I refuse to get into a religious
> war over static vs. dynamic typing; suffice to say that my personal
> preference is for static typing because it helps me find more bugs at
> compile time.

I'm having a discussion about this with M. Roberts, and at the end it seems
that
it's impossible, even with C++, to avoid dynamic typing (you find the
discussion
in thread "[TADS 2] OO Library Design Questions From a Newbie").

-- Niko


Iain Merrick

unread,
Jul 10, 2002, 4:10:36 PM7/10/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote:

> I am expressing my own opinions, and not trying to start a flame war.

Cool. I think your points are well worth making, by the way, even if
they are a little contentious, so thanks for posting.

[...]


> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO).

[...]


> All three lack support for floating point.

Have you looked at TADS 3? It has floating point support, among other
features, and lots of syntax tweaks which make it much more C-like than
TADS 2. (I think Mike has been converging the syntax towards Java rather
than C, in fact, but that's largely the same thing.) It's still
dynamically typed, however.

> All three use dynamic rather than static typing.

[...]


> TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.

You can use '=' if you switch into C syntax mode, enabled with '#pragma
C+'. This is kind of ugly, since you'll probably still be using
libraries that don't use C mode (such as adv.t). As someone who learned
C before TADS, however, I find it useful.

TADS 3 has an even more C-like syntax, and no icky #pragma. Yay!

> Local variables must be explicitly declared 'local'.

This is really due to the dynamic typing, rather than a flaw in its own
right. Since everything's dynamic, you don't have to declare the type of
anything. The use of 'local' gives you some compile-time checking, since
it statically determines the scope of identifiers; therefore, I assume
you'd prefer it to no variable declarations at all.

I find the handling of local variables in Inform to be very untidy in
comparison -- unless I misunderstand it, local variables and parameters
are the same thing. That's just nasty.

--
Iain Merrick
ia...@diden.net

Nikos Chantziaras

unread,
Jul 10, 2002, 4:18:35 PM7/10/02
to
"Iain Merrick" <ia...@diden.net> wrote in message
news:iain-137BC7.2...@socrates.zen.co.uk...

> You can use '=' if you switch into C syntax mode, enabled with '#pragma
> C+'. This is kind of ugly, since you'll probably still be using
> libraries that don't use C mode (such as adv.t). As someone who learned
> C before TADS, however, I find it useful.
'#pragma C+' is safe to use. The compiler remembers which file uses what
syntax.

-- Niko


Iain Merrick

unread,
Jul 10, 2002, 4:27:01 PM7/10/02
to
Nikos Chantziaras <rea...@hotmail.com> wrote:

> Iain Merrick <ia...@diden.net> wrote:
>
> > You can use '=' if you switch into C syntax mode, enabled with '#pragma
> > C+'. This is kind of ugly, since you'll probably still be using
> > libraries that don't use C mode (such as adv.t). As someone who learned
> > C before TADS, however, I find it useful.
>
> '#pragma C+' is safe to use. The compiler remembers which file uses what
> syntax.

I didn't say it was unsafe, I said it was ugly.

For instance, if someone posts a code snippet to the newsgroup in the
normal syntax mode, I have to convert it to C mode before pasting it
into my game's source code. (Not much extra effort, admittedly, since I
always reformat it in my preferred style anyway.) Also, when debugging,
I might have to step through both my own code and the library code, and
if they use different syntax modes it looks a little odd.

--
Iain Merrick
ia...@diden.net

Stephen Cameron

unread,
Jul 10, 2002, 5:16:02 PM7/10/02
to
On Wed, 10 Jul 2002 17:02:10 GMT, John <nojgoa...@hotmail.com> wrote:
>Ray
>
>Thankyou for taking the time to make this post. It was very helpful for me.
>I have been taking a similar approach using verbs as methods. That made the
>most sense to me. I got to the point of splitting sentences and ignoring
>"the,an,a" etc. Also implemented "it" much the same way.
>

(Hmm, this came out longer than I expected... )

Articles are not completely useless and you might not want
to throw them away. For example, you know that after
seeing "a", "an", or "the", you pretty much have to see
a noun (or noun phrase at least) before you will see a verb again.
(I'm sure counterexamples exist, but it's a useful tactic)

Consider:

> look
you see a hammer, a ring, and a bell
> Take hammer ring bell. (is "ring" a verb or noun here? no way to know.)

vs.

> Take the hammer the ring and the bell. (clearly "ring" is a noun)

Also, "and" and "then" can help disambiguate:

Take hammer, then ring bell. (*probably+ "ring" is a verb... )
vs.
take hammer, ring and bell. (ring is definitely a noun because of "and")

Or:

> take hammer ring bell with hammer

It is possible to tell that ring must be a verb here.

(though your parser might think you mean to use the
hammer as a tool to take the hammer, the ring and the bell
if you aren't careful.)

Ages ago, (1988 or so) I wrote a parser that could handle this kind
of junk (in Turbo Pascal. What a waste. At the time it seemed
a reasonable choice. And now, that computer is dead... oh well. :-)

It worked by having a template for various types of phrases
I had a crude way of representing the grammar
by a string, each character represented some, not
exactly a part of speech, but something like it.

something like:

L = list of objects = [noun] [separator] [ list of objects ]
P = preposition
O = single object

(included in [noun] was "all", "it", etc.)

Then I had a format for each distinct verb. (A distinct verb
might have evil twin verbs that are spelled the same and mean
nearly the same thing, but have diferent "formats".)

For example, the grammar for "put" looked something like:

put "PL" (for "put on the sweater")
put "LP" (for "put the glasses and the sweater on")
put "LPO" (for "put everything on the table")
put "LPOPO" (for "put the peanut butter on the bread with the knife")

Then, as I was parsing a sentence, I kept a list of each possible
way of interpreting the sentence. Whenever I came to a word that
could be interpreted in multiple ways, I interpreted it multiple
ways. So If I start off with the work "put", immediately I generate
4 possible interpretations (using above example) If the next word
is a preposition, I can then toss 3 interpretations.
Hopefully by the end, only one interpretation would match all the
words, and need no more words to reach a completed state. In that
case, the sentence was successfully
parsed. If multiple interpretations matched, the parsing was ambigous.
If none matched, the sentence was not understood. So in a way it
worked similarly to something like YACC, except it could look arbitrarily
far ahead in the input stream, delaying the interpretation decision as
long as possible, and there weren't really any "productions" until
the very end of parsing a (possibly compound) sentence.

The vocabulary/grammer stuff was somewhat intertwined with the
representations of objects in the game, as it must be to some
extent for words like "everything" and using the presense or
absense of objects to know what is being talked about, as well
as binding the "words" to the "objects/meanings"

Anyway, just some stuff I thought you might enjoy.
Not to say my way is right, or even particularly good.

On the other hand, bothering with the articles and this kind of parser
is a lot of work considering that typically people go around typing very
simple commands most of the time (e.g. "n", "x object"),
if they are playing a game as opposed to playing with the parser.

Ok, back to lurk mode.

-- steve

Eytan Zweig

unread,
Jul 10, 2002, 6:13:42 PM7/10/02
to

"Stephen Cameron" <scam...@zuul.cca.cpqcorp.net> wrote in message
news:slrnaip7v4....@zuul.cca.cpqcorp.net...

> On Wed, 10 Jul 2002 17:02:10 GMT, John <nojgoa...@hotmail.com> wrote:
> >Ray
> >
> >Thankyou for taking the time to make this post. It was very helpful for
me.
> >I have been taking a similar approach using verbs as methods. That made
the
> >most sense to me. I got to the point of splitting sentences and ignoring
> >"the,an,a" etc. Also implemented "it" much the same way.
> >
>
> (Hmm, this came out longer than I expected... )
>
> Articles are not completely useless and you might not want
> to throw them away. For example, you know that after
> seeing "a", "an", or "the", you pretty much have to see
> a noun (or noun phrase at least) before you will see a verb again.
> (I'm sure counterexamples exist, but it's a useful tactic)
>
> Consider:
>
> > look
> you see a hammer, a ring, and a bell
> > Take hammer ring bell. (is "ring" a verb or noun here? no way to
know.)
>
> vs.
>
> > Take the hammer the ring and the bell. (clearly "ring" is a noun)
>

[snip]

Not to mention that you want to show the following is ungrammatical:

"Take the a hammer"

Eytan


L. Ross Raszewski

unread,
Jul 10, 2002, 5:29:39 PM7/10/02
to
On Wed, 10 Jul 2002 23:08:36 +0300, Nikos Chantziaras
<rea...@hotmail.com> wrote:
>"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
>news:Xns924755A2D30A1ed...@199.45.49.11...
>> Okay, here's a laundry list of what I don't like about what seems to be
>> the "big three" (Inform, TADS and HUGO). I didn't look at any of the
>> systems which advertised themselves as being GUI- or forms-driven, or
>> sought to minimize "programming".
>>
>> All three lack support for floating point.
>> All three use dynamic rather than static typing.
>
>Add the following:
> No private/protected members.
> No private/protected inheritance.

Inform has private members.

L. Ross Raszewski

unread,
Jul 10, 2002, 5:32:03 PM7/10/02
to
On Wed, 10 Jul 2002 20:10:36 GMT, Iain Merrick <ia...@diden.net> wrote:
>
>I find the handling of local variables in Inform to be very untidy in
>comparison -- unless I misunderstand it, local variables and parameters
>are the same thing. That's just nasty.

Not really. They just have the same syntax. In most languages,
parameters are local variables as well (Perl is an interestign
coutnertexamplem but perl is hardly 'most languages'. I can't see
anythign 'nasty' about it.

Tzvetan Mikov

unread,
Jul 10, 2002, 5:34:06 PM7/10/02
to

"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924750FD06ABAed...@199.45.49.11...
> "Tzvetan Mikov" <ce...@jupiter.com> wrote:
> >> You would think that by now a C-library or C++-library would have
> >> materialized that allowed you to write IF, but I honestly can't
> >> think of one.

> > I asked a question along these lines some time ago (the thread was
> > called "[Dis]Advantages of IF languages") and eventually became
> > convinced that a C/C++/C#/Java IF library would be very inconvenient
> > to use, if not outright impossible.
>
> Could you go into more detail, please?

You'd be better off checking the thread in google and making your own
conclusions. There were lots of interresting contributions on the subject,
for example how Tads evolved from a C library, through a C library with
scripting capabilities, finally to a full-blown language (IIRC).

Anyway, I here I am copying part of my final thoughts from that thread:

<<<<
I finally carefully read the Inform DM4 (something that I should have
done long time ago) and what can I say ... I must apologize for
wasting everybody's time. It is now obvious to me that it is
impossible to achieve similar functionality in C++ without an enormous
amount of typing (I am not even talking about the library).

Initially I started playing around with macroses, trying to "port" the
Cloak of Darkness (which I could finally understand, having read the
DM4) to C++, as if there was a C++ library. The initial results were
reasonably encouraging - I got something like this to even compile
with a C++ compiler:

Object( foyer, "Foyer of the Opera House" )
with
prop( description )
retprn "You are standing in a spacious hall...";
prop( s_to ) return bar;
prop( w_to ) return cloakroom;
prop( n_to ) retprn "You've only just arrived, and besides...";
has
attr |= light;
EndObject( foyer );

Seemed good at first, but of course soon after that I came to a dead
end. I just couldn't implement polymorphic properties - there was no
way to check for their existence in an object and keep an intuitive
syntax for accessing them. I realized that it is insane to
try to artificially transplant another language's concepts into C++.

Finally, I must admit that I felt significantly more comfortable with
Inform than I thought I would. It feels pretty neat.
>>>>

In short, the problems are:
- Polymorphic properties. To define an abstract interface for every property
and use dynamic_cast to check for it is sheer madness, IMHO :-)
- Instantiation of objects. This can be achieved with macroses, but as you
can see from my example above, then you aren't really programming in C++
since it is hidden underneath a thick layer.

I still don't exclude the possibility of implementing an entirely new IF
design in C++. That would make sense more than simply duplicating in another
language already existing and proven designs.

regards,
Tzvetan


OKB (not okblacke)

unread,
Jul 10, 2002, 6:23:15 PM7/10/02
to
L. Ross Raszewski wrote:

Well, I think there's a bit more to it than "just the same syntax". Or perhaps they "have the same
syntax" in that a single syntactical declaration defines them both, in an intermingled way. The crucial
thing is that there's no distinction between a local variable that's going to be initialized with a function
argument (when the function is called) and one that isn't. This means that the code inside the function
doesn't necessarily know "where it stands" with regard to its local variables.

The nastiness or lack thereof is something else. I actually found Inform's approach kind of handy
when writing in Inform, but in using TADS 3 I've never wanted it, and in fact it would probably be a
distraction. This is probably due as much to the different library designs as to the language differences.

Alex Warren

unread,
Jul 10, 2002, 6:28:05 PM7/10/02
to
Raybert wrote on the subject of parsing (all snipped)

I'm not convinced that a complicated parser is necessary for IF, particularly
when most commmands that are input by the player are one of only a few "rigid"
forms, e.g. "LOOK AT x", "TAKE x" (and their abbreviations) etc.

I deliberately made the Quest parser very simple, although with the latest
version (3.1) I have made it a little more sophisticated. The basic principle is
the same though - since often an IF author will simply want to allow the player
to type something specific, say "SMASH x", the Quest parser allows you set this
up. If you want the "x" to be an object, you'd put:

command <smash #@thing#> ...

where "..." is some script to execute whenever the player types "SMASH x", where
"x" is a valid object. This valid object must be something accessible to the
player, i.e. in the current room or the inventory, and Quest will remove any
"the" prefixed to it and it will also automatically cater for the player typing
"it", in which case it will use the last object that was referred to. If the
command is accepted, the name of the object that the player referred to will be
in the string variable named "thing", and the script will then be executed. If
there is an ambiguity, Quest will ask the player for clarification before
executing the script. If an object of the required name is not available, Quest
displays a standard message (or one the author specified).

As for the #@thing# syntax: in earlier versions of Quest, the name of an object
that was displayed was the same as the name of the object in code, and a
variable which might contain this object name would also be referred to as
#thing#, #object#, #whatever#... but with aliases meaning several objects might
all be referred to be the player as the same thing, the #@whatever# syntax
provides a quick way to refer to the displayed name instead.

I think this is a sensible approach - an author can easily cater for the vast
majority of possible ways that a player might try to express something, without
having to worry too much about what the parser might make of it.

Any kind of NLP parser would be a pain to code in the first place, and then
quite probably a pain for any IF author who might have to try and guess what it
would make of any given sentence - and I think possibly that the parsers in many
IF systems are too complicated already for the kinds of things that players
usually type.


Alex Warren
http://www.axeuk.com/quest

Kevin Forchione

unread,
Jul 10, 2002, 9:49:10 PM7/10/02
to
"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924755A2D30A1ed...@199.45.49.11...

> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO).

Rather than debate these items point by point. I'm rather interested why you
believe these are deficiencies in the creation of Interactive Fiction.

--Kevin


L. Ross Raszewski

unread,
Jul 10, 2002, 10:30:26 PM7/10/02
to
On 10 Jul 2002 16:23:15 -0600, OKB (not okblacke) <Bren...@aol.com> wrote:
>L. Ross Raszewski wrote:
>
>> On Wed, 10 Jul 2002 20:10:36 GMT, Iain Merrick
>> <ia...@diden.net> wrote:
>>>
>>>I find the handling of local variables in Inform to be very
>>>untidy in comparison -- unless I misunderstand it, local
>>>variables and parameters are the same thing. That's just
>>>nasty.
>>
>> Not really. They just have the same syntax. In most
>> languages, parameters are local variables as well (Perl is
>> an interestign coutnertexamplem but perl is hardly 'most
>> languages'. I can't see anythign 'nasty' about it.
>
> Well, I think there's a bit more to it than "just the same
syntax". Or perhaps they "have the same
>syntax" in that a single syntactical declaration defines them both,
in an intermingled way. The crucial
>thing is that there's no distinction between a local variable that's
going to be initialized with a function
>argument (when the function is called) and one that isn't. This
means that the code inside the function
>doesn't necessarily know "where it stands" with regard to its local variables.
>

I'm not sure I understand this. In C, the code

x = y+z;

doesn't "know where it stands" with regard to local variables. I don't
see a fundamental difference between

[ foo bar baz zork;

and

foo(bar, baz)
{
local zork;


I gather you mean something like "after this point, you don't know if
zork was initialized by havign something passed to it", but this is
irrelevant; if you intend for zork to be a local and not a parameter,
what does it matter to you if it has "random data" in it at the
beginning of a function -- in the inform syntax, it could be
initialized as a result of someone calling this two-parameter function
with three parameters, in the C-like language above, it could have
random data as a result of the fact that a variable has random data in
it when you allocate it off the stack. There's no conceptual
differencefrom the point of view inside the function.

Unless your concern is more along the lines of 'I can't mandate that
foo is called with exactly two parameters'. This is maybe fair, but
it's a concern reliant on an idea of static typing, which inform
hasn't (you can, indeed, make this mandate at run-time; there's an
opcode to count the number of parameters passed in). The conflation
does allow you to write functions which take a variable number of
arguments
(And before you shout 'overloading', it's debatable whether this kind
of overloading is a Good Thing; C works close to the way inform does
in this respect with varargs, and Java doesn't allow you to change the
signature of overloaded methods).

Fred the Wonder Worm

unread,
Jul 10, 2002, 11:15:59 PM7/10/02
to

In article <slrnaip7v4....@zuul.cca.cpqcorp.net>,

Stephen Cameron <steve....@hp.com> wrote:
> Articles are not completely useless and you might not want to throw
> them away. For example, you know that after seeing "a", "an", or
> "the", you pretty much have to see a noun (or noun phrase at least)
> before you will see a verb again.

Another thing to consider is that "a" or "an" should indicate a
willingness to choose any of the available matches. e.g.:

You are in a room. There is a red ball and a blue ball here.
> take the ball
Which ball do you mean, the red ball or the blue ball?

vs

You are in a room. There is a red ball and a blue ball here.
> take a ball
red ball: taken

Not a big point, but the implication seems valid to me.

Cheers,
Geoff.

-----------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@maths.usyd.edu.au | Gameplayer by vocation.
-----------------------------------------------------------------------------

Tzvetan Mikov

unread,
Jul 10, 2002, 11:21:47 PM7/10/02
to

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:656X8.29751$5f3....@nwrddc01.gnilink.net...

>
> I'm not sure I understand this. In C, the code
>
> x = y+z;
>
> doesn't "know where it stands" with regard to local variables. I don't
> see a fundamental difference between
>
> [ foo bar baz zork;
>
> and
>
> foo(bar, baz)
> {
> local zork;

Don't you agree that there is a difference in the ease of understanding and
maintaining the code ?

-tzvetan


Joao Mendes

unread,
Jul 10, 2002, 11:43:26 PM7/10/02
to

Hi, :)

"John" <nojgoa...@hotmail.com> wrote in
news:mMZW8.12109$A43.1...@newsread2.prod.itd.earthlink.net:

> ignoring "the,an,a" etc.

To those of you writing parsers: please don't harcode this. Please have the
decency of having 'article' objects in the library and having your parser
ignore words that match them. Otherwise:

1) The article list won't be extendable

2) Your engine won't be localizable

3) (more obscure) You might run into problems if people stick articles in
their object vocabularies

> You know, this would be awesome to capture somewhere (it its not
> already), as a series of test cases for adventures. Maybe have
> different levels of functionality. Could set up a simple specific
> location, maybe from one of the classic games with a couple of rooms
> for navigation. It could be like a hello world of IF? Just a
> thought.

I would presume that the current IF 'hello world' is Cloak of Darkness...

Cheers,

J.

Dan Schmidt

unread,
Jul 10, 2002, 11:38:00 PM7/10/02
to
ad...@fsf.net (Adam Thornton) writes:

| It seems to me that what you need is not a new IF development
| language, but a preprocessor wrapped around one of the existing ones
| that sugars the syntax for you. m4 could probably be applied
| usefully here.

I used a combination of m4 and Inform for one project before I rewrote
it all in a different language, and it worked pretty well. I wasn't
doing any exciting syntactical things with it, though.

Dan

--
http://www.dfan.org

L. Ross Raszewski

unread,
Jul 11, 2002, 12:10:15 AM7/11/02
to

Actually I don't. When I read code, I understand the meaning of
variables from how they're used, not where they're declared. If
inform were statically typed, I might see this differently.