Look vs Examine (in parser games)

[arj0n]

As my parser game is being tested, something I knew that could be a problem popped up indeed:

Look vs. Examine

In my game Look is not the same as Examine. I thought this to be a well thought out and an OK design choice but yet it might not be that case...
So I looked into this again, search the web to see what others think and therefor I'm posting the question here too:

What do you think: should Look and Examine be the same, or should Look and Examine be different?


Here's some thoughts:

LOOK and EXAMINE should be the same because:

• players often assume that "look at " and "examine" are the same
• most gamers are going to just examine things right-away without looking at them first
• players prefer you give all (detailed) info, or reveal something, right-away when using examine or look instead of look for general info and examine for detailed info/revealing stuff./li]
  

LOOK and EXAMINE should be different because:

• it's nice to give more detailed info, or to reveal something, when using examine, look should only give a generic description. Look is the general portrayal of an object, and should be used to entice a reader to examine it, while Examine should only be used to detail an object (serial numbers, panels, inscriptions, etc.)

So what do you think?

[Laura Hunt]

If memory serves me right, in most of the text adventures I remember playing (e.g., The Hobbit) you could simply type LOOK without any arguments, and you would get a quick description of the room and its items ("You are in a humid cell. You can see: a closed DOOR. A wooden TABLE and some stale BREAD on it. An empty BUCKET by the door"), and then LOOK or EXAMINE a specific object would return a more detailed description ("The piece of bread is hollowed out. There is a KEY inside", and this would update the general room LOOK command to list the newly found key). I think this is a very elegant solution, personally!

[arj0n]

Yes, that's another way to implement.

In my case, look is the exact same as (a synonym for) 'look around' and 'look room'.
Look <char/object/item> gives a generic description of the char/object/item
Examine <char/object/item> gives a specific in-depth description of the char/object/item, which resembles inspecting/(re)searching the char/object/item

Example:



   
   
   
   

command	same as	response
look	look room / look around	You are at the northern end of the catacombs.
look wall		The wall is old and moisty.
examine wall	inspect wall / investigate wall / research wall / search wall	One stone in the wall is a bit loose.

