Each text adventure presents the player with an artificial world that they explore through input commands. Commands may look like natural language sentences but typically they just describe actions to be performed with one or two objects, such as "Examine the box" or "Put the jewel into the box". Commands will fail if a verb or noun is not recognised or if the action can't be performed for some reason. This post is about the best way to handle missing nouns. Other failures will be looked at in separate threads.

To illustrate the discussion, consider the following (artificial) opening scene in a game:
"It’s a beautiful day and you can’t help but smile as you walk east along the beach. The sun has just risen and the sky is free of clouds. Taking off your sandals, you start to paddle. Almost immediately you feel something hard under your right foot and stare down to find out what it is. You can see the top of a small wooden chest stuck in the sand."

The game developer is encouraging you to look at the chest more closely. Perhaps there is something important inside it? So, for most people, the first command would be "Examine the chest" or "Take the chest". But what if the player types "Look at the sky" (mentioned in the text but unlikely to be important) or "Look at the clouds" (mentioned but saying there are none) or "Look at the sea"? (not mentioned but implied). How should such commands be handled?

In Quest, if the object named in a command has not been defined, the current standard response is "I can't see that." Everyone knows there is a boundary to the illusion presented but some are unhappy with the apparent contradiction between an item being mentioned in a description and then a denial that it exists.

