“I’m not talking about a Windows style drop down menu. A clean interface is important.”
It’s certainly important if you’re going to consider that many actions, and I think it would be a challenge to do so. But as mentioned, it really comes down to personal preference; some people prefer clicking on an action from among 30 buttons, while others prefer to just type it in.

“This doesn’t prove that some puzzles require special verbs. The connection is too vague.”
It was a quote, and not intended to prove anything. I’ve seen enough instances where unique verbs were used in creative and effective ways to know that disclosing these verbs would eliminate what some people believe is an important part of playing IF: the sense of discovery that comes with creative problem solving. You’ve made it clear that you believe that problem solving should not involve a thoughtful testing of the verb space. That is your preference, as it is for many individuals. For others, that’s part of the challenge and the fun.

To quote another individual from a couple of years ago, “It’s not an ideal of IF that the player knows the entire set of possible actions, or even the entire set of verbs, although that may well be the ideal of several things which are not IF. Rather, the ideal is that when the player thinks an action should work, then the action should work. Ideally, the player should have an intuitive feel for what is possible and what is not, a feel which develops as he explores and interacts with the game. This offers a much deeper and more engaged participation in the game world than what is possible in the SCUMM system. The player develops insights about the game, discovers how to interact with it. The best such experiences I’ve had in IF would not work if all the possible actions were given up-front.”

Some of us who like IF think this is a virtue. Some people (particularly those who don’t like IF) think it’s a shortcoming. A lot depends on how well crafted the game is. In any case, this is an argument that has existed for some time; there is no one correct side, there is only personal preference.

“A drop-down menu with 30 skills is ill conceived”
I’m not talking about a Windows style drop down menu. A clean interface is important.

“Red herrings can obfuscate the important skills”
Don’t use red herrings. SKILLS should be relevant to at least one puzzle.

“Unique verbs, like magic words, won’t fit”
Start with a closed skill set and expand it. Learn new skills as you go.

“some puzzles require non-obvious actions, and some non-obvious actions require special verbs”
This doesn’t prove that some puzzles require special verbs. The connection is too vague.

“A verb list is a trade-off between full skill disclosure and ability to deduce actions outside the normal range.”
This “normal range” changes according to the gamer’s real life experience. A singer will always want to SING. A thief always try to STEAL. A correct design avoids this stochastic approach by grounding the set of your actions on certainty.

“One doesn’t have to invent methods for conveying possible actions from scratch”
You can forgo the added design time altogether, and focus more effort on game-world manipulation.

“Figuring out what your key interactions are going to be and how to teach them to the player often makes for a much stronger, more focused design.”
True, but you’re talking about informing the gamer HOW to use an interaction mechanism. I’m talking about informing the gamer WHICH interaction mechanisms he has at his disposal.

And I agree with you, valzi. Although some have argued that placing limits on the number of possible actions, with the player aware of them all at all times, makes the game world seem artificial. It comes down to a matter of choice.

You can certainy work around this, by designing your game more intricately and nudging the gamer towards using insight to figure out what skills the “player” has, but that’s added design time with little benefit.

This I disagree with. There’s a lot of IF technique that has developed around ways to nudge the player toward understanding his range of available actions, so it’s not as though one has to completely invent methods from scratch; and on the other hand, figuring out what your key interactions are going to be and teaching them to the player often makes for a much stronger, more focused design.

Lots of games support SING since it’s part of the Inform default library, also meaning more thoughtful authors at least try to customize the message.

A drop-down menu with 30 skills doesn’t come across to me as a particularly well-conceived interface I’d enjoy playing with, particularly if many of them are added just as red herrings.

And you still have the issue of special, unique verbs, like magic words, which wouldn’t necessarily fit a solution like this.

A drop-down menu with a list of 30 skills like that would really be no different than a parser with an avalable “verbs” command, listing all of the possible verbs in a given game. And I would still contend that a verb list — whether from a “verbs” command or a drop-down menu — is a trade-off: the player gets to know all actions available at all times, avoiding any frustrating “guess-the-verb” pseudo-puzzles, but at the expense of the author being unable to devise clever puzzles that require the player to creatively deduce actions outside of the normal range.

As one individual once noted: “IF is, I believe, enriched by the fact that some puzzles require
non-obvious actions, and some non-obvious actions require special verbs.”

I agree, and I think that, in many cases, putting those special verbs in a list (verb list or drop-down menu) can destroy a big part of the fun of these games by eliminating much of the need for analytical thought.

“Would you include SING in a drop-down menu in every location in a graphical game?”
You can create a SKILLS button that allows the player to perform skills (SING, DANCE, GESTURE, CLIMB, SWIM, around 30 such skills). That way each skill is defined as a possibility, and yet hidden among it’s kin.

I’m El Clérigo Urbatain, an IF author and user, Spanish.

I’m quite excited about Vespers 3D so I want to make an interview to you for SPAG and SPAC (spanish webzine about IF). Please contact me when you can and we will talk about the interview, at urbatain at gmail dot com

