More suggested additions to Quest===>

  Axe Software Forums
  Quest Developer Forum
  More suggested additions to Quest===>

Author Topic:   More suggested additions to Quest===>

Mega posted 08-12-2001 21:56 GMT
1) I know that the object pane windows allow drag-and-drop interface; if you drag an item over to another item, it automatically calls "use item1 on item2" -- a very handy feature. However, I noticed that, while this works when using an inventory item on an item in the room, it doesn't work when using one inventory item on another inventory item. Plz correct this :-)
2) Another handy function that Quest provides are buttons to automatically call the 'look', 'take', and 'speak to' functions. However, again, this only works on items in the room, not in your inventory. Obviously the 'take' button shouldn't work on inventory items, but the 'look' button certainly should, and even the 'speak to' button may have a use if you're carrying something that's alive :-)
3) Quest supports coding "on" phrases ('use hammer on nail') and "to" phrases ('give money to clerk'), but not "with" phrases('kill monster with sword').
Computer Whizz posted 09-12-2001 01:44 GMT
You can make your own "with" command....
eg.. #variable1# with #variable2#, I'm not sure if the following will work; #var1# #var2# with #var3#
I think it should since there are spaces inbetween the variables - but I don't know.
Computer Whizz
Mega posted 09-12-2001 04:35 GMT
No, it doesn't.
If 'man' has a 'give gold' action and 'gold' has a 'give to man' action, Quest knows that the command will take the form 'give gold to man'.
But if 'monster' has a 'kill with sword' action and 'sword' has a 'kill monster' action, Quest won't know what to do. The command 'kill monster with sword' won't work correctly.
Computer Whizz posted 09-12-2001 18:09 GMT
No - it's a "custon player command".
You say "#var1# #var2# with #var3#" and then have:
if property (#var2#; withable) then {
if (#var1# = kill) then [I'm not sure how you execute an object's action....] <killwith>
if (#var1# = use) then [objectaction execution code] <usewith>
ect.. }
You should also have extra stuff like checking #var3# to see what the object (#var2#) does, ect...
Computer Whizz
Mega posted 09-12-2001 19:51 GMT
Exactly, it has to be coded separately. That's what I've been doing so far in order to make it work. But the point is, other 2-part commands using "to" and "on" are understood automatically, as I said, by simply giving the appropriate actions to the objects. They don't need any separate coding to implement them, and neither should "with" commands.
Alex posted 09-12-2001 21:05 GMT
I must confess you've lost me completely. Quest only automatically supports the commands "give" and "use". The word "with" is irrelevant - the commands "kill monster with sword" and "put cloak on nail" both have to be coded in the same kind of way.
Mega posted 10-12-2001 01:36 GMT
For example:
if 'sword' has action 'use on man'
and 'man' has action 'use sword'
then the command 'use sword on man' works
AND
if 'sword' has action 'give to man'
and 'man' has action 'give sword'
then the command 'give sword to man' works
BUT
if 'sword' has action 'kill man'
and 'man' has action 'kill with sword'
then the command 'kill man with sword' does NOT work
Does that help clarify what I mean? :-)
passerby posted 10-12-2001 17:59 GMT
Mega, I think you have hit on not just an interesting problem, but one that has a lot of implications for parser design.
are you trying to say that:
You would prefer a command that says what you are doing ("kill monster with sword") rather than one that quest will easily understand ("use sword on monster").
The thing about quest is that it assumes that there are only two possible interactions between any set of objects. "use" and "give". "on" and "to" are only ever used as part of those commands. i infer Alex chose "use" because it is a word that can mean any type of interaction, depending on the context it is used in.
This is why he would not have given any "with" command. Because that means he would have to have forseen the "kill" command that goes with it, because the commands involved in any game are specific to that game only. Alex had no idea that "kill...with" would be needed. Only you, because you are trying to do it, do.
Alex can't be expected to do this, because he would need to create thousands of "kill...with", "jump...over" and "place...into" commands. And when he was done, he still wouldn't satisfy everyone, because not every possible command can be predicted.
Actually, from a design perspective, this would mean that an easy way to make the quest parser more flexible would be to let the game maker specify a word to use instead of "use" (eg a knife might be called with "cut" instead, or a rope with "tie").
And what Mega seems to be saying is that he shouldn't have to write extra code just because one insignificant word is different. Fair enough, but how to fix the problem?
CW's way will work, but will make for a lot of fiddly work in any reasonable sized game, because everything that can be used with "with" needs to have the property "withable" added to it.
Of course, if everything that can be used "on" something can be used "with" it as well, "withable" is not needed, and all u need to do is set up a global command "use x with y" that executes a command "use x on y"
Alex posted 10-12-2001 19:58 GMT
The only reason "use" works in actions is to provide a way to change the "use" tag behaviour while the game is running. Actions don't necessarily correspond to user commands, as not everything that can be done to an object might be initiated from a user command (you might have an action that only gets called from script commands). Quest provides "use" and "give" as user commands by default - others you have to add yourself. Hence if you want to add a "kill" action you have to do that yourself, and it's not hard:
command <kill #@obj#> doaction <#obj#; kill>
(The "@" is a Quest-3.1-ism, omit it in Quest 3.0. It will actually prove rather useful, as it won't execute the "doaction" if the object specified by the player doesn't exist, and it will disambiguate automatically for you).
If actions automatically were transcribed into user commands, you would lose a good deal of flexibility. For example, I could replace the script above with:
command <kill #@obj#; murder #@obj#; stab #@obj#> doaction <#obj#; kill>
Or
command <kill #@obj#> {
if not got <dwarfkiller> then {
if not property <#obj#; dwarf> then doaction <#obj#; kill>
else msg <You haven't got anything to kill an dwarf with.>
}
else doaction <#obj#; kill>
}
passerby posted 10-12-2001 21:00 GMT
if the code you supplied works like i think it does it's already possible to do what i intended.
what i was thinking was that because use and give work with a combination of objects, it would be possible to rename this combination something else. This means that when using a knife on a rope, you would call it a "cut", while giving a coin to a merchant is renamed "pay".
This means that it is possible to give a merchant a coin with "pay merchant" rather than "give coin to merchant" and to "cut rope" rather than "use knife on rope". Both seem (to me at least) more natural ways of describing the acts attempted.
Since each combination of objects is unique, each can be called a different name if required. In each case, the game maker only need specify the actions triggered, and the name the interaction is known by.
Sorry. I've just long wondered how a parser for adventure games is written, and thought i found an elegant way of doing it here.
Mega posted 12-12-2001 16:38 GMT
I understand that it is impractical to try to think of every unique command a user might type. That's not what I'm suggesting.
Obviously, if I want to make a unique command, I'd have to code it myself. The problem is in the word order.
If I had an object 'lever' and gave it the action 'pull', then the game would expect the user to type 'pull lever'. And if an object 'water' had an action 'drink', the game would expect the command to be 'drink water'. The command would always take the form '#verb# #object#'.
But here's where the problem arises. If an object 'dwarf' had an option 'kill with sword', then the game would once again expect a '#verb# #object#' command - which, in this case, is 'kill with sword dwarf'. That makes absolutely no sense. It should be 'kill dwarf with sword', which means inserting the object in the middle of the action name. That's what I was suggesting Quest should do. It should have some way of parsing "transitional" words such as 'on', 'to', and 'with', so that ANY command I wrote involving those words would be handled correctly by Quest.
Mega posted 14-12-2001 14:18 GMT
You know, there were 2 other suggestions besides the 'with' command... :-)
passerby posted 15-12-2001 15:01 GMT
Yeah, but the other two are hard to disagree with.
The only possible problem is that using the drag-and-drop idea might make it too easy for a player to just try using everything with everything else and solve a game's problems by exhaustion of possibilities, rather than by working out a solution for themselves.
Mega posted 15-12-2001 18:58 GMT
I don't mean providing new ways of interacting with objects. The drag-and-drop already exists for dragging inventory items onto room items. I'm just suggesting you extend it to allow dragging inventory items onto each other. :-)
carlii posted 26-12-2001 06:30 GMT
Don't you think Quest is too easy to use already?
LOL
No, what I mean is that you think back to the old IF games, how all you really had was a typing interface and you didn't use the mouse? Whereas now you use mouse a lot in Quest (compass, use, speak to, etc).
Do you get what I am saying? Maybe passerby is right...it WOULD be too easy if you could use everything with everything to try and find a solution. Great suggestions tho` Mega! ;)

Author	Topic: More suggested additions to Quest===>
Mega	posted 08-12-2001 21:56 GMT 1) I know that the object pane windows allow drag-and-drop interface; if you drag an item over to another item, it automatically calls "use item1 on item2" -- a very handy feature. However, I noticed that, while this works when using an inventory item on an item in the room, it doesn't work when using one inventory item on another inventory item. Plz correct this :-) 2) Another handy function that Quest provides are buttons to automatically call the 'look', 'take', and 'speak to' functions. However, again, this only works on items in the room, not in your inventory. Obviously the 'take' button shouldn't work on inventory items, but the 'look' button certainly should, and even the 'speak to' button may have a use if you're carrying something that's alive :-) 3) Quest supports coding "on" phrases ('use hammer on nail') and "to" phrases ('give money to clerk'), but not "with" phrases('kill monster with sword').
Computer Whizz	posted 09-12-2001 01:44 GMT You can make your own "with" command.... eg.. #variable1# with #variable2#, I'm not sure if the following will work; #var1# #var2# with #var3# I think it should since there are spaces inbetween the variables - but I don't know. Computer Whizz
Mega	posted 09-12-2001 04:35 GMT No, it doesn't. If 'man' has a 'give gold' action and 'gold' has a 'give to man' action, Quest knows that the command will take the form 'give gold to man'. But if 'monster' has a 'kill with sword' action and 'sword' has a 'kill monster' action, Quest won't know what to do. The command 'kill monster with sword' won't work correctly.
Computer Whizz	posted 09-12-2001 18:09 GMT No - it's a "custon player command". You say "#var1# #var2# with #var3#" and then have: if property (#var2#; withable) then { if (#var1# = kill) then [I'm not sure how you execute an object's action....] <killwith> if (#var1# = use) then [objectaction execution code] <usewith> ect.. } You should also have extra stuff like checking #var3# to see what the object (#var2#) does, ect... Computer Whizz
Mega	posted 09-12-2001 19:51 GMT Exactly, it has to be coded separately. That's what I've been doing so far in order to make it work. But the point is, other 2-part commands using "to" and "on" are understood automatically, as I said, by simply giving the appropriate actions to the objects. They don't need any separate coding to implement them, and neither should "with" commands.
Alex	posted 09-12-2001 21:05 GMT I must confess you've lost me completely. Quest only automatically supports the commands "give" and "use". The word "with" is irrelevant - the commands "kill monster with sword" and "put cloak on nail" both have to be coded in the same kind of way.
Mega	posted 10-12-2001 01:36 GMT For example: if 'sword' has action 'use on man' and 'man' has action 'use sword' then the command 'use sword on man' works AND if 'sword' has action 'give to man' and 'man' has action 'give sword' then the command 'give sword to man' works BUT if 'sword' has action 'kill man' and 'man' has action 'kill with sword' then the command 'kill man with sword' does NOT work Does that help clarify what I mean? :-)
passerby	posted 10-12-2001 17:59 GMT Mega, I think you have hit on not just an interesting problem, but one that has a lot of implications for parser design. are you trying to say that: You would prefer a command that says what you are doing ("kill monster with sword") rather than one that quest will easily understand ("use sword on monster"). The thing about quest is that it assumes that there are only two possible interactions between any set of objects. "use" and "give". "on" and "to" are only ever used as part of those commands. i infer Alex chose "use" because it is a word that can mean any type of interaction, depending on the context it is used in. This is why he would not have given any "with" command. Because that means he would have to have forseen the "kill" command that goes with it, because the commands involved in any game are specific to that game only. Alex had no idea that "kill...with" would be needed. Only you, because you are trying to do it, do. Alex can't be expected to do this, because he would need to create thousands of "kill...with", "jump...over" and "place...into" commands. And when he was done, he still wouldn't satisfy everyone, because not every possible command can be predicted. Actually, from a design perspective, this would mean that an easy way to make the quest parser more flexible would be to let the game maker specify a word to use instead of "use" (eg a knife might be called with "cut" instead, or a rope with "tie"). And what Mega seems to be saying is that he shouldn't have to write extra code just because one insignificant word is different. Fair enough, but how to fix the problem? CW's way will work, but will make for a lot of fiddly work in any reasonable sized game, because everything that can be used with "with" needs to have the property "withable" added to it. Of course, if everything that can be used "on" something can be used "with" it as well, "withable" is not needed, and all u need to do is set up a global command "use x with y" that executes a command "use x on y"
Alex	posted 10-12-2001 19:58 GMT The only reason "use" works in actions is to provide a way to change the "use" tag behaviour while the game is running. Actions don't necessarily correspond to user commands, as not everything that can be done to an object might be initiated from a user command (you might have an action that only gets called from script commands). Quest provides "use" and "give" as user commands by default - others you have to add yourself. Hence if you want to add a "kill" action you have to do that yourself, and it's not hard: command <kill #@obj#> doaction <#obj#; kill> (The "@" is a Quest-3.1-ism, omit it in Quest 3.0. It will actually prove rather useful, as it won't execute the "doaction" if the object specified by the player doesn't exist, and it will disambiguate automatically for you). If actions automatically were transcribed into user commands, you would lose a good deal of flexibility. For example, I could replace the script above with: command <kill #@obj#; murder #@obj#; stab #@obj#> doaction <#obj#; kill> Or command <kill #@obj#> { if not got <dwarfkiller> then { if not property <#obj#; dwarf> then doaction <#obj#; kill> else msg <You haven't got anything to kill an dwarf with.> } else doaction <#obj#; kill> }
passerby	posted 10-12-2001 21:00 GMT if the code you supplied works like i think it does it's already possible to do what i intended. what i was thinking was that because use and give work with a combination of objects, it would be possible to rename this combination something else. This means that when using a knife on a rope, you would call it a "cut", while giving a coin to a merchant is renamed "pay". This means that it is possible to give a merchant a coin with "pay merchant" rather than "give coin to merchant" and to "cut rope" rather than "use knife on rope". Both seem (to me at least) more natural ways of describing the acts attempted. Since each combination of objects is unique, each can be called a different name if required. In each case, the game maker only need specify the actions triggered, and the name the interaction is known by. Sorry. I've just long wondered how a parser for adventure games is written, and thought i found an elegant way of doing it here.
Mega	posted 12-12-2001 16:38 GMT I understand that it is impractical to try to think of every unique command a user might type. That's not what I'm suggesting. Obviously, if I want to make a unique command, I'd have to code it myself. The problem is in the word order. If I had an object 'lever' and gave it the action 'pull', then the game would expect the user to type 'pull lever'. And if an object 'water' had an action 'drink', the game would expect the command to be 'drink water'. The command would always take the form '#verb# #object#'. But here's where the problem arises. If an object 'dwarf' had an option 'kill with sword', then the game would once again expect a '#verb# #object#' command - which, in this case, is 'kill with sword dwarf'. That makes absolutely no sense. It should be 'kill dwarf with sword', which means inserting the object in the middle of the action name. That's what I was suggesting Quest should do. It should have some way of parsing "transitional" words such as 'on', 'to', and 'with', so that ANY command I wrote involving those words would be handled correctly by Quest.
Mega	posted 14-12-2001 14:18 GMT You know, there were 2 other suggestions besides the 'with' command... :-)
passerby	posted 15-12-2001 15:01 GMT Yeah, but the other two are hard to disagree with. The only possible problem is that using the drag-and-drop idea might make it too easy for a player to just try using everything with everything else and solve a game's problems by exhaustion of possibilities, rather than by working out a solution for themselves.
Mega	posted 15-12-2001 18:58 GMT I don't mean providing new ways of interacting with objects. The drag-and-drop already exists for dragging inventory items onto room items. I'm just suggesting you extend it to allow dragging inventory items onto each other. :-)
carlii	posted 26-12-2001 06:30 GMT Don't you think Quest is too easy to use already? LOL No, what I mean is that you think back to the old IF games, how all you really had was a typing interface and you didn't use the mouse? Whereas now you use mouse a lot in Quest (compass, use, speak to, etc). Do you get what I am saying? Maybe passerby is right...it WOULD be too easy if you could use everything with everything to try and find a solution. Great suggestions tho` Mega! ;)