How does Inform get around this problem?

[Brian]

Lets take an example where you were writing an adventure where the player
had to collect three gold coins to complete the adventure.

If the player typed Get coin then would inform know which coin the player
is referring to? Maybe inform just checks to see if there is a gold coin in
the current room.

If the player is carrying the first coin and wants to pick up another coin
with the command 'get coin' then would Inform do an inventory and tell the
player that he already has a coin making it impossible to pickup another
coin?

If the player has more than one coin and types 'drop coin' then would
Inform drop all the coins and if Inform dropped one of the coins how does
it know which coin to drop?

If there are more than one coin in the room and the player types 'get coin'
then does Inform get both coins and if it got one of the coins then how
does Inform know which coin to get?

When doing an inventory is each coin listed or are the coins listed as a
collection? eg 'you have gold coins'

If you have more than one coin in the room and typed 'examine coin' then
does Inform give a description of a single coin or groups the coins
together in its description? Eg the coins are made of gold'. If a single
coin was to be described then how does Inform know which coin to describe.

I'm currently writing a adventure program (nothing like Inform) and these
are some of the problems I'm encountering. So I'm interested in knowing how
Inform gets around these problems.


--
Regards Brian


--
Regards Brian

[Andrew Plotkin]

Here, Brian <bcl...@es.co.nz> wrote:
> Lets take an example where you were writing an adventure where the player
> had to collect three gold coins to complete the adventure.
>
> If the player typed Get coin then would inform know which coin the player
> is referring to?

Inform (probably TADS too, but I haven't checked) has a notion of
"indistinguishable objects". Ideally, a set of objects are
indistinugishable if they have exactly the same set of noun synonyms.
(Inform's approximation of this ideal is rough, but can be made to
work.)

If you say "get coin" and there are more than one available, the
parser divides them into equivalence classes based on
indistinguishability. If there's only one class available, it
autoselects an item from that class. If there's more than one class
available, it asks a disambiguation question listing the *classes*
(not the objects).

So you might get a question like "which do you mean, a gold coin, a
copper coin, or the silver coin?" (If there were three gold coins, two
copper coins, and one silver coin available.)

In the same situation, typing "take gold coin" would take one of the
gold coins with no question.

> If the player is carrying the first coin and wants to pick up another coin
> with the command 'get coin' then would Inform do an inventory and tell the
> player that he already has a coin making it impossible to pickup another
> coin?

The "take" grammar uses a token which is biased towards not-held
objects. Similarly, the "drop" grammar uses a token which is biased
towards held objects. These mechanisms are somewhat crude, but work
for the simple case of N indistinguishable objects in a room. You can
take and drop them one at a time.

> When doing an inventory is each coin listed or are the coins listed as a
> collection? eg 'you have gold coins'

They are listed as a group. This is a separate mechanism, though. The
list-writing function has a notion of groupable objects, and puts
groups together as it writes the list out.

(Objects don't have to be indistinguishable to be groupable. The
list-writer can produce output like "You have six coins (one silver,
two copper, and three gold).")

You should download Inform 7 and try a few of these cases yourself.

--Z

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

[Brian]

Thanks Andrew for your reply.

It looks like it would be better to not have identical objects. Maybe
having a large gold coin and a small gold coin or some other description
would be better. I encountered this problem when converting an adventure
that had a pile of bones in more than one location.

I did try the natural english version of Inform but found that the results
were sometimes unpredictable and some of the more complex examples needed a
lot of text to cover various situations and was difficult to understand. I
understand that the original Inform adventure writing language which looks
a bit like a C language is still getting supported. I'm wondering if its
worth learning. i suspect that those that know the original Inform language
might find it easier to use the natural english language when writing
adventures.

--
Regards Brian

[David Griffith]

If you think better in C terms, then by all means, choose Inform6. I
maintain the Inform6 Library these days.

--
David Griffith
davidmy...@acm.org <--- Put my last name where it belongs

[Brian]

I have done computer programming (mainly in Visual Basic) so I feel
compatible in using Inform6.
It seems that Inform6 is for programmers and the other natural language
Inform is for non programmers.

