Using “use” (rather proud of myself)

I know that supporting the verb “to use” is frowned upon, but in multiple “home testing” it is quite apparent that IF users, especially the less hardcore ones, do like using it.

The obvious problem with the verb “to use” is how generic it is. It could be anything. So for this story I’m writing to learn about Inform7 I had the idea to just make it map to the corresponding actions, when known, while hinting to the user about what the actual action was, in hope that they’d use the correct verb afterwards.

As it turns out, remapping actions is … less trivial than I would have originally imagined, especially if we want to preserve rulebook outcomes (which is what I want; and yes I have gone through the forum and I am aware of the fact that these outcomes are not important story-wise —except when they are).

Yes, you can do a try the other thing in the Carry out rules, but outcomes are easily lost. Yet the standard rules definitely do these kind of things (e.g. remapping giving to taking or a number of other things), so I went to the source and discovered that there is an actual convert (I think this is very briefly mentioned in the guides, but not in much detail). After some (OK, a lot) of tinkering, I’ve managed to come up with a working solution, which I want to share with you, It’s very skeletal (covers only the actions I care for my story) and should at the very least be expanded to allow generic actors, but I feel like it’s a decent starting point. Has something like that been done by others?

Using is an action applying to one visible thing.
Using it with is an action applying to two visible things.

Understand "use [a thing]" as using.
Understand "use [a thing] on/with [a thing]" as using it with.

[ Using ]

The using action has an action name called the converted using action.

Rule for setting action variables for using (this is the using action variables rule):
	now the converted using action is the using action.

Check using (this is the turn devices on rule):
	if the noun is a device:
		say "(switching on [the noun])[command clarification break]";
		now the converted using action is the switching on action.

Check using (this is the pass through door rule):
	if the noun is a door:
		say "(going through [the noun])[command clarification break]";
		now the converted using action is the going action.

Carry out using (this is the using fallback rule):
	if the converted using action is the using action:
		say "What do you want me to do with [the noun]?";
		stop the action;
	otherwise:
		convert to the converted using action on the noun.

[ Using it with ]

[ Lesson learned: the variable names are global, but their initialization is not:
  if we call the action name 'converted action' both here and in the using action,
  we get uninitialized variables warnings at runtime even if the code works.]

The using it with action has an action name called the converted using-it-with action.
The using it with action has an object called the direct object.
The using it with action has an object called the indirect object.

Rule for setting action variables for using something with (this is the using it with action variables rule):
	now the converted using-it-with action is the using it with action;
	now the direct object is the noun;
	now the indirect object is the second noun;

