Is there, maybe even an easy way to get rid of all the default responses in Quest? I'd like in my game to be reactions to only those things I set to generate reactions. Anything else would ruin it.
I talk about the "I can't see that." or "I don't understand your command." type of responses. Can I get rid of those?

The first question is: what do you want instead? For example, if they type a command that is not recognized, do you want it to print something? (I assume so; it would be a bit strange to get no feedback.) If so, then you can change what the responses are by overriding the appropriate templates.

If you'd like something else, then it would be helpful to know what your design is (e.g. what happens if they try to look at something not visible).

There should be nothing. Really. No feedback.
I want to achieve a very consistent feedback loop. I show the player what input makes sense and anything beside that just isn't really input. You don't get any feedback in a video game when you hit a useless button, do you? Or miss a button.
People tend to think that in a textadventure they merely have to use the right language and any activity they suggest or input they type in, should work in way or another. And showing feedback to no input is just giving the player the impression that that's how it works. I use all I can think of and something is bound to be right. But I want to discourage that sort of thinking. The player should never be in doubt what he can and can't do.

It looks like if you add a script called "unresolvedcommandhandler" to your "game" object, then that will be invoked whenever a command is not recognized. You can have it do nothing.

It also looks like if you drop this into your game:

<function name="UnresolvedCommand" parameters="objectname, varname">
</function>

then it won't complain about missing objects either. Both of the above are untested, so let me know if they don't work.

Since you had asked for game discussion in another thread, and since you're verging out into uncharted territory, I just wanted to give you your first actual player feedback, based on your "A Test Concerning..." game that I have seen so far.

While analogies can be insightful and make us look at things in new and different ways, not every analogy is valid. The fact that there is no feedback to an incorrect button press on a game controller can lead to a *thought* that perhaps it can work for text as well. Maybe it can and maybe it can't. The important thing is to try and see how it works with real live people. There are other analogies you could follow - for example, the same game controller used when watching video will typically get a circle-with-slash-through-it in an upper corner if they try to hit something incorrect. (I've worked on such software.) What's the difference? Conventions. The convention in console games is that when you press a button that has no function, nothing happens. The convention when using video playback software is that you get a rude sound and a red circle. The convention in text adventures is that when you type something unrecognized, it tells you.

So here's my feedback: when I got into your first room and it said to look around and then exit through the door, I thought, "OK, to look around in a text adventure game, I type 'look'." So I did that, and it did nothing. No response. So I typed "l", and the same non-response. I tried other things, all with no response, and my conclusion was that the game was broken. Or that you would fix it later. I didn't see it as a paradigm-busting innovation on your part. I didn't see it as me doing something wrong. I saw it as the game wasn't designed properly.

For me, the feedback from the game is not implying that there is this large range of commands for me to try. The text prompt itself does that. Actually, the feedback tells me the opposite - it tells me I *can't* type certain things, that I need to figure out (from the text or whatnot) what to type in that will work. Removing that feedback does not remove the mentality or even the need on the part of the player to work out what to type. It's the same loop, it's the same process, just with even less feedback, so with even more frustration.

Now to your mind, perhaps saying in your text, "Look around and ..." means that they should know to type the exact words "look around." From your point of view, I'm sure it's quite clear. That is the advantage of the author point of view. But from the player point of view, I'm still struggling to figure out what to input. I'm still trying to find the magic incantation that works. And under the covers, you're still using the same code that everyone else uses to parse input - you're just not providing any feedback to what has gone wrong when they get it wrong. That doesn't cause a mind shift for the player to "oh, I can't type just anything. I have to type just certain things.", because parser-based games already are that and because despite the text you put in your game, we're all still human beings interpreting things and trying to map that into thing to type in. As I have never had to type "look around" in a text adventure before, it simply did not occur to me, because I did not think so literally. The lack of feedback did not cause a mental shift to some other meaning of what I was typing. So I walked away. If that's what you're going for - where the input is actually part of the puzzle to the extent that you want to throw out all conventions - then I say more power to you. But go into it with eyes wide open about what that will cause. My bet: people are not going to say, "Here's a new ground-breaking paradigm we should all adopt." They're probably going to say, "Here's someone making the painful experience of using a text parser even worse by not even telling the player what they're doing wrong."