--
Regards Brian

[Andrew Plotkin]

Here, Brian <bcl...@es.co.nz> wrote:
> It seems that Inform6 is for programmers and the other natural language
> Inform is for non programmers.

I am a programmer. I disagree.

[rpresser]

On Tuesday, June 4, 2013 11:00:37 AM UTC-4, Andrew Plotkin wrote:
> Here, Brian <bcl...@es.co.nz> wrote:
> > It seems that Inform6 is for programmers and the other natural language
> > Inform is for non programmers.
>
> I am a programmer. I disagree.
>
> --Z

You are, by anyone's standards, exceptional.

I think that the statement "Inform6 is more suitable for
programmers than non programmers" is quite defensible. Inform7
is quite usable by programmers, but Inform6 is not that usable
by those who have no programming experience.

[Andrew Plotkin]

Here, rpresser <rpre...@gmail.com> wrote:
> On Tuesday, June 4, 2013 11:00:37 AM UTC-4, Andrew Plotkin wrote:
> > Here, Brian <bcl...@es.co.nz> wrote:
> > > It seems that Inform6 is for programmers and the other natural language
> > > Inform is for non programmers.
> >
> > I am a programmer. I disagree.
>

> You are, by anyone's standards, exceptional.

Thank you, but I still protest the statement.

> I think that the statement "Inform6 is more suitable for
> programmers than non programmers" is quite defensible. Inform7
> is quite usable by programmers, but Inform6 is not that usable
> by those who have no programming experience.

I'd agree with "Inform6 is not very suitable for nonprogrammers," but
that's quite a different emphasis!

[Adam Thornton]

In article <0af06dab-86c5-49d5...@googlegroups.com>,

That, however, does not imply that Inform 7 is not also superior for
those with programming experience.

I've been a sysadmin on Unix and Unix-like systems since 1989. I know
quite a few programming languages--I am fluent in Perl and POSIX-ish
shells, I am competent in Python and C, and I can muddle my way through
in Java, BASIC (either old-school Dartmouth-with-line-numbers or more
modern VB-like dialects), COBOL,
x86|m68k|SPARC|System/360-and-descendents|6502 assembly, et cetera.

I have written a quite large game in I7, and a medium-scale game (Stiffy
Makane: The Undiscovered Country) in I6, as well as a good many smaller
pieces in each.

I prefer, in general, writing in Inform 7 to writing in Inform 6.

Adam

[Brian]

Can you tell me the reason why you prefer inform 7?

--
Regards Brian

[Adam Thornton]

In article <1183054696392284104....@free.teranews.com>,
Brian <bcl...@es.co.nz> wrote:

>Adam Thornton <ad...@fsf.net> wrote:
>> I prefer, in general, writing in Inform 7 to writing in Inform 6.

>Can you tell me the reason why you prefer inform 7?

The gap between "I want some rooms and items that are laid out like
*this* and behave like *that*" and having it work is much smaller, for
me, in I7 than in I6.

I can throw together a basic map and set of objects in I7 about as fast
as I can type. Adding complex behavior isn't really any harder than in
I6; the syntax is verbose rather than prickly, but that's OK. I6 feels
a little like C; I7 feels a little like Hypercard. In recent releases,
I7 feels a lot like Python, and that's delightful.

The organizational tools in the IDE are also very helpful. I mean,
yeah, I'm the guy saying that who maintains the no-IDE Linux CLI port,
and who still hates Eclipse and does his real programming in Emacs, but
the Index tabs in the I7 IDE are fantastically useful, and the
code-folding you get by defining headings is also really handy.

The unit testing features are also really great for regression-testing
as you add functionality.

Adam

[Brian]

One thing I did like in I7 was that you can immediately test the changes
you made in the adventure and it tries to give you a clue if something is
wrong.
The problem with writing in natural english is that there are many ways to
say something which has the same meaning.
I think I might need to learn to program in I6 before trying I7 again.
While its true that some things are quicker to write using I7 I did find
that to tell the program exactly what you mean and to cover a few
conditions when more writing is needed.

--
Regards Brian