I'm sure when I was designing Quest there was some reason why I thought it would be a good idea to have "look at" distinct from "examine". However, I've no idea now why this should be.

Be default, should they both correspond to the same thing in Quest 4.0?

You could set up your own separate commands if you really needed these to be distinct. I just think that most of the time, it's not convenient to have these as two separate commands.

Any thoughts?

I feel 'look' is a general cmd which is best used to survey the whole scene, where as 'examine' is a close/detailed inspection of a object. So if there is a differance then I would have 'look' as a stand alone cmd that gave a discription of the scene (ie the room, and a list of the visable objects). Examine is to inspect an individual object to you could only used the cmd examine followed by an object name.

I personally think examine should default to look <> ... While if examine <> is there - it should display that.
I thought Quest worked that way already?
Another misconception on my part?

That's correct. The question is, do we by default really need a separate "examine" tag?

Well...I see why it is there and in fact, I used to use them a lot. However, after mr David reviewed Get Out of the House, I realized that aside from my own errors and overlooking some things, I also realized that most gamers are going to just examine things without looking at them first.
For instance, he had pointed out a detail that the TV's description simply said "It's a TV...with buttons!" and it did not provide any other detail about it. If a player looks at the TV before examining it, you get a meager joke out of it as follows:

Look at TV:
"It's a TV"

Examine TV:
"It's a TV....with buttons!"

This was just a simple joke where the player examined it (looked more closely), they discovered it was, in fact, a TV with buttons. The buttons had no purpose in the game. (that was one of my overlookings that I need to expound on in the remake/sequel)

So, to answer your question, in my opinion we probably need look and examine to return the same response.

Well, I don't see why it needs to be removed - and infact, as you've said in your other topic Alex, more default verbs..

The only point to remove it would be if it would ONLY output the examine tag.

I think it's quite useful myself;
Say you have a book. Looking at it reveals nothing - it's a plain old dusty book.
Examining it would reveal a part of the cover is ripped away, and a secret letter stashed inside (along with the usual read commands for books).
Or better yet - a clock. Looking at the clock may output a time, while examining it would (maybe) give the make and model of it - how you bought it, etc.

I suppose you could renovate the look tag into non-existance.
Both should be easily replaceable with a command which checks for an object action.

I guess it's all dependant on both;
how gamers use look/examine
how often programmers use them both on the same object.

I personally do a look - and if it looks more interesting, or a simple output is returned, I use examine - as a player.
As a programmer, I'd mostly just use the look tag - seeing as examine defaults to it. Using examine for curious items/more detail.

Anyone else?

As a player, I assume that "look at ____" and "examine ____" are the same. If I get stuck and discover I missed something because I did one instead of the other, I will very likely quit then delete.

And I don't think that adding more verbs is necessarily important; I think it's important to make it easy to add new verbs and keep it consistent.

I think the obvious problem with having "look at" and "examine" mean two different things is that most people expect them to mean the same thing, so there's no reason for them to go and type out both. Aside from that, it's a pain having to "look at" every item in the game and then "examine" every item in the game.

In Tron's example above, why would I need to use two different commands to get the full description of the book? If I "look at" the book, I ought to get the full description of it and not then have to "examine" it as well.

I use both separately myself. It would probably be best that if the 'examine' field is blank it defaults to what is entered for 'look'.

Perhaps an investigation into how the general IF community expects this to be handled is in order. I know several of the 'highly-touted' games I've played implement 'look' for just looking around, 'look at' for passing descriptions of objects, and 'examine' for detailed descriptions of objects.

On the other hand, forging our own path is not that bad of an idea, either. Personally, I think 'look' and 'examine' are redundant (as a pair). If I know that 'examine' is going to yield the better information, I forsake 'look'. Now it is rather obvious that one cannot examine an object from far away, but one can certaintly look at it. So. I don't know.

