For example:
:> look
You are in a small cell. There is a straw mattress in the corner with a
rough pillow and a cotton sheet. There is also a bucket, a stool, some
shaving equipment and a hacksaw.
:> get *
Mattress ? n
Rough pillow ? n
Cotton sheet ? y
Taken.
Bucket ? n
Stool ? n
Shaving equipment ? y
Taken.
Hacksaw ? y
Taken.
The idea is that it would list all of the items available, and allow the
player to type "y" or "n" for each one. Pressing Enter would mean "n" by
default. Entering "q" would quit (same as typing "n" for the rest of the
items), and "c" could mean "cancel the command". Possibly "a" could mean
"include all the rest" (the opposite of "q"). Going really crazy, maybe "*y"
could mean that the default is "y" instead of "n" when you just press Enter.
Not sure if the commands should be executed one at a time (as in the example
above) - equivalent to "get sheet. get shaving equipment. get hacksaw" - or
all at once, as in "get sheet and shaving equipment and hacksaw". The
advantage of "one at a time" is that you can do something like "x *" and not
have it scroll off your screen ... it should probably still take a single
turn, though (just like "get all" would).
Is it difficult to get a list of objects that are in scope for a particular
command (in Inform or TADS) ? I realise that the scope of "get all" is
different from "drop all" ...
Just a random idea - ignore it if it seems silly,
David Fisher
In everyday IF this would probably be silly, but in very object-heavy
games it could be very useful. What about "some", like
>get some
Hammer? y
Green toupee? y
Puddle of acid? n
or as
>get all
Tools? (yes/no/some) y
Bedclothes? (yes/no/some) n
Interns? (yes/no/some) s
Tommy? y
Shirly? n
Taken
To be honest, I think it'd annoy the life out of me if the game stopped
and asked me about every single object in the location. What if there
are twenty different objects? Having to tap "y" or "n" for each of them
would drive me to distraction. What's wrong with "get all" anyway? It
does its job fine for me.
Just an option (which you never have to use if you don't want to) ... it
wouldn't affect the normal behaviour of "get all" at all (I'm feeling Irish
now ... t'be sure, t'be sure ! :-)
I just noticed the people don't seem to like having to type long object
names:
:> enter ship
Which ship do you mean, the Thwakiavaelian ship or the Tyronnessian ship ?
... and this might be a quicker way to select things out of a group:
:> enter *
Thwakiavaelian ship ? n
Tyronnessian ship ? y
Following the UNIX style, you could possibly even use "*" as a wildcard to
form abbreviations:
:> enter ty*
David Fisher
What would you do in the case of exclusive options? Your "enter *" example
is
a good candidate. You can only enter one thing at a time (modulo crazy
physics)
and order of selection would be important.
Your choice of "get all" = "get rock. get pillow." or = "get rock and
pillow" will
determine certain other things. For example, "Drink all" when there is
poison and
poison antidote in scope. The first method, you die before you get to
choose whether
to drink the antidote. The second method, given a sufficiently advanced
game, may
interpret that as drinking them at the same time.
Currently systems like TADS 3 allow only certain verbs to be used with
all, so
they avoid that problem. Furthermore, TADS 3 has a little option where you
can
hide a specific object from all (for specific verbs if you like). That way
you
don't get the irksome "ground: You can't take the ground!" messages when
you say
"get all". Scope in this sense is heavily customizable.
Personally, I wouldn't mind this construction in IF, although using * is a
bit
awkward (especially for non-computer savvy folk). It breaks the feel a
little, I
think. Ideally there could be an option available to authors to use this
"yes/no"
method for "[verb] all" commands, or use the traditional (answer yes to
everything)
method.
BrettW
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
David Fisher wrote:
> I just noticed the people don't seem to like having to type long object
> names:
>
> :> enter ship
>
> Which ship do you mean, the Thwakiavaelian ship or the Tyronnessian ship ?
>
> ... and this might be a quicker way to select things out of a group:
>
> :> enter *
> Thwakiavaelian ship ? n
> Tyronnessian ship ? y
In this instance, mightn't it be better to number options? Like
>Open office door
Which door do you mean, the adminstration office door (1), custodian's
office door (2), or the antidisestablishmentarianism office door (3)?
Maybe not actually printing the (1), but letting the player respond
with 1-3, as long as they've been told in advance that numbers work in
this situation.
But surely "get some" already has been implemented....
...in AIF
I like the idea of numbers (if the options are mutually exclusive, as in
disambiguation) , but I get the impression that some people don't like
deviating from a "text only" (ie. natural language only) interface ... an
objection people have raised to using menus in IF. I'm kind of glad somebody
else thinks numbers might be OK, too. :-)
David Fisher
... [and in another post] ...
>> :> enter ship
>>
>> Which ship do you mean, the Thwakiavaelian ship or the
>> Tyronnessian ship ?
>>
>> ... and this might be a quicker way to select things out
>> of a group:
>>
>> :> enter *
>> Thwakiavaelian ship ? n
>> Tyronnessian ship ? y
> What would you do in the case of exclusive options?
> Your "enter *" example is a good candidate.
Yep. Maybe the parser could be intelligent enough to recognise this
situation, and stop when "y" is entered (and automatically assume "y" if
there is only one option left).
> Your choice of "get all" = "get rock. get pillow." or
> ="get rock and pillow" will determine certain other things.
> For example, "Drink all" when there is poison and poison
> antidote in scope. The first method, you die before you get to choose
> whether to drink the antidote. The second method,
> given a sufficiently advanced game, may interpret that as
> drinking them at the same time.
This is already an issue with "all". What does Inform / TADS do at the
moment with "drink all" ? (I assume you drink the objects in a semi-random
order depending on where things are in the object list - if "drink all" is
permitted at all).
It might be complicating things a bit to introduce simultaneous actions into
IF, too :-)
> Currently systems like TADS 3 allow only certain verbs to be
> used with all, so they avoid that problem. Furthermore, TADS 3
> has a little option where you can hide a specific object from all
> (for specific verbs if you like). That way you don't get the
> irksome "ground: You can't take the ground!" messages when you
> say "get all". Scope in this sense is heavily customizable.
Cool ...
I think there are ways to do this in Inform / TADS 2 as well (not sure ?)
>
> Personally, I wouldn't mind this construction in IF, although
> using * is a bit awkward (especially for non-computer savvy folk).
Good point. After using "*" to mean "everything" for the last 15 years, it
feels pretty natural to me, though :-)
> It breaks the feel a little, I think. Ideally there could be an
> option available to authors to use this "yes/no" method for
> "[verb] all" commands, or use the traditional (answer yes to
> everything) method.
I would leave "all" as it is (rather than frustrating players like David
Whyld !) and just have "*" as an optional thing to enter ... if it is never
used, then there is no problem with mimesis, etc.
BTW can you think of a nicer syntax for abbreviating a word than "Th*" ?
(Using a dot as in "Th." could be confused with the end of a command, and
"Th..." might be too much typing ... ?)
David Fisher
Would it be too weird to allow people to say things like "the first",
"former", "latter", "last", "middle", "second", "2nd", etc as well as
numbers ? (As long as another option doesn't contain the word ...)
This is reminding me of Zarf's experiment, "Futzing with continuous
substances" - where you could specify the first potato, the largest potato,
etc. How about this (really getting carried away now :-) :
Which ship do you mean, the Thwakiavaelian ship or the Tyronnessian ship ?
:> the biggest one
David Fisher
In standard Inform, this is pretty much built-in. When a question is
asked, the original command is re-built with the new noun phrase, so the
player can use any of the words found in the 'name' property. The
following should allow exactly what you suggest:
object ship1 "Thwakiavaelian ship"
with
name 'Thwakiavaelian' 'big' 'bigger' 'biggest' 'ship',
description "It's a big ship.",
has enterable;
object ship2 "Tyronnessian ship"
with
name 'Tyronnessian' 'small' 'smaller' 'smallest' 'ship',
description "It's a small ship.",
has enterable;
JohnnyMrNinja wrote:
> In everyday IF this would probably be silly, but in very object-heavy
> games it could be very useful. What about "some", like
> >get some
> Hammer? y
> Green toupee? y
> Puddle of acid? n
If this were needed in a game, I'd go with 'some'. I wouldn't assume
that players are comfortable with Unix-like wildcards. 'some' would
work well for those cases where you are allowed multiple objects
(generally speaking, only the 'take' and 'drop' type of commands).
Again in standard Inform, using a command which takes a single object
without specifying an object results in either choosing the best target
or asking a question. Thus, the following should work:
You see the Thwakiavaelian ship and the Tyronnessian ship.
> enter
Which do you mean, the Thwakiavaelian ship or the Tyronnessian ship?
I haven't tested the preceeding code snippets, but they should work
assuming that the grammar for the 'enter' command is something like this:
Verb 'enter' * enterable -> Enter;
Ash
I'd love to have this number feature in disambiguation. Could please
someone write it for Inform?
Pleeease?
Ian
TADS 3 understands most of those variants. I don't think you can
type just "3", but "the third one" should work as expected.
-- Krister Fundin
Doesn't seem too difficult.
In ParserM make the following additions
for (i=1 : i<=number_of_classes : i++) {
while (((match_classes-->marker) ~= i) &&
((match_classes-->marker) ~= -i)) marker++;
k = match_list-->marker;
! *****************
! Added the following line
! *****************
print "(",i,") ";
if (match_classes-->marker > 0) print (the) k; else print (a)
k;
if (i < j-1) print (string) COMMA__TX;
if (i == j-1) print (string) OR__TX;
}
L__M(##Miscellany, 57);
! ...and get an answer:
.WhichOne;
#Ifdef TARGET_ZCODE;
for (i=2 : i<INPUT_BUFFER_LEN : i++) buffer2->i = ' ';
#Endif; ! TARGET_ZCODE
answer_words=Keyboard(buffer2, parse2);
! Conveniently, parse2-->1 is the first word in both ZCODE and
GLULX.
first_word = (parse2-->1);
!******************
! Added all of the following
!******************
i = 0;
switch (first_word)
{
'1//': i = 1;
'2//': i = 2;
'3//': i = 3;
'4//': i = 4;
'5//': i = 5;
'6//': i = 6;
'7//': i = 7;
'8//': i = 8;
'9//': i = 9;
'10': i = 10;
}
if (i >=1 && i <= number_of_classes)
{
marker = 0;
while (((match_classes-->marker) ~= i) &&
((match_classes-->marker) ~= -i)) marker++;
k = match_list-->marker;
return k;
}
Seems to work ok.
It's easy enough to write a ChooseObjects routine that skips
static/scenery objects when matching "all". (Or any other category.)
See chapter 33 in the DM.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
You *could* put in some exclusivity flag but it's problematic (an
exclusivity
function taking in the current verb and other objects may be better). In
any
case, I prefer "VERB ALL" to be an indiscriminate wide-ranging action. If
the
player is too lazy (or used to computers doing all their work ;) ) to type
out
selected objects, then I dunno...
> This is already an issue with "all". What does Inform / TADS do at the
> moment with "drink all" ? (I assume you drink the objects in a
> semi-random
> order depending on where things are in the object list - if "drink all"
> is
> permitted at all).
TADS 3 (my language of choice) does three things:
a) by default, it doesn't permit "Drink all". You can change that. You can
change it on a library or a verb-to-verb basis and maybe even do it
functionally
(have some boolean function decide at the time).
b) Some verbs (in some situations) can be flagged as dangerous, so you
don't
accidentally trigger them. This is caught all the way up in the
verification
process.
c) I knocked up a little example where "GET ALL" would kill you. There's
two
objects, one is inert, and the other kills you if you pick it up. On "GET
ALL",
when it gets to the deadly object it kills you and stops processing. Which
makes
sense. (I didn't flag "GET DEADLY OBJECT" as dangerous so the game didn't
modify
this behaviour)
So TADS 3 at least runs through each, processing each verb on each
candidate object.
> It might be complicating things a bit to introduce simultaneous actions
> into
> IF, too :-)
Oh God... I could see this become a new form of maze by way of Twister(tm):
> PULL LEVER WHILST PUSHING RED BUTTON WHILST PUSHING PEDAL
Which lever did you mean, the red one, the blue one or the yellow one?
Yellow
Which hand did you want to pull the lever with, the left or right hand?
Left
Which red button did you mean, the first red button, the second red
button, or the BIG red button? BIG
Which pedal did you mean, the accelerator or the brake?
Which foot did you want to push the lever with, the left or the right?
You can't reach the button from here.
> BTW can you think of a nicer syntax for abbreviating a word than "Th*" ?
> (Using a dot as in "Th." could be confused with the end of a command, and
> "Th..." might be too much typing ... ?)
Depends on the context. In IF, some people regularly only type six letters
of an
object's name because they know that the parser only cares about those
six. This
can lead to many amusing misinterpretations for the parser, or someone
reading a
transcript ;)
BrettW
:-)
How about a guess the verb, adverb, anatomy and simultaneous actions puzzle
?
:> Gently depress red button with left index finger while pulling the lever
up quickly with right foot
Nothing almost happens.
David Fisher
"David Fisher" <da...@hsa.com.au> wrote in message
news:_espe.18804$Le2.1...@nasal.pacific.net.au...
>> Currently systems like TADS 3 allow only certain verbs to be
>> used with all, so they avoid that problem. Furthermore, TADS 3
>> has a little option where you can hide a specific object from all
>> (for specific verbs if you like). That way you don't get the
>> irksome "ground: You can't take the ground!" messages when you
>> say "get all". Scope in this sense is heavily customizable.
>
> Cool ...
>
> I think there are ways to do this in Inform / TADS 2 as well (not sure ?)
In TADS 2, "all" refers to whatever the verb returns as a list of defaults. You
can modify a verb (or the verb class itself) to leave some objects out for
whatever reason. If no defaults are returned, you get "I don't see what you're
referring to," which is what I do for "look at."
To exclude objects in specific cases, you could give objects a method
which returns whether the object should be used as a default for the given
verb (or under present circumstances). Then a verb could modify its list
of defaults accordingly.
Kevin Venzke