One simple adjustment is to change the error response. It can be softened to "Sorry, what was that?" or assume that the object is mentioned and reply "Nothing special." (e.g. see http://textadventures.co.uk/games/view/wqntzlbay0kttqjoh5l-lg/portcullis). That of course means that when the player mistypes an object name, the error message will be confusing, but perhaps that is still a better approach overall?

Some refinement is possible if Quest allows a script to be run instead of using a simple error message. All descriptions within scope, that have been examined, could be scanned for the object name typed and "I can't see that" used only when no match has been found.

Another strategy for improvement is for the developer to indicate (in the game introduction and help text) that background objects are not relevant to the game (assuming that is the case). This would discourage the player from poking around in the background and lower their expectations of the responses they are likely to receive. Such 'foreground' games would have to clearly separate foreground and background objects, with nothing hidden in the background. In Quest, using hyperlinks or game panes, this separation is obvious. In pure text games, a standard phrase such as "You can see..." can serve the same purpose. Saying that an adventure is a 'foreground game' would be similar guidance to saying a game was a 'one-room puzzle', though with the opposite meaning...i.e. in a one-room puzzle everything usually has to be scrutinised thoroughly.

This feels long enough for one message! A later one will say more about the distinction between foreground and background objects and consider how best to handle the background.

If the object is mentioned then it is fair to assume that the PC will, at some stage, want to try to interact with it. Obviously, they have seen the mention in the description so a generic "I can't see that" is not going to cut it. The best way I know is to override the default response with one of your own. - "That is something that is not important to the game" or some other. This is much better than being told that it is not there when the room description still says it is.
The messages can be randomised if you like so that you get a few different (but similar) responses. This is far easier than having to cover off each and every unimportant object.

"Look at the clouds" (mentioned but saying there are none)

Logically, clouds should not exist when "the sky is free of clouds."

In this case, "I can't see that" would be acceptable, but, if the author was already taking the time to consider what the response to "x clouds" could be in this scenario, and if (and only if) that author's purpose was to entertain a player who might try to "x clouds", clouds could be created with a description such as "What part of 'the sky is free of clouds' made you want to interact with nonexistent clouds?"

or "Look at the sea"? (not mentioned but implied)

If the sea is not mentioned in the room description, there is no need to create it, unless you just want to entertain players who try to examine implied backdrops.

The issue is when objects which are mentioned are missing. Most players are not normally concerned with things which would exist if the game world were real (such as the floor, walls, ceilings, keyholes, doorknobs, hands, feet, arms, legs, fingers, toes, etc.), but the player is pretty much required to be concerned with objects mentioned by the author.

One simple adjustment is to change the error response. It can be softened to "Sorry, what was that?"

The parser understands that the object referenced is the problem, though. To avoid confusion, the default response in this case should let the player know that the object referenced is not in scope.

I usually change "I can't see that" to "I do not understand 'whatever' in the current context." This is basically the same thing as R2T1's suggestion, but this way it lets the player know that rephrasing might be helpful and it singles out the word or phrase which wasn't understood.

To do that, I put this in the start script:

// Set this temporary attribute up to avoid errors on game load
game.pov.currentcommandvarlist = NewStringDictionary()
dictionary add (game.pov.currentcommandvarlist, "object", "")
// Add unresolved object response to lookat command
lookat.unresolved = "I do not understand  '{=StringDictionaryItem(game.pov.currentcommandvarlist, \"object\")}' in the current context."

> x R2T1
I do not understand 'R2T1' in the current context.

> x DavyB
I do not understand 'DavyB' in the current context.

> x R2T1's post
I do not understand 'R2T1's post' in the current context.

All descriptions within scope, that have been examined, could be scanned for the object name typed and "I can't see that" used only when no match has been found.

This sounds like it would match any string in any description of any object in scope with the object parameter from the current command, which could allow this sort of thing could happen:

It’s a beautiful day and you can’t help but smile as you walk east along the beach. The sun has just risen and the sky is free of clouds. Taking off your sandals, you start to paddle. Almost immediately you feel something hard under your right foot and stare down to find out what it is. You can see the top of a small wooden chest stuck in the sand.

> x free
You see nothing special about free.

> x and
You see nothing special about and.

> x Taking
You see nothing special about Taking.

If you wish to handle backdrop items, mrangel seems to be onto something:

http://textadventures.co.uk/forum/quest/topic/6vtyg1ljbeoitqmuep5onq/silly-backdrop-scope-script

No matter how things are phrased, default responses do not make games more enjoyable. An author's attention to detail is one of the main things which can make or break a text adventure.

PS

I know I said I was going to stay out of this thread, but I thought I could be helpful and...

Well... I guess I lied. (In my defense, I was lying to myself, though, if that makes anyone feel any better.)

Thanks R2T1, I guess that is a vote for Robin Johnston's approach in Portcullis but with wording that is unclear about whether the object has been identified or not. As someone who mistypes quite often, however, I would prefer to see a clear statement when an object has not been recognised and live the consequences of that decision. What I'd like to put out is:

x thing
Sorry, what was that? (thing)

and have that appear consistently in any command when the verb or noun is not recognised. Since Quest 5.8, the developer has access to the text for any failed command so the error response can take various forms. The above form can be achieved, for example, with

words_in_command= Split(command, " ")
msg ("Sorry, what was that? (" + ListItem(words_in_command, 0) + ")")

Hopefully something similar can be opened up for unresolved objects in a future Quest release. This would allow the words in location description and and any other relevant text to be examined and a suitable response prepared.

To do that, you could put this in the start script:

// Set this temporary attribute up to avoid errors on game load
game.pov.currentcommandvarlist = NewStringDictionary()
dictionary add (game.pov.currentcommandvarlist, "object", "")
// Add unresolved object response to lookat command
lookat.unresolved = "Sorry, what was that?  ({=StringDictionaryItem(game.pov.currentcommandvarlist, \"object\")})' in the current context."

Sorry K.V., I sent my response before seeing yours and immediately went out for the afternoon. I think we are getting somewhere here! If Quest can handle 'missing' objects in an 'intelligent' way, it allows the game developer to implement responses to background items in whatever way they see fit, knowing that the responses to anything they miss or simply don't want to handle will be covered in a way that is still acceptable to players and reviewers.

Tried the code you suggested (cut and paste) but the result was:

> x thing
Sorry, what was that? ({=StringDictionaryItem(game.pov.currentcommandvarlist, "object"))' in the current context.

Last line of code should be:

lookat.unresolved = "Sorry, what was that?  ({=StringDictionaryItem(game.pov.currentcommandvarlist, \"object\")})"

This would presumably have to be added to all verbs that might have unresolved objects?

I've seen a good number of different approaches in actual use:

• In good old Inform 6 nouns denoting non-existent objects could be listed in the room's noun attribute, which wasn't otherwise used, and the game would know to tell the player "that's not important".
• TADS 3 is more sophisticated: you can make objects marked as scenery, that react to any attempt to interact (except examining) with a similar message. Moreover, you can even have objects that aren't actually there, like the clouds in the sky free of clouds from a previous post.
• In Alan 3, which is a lot more simplistic, I found it effective enough to just make an ordinary object that responds to all those nouns and acts like a catch-all, but doesn't actually do anything.
• Last but not least, pretty sure I've seen at least one game with a very interesting default message: "That's either not here or not important." Which covers both cases very very nicely, while sparing the author from a lot of spurious work.

Of course, there's also learning to write very vague descriptions that don't mention many nouns in the first place. Frankly, I'd prefer it if critics were willing to simply accept the game's fiction. Which players, in my experience, usually do without a problem.

Whoops! Ha-ha! I lost a } when I changed it to your example. Doh! Sorry about that!

This would presumably have to be added to all verbs that might have unresolved objects?

I think so, but mrangel or Pixie may know of a trick to get around it.

Frankly, I'd prefer it if critics were willing to simply accept the game's fiction. Which players, in my experience, usually do without a problem.

Yes indeed Felixp7, that is probably the lament of most authors. It's on my Santa list but I'm not hopeful!

Thanks also for the summary of approaches to handling unresolved objects. I'm sure it is possible for Quest to do more for authors and perhaps some discussion on the problem might clarify the best way to go.

In my experience, handling scenery is the last step in the process, after the game has been implemented, tested and polished. It is an extra layer of effort that is significant, can have side effects (handling name clashes, tinkering with the narrative to simplify descriptions, introducing more objects...) and holds up the release of the game. Also, the author can end up dithering about what actions to anticipate and how best to handle them.

Going back to the beach example, what must, should, or could be added? For me, the ‘must’ items are the location and the exits. In principle these could largely be handled automatically, as the current location is known and there are 8 standard directions in which to move. However, in the example, even though the location name is ‘beach’ a separate object has to be created to handle any player reference to the beach. I use ‘Beach’ for the first and ‘beach’ for the second. Operations available for the first can be repeated for the second, so ‘look at beach’ can just show the room description (ShowRoomDescription).

In Quest, exits can only be referenced if they have been defined. So, in the beach case, if the only exit is to the east, and that is locked until the chest has been opened, references to the east all give nice responses, but not the other directions:

> go east
You think about walking on but the chest is too interesting to ignore.
> look east
You are looking east. You think about walking on but the chest is too interesting to ignore.

> look west
I can't see that.
>go west
You can’t go there.

Quest really needs to help with the visibility of directions. The default error responses might also be improved, such as:

>go west
There is nothing of interest in that direction.

I don’t like to put up too much at one time, so I’ll stop there for the moment! There is a lot to say on this subject!!

In regards to objects...

IF the author writes properly, I believe the fault lies on the player if they get pissed and dislikes the game. If the author doesn’t write properly, I believe the fault lies on the author and they should expect players to be unhappy with the game. More to come on “writes properly”.

I understand that there will be some players who for whatever reason (be it out of sheer curiosity, an effort to prove the authors banality, or because they just want to explore every nook and cranny as to not miss anything the author has put in the game)... and, wow... now I just realized I need a preamble to my ramble. In NO WAY am I ridiculing the player for playing a text adventure this way. I don’t do this because I think I have a good radar for what SHOULD be examinably important (either to game play or because the comment might prove entertaining). Now...

If I stumble into a game where a crucial bit is in a description about a “wall” that is not especially described (or clued) somewhere in the game... well shame on the author.

By “write properly”, I mean... authors should be as considerate and thoughtful as they can when they write for others especially when writing a text adventure. It is very difficult. Very. I think it’s tougher to write a good TA then it is a good book. The goal of TA writing is sort of a cross between prose and poetry. It has to be succinct as not to drone on (if you want to do that, write a CYOA 😏) but specific AND vague enough to make the reader wonder and infer... but not too much. How do you define for the reader AND make them question?

A properly written game will either A) mention objects in descriptions AND describe them in a way that rewards a players curiosity OR B) writes descriptions so that the player really has no reason to examine them or even think about examining them.