Being different for the sake of being different (i.e. forging your own path) is never a good idea. Quest doesn't have a good reputation among the rest of the IF community as it is. If it starts moving further away from what the rest of the community expects as a normal, it'll never attract any new users.

Overcat wrote:Perhaps an investigation into how the general IF community expects this to be handled is in order. I know several of the 'highly-touted' games I've played implement 'look' for just looking around, 'look at' for passing descriptions of objects, and 'examine' for detailed descriptions of objects.

Which games? I'm fairly sure that you'd have to do a bit of library hacking (not much, just modify a few lines in grammar.h and add a new VerbSub) to make Inform do that, and I think you'd need to make a deliberate effort to do that in TADS.

I think Cheiron (the hospital sim game) might have done that, but it was not a well-received game overall.

On the other hand, forging our own path is not that bad of an idea, either. Personally, I think 'look' and 'examine' are redundant (as a pair). If I know that 'examine' is going to yield the better information, I forsake 'look'. Now it is rather obvious that one cannot examine an object from far away, but one can certaintly look at it. So. I don't know.

IMO, I'd consider looking at a far away object to be the same as examining it.

Unless you have a good reason for doing so, and specifically mention to players that "look at" and "examine" are different, they should mean the same.

(Example: If you're doing a CSI-type game, I can see how having a number of different actions for examining could be useful. But you should definitely directly tell the player about the different commands.)

See also Graham Nelson's Player's Bill of Rights.

I've played games that ... 'look' for just looking around, 'look at' for passing descriptions of objects, and 'examine' for detailed descriptions of objects.

vs.

Which games? I'm fairly sure that you'd have to do a bit of library hacking (not much, just modify a few lines in grammar.h and add a new VerbSub) to make Inform do that, and I think you'd need to make a deliberate effort to do that in TADS.

You're right - they don't do that. 'look object' results in 'I only understand you as far as wanting to look.'. 'look at object' and 'x object' produce the same results. Thanks for pointing out my error.

If it starts moving further away from what the rest of the community expects as a normal, it'll never attract any new users.

This is true.

I'm not entirely sure, but Unkoolian Unventure (1 or 2) may have had differences in look/examine.
'Look at body' may have returned one thing, while 'examine body' turned up a key inside the jacket.
I think that was an old TADS game.

personally would prefer examine to be the default - and have look just do the examine bit.
I mainly use examine (or x #object#) because I know it's more likely to return the more detailed.

I think the very definition of "look" and "examine" are different.
From dict.com;

look:
   1.
         1. To employ one's sight, especially in a given direction or on a given object: looking out the window; looked at the floor.
         2. To search: We looked all afternoon but could not find it.
   2.
         1. To turn one's glance or gaze: looked to the right.
         2. To turn one's attention; attend: looked to his neglected guitar during vacation; looked at the evidence.
         3. To turn one's expectations: looked to us for a solution.
   3. To seem or appear to be: look morose. See Synonyms at seem.
   4. To face in a specified direction: The cottage looks on the river.

examine:
   1. To observe carefully or critically; inspect: examined the room for clues.
   2. To study or analyze: examine a tissue sample under a microscope; examine the structure of a novel; examine one's own motives.

# To test or check the condition or health of: examine a patient.
# To determine the qualifications, aptitude, or skills of by means of questions or exercises.
# To question formally, as to elicit facts or information; interrogate: examine a witness under oath. See Synonyms at ask

While one is just turning your gaze, the other is to carefully/critically inspect/study/analyse.

Seeing as getting rid of one doesn't really matter, and it can easily be re-implemented with an "examine #object#;x #object#" command (or look in-place of examine) which launches an object action if it exists - or uses the normal look #object# command..
I say get rid of look, and have examine for "when the player examines an object" - which would link verbs like "inspect #,detail #, look #, analyse #" to kick it off.

Making "look at" different from "examine" gets into "Guess The Verb". Imagine if "CLEAN POT WITH BRUSH" gave a response like "You attempt to clean it, but make no progress." where "SCOUR POT WITH BRUSH" succeeded. Personally, I'd take the first failure to mean that I needed another object (possibly soap) instead of trying another verb.

Well that'd be silly.

While I'm saying it'd be different, I'm not saying you souldn't have a clue.

Something like "clean put with brush" may return "you try and clean the pot, but you can't get the harder pieces off... Maybe you need to try a different approach with the brush.".. Although I'd personally use clean as enough.

Similar with the book idea - the look may return "There's a plain red cover on the book.. You notice some symbols on the cover and a lump on the side - perhaps you should examine it more closely.".
And examining it reveals more.

I'm not arguing the point any further, as I believe there is a place for it, and that there's an easy code-around for it.

Oh, and I'm starting to think in UU1, right at the start, you have to search the body - not examine it - to get the key.

I think it's something better left to designers to implement as a command of their own. There is no need to add redundancy to the language, when it can be specified at a creators personal discretion.

Tr0n wrote:Oh, and I'm starting to think in UU1, right at the start, you have to search the body - not examine it - to get the key.

That's poor game design. Is the player expected to go through the game and type "examine object", "look at object" and "search object" for every object in the game?

Well, searching the body is different than looking at it I'm sure you'll agree..

Wouldn't it be really screwy if all you had to do in the game was look at things to do anything?
Searching a dead body is certainly different enough from looking at it to warrent another command.. Although it did piss me off that no clues were given for me to search the body (or even look more closely at it) as it only said "the dead body of your master" and woffled on about him beating you because you were a servant.

Good: When the player learns the solution to a puzzle, thinks "I should have thought of that."

Bad: ... "How could anyone have thought of that?"

Worst: ... "I already tried that and it DIDN'T WORK!"


As for UU, I consider that okay; I view "search" as a different action from "examine", and I view corpses as an object likely to be worth searching.

Also note that UU is rather old (1990), and predates many of the conventions of modern IF.

Tr0n wrote:Well, searching the body is different than looking at it I'm sure you'll agree.

Sure. But it's still a pain having to search, examine and look at every item in the game.

I view "search ____" as being closer to "look in ____", "look under ____" and the like than "look at ____".

I view it as a pain when I "examine" every item in a game, then find out later that I needed to "search" one of them to find a crucial clue.

While deciding when to only use LOOK and when to add detail with EXAMINE is an interesting design decision, I think the current Quest functionality (EXAMINE defaulting to LOOK if not defined) works well.

Sorry to revive dead threads, but I really like having two distinct commands; look and examine. I think it'd be a little boring if you just 'looked' at objects and got all the clues. I like being able to do things like: "You look at the floor. The floorboards glisten in the light." "Upon closer examination, you can see that one of the floorboards look loose. I bet that with the right tool you could probably pry it open."

To me, look and examine are 2 totally different commands.

I agree with ebayfan. I use them in much the same way as he explained. And getting off track, I still want a destroy object thingy. Is it on your to do list yet alex?

When "look" provides a captivating description, then having it as a command enhances a game and lures the reader's mind into wonder and excitement. If "look" is constantly attached to jokes and simple, boring descriptions, such as "it's a yellow clock" or "it's a round clock" or "looks like a clock to me," then it puts the readers mind to sleep. Therefore "look" is the general portrayal of an object, and should be used to entice a reader to examine it.

"Examine" should only be used to detail an object. Serial numbers, panels, inscriptions, characteristics not readibly visible without flipping an object over, etc., should be described with the "examine" command.

To me, the argument seems to be based on two points:
1. Does the player care to take time to "play" the game and be interested in it or is the player just seeking the finish line as soon as possible.
2. Is the programmer interested enough in creating a well-written game fruitful in detail or is the programmer just trying to get the player to the finish line in a hurry.

A text-game's narration should compare to a well-written book. How boring is a book that doesn't provide details.

Keep both commands, but make their drop-down menu option a programmer's choice.