Thanks a lot and good work!

Urbatain

I think one of the issues is that you are focusing on what you call “skills”; that is, those actions that are available as defined by the background of the protagonist but which are not necesssarily “common” verbs. If the protagonist of a game is a police officer, then it makes little sense to hide the fact that ARREST is a possible verb to use in a situation. I have no particular argument with that. If someone wanted to implement a disclosure system — such as, in IF, a “verbs” command that shows all possible verbs in a game — you could include ARREST in that list. Hiding the fact that the player can use ARREST just creates an unnecessary puzzle that players obviously don’t appreciate.

I do, however, disagree with including a verb list such as this is, and that if you are designing a game that includes a relatively obscure verb (for IF at least) such as ARREST, you can (and should) design the game such that this option is made clear to the player. It should be fairly obvious, or at least logical, that the player can try ARRESTING the individual at a particular point in the game, and it’s really not that difficult to do. Not all authors do this, and not many do it well, but it’s a sign of good authorship talent.

But the issue of concealed verbs and full disclosure extends beyond just the domain of “acknowledged skills,” and I think there are fairly convincing circumstances where full disclosure of possible actions is not always desirable. Including these actions in a verb list, or in a pop-up or drop-down menu, removes much of the analytic part of the game. It can spoil puzzles with options that are logical but that the player hasn’t thought of yet.

Take, for instance, the BREAK verb. In real life, nobody has to disclose to you that you can break all of the different objects around you. But you can certainly devise a game puzzle that relies on the player deducing that he must break a certain object to solve the puzzle. So if you have a system, say in a graphical adventure, where you can click on an object to produce a drop-down menu of verb options to act upon that object, do you include BREAK as an option for every single object in the game? Or do you just include it on the object that needs to be broken in order to solve the puzzle? And by doing that, aren’t you basically giving the puzzle away?

As an example, consider a game that has a note hidden inside of a fancy porcelain statue. The only way to get the note is to break the statue, and you may not provide clues to the presence of the note inside the statue until later in the game. Do you automatically include BREAK in all of the drop-down options for that object, even from the very beginning of the game? If you do, you give away the fact that it needs to be broken, perhaps well before you’ve provided clues to that effect, and the puzzle is ineffective. Unless you provide BREAK as an option for every single breakable object in the game, and that becomes excessive — do you provide every possible verb for every object? If the player responds with, “Well damn, I didn’t even realize I *could* break the statue!”, the point is that it’s not necessarily logical (in real life) to walk into a room and try breaking everything to find out if there are any goodies inside of them. Yet, it’s a “skill” we all have.

In most IF engines, a relatively common command such as BREAK is defined by default, so if an IF game included a full disclosure of verbs, BREAK would appear on it, and this wouldn’t necessarily give away a puzzle such as above — that, to me, is one of the advantages of an IF parser over graphical interfaces. However, what of puzzles that use more obscure verbs, but in a similar fashion? What about STAB? What if a game has designed a puzzle where you are facing an enemy, and your only defense is a pencil in your inventory. In real life, nobody has to tell you that you can STAB somebody with a pencil, but does that mean it becomes an option in the drop-down menu at all times with all NPCs? And if it’s only with the enemy NPC, that really eliminates any of the challenge of the puzzle, doesn’t it?

And then, what about a verb like SING? I can think of only one IF game that has ever implemented a SING command. You could easily imagine a puzzle solved by SINGING in the right place at the right time. Nobody has to disclose to anyone in real life that you can SING. But if you want to devise an IF game that requires the player to deduce that he needs to SING to solve an important puzzle, including SING in the full list of verbs available in the game would certainly go a long way towards giving that away. And how would you do that in a purely graphical game? You can SING just about any time in real life — would you include SING in a pop-up or drop-down menu in every location in a graphical game? That wouldn’t be a very creative puzzle. “But my protagonist is a singer, of course she would think of singing as an option!” a player might respond. But then, that’s the goal of good writing and design — make the player aware of the protagonist’s skills, and let the player deduce when, where, and upon which objects to use those skills.

Then you have the whole subject of magic words. Plenty of games use magic words as solutions to puzzles — granted, they often aren’t the best puzzles, but still — and part of the puzzle involves first, figuring out that there is a magic word and what it is, and second, figuring out where/when/upon which object to use the magic word. If you include the magic word in the full list of verbs, that destroys a big part of the puzzle. But even if you create a system that leaves the magic word out of the list until you discover it in the game, you’re still left with a situation — at least in a graphical game — where you either put the magic word in the drop-down list for every location or object, or only those upon which the word will operate, and that destroys the other part of the puzzle.

This argument extends well beyond “searching for skills”, and make no mistake about it, there is no one solution that works best for every player. You can call this an interface flaw, but there are flaws in every system, including ones that always fully disclose. In my opinion, the critical thing is good puzzle design and good writing. When done well, puzzles like these can be very satisfying. When done poorly, they can suck and make players resentful.

I’ll go into this in more detail in the blog.