Examining, looking at, and searching

Authoring General Design Discussions
1

Lost my old account credentials, so starting from scratch. Nobody knew me anyway.

These are two related commands and one only kinda related, since searching is mostly reserved to containers, but I’ve been wondering as I’m toying around with my various projects: how would you, fellow IF players and authors, like to distinguish between the commands “examine”, “look at” and “search” in a modern parser game? What do you think ought to be obsolete and common practice by today’s standards?
Should look at and examine produce the same result like they so often did in classic text adventures, or should looking give a broader picture whereas examining increases the level of detail? Should you find a hidden piece to the puzzle by simply examining a container, or only by searching it (given that there are clues toward it)?

2

My understanding is that examine, x, and look at are all the same command and are just different aliases. search, look in, and look inside and also aliases of each other. So really it’s two different commands with alternate ways of saying it.

Someone please correct me if I’m wrong.

1 Like
3

Yeah, you’re correct, but I’ve come across different opinions on this, which is why I wanted to ask. My container question still stands, however: is forcing the player to “search” or “look inside” a container to find the hidden item bordering on being too old school—the same way forcing them to open a door before entering is?

4

I think it depends on context. Like if it’s a fish tank, making them look inside to see the fish is pretty dumb. You could maybe have the examine command also append the search output to the end of it, so that search is it’s own thing, but anybody with the ability to see through transparent glass would be looking inside it without even really intending to when they look at it.

A cardboard box with an open top is up to whichever one supports the story best. If you don’t want to force searching on the player, you can treat it in the same manner as the fish tank. Like “There’s a box here. There seems to be a teddy bear in it for some reason.”

However, if you want to make the box dramatic, you could say “It’s a box. The lid is open. Something inside seems to be making the bottom of the box wet…” and then it would give you some horrible description when you manually look inside it.

Alternatively, a box that’s closed and easily openable shouldn’t have the search description added to the examine description, but I feel like the act of searching should also open the box. I personally find it annoying when I have to open something before looking inside it. It should just be automatic. Like if someone asks you to look in a drawer to see if the scissors are in there, you don’t tell them “But the drawer isn’t open.” They’d tell you to stop being stupid and that they obviously meant to open the drawer first.

Anyway, that’s my opinion on it. :slight_smile:

2 Likes
5

That’s the default for Inform 7 (and 6). Other systems differ. I feel like Inform is the only one that makes “search” and “look in” the same action, for example, although I haven’t done a survey.

My memory from ancient days says that it used to be unexceptionable to require “search”, as a distinct action, for any large mess that would take time and effort to sort through. A garbage heap, for example.

But that was in the days when time limits and expendable light sources were kind-of-normal IF fare. In modern times I make EXAMINE and SEARCH work the same in nearly all situations. If I really want to make the player type a separate command for an intensive search, I’d hint it explicitly. “[Type SEARCH HEAP to go through the garbage in painstaking detail.]”

3 Likes
6

Ah. Thanks for clearing it up. Indeed, most of my history of playing IF has been inform games, not infocom or even many TADS games.

But yeah, your garbage heap example kind of supports how I felt about it. Anything that would involve more than squinting to see its contents should require you to search it. But I also understand the desire the streamline and combine the two, which makes it easier on both the developer and player, even if it’s slightly less realistic.

7

I am working in TADS, and as above, ‘examine’ and ‘look at’ are the same. ‘search’ and ‘look in’ are defined as two different verbs in TADS, but I believe the default library behavior is to make one remap to the other. I explicitly informed the player in my instructions that ‘search’ (which I’ve abbreviated to ‘c’) and ‘look in’ will never produce different results. I think that it is reasonable for ‘examine’ and ‘search’ to be considered separately in a parser game… but as some have mentioned, obvious motions can be performed automatically (by Preconditions in TADS).

2 Likes
8

Just as you have to learn the vocabulary of film – e.g. what reverse shots, montages and sets illuminated by blue light mean – before you can understand a movie, so players have to learn the conventions of IF.

The real world is infinitely detailed. The game world, obviously, is not. As well as giving the player information about the game world, the commands relating to vision are also metacommunication, telling the PC the level of modeling that the game has used.

I’ve always understood “look” to be short for “look around” i.e. the player is (unless othewise noted) standing in approximately the center of the room and getting a general impression of the surroundings and its notable features. Rubbernecking, in short.

In I6 (I don’t know about I7) vocab words can be added to the room so that the game recognises them, but the message is “You don’t need to refer to [the vocab word] in this game.” IOW that object isn’t modeled at all. It was probably mostly to save memory, but it’s also useful to stop players getting into a dead end, thinking that "the ichor stained alcove must do something!" when the author only intended it as atmosphere.

“Examine something” means the player is focusing their attention on a particular object, and should return a detailed impression of the object as seen by the naked eye.

