So I figured that I would try my hand at writing a text adventure and got Inform 7.
I understood the basics, created a few rooms, but ran into an issue with how I wanted the door out of the starting room in my test quest to work. It’s a quite simple setup: The door is nailed shut and there is a crowbar in the room, so the crowbar needs to be used on the door to open it.
I can’t for the life of me find how I can get a “use crowbar on door” command to work anywhere in the documentation. I can’t seem to get any “use” command to work, for that matter…
“Use” is not included in the standard library, so if you want such a command in your game you have to create it yourself. Creating new actions is covered in manual chapter 12.7. Basically you need to create the new action and define which commands it responds to, for example:
Using it on is an action applying to two things. Understand "use [something] on [something]" as using it on.
(USE is often considered a non-standard command, so don’t forget to take into account other wordings: pry door with crowbar, open door with crowbar etc.)
But “use” not being a standard command does confuse me a tad, as it’s a command one would expect to use a lot in text games.
It now works with both use and pry, and the relevant code is now this:
[spoiler][code]The Entrance is a room. “You are standing in a nondescript room. A door is on the western wall.”
The wooden door is west of the Entrance and east of the Corridor.
The wooden door is a door.
The wooden door is scenery in the Entrance.
The crowbar is a thing.
The crowbar is in the entrance.
The description of the crowbar is “A standard crowbar.”
Prying is an action applying to one visible thing. Understand “pry [something]” as prying.
Using it on is an action applying to two things. Understand “use [something] on [something]” as using it on.
Check prying wooden door: if the crowbar is not carried then say “With what?” instead.
Check prying wooden door: if the wooden door is open then say “No need to do that again.” instead.
Check using [crowbar] on wooden door: if the crowbar is not carried then say “You don’t have a crowbar.” instead.
Check using [crowbar] on wooden door: if the wooden door is open then say “No need to do that again.” instead.
Report prying a wooden door: say “You pry the door open with the crowbar.”
Report using [crowbar] on wooden door: say “You pry the door open with the crowbar.”
Carry out prying: change the wooden door to open.
Carry out using crowbar on wooden door: change the wooden door to open.
Instead of opening the wooden door: If the door is closed, say “You attempt to open the door, but to no avail. It has been nailed shut.”
[/code][/spoiler]
What I also would like to do is make the player not see the crowbar without first having looked around… but that’s a later question.
“Use” has never come into general… er, general use (sorry) because it’s too… useful. (Wow, that sentence sucks.)
If you implement “use” for one object, the player is really going to expect it to work for every object – why should it only mean some usages? And if you’re writing that game, why would the player use any other verb?
This may sound like pointless cruelty – hiding verbs behind a curtain. Maybe it is. But it’s a general game-design principle that the range of interesting commands should reflect the range of choices. If you’re building a point-and-click game (in which click means “do something”), you design around the objects. If you’re building a game with verbs, you design around the verbs and objects together.
I consider “use” very useful (er…) actually. If implemented correctly. Which means going through every object in the game and making sure it provides a reasonable response for it. I guess that’s a lot of work, and if you can’t do that, then you shouldn’t implement “use” at all.
When is “use” useful? When the use of an object is obvious but non-trivial, and you don’t want the player to resort to guess-the-verb in order to solve a task.
For example, imagine you have a computer in your game. The player is supposed to unlock and open the bank’s safe with it. “use computer” would then bring up a menu with possible actions, or “use computer to open the safe”; this is preferable here compared to trying to explain to the player how to do that using out-of-game messages that explain the verb syntax. Because really, “activate computer” (which probably is what most authors would have done) has nothing to do with using the computer.
Other examples would be:
USE PHONE
Whom do you want to call?
USE NORTH DOOR
[remap to N]
USE FRIDGE
The refrigerator has no obvious use other than placing something inside it.
The last example is what makes this difficult to implement; if you can’t provide these messages for all objects in the game, then better don’t provide “use” at all.
I’ve always considered USE to be too vague to be, uh, useful. For example the crowbar: does USE CROWBAR WITH TABLE mean that you want to move the table with the crowbar, or hit it, or lift it, or put the crowbar on it, or something else? The game could make a guess, but it usually frustrates the player if the game’s guess is different to what the player intended.
One solution that I’ve used (similar to RealNC’s above) is to have USE by default say something like “USE is too vague, please be more specific” but have the game respond to obvious actions appropriately (for example USE DOOR usually means that you want to go through it) or give hints on how to use the object (“You could PRY or HIT something with the crowbar.”)
Just a quick comment on the code: These lines don’t work as intended. If you use square brackets outside strings, they’re considered a comment which is ignored by the parser. So Check using [crowbar] on wooden door is considered as Check using on wooden door, which in turn means that any object triggers these rules (try picking up the crowbar and then USE YOURSELF ON DOOR or USE DOOR ON DOOR.) Just remove the square brackets to fix this.
Ah, gotcha. I think I added those when it gave me errors, but it must have been wording elsewhere that caused said problems.
And, yeah, I understand how “use” isn’t a specific enough command, but it’s the kind of command one would assume anyone would try when playing a text adventure.
Well, most of my quest is working now. Left to do is figure out how to a) make a device in one room enable access to other device in another room, b) make said other device unlock a door in yet another room, and c) make exiting through said door into the winning condition of the game. Then I shall share my game with you to laugh at my newbie code! But we all have to start somewhere!
I’m guessing you haven’t played much IF, so I’d like to suggest that you play a bunch of games, and then see if you still feel the same way.
I’m not saying that your point of view is invalid (even though I disagree with it), and sometimes conventions should be challenged, but becoming familiar with the conventions is usually a good idea before heading off in another direction. That way the decision to head off into another direction is an informed one.
Are you trained on graphical adventure games, btw? This makes me recall Dave Gilbert’s experience on how new users didn’t think to “use the crowbar on the door”. Something he, and every seasoned (graphical) adventure gamer thought was obvious.
Edit once more: Just keep in mind that seasoned players of IF will probably not consider to use “use” so don’t forget to allow “open door with crowbar” and other variations as well as “use”. Unless you design the game around the “use” verb and let the player know that clearly.
I have indeed not played many text-based adventure games. Haven’t played any Inform ones at all. Point&click games like Monkey Island have been favourites of mine, however.
But, I mean, I totally understand how certain commands that you might be used to from adventure games just won’t work in the Inform engine. And so one wanting to design a game with is needs to take it into account.
I weren’t ever planning to write any long, involved games where there could be a dozen different valid commands to take into account, mostly some short scenarios related to a story me and some friends are making. Seasoned IF players will not be in my target audience there. And the game I’m writing with the help of this topic right is just my “Mess around with Inform 7 to understand the program”. Thanks to everyone that has helped me, by the way. I’m starting to get the hang of this (yeah, right). Just need to read up on how devices work.
Ohh, I like this. I wonder if you could even have something autogenerate from what each object’s defined interfering (Before/Instead/After) rules. Or have a Table of Notable Verbs matching verbs with interesting effects to various objects.
Something like, “Well, there sure are a lot of things a crowbar can do! Do you want to SMASH the door, PRY the door, SLIDE the crowbar under the door, try to UNLOCK the door with the crowbar (unlikely to work!) or what?” would be friendly to newbs (or those more familiar with clickable graphic adventures) while pointing out the reason why we have the “unlikely to recognize USE” convention in the first place.