[Click'd]

There's a reason these games went out of style.

Have you tried LOOKING AT or EXAMINING the "Snail Trek" games, a recent entry to the genre? I don't remember how they handled it but their goal was to make the experience as painless as possible, or something.

[arj0n]

Yes, I've played  Snail Quest and Void Quest, the latter I really enjoyed.
But IIRC he made a fully custom "smart" parser, having auto-suggest and auto-correct and being context sensitive to the player’s current location.

[Crimson Wizard]

I'd ask why do you need to separate quick description and full description, is there a reason to do that? Why would player want to *not* get a full available description? Why there's a need to force player to type two commands all the time making sure that they don't miss anything?

If there's no reason, then typing LOOK ITEM should be equivalent to EXAMINE ITEM. While LOOK could still work as LOOK AROUND.

The only use-case of separate look and examine that I could imagine so far is a situation where examining an item can trigger a side-effect. For instance, looking at mirror will make character see a common mirror, but examining a mirror closely makes a ghost appear. But then, perhaps in such case "examine mirror" may be replaced with "interact mirror".

[Click'd]

To get a little more on topic, I don't mind fluff or flavour text if it's just one click away. With a text parser I'd want little effort to get what I need to know. So, tell me everything at once.

[mkennedy]

What about including an option for the player so they can decide whether look and examine should give the same output? But if they do produce different  outputs you should definitely tell the player that.
Another possible solution would be to have look and examine both give the long description and then have a 'glance' command that gives a short description. Of course this would only be needed if you bother adding short descriptions in the first place.

[Cassiebsg]

Technically, I see what you mean about "look" and "examine"... if one looks at something it's normally hands off and might be from a distance. While "examine" would require to come rather close, maybe even pickup an object (if it can be picked up) and rotate it and check every inch of it. In a wall or a desk, that you can't pick up, you would probably run your fingers along the surfaces trying to determine if you could feel some anomaly. Personally I like this, but yes, make sure the player knows the difference, and maybe only allow examine after looking? Don't know. 

That said, thru the years of adventuring we've been "taught" to look and that look will give you all the info you need (though sometimes a clue that you need to look again to get more info). Parser games and text adventures I didn't play that many and those memories are took long away to help me do comparisons. But the only game I remember having something similar (and it was just using the look command) and LLSL and SQ1, that require you to come close or to a specific place to get a more detailed description (and people seem to hate this mechanics).

[Crimson Wizard]

I guess, if that's the purpose, one could design a game intentionally as obnoxious as possible.

> EXAMINE ITEM
* you are not close enough
> WALK TO ITEM
* there's a chair in the way
> MOVE CHAIR
* you are not close enough
> WALK TO CHAIR
* you are standing near CHAIR
> MOVE CHAIR
* where should I move the CHAIR to?
> MOVE CHAIR ASIDE
* which side should I move CHAIR to?
> KICK CHAIR!!!
* you kicked chair and hurt your leg
> WALK TO ITEM
* you cannot walk, your leg is hurt
> CRAWL TO ITEM
* you tried crawling but got exhausted

[Cassiebsg]

 
Making a game where the objective is going from one end of the room to the other, like a new blind person... one could probably make this little task take a couple days game play that way. 

This reminds me of PQ, where I stop the drunk driver and know exactly what to do, but no matter what I typed it didn't worked: use test, give test, take test, use DUI test, look test... etc etc etc... took me 2 years to get past that "puzzle" (finally got a walkthrough) ... turns out "administer test" was the magic words  I was really mad! (but at least I never forgot the solution and the word!  )

[Stupot]

For me, these days, I’d rather just have a ‘look’ button that does all the work. But if you’re going to have separate ‘look’ and ‘examine’ buttons then they should perform very clearly different functions from the first room. Make it clear to the player that ‘look’ is for the character to simply describe what he sees from his current position, whereas ‘examine’ involves the character taking a closer inspection of the item that would involve lifting it up, rotating it, taking the lid off, peeling back the label, reading the fine print, etc. If these two functions are not completely seperate then you might as well just have one ‘look’ option.

[cat]

This reminds me of a Ben Jordan game where you had different interactions for "talk" and "interrogate" or something, which seemed pretty pointless.

Why should I bother to type "look" when "examine" gives me the full response anyway?

[heltenjon]

The problem probably is, as mentioned above, that us dinosaurs who played text adventures in the early days are used to using look/examine in the same manner. L was commonly a valid abbreviation. It's entirely possible to make these two verbs perform a different action, but there ought to be a point to it. If one gives more details, why shouldn't the player always use that one?

There have been several attempts at doing this differently. Melbourne House's "Sherlock" allowed the player to "closely examine", IIRC. Several games have used the verb "Search" as another action than examining, usually meaning a hunt for objects. Infocom sometimes had different reactions to examine/look at or the other senses, like smell, feel, listen to or taste. And of course, there is the famous "look under bed" command.

I, for one, am more partial to having the text parser understand several ways of saying the same command rather than hunting the verb. Generally.

One solution is to make "examine" or "scan" take more time or resources than simply looking. That way, the player has to choose what to examine. But in a standard fixed storyline with save options, this puzzle type doesn't really work.

[Danvzare]

• players often assume that "look at " and "examine" are the same

Nuff said.
Text adventure games are already relying on a lot of assumptions. Such as what actions are available, that the player knows what that clump of pixels is supposed to represent, and how to spell correctly. If you wanted a separate "look at" and "examine" actions, you'd have to make it clear somehow. And text parsers aren't about making available commands clear.

But personally, when I want the character to look at something, I want them to give me detailed information about it. That's why I looked at it in the first place.
I can already tell that it's a coin! I want to know if there's something special about the coin!
I already know there are books on the bookshelf, I want to know if any of them are interesting!
I can see it's a well! I want to know if there's anything inside it!
You get the idea.

At the end of the day though, do what you prefer. If you go for two separate commands though, at least tell the player at the start. Throw in a little tutorial puzzle which requires you to use it, while you're at it.