Depending on the genre, I’d expect to have to use EXAMINE STAIN WITH MAGNIFYING GLASS or maybe TRICORDER or something equally specialised to get “hidden” information.

A further level of detail can be shown using parts, so:

X TABLE

“It appears to be a sturdy oak table, common in monkish refectories. The legs at one end are heavily scored.”

X LEGS

"Parallel grooves mar the legs, which are also blotched with dark marks to which black hairs are stuck. Your zoological training instantly identifies these as claw marks, probably ursus americanus."

The convention for indicating that there is no further level of detail is to repeat the same message:

X HAIRS

"Parallel grooves mar the legs, which are also blotched with dark marks to which hairs seem to be stuck. Your zoological training instantly identifies these as claw marks, probably ursus americanus."

For me, “searching” indicates that the player is no longer merely observing the object but physically interacting with it: prodding it, tapping it and listening for false panels etc. So this command is reasonable for attaching traps to: the player getting poked by a drugged needle or something. (Though if the game is observing the player’s bill of rights I’d expect a hint beforehand.)

(It’s also useful to have search resolve to a separate command because one of the synonyms for “search” is “look through” (“look through clothes heap” etc. and so it’s a convenient way of coding simple windows.)

Writing IF descriptions is an art form, and so there can be all kinds of subtleties. For example the description “They seem to be a perfectly ordinary set of pilliwinks.” could be a chilling reminder that the PC is a torturer by profession.

But the main thing is to consciously decide what the differences (if any) between commands mean, and to then be consistent about implementing that.

4 Likes
9

I thought you’d never ask. =) This is something I thought a lot about when designing the Dialog standard library.

A major insight was that most players will examine a lot, but won’t search or look inside objects unless they’re explicitly told to look closer. Some players will do it unprompted. Therefore, while story authors can be expected to provide custom examine-text for every object, there is little incentive to modify the default responses to Search and Look In. They can be bland and procedurally generated—except in very special story-specific cases that are clearly signposted.

Now, the role of a standard library is to provide reasonable defaults that story authors can override and reshape to fit a particular situation. I very much agree with @tayruh that the desired behaviour of these commands is context dependent. So the following is intended to function as a sensible baseline, but above all to be malleable.

Look In and friends

In Dialog, objects can be located in, on, under, or behind other objects. Consequently, there are four distinct player commands to LOOK IN/ON/UNDER/BEHIND something. By default, these commands result in a list of objects with the specified relation to the parent object, e.g. LOOK ON FRIDGE might yield “On the fridge is a postcard and a todo list”, with no mention of the food inside the fridge.

Search

Dialog treats Search as a separate action from Look In and friends. The default implementation of search will report any child objects, regardless of preposition. Furthermore, it will report them in roughly the same style as “look preposition”. So for SEARCH FRIDGE, you’d get “On the fridge …” and “In the fridge …” as separate sentences in the same response. If the fridge is closed and opaque, the objects inside the fridge are not reported. If all child objects have the same relation, e.g. “on”, then the default output of SEARCH is indistinguishable from the default output of LOOK ON.

So in practice, in many cases, SEARCH will behave as if it were a synonym of LOOK IN or LOOK ON. Players can surely be expected to make that assumption. Unfortunately, this puts an extra burden on the story writer—one that I think is unavoidable unless we restrict objects to be either containers or supporters, but not both. The burden is that whenever the author overrides the default behaviour of one of these actions, they probably have to override the other as well.

Of course, parser game authors are already used to working hard to cover every possible way of expressing the same intent. Every time they override “show x to y”, they have to think about overriding “give x to y”, and maybe “tell y about x”. But still, being forced to override two rules instead of one is clearly a downside to my approach.

Examine, descriptions, and appearances

Every object has a description, which is shown in response to EXAMINE (for which LOOK AT is a synonym). The story author can easily, on a case-by-case basis, insert code for listing child objects as part of the description. Thus, for instance:

(descr #table)
        It's a large sturdy oak table.
        (list objects #on #table)

might produce:

> X TABLE
It’s a large sturdy oak table. On the table is a bowl of fruit.

Objects may also call attention to themselves with an appearance. For instance: “A service robot whirrs around on the floor, humming to itself.” This gets appended to the description of the parent object, usually a room. But the same mechanism can be used for child objects, like so:

(descr #fridge)
        White and tall.

(appearance #todo #on #fridge)
        A todo-list is stuck to the fridge with a magnet.

Then, if you X FRIDGE, you get:

This happens because the default implementation of Examine invokes both the description of the object itself, and the appearance of each of its children. As always, the story author can override the default implementation, generally and/or in specific cases. Thus, when we explicitly list child objects as part of an object description, it’s prudent to turn off their appearances (in case they have any) to prevent them from being mentioned twice:

(descr #table)
        It's a large sturdy oak table.
        (list of objects #on #table)

~(appearance $ #on #table)

Conclusion

I don’t know… maybe that this is complex? It certainly depends on context. Dialog offers many different ways of overriding the default behaviour, in order to meet the particular demands of each story. But the baseline behaviour must be sensible, since some players will expect these commands to provide reasonable responses, while a good proportion of players don’t even know that they exist.

8 Likes
10

Oh, so in Dialog, an object’s appearance will still get printed even if the parent of an object isn’t a room? Neat! I’ve always regretted that Inform’s “initial appearance” property doesn’t work if the object is, say, “on the rocking chair”.

11

I can see how merging examine and search makes sense, but what if you give the player a nudge toward the right action early in the game? Say, one of the first puzzles has a chest of drawers. Opening the top drawer describes the contents in a superficial way, like “The drawer seems to be mostly full of neatly folded shirts, but you can’t possibly tell what’s underneath without rummaging through them.” Searching the top drawer (or rummaging through shirts or any other possible derivative) then produces the loft ladder pole, a safe key, or whatever.
Then, in a later puzzle, the player has to search or rummage through a pile of papers to find something wedged in-between, without any direct suggestion.
Would you say parser IF has evolved, or should evolve, beyond this sort of inductive reasoning?

12

All great points! “Look at” is a different command from “look”, though. Looking at something, in Inform, defaults to examining it, but I’ve toyed with the idea that looking at something might give the player a more subjective description, in an observing kind of way, whereas examining produces a more objective and detailed description. Maybe a distinguishing factor, at least when it comes to smaller items, could be that looking is just using your eyes, and examining is using your eyes and hands (looking up close, turning over, etc.). It’s more work, obviously, but could make an opportunity for more colourful descriptions without cluttering the game-progressing information.

Also—I’m going on a tangent here about windows since you mentioned them—I’ve wondered if examining a window should return a description of the window, and only looking through the window or looking outside produces its view. Examining a window, or looking at a window seems like a weird thing to do if you want to look through it. Or maybe a compromise would be to do both when examining, and describe only the view when looking through or outside?

1 Like
13

I’ve never tried Dialog (mostly because I’m on Mac, and the fact that I’m not a programmer) but it seems powerful! And yeah, it is a complex matter. Just in this thread, I’ve read several conflicting opinions. Sure, it depends on context, but it would’ve been nice to develop a set of modern IF conventions (entirely free to either follow or disregard, of course) to lay the groundwork for a writer-turned-game-designer. Mostly to prevent unconventional actions required to solve puzzles, and to let authors be creative with prose and game design rather than keep re-inventing the wheel.

14

No matter what you do, you’re going to get users that aren’t familiar enough with parser games to know the conventions. IF shouldn’t be limited only to players that are used to playing them. If they were, we wouldn’t even be having this discussion because we all know that “search” exists.

I think the best thing you can do is what a lot of people do, which is to include a “help” command that introduces people to how a parser game works, including a list of the most common commands. Something like this but in text form. Also list any non-spoilery “guess the verb” commands in there that even regular players maybe wouldn’t guess that you have implemented.

If you do that, then you don’t need to worry about adhering to unspoken laws because you already laid out the framework before the game even started.

Or at least that’s what I think. I don’t write parser IF, so take that with a grain of salt, I guess.

2 Likes
15

This would certainly increase the level of detail and realism of the world model. On the other hand, it might annoy players. Now, instead of examining everything, they have to look at and examine everything.

Most players will instinctively “X” every noun. You might be able to train them to “L” everything first, but I suspect they will forget often, and thus read the detailed description before the superficial description (if they ever see it).

In Robin & Orchid, the player character carries a notebook with extensive information (ramblings) about lots of gameworld objects. I can highly recommend the game, but Emily Short observed that there are two kinds of players: Those who look up everything in the notebook, and those who don’t, and only the first group tends to like the game.

2 Likes
16

re: windows,

Yes, that’s what happens natively in I6 and I7. “x window” gives a description of the window, but “look through window” (->search, internally) gives something like “Broad meadows stretch out in the shadow of the Awesome Tower.” If you’re doing something more complicated, like a murder house mystery, where you have NPCs traveling around, and so say, looking out of the upper bedroom window will let the player see who’s on the Tennis Court, then you can add Tennis court to scope (though you have to remember to disallow taking etc. But then scope hacking is kinda advanced for me!) There’s even code in the recipe book – “Ornamental Gardens” I think. It’s about letting the player look at different parts of said garden from a distance, but should be adaptable to window views.

Re: subjective and objective descriptions, one of the classic Infocom games took this approach. (I’ve clean forgotten the name, but someone on here will know.) Anyhow, you’re the AI on a damaged space station, trying to repair it, and you have three different waldoes that you can use. Each waldo has a different set of senses and capabilities, so the description of the room and objects within varies depending on which waldo you’re currently projecting your awareness into.

Edit: I think the game was Suspended but I could be wrong.

2 Likes