You say, "But I want to discourage that sort of thinking." What I'm telling you is, based on my own experience, that doesn't happen. It didn't discourage the "I need to figure out what to type" mentality. It just discouraged me from wanting to play at all.

Imagine you're playing a game on a PC and you see a button on your computer screen and when you click it with your mouse, it depresses but then nothing happens. You'd think it was broken. Because the convention is that when a button is active and enabled, that it does something. Someone could say, well, in console games, pressing an inactive button does nothing, so I'm not going to do anything either. And people will say, fine, and the convention then is to disable it so that the user knows. Feedback up front. I would suggest you do more than you're doing so far. If you're not going to provide feedback after the fact, then make it crystal clear up front - and just having it in the body text just might not be enough.

I applaud your attempt to go in new directions. If you wish to play with conventions - well, the best and most creative people do that all the time. And they get blasted to bits if it doesn't work. So be prepared. My suggestion to you is to have empathy for the player - have thoughts from the author's point of view about what people "should" do, but then also put yourself in the player's place and make sure that, if they can only do X, Y or Z and you expect them to only input X, Y, or Z, that you make it really clear. And know that what I have played so far, it was not clear, because you have something that looks like standard IF but isn't.

And get lots of people to test.

Ok, thanks, I'm going to try the script.

As for your concerns, I actually did some playtesting already. With people, who didn't play textadventures before. And all of them typed "look around". So, I guess I just have to take in account the textadventure-conventions that "look" works as well.
I'm not trying to allienate anybody. I actually try to include a lot of people. I'm just still working out the game design and the underlying game mechanics. I'm just not there yet to take all the sensible input in account.
The problem I had a lot with playtesting that players always were messing around with the input. what happens if I type that in, what happens if I type that in. And the focus shouldn't lie on typing. It should lie on the game mechanics. And I think, I'm not sure, it is indeed an assumption and I want to test it, that the cause of that problem is, that input and output are very similiar, people have different expectations concerning the feedback loop than with video games. With video games you push buttons and you get an audiovisual feedback. Because input and output is so different from each other, people have an easy time understanding the feedback loop. With textadventures it is different. You type in text and the feedback is text. Because input and output are so similiar, people have a harder time understanding what the focus lies on. And I think removing non-game mechanical text input out of the feedback loop will give a better focus.
You posted a topic, I believe, about how you describe IF as a conversation and while I believe it is true for a certain kind of IF, I don't believe it is true for this one. With this one, I don't regard merely typing a text as interaction.
So, thanks for the concern, but I'm not blind to this issues. I'm doing playtesting, I didn't even start with designing the game, I'm still trying to figure out how to get the focus right and so on and on.
But you did show me the problems with conventions and I certainly will take them into account. I want this game to be pretty accesible. So, thanks.

I appreciate your response, and I've actually been thinking some more, while I took a long walk. I'll provide these last thoughts and then leave you in peace.

I'm glad non-IF people went for "look around". I can't put myself into that mindset because I'm not there any more, so the feedback is good. What I wonder is: what happened to those who typed something else and got an empty response? A big part of these text input games is working out the mechanics up front. There's just no way to avoid it. So we type something and see what happens. We naturally work out what happens with good from what happens with bad. Once we do that, we get on with things.

If we're lucky and provide good input up front, then we see a positive response. Nice. Then if we type something that doesn't fit and nothing happens, we can say, "Ok, when I get it right, it responds, and when I don't, it says nothing." Easy peasy, move on to enjoying the game.

If we aren't so lucky and type something wrong up front... well, no response. I wonder what a typical user will make of that? The problem I can see is that there is a convention with text input as well. When I type something and submit it (hit Enter, click a button, etc), something happens. Whether it's the command prompt on a computer or a text input field in a web browser (e.g. the address bar) or the input line in a chat/IM program, when I type something and "submit" it, something happens.