In either situation, responses to objects is always appreciated by the player. In “A” I believe descriptions for objects is necessary, but I believe they are not necessary in the case of “B”.

Agreed XanMag! Anything intriguing in a description should have a response, especially in a location where there is a puzzle to solve. I have been involved in a game (http://textadventures.co.uk/games/view/ns08ob-ss02brmmcvrnv7w/woo-goes-even-further) where the original author (Longshot) had a puzzle involving a character Jack found dazed at the bottom of a hill. It was a play on the Jack and Jill nursery rhyme, with vinegar and brown paper needed to sort out Jack. As a clue, the scene description up the hill mentioned a well but didn't provide an object for it. The most recent reviewer wasn't happy with that and also missing objects for paths, leaving a two star review after playing for a couple of minutes. I went over the whole game adding objects and providing suitable interaction afterwards. It's a large game so I have good feel for the effort involved!

So, in relation to 'must' scenery for a location, it should cover (i) the location; (ii) anything to do with exits; and (iii) any item mentioned that sounds interesting. The exit descriptions obviously include doors, paths and the use of the word 'exit'. There can also be knock on interest if, say, there is a locked gate into a walled garden. The author should recognise that someone without a key might reasonably try to 'climb the wall'.

Anything intriguing in a description should have a response

How will the player know which objects an author thinks he or she should find intriguing?

Funny, Forgewright. Funny.

You make a valid point, Forgewright.

I'm not helping, and I should have stopped trying to a long time ago.

K.V. appears to have signed out for the holidays, so perhaps I should wind up as well, with a summary as tight as I can make it. The main points so far have been:

1. As a community we seem to have ended up in a position were missing background objects are given greater weight than they seem to deserve; even in games were background objects are clearly separate, and hence clearly unimportant, some insist that reasonable responses are still required, and go even further to suggest that authors neglecting such responses are 'lazy' and their games should be damned as not meeting minimum standards.
2. There seems to be a possibility of Quest doing more to help handle missing objects, rather than pushing everything on to the author. In particular, Quest might (i) give more control to the author when missing objects are identified; and (ii) do more to handle background objects automatically (such as provision of room and exit objects). More research/opinions are needed here.
3. As well as missing objects, failure can also result from (i) missing verbs/commands; and (ii) verbs where the default responses defined for particular objects are not meaningful. This seems equally important to objects being mentioned in a description but not recognised within the game. For example, in the beach example, 'search beach' seems like a reasonable request, but the default is 'You can't search it,' which doesn't make much sense. Perhaps a different text is all that is needed, such as 'You search, but find nothing of interest,' with a general weeding out of all "you can't..." responses. Again there is more to say here so feel free to chip in opinions.

In the meantime, hope you all have a good break!

I was actually quite bored with this discussion in the other thread so didn't bother responding, but I just felt I had to comment on this:

"As a community we seem to have ended up in a position were missing background objects are given greater weight than they seem to deserve; even in games were background objects are clearly separate, and hence clearly unimportant, some insist that reasonable responses are still required, and go even further to suggest that authors neglecting such responses are 'lazy' and their games should be damned as not meeting minimum standards."

Who exactly feels this way? To date, unless I've missed something, only three people hold this viewpoint, and you're one of them. Everyone else disagrees with it. The IF community has held the view that it should be possible to interact with background / scenery objects pretty much since day one (memory limits back in the 80's notwithstanding) and nothing I've seen in this or the other thread seems to raise a valid argument against that viewpoint.

Davyb, for someone who feels as passionately about IF as you clearly do, it seems strange that you're so hellbent on creating games that will be marked down because of the way you're writing them. Yes, you might not agree with the viewpoint of the other 99.99% of the IF users out there, but surely when the majority hold a different viewpoint to you, you have to realise that you're never going to win the debate and you'd be much better off simply accepting it?

I'm with David & K.V. on this. I did start off in "the old school" back in the 1980's and so am probably biased. But as has been said over and over here and the other thread that was hijacked, if it is worth mentioning in a room description or a response to something, then it at least calls for a response of some kind when examined. That may be a "You don't need to bother with that" or "Within the fronds of the fern is a delicate broach" which in turn would mean that the broach requires a description too. And hopefully "fronds" and "fern" would be grouped to mean the same via synonyms or some other mechanism that the game engine uses.
Currently I am converting an old type-in game from a 1984 magazine written in BASIC into ADRIFT. As I do so, I have been adding all the extra descriptions that were missing due to memory constraints 40 years ago. Sure it is time consuming but at the same time enjoyable as I know that it all helps to make the game more enjoyable. (I have also done others into Quest & Inform6 by way of teaching myself the program.)
I am by no means an author when it comes to IF, more of a player, and when I strike something that is "there but not there" again and again, I quickly become disenchanted with the entire game. It doesn't matter if it is written in INFORM, TADS, ADRIFT, QUEST, or one of the other development engines, I, like so many others, expect to be able to interact with any mentioned object. Sure, a mention of a sky without clouds may make some players, want to examine clouds and they should be given a suitable response that steers them back to the real purpose of the game at hand.
All this extra writing may seem like a lot of work, but if it makes your game one which players will want to play and tell others about, then it is worth it.

I prefer the description of as many objects as possible (seen or unseen, mentioned or not), otherwise you may as well play a choose your own adventure that walks you in a relatively straight path to the end. I like the digging of a story. It's a big part of the adventure and indeed requires patience.I don't want to see it, click it and move on.

This is only an opinion and doesn't mean there aren't other preferences when writing or playing a game. As a moderator, this subject has never been a reason either way for me when placing a game.

The community at large may see certain Quest games entered into competitions and it does not matter to me what they think. The finish game product does not necessarily reflect on the game's engine.There are many more considerations I use to place games or to enjoy games for that matter.

Possible solutions to the subject of this thread/conflict:

• Perhaps moderators need to vote or agree on a category for a game before it is placed. Then more opinions can be accounted for when placing the games.

• This subject should not stop a game from being placed. Players and their comments or reviews can help others decide for themselves if they want to play the game. ( I prefer this one)

Text game and D&D game players are certainly a passionate bunch. Ain't we?

Mamma always said.
"Text games are like a box of chocolates, you never know what you're gonna get."