Check using something with (this is the use a key to unlock a door rule):
	if direct object is a key and the indirect object is a door:
		[ To swap the direct/indirect object we'd only need one temp variable, but we use two for expressivity ]
		let the used key be the direct object;
		let the used door be the indirect object;
		if the used door is lockable:
			now the direct object is the used door;
			now the indirect object is the used key;
			if the used door is locked:
				say "(unlocking [the used door] with [the used key])[command clarification break]";
				now the converted using-it-with action is the unlocking it with action;
			otherwise:
				say "(locking [the used door] with [the used key])[command clarification break]";
				now the converted using-it-with action is the locking it with action;

Check using something with (this is the maybe inserting into rule):
	if the second noun is a container:
		say "Did you mean to put [regarding the noun][them] in?";
		if the player consents:
			say "(inserting [the direct object] into [the indirect object])[command clarification break]";
			now the converted using-it-with action is the inserting it into action.

Carry out using something with (this is the using it with fallback rule):
	if the converted using-it-with action is the using it with action:
		say "I don't know how to use those things together.";
		stop the action;
	otherwise:
		convert to request of the player to perform converted using-it-with action with the direct object and the indirect object.

12 Likes

Very nice!

The only time I’ve seen “use” as a default command is in Quest. We can add a use attribute to an object to handle it. If the object isn’t set up to handle it, then Quest just prints something like “You have to be more specific.”

Checking if the object is a device, container, etc. before printing that default “can’t do that” text is a great idea.

3 Likes

This does look interesting. The way I started implementing “use” was simply by writing very specific grammar rules, for example:

Understand "use [a switched off thing]" as turning it off.
Understand "use [a switched on thing]" as turning it on.
Understand "use [a locked door]" as unlocking keylessly.
Understand "use [a closed door]" as opening.
Understand "use [an open door]" as entering.

And so on.

But, that probably has some limitations, so it’s possible your approach may be better sometimes.

4 Likes

I implemented “use” in several of my parser games. Possibly all of them, or almost. Like you said, people less familiar with text adventures will try it, and you know what? They’re right. Besides, many items in the real world do have an obvious default usage, especially in a given context. What exactly are you going to do with a broom on a floor? A key on a door? Might as well have “use” as an option. Doubly so if the exact verb you’re thinking of isn’t so obvious.

Parser IF conventions are not obvious or intuitive, nor widely known outside the hobby. Notice how graphic adventures evolved from having a full-blown parser to basically having only use as a verb (you pretty much even “use” an exit to move about), and it proved to be plenty enough.

3 Likes

Oh this is actually a pretty good idea. It’s way more compact and requires considerably less code than my solution so now I’m kicking myself for not thinking about it 8-D. I guess you also end up the chain with some generic grammar rule to give negative feedback? Or do you just let the parser handle that?

I assume there are historical reasons why the IF command line conventions are what they are. Simpler / more compact to have one dispatch table at parsing time rather than one for parsing and then another one to handle the complexities of the multiple meanings of “use”, when every byte counted —which is something that more recent software in general, and graphic adventures in particular, were freed from.

1 Like

I suppose that could be handled by “understand as a mistake” rules? I don’t think I actually got as far as doing that though.

You can come at this from a lot of angles, and there is no one right answer.

But the general tack which I think is useful to think about is:

  • If a game can be 80% played with USE, it’s just a bad design. Players will rapidly learn to type USE for every action, and then they’ll run into the one puzzle which requires a different verb, and they will complain about it. Correctly. Don’t swap in a whole new UI model late in the game.

  • If a game can 100% be played with USE, you might as well get rid of the other verbs entirely. Most players will never notice them – see above. You’re essentially writing a whole second UI layer to cater to a niche audience. Extra work, more space for bugs (which may go unreported for a long time). Also, if there’s only one verb, there’s no reason for players to type it – that’s busywork. Let them focus on the important parts of the command.

This is the design slope that led from parser-style games with optional on-screen menus (Spellcasting 101) to graphical “verb wheels” (I forget the good example here), and then reduced the number of verbs on the wheel from eight (Monkey Island 1) to three or two (EXAMINE/USE/TALK) to one-click Myst-style interfaces.

5 Likes

Hah, that wasn’t on purpose.

Funnily enough, Monkey Island 1 started out with twelve verbs:

Later versions reduced it to nine:

4 Likes

And that’s why I moved to making choice-based games. Sure enough, they were so much better received.

2 Likes

When I was working on a hyperlinks-only Inform game, I created an “interacting” action that subbed in for a number of common verbs: open, close, push, pull, touch, rub, etc and a “using” action for actions with a second noun. That all worked pretty well!

I shelved the project because I was in over my head with the interface stuff. Maybe I’ll dust it off one day.

3 Likes

Obviously the kind of interface one is working with has a profound effect on how interactions are managed. Graphical adventures evolved from something pretty close to a direct transposition of the textual interactive fictions (including the variety of action verbs) to an interface that completely subverts the paradigm (from “verb + object” to “object → verb”), and that gives them the possibility not only to minimize the number of verbs, but also to customize their appearance and variety to account for object specificity, even to the extreme of having verbs that only exist for a single specific object in a single specific gameplay moment.

This doesn’t make the interface choice necessarily more intuitive or “natural” to everybody who is going to play the game though. To account for that, for example, Deponia has a kind of introductory tutorial to familiarize the user with the interface.

The more classic form of interactive fiction has a problem here: since the user input is basically free text, it needs to adapt to the intricacies of natural language processing, which is orders of magnitude more complex than visual interaction. And if classic commercial games could afford (and players expect) a printed manual to accompany the game and explain how it worked, modern online games do not have this luxury. So while The Hobbit for the ZX Spectrum could explain in its manual how INGLISH (yes, that’s what the parsable language was called) worked, what was acceptable and what not < The Hobbit Manual (GB) : Melbourne House Software : Free Download, Borrow, and Streaming : Internet Archive > (and what was acceptable was truly impressive), this is not common anymore (for a number of reasons, both good and less good).

I believe that one principle that the language parser in classic IF should strive to follow is the principle of least surprise. This means, among other things, that if the user input has a contextually sensible meaning, it should be accepted, if possible. Of course the complexity of NLP makes this extremely hard in the general case, but at least low hanging fruits, especially ones that are commonly picked, should be picked.

I wouldn’t posit the (philosophical) matter in terms of which percentage of the game can be completed with just the verb USE, or even on the “why even have other verbs”, but rather: is it more surprising for the user to be able to use USE, or to not be able to do it?

I have my doubts that a user who finds out they can use USE will just use USE for everything, because that’s not how people describe actions, and Interactive Fiction encourages users to do just that: describe the action.

Nobody USEs a BOOK, they either READ it, or PROP the CHAIR with it, in which case it might make sense to accept to USE BOOK WITH CHAIR, if one wants to be tolerant. But they could definitely USE a TOILET as an alternative to SITting on it (in fact, the former would generally be more specific than the latter, since it implies that you intend to GO, too, with a meaning different from the usual meaning of the verb), and the USE‌ of a KEY on/with a DOOR might come to them more naturally than UNLOCKing the DOOR with the KEY —and it’s perfectly good design to allow both descriptions of the action to achieve the expected result.

So even if a game is 100% completable using just USE, it still makes sense to include other verbs if the users may use them, and an 80% USE-able game will only end up surprising the user if that remaining 20% of actions could be described as USing something but they weren’t (i.e. would the user expect the verb to describe the action?). That’s how I see it.

On the other hand, from an educational perspective, I agree that it’s better to teach users about the existence of other verbs, which is why in my solution when an USE action is understood is to add a clarification remark about what is actually being done, so that the user can learn about the “proper” verb, and the simple help system I’ve built into the game doesn’t even mention USE at all since all actions allowed in game can be described by more appropriate verbs. But I don’t think that’s reason to reject USE.

4 Likes

Thank you! People are not lazy and stupid as a general rule, and failing to educate them (on the grounds of that cynical assumption) is a self-fulfilling prophecy. They just need all the help they can get. We all do sometimes. It’s the curb-cut effect at work.

1 Like

Think in terms of a player who has never encountered IF, and USE is the first command they learn.

1 Like

In my (limited) experience the more frequent issues are (1) users spelling out every sentence thoroughly (UNLOCK THE CELLAR DOOR WITH THE CELLAR KEY) so that if anything you’d want them to learn about shortcuts, and at the other extreme (2) user not able to think of the right verb to use in a specific situation (the UNLOCK example wasn’t pulled out of thin air).

Users assuming USE is the only verb because it’s the first they try is the only thing I haven’t actually come across. That being said, that’s were the educational component comes in: in absence of a manual, a more or less comprehensive help system hinted at right from the start

Help me complete my task, by telling me what to do. And maybe I can HELP you
help me.

(HELP in bold, where allowed), and something like my indication of what the USE is doing.

>use door
(going through the cellar door)
(first opening the cellar door)
It seems to be locked.

I’m not saying it’s ideal, but in my experience it seems to solve more problems than it creates.

1 Like

In this case, supporting more synonyms (maybe also including USE) can be a help for non-native English speakers too.

2 Likes

I like the verb USE as a player, but as an author I concluded that I would only allow it for the most commonly understood applications. For example, using a light switch could only mean turning it on or off. Of course, the game would reply with the actual verb taking place to be explicit. However, I really like the idea of multi-use items so that uncommon applications have to be specifically stated by the player. The game would assume the common use only and because the game would explicitly say how it interpreted USE (and potentially failed at solving the puzzle) the player would be left to try a different, more explicit approach.

Monkey Island did a few things that were unanticipated, but still rewarded the player. I think parser players want to be the clever ones, and not feel like the author is holding their hand.

I like the idea of a parser game assuming “USE POTION” means to drink it, but I’d also like the ability to “POUR POTION ON SOMETHING” as well. Just don’t make me “UNCORK POTION” first or I will throw a tantrum. :wink:

3 Likes