I can really understand and appreciate your thoughts about text output vs input. I hope you can also appreciate when I say, at least in my opinion, I don't think that's the issue. To me empty feedback is just an alternate form of textual feedback. Basically, I type something in, and I want to see what happens, whether I typed something good or not. In a traditional IF game, it tells you, no, sorry that's right. In your game, it will respond with silence - which the player will eventually interpret as, no, sorry, that's not right. In the overall feedback loop of the game, it will come to signify the same result as a message - I did something wrong. So I'm still not seeing where the difference will come in. To me it's still the same:

1) Read what's on screen
2) Try to work out what to type in
3) Type it in
4) See what happens. It's either good input or not.
5) If it's good, then something interesting happens.
6) If not (the game responds in its "negative" way, which might be silence in your case; it could be text, or it could be a little figure in the corner wagging his finger going "uh uh uhhh"), then I'll have to try again with something else
7) Either way, go back to 1.

I'm curious how your player testing works out! (not that I expect or deserve to know lol)

so, I found the function you mentioned, but I don't know what to do with it. How can I make it do nothing?

Ok, I see what you mean.
Hm, I really didn't think about what happened if the first response was silence.
So, I included an introduction to the game where I try to give the player a clear mindset and I even add a list with all the text-input that works to the inventory. I hope that will be enough, but as I said, it is indeed experimental and I want to test it.
I think the difference is a focus-shifting one.
In a classic textadventure, I read a text and try to figure out what to type in. But I want the player to read a text and try to figure out what interaction to perform. It may not seem like a huge difference, but I think it can mean the world.
And I think giving the player feedback to typing, gives the impression that the player is interacting, regardless if it's meaningful or not.
Not giving any feedback gives the impression of not interacting. So the focus shifts from typing to performing an interaction.
I think.

ok, so I dropped your script into my game and it got rid of some default responses, but some still remain.
How can I get rid of the rest?

If you could let me know what's left, we can pick them off one by one.

I'm not sure. For example I tried out "jump" and that had a response, so I guess there are much more default responses that I don't know of.
But just typing something randomly in, generates no response anymore, so that's a huge step.
So, sorry, I can't really tell you all. I just don't know the input that usually works. But for example taking objects that can't be taken says "You can't take that."

If you go to the bottom of the left pane, click Filter and then Show Library Elements, then all the verbs and commands will show up in your tree. So, for example, "jump" is there and "take".

For something like "jump", you can click on the command and then click the Copy button in the top right to make a local copy in your game. Then you can just make it do nothing by deleting the script inside. Something like "take" will require a look, as you probably want some "takes" to work and others not.

Alright, jump is disabled now.
With "take", I run a script instead of the default behaviour, so that works as well.
Thanks again!

I've encountered a problem with disabling verbs. when I start the game, an error occurs, something like Error running script: Error adding key '' to dictionary: an element with a same key already has been added.
it happens when I disable two or more verbs, only one works fine.

Do you have a small game sample where this is happening?

Here it is, simply start the game and it's the first thing that appears.

It seems the "attribute" value (known as "property" in code view) must be unique. You can't have two of the same, even an empty string. I would leave that attribute value alone in the verbs you disable. The pattern can be made empty, which means the verb won't match any input, but the attribute needs to be something unique, even if the verb is never called.

Ah, yes, now it's gone, thanks a lot. I would have never come up with that. How do you do it, do you just mess around with another code, imitating the things I did until something happens? or did you study coding? or I don't know.

It's hard to identify a single process. It really depends on the situation. (But, then, I've had lots of experience debugging problems over a long period of time!)

For this one, I first looked for clues in the error message. It was complaining about trying to add the same key twice, and the key was an empty string. Unfortunately, there was no direct code in your game that was adding a dictionary key, which made it more difficult to work out.

Then knowing you had been overriding verbs, I looked at the verbs you created, in Code View. Each verb was very simple - only four fields. And all the fields were empty, So first I reduced them down to empty verbs, with no fields at all (just the verb name). And that worked - no error. So now I had bracketing cases, and I just worked my way in, going back to the failing case and removing fields one by one until I found the one that made it work again. Then I changed the code back to what you had and just set that one field to a non-empty value to prove it was the problem.

I'm not sure if that makes sense or not.

Oh, it totally does. That's what I was thinking too. I just come up with it way too late. Anyways, thanks again.