Alternatives to verbs in UI of adventure games

[DZ-Jay]

@seguso

@DZ-Jay

I see what you are saying. However, both of those are symptoms of the same problem: bad design.

Yes. But let me be more precise: it is bad UI design. Not bad puzzle design. This is important. Because it reveals that the UI matters. And it’s silly to redesign the puzzle when in fact what you have is a UI problem. So this is why I feel the objections “redesign the puzzle instead” are misplaced. Here we are clearly in the presence of a flaw in the UI, not in the puzzle.

I don’t think one follows from the other. It could be both, it could be one or the other. It depends on the specific puzzle and interface in question.

This is part of what I meant by looking for a “silver-bullet”: there isn’t necessarily one single answer that will reveal the problem in every single case, where you can say, “Aha! Avoid doing this one thing and the game will be perfect.” This is where the art and craft of the designer comes into play.

@seguso

@DZ-Jay

You could provide a simple instruction guide,

I totally agree that if the user knows that he is supposed to think first, instead of clicking mechanically, the problem does not exist.

But the question is: how can we make this information reach the user?

First of all, you must start with the premise that the player will engage his brain and not click mechanically. Ignoring this is, to me, the most significant flaw in your previous reasoning.

Think about that: Do you really think that a player goes to the store and says, “yay! A new adventure game! I can’t wait to go home, turn off my brain, and start clicking randomly at stuff for the rest of the week to see what happens! Woo-hoo!”

Or do you think it is more reasonable to expect the player to say, “A new adventure game! I can’t wait to check out the puzzles and the story, I hope they are interesting and fulfilling!”

If you start with that premise and trust your player to not be an idiot or a pr*ck, then guiding him into the right way of doing things should be easy: the player is already predisposed to follow your lead.

I can’t say this enough: the player is predisposed to think and to act in a manner that is consistent with his understanding of the world. You know, where Eyes “see” and Hands “touch” and “grab,” etc.

This is the starting point of every game. What happens after that is up to the designer.

@seguso

Now, you are suggesting: write this in the instruction manual. Well, if we could be sure the user has got the manual, and they read it, I agree there would be no problem. But sorry if I tell you this assumes too much.

I am not suggesting any such thing. I was merely stating that there are myriad ways in which to convey this. Tutorials, manuals, hints, etc. If your mechanics are complex enough (and sometimes they must be), then even a simple “Starter Room” that guides the player into solving his very first puzzle.

Or when all else fails, just tell the user: if the player took too long to open a door pause the game and pop-up a message: “Why don’t you try the ‘Hand’ over the door to open it?” Done.

None of this is to suggest that they are good solutions, only that they are possible solutions to the problem of conveying the mechanics to the player.

However, I submit that you are over-thinking it. The player is already predisposed to follow your guide, and he already knows how the REAL world works (and even how CARTOON worlds work, etc.). So, as long as you remain consistent with that logic, he is bound to first try the things that make sense to him.

@seguso

As I have come to believe during this thread, a much better solution is the following: at the root of the problem is that we are trying to find a bunch of verbs (or icons like hand-mouth-ear ) that are good for everything. But there can’t be a bunch of verbs that can express everything well. So the solution IMHO is: each class of objects must have their own set of verbs. Then, when the user plays, his thought process will be like this:

here is what we can do on trees: climb, look, shake, hide behind.

here is what we can do on windows: open, close, walk through, break;

and so on.

So there is an initial phase where you are communicating to the user the “rules of the game”, so to speak. And after he knows all this, he starts thinking and solving puzzles, within the clear boundaries you have set.

Fair enough, that is one way to do this. However, I still submit that limiting the vocabulary is not a bad thing. Not being able to “express everything well” is not necessarily a problem, it could be a feature.

Let me explain. I have played and enjoyed games in which none of the puzzles required me to climb a tree or jump out of a window. I say that these actions are not absolutely necessary for a puzzle to be interesting and challenging.

If the vocabulary of my game precludes such actions, it just means that I cannot have such puzzles. You could view this as a limitation (and indeed it is), but you could also view it as an opportunity to focus your effort in all the other types of puzzles that the vocabulary does support.

In Thimbleweed Park, for example, I cannot fly. My playable character cannot transform into another being, and there is no shovel for me to dig in the cemetery. Does this make Thimbleweed Park a bad game because it cannot do some actions that other games can? I don’t think so.

By the same token, in Thimbleweed Park I use the same “Use” verb for activating a microwave, making a photocopy of a map, and dialing the telephone. Does this mean that Thimbleweed Park is a lesser game because it does not let me employ a “Turn On” or “Copy” or “Dial” verb explicit for each action? I do not think so.

-dZ.

[Someone]

@seguso

Yes. But let me be more precise: it is bad UI design. Not bad puzzle design.

The UI and the puzzles are connected. They depend on each other.

@seguso

I totally agree that if the user knows that he is supposed to think first, instead of clicking mechanically, the problem does not exist.

But the question is: how can we make this information reach the user?

Most games …

@seguso

So there is an initial phase where you are communicating to the user the “rules of the game”, so to speak.

… introduce the UI to the user in the first few rooms and with easy puzzles.

/edit: DZ-Jay was faster.

[Someone]

@DZ-Jay

However, I still submit that limiting the vocabulary is not a bad thing.

I would go further and say: That’s necessary. If you give the player too much freedom, he gets lost in your world, not knowing what to do next. There are “walking simulators” where you don’t know what to do and (more important) what you could do. This could be very frustrating for the player.

[seguso]

@Someone

I would go further and say: That’s necessary. If you give the player too much freedom, he gets lost in your world,

Let me point out that my solution is actually better in that regard. Because you cannot combine any object with any other, as you can with most existing adventure games. In scumm, you can combine any pair of inventory objects (e.g. use bottle with invoice). And you can give anything to anyone. In my proposed UI, you click the bottle, and you see: open, drink, break, give.

So you can’t use it with the invoice.

And not all objects will have “give”. The bottle has it, because the puzzle is that you must give it to someone. But some other object class will not have “give”.

So, it seems to me you believe that my proposed UI would give too much freedom, whereas it allows to give just enough freedom not to give away puzzles, but no more than that.

[Someone]

@seguso

Let me point out that my solution is actually better in that regard. Because you cannot combine any object with any other, as you can with most existing adventure games.

But that could be fun. I recommend to play Edna & Harvey: The Breakout (Edna & Harvey: The Breakout - Wikipedia). You can combine nearly everything and you get at least a funny comment.

But yes, as I said, you shouldn’t open your game too much. But …

@seguso

And not all objects will have “give”.

… you shouldn’t limit the player too much either.

@seguso

The bottle has it, because the puzzle is that you must give it to someone.

In this particular case you give the player the solution. He thinks: “Ah, I can give the bottle to someone, so I have to give it to someone”.

I really like your idea with the object classes. But again, it depends on the puzzles and the story if that works.

[seguso]

@Someone

“Ah, I can give the bottle to someone, so I have to give it to someone”.

…no, because 1) the puzzle is to understand which bottle to give, and to whom; 2) bottles won’t be the only class that will have “give”. Other classes that you don’t need to give will have “give”. The point is that you as a designer are not forced to allow “give” everywhere. (as in scumm.) That’s the whole point. You can fine-tune it as you want. It allows you to find the right compromise between not giving away puzzles and not giving too much freedom.

[seguso]

@Someone

it depends on the puzzles and the story if that works.

Yes, and that’s why this morning I asked: what kinds of puzzles do we lose? And are these puzzles that we want to preserve?

The answer is that we only lose those puzzles that 1) involve a unique object, i.e. an object that is the only one in its class in the whole game; and 2) such that the puzzle is to understand what verb to use on that unique object.

Now, at first glance, these don’t seem to me puzzles that you would want to keep. I am interested in concrete examples of puzzles of this kind that are “good”.

[seguso]

@DZ-Jay

If the vocabulary of my game precludes such actions, it just means that I cannot have such puzzles. You could view this as a limitation (and indeed it is),

I understand you can still create a good game without such puzzles. And I understand that you can sometimes redesign puzzles in order to work with a given UI.

But… I can accept to have to redesign a puzzle only if the puzzle is “bad”. But if the puzzle is “good”, I can’t accept to have to redesign it just because the UI does not allow me to express it properly.

[DZ-Jay]

@seguso

@DZ-Jay

If the vocabulary of my game precludes such actions, it just means that I cannot have such puzzles. You could view this as a limitation (and indeed it is),

I understand you can still create a good game without such puzzles. And I understand that you can sometimes redesign puzzles in order to work with a given UI.

But… I can accept to have to redesign a puzzle only if the puzzle is “bad”. But if the puzzle is “good”, I can’t accept to have to redesign it just because the UI does not allow me to express it properly.

I think you misunderstand. The puzzles flow from the expressivity of the language. Just like poetry and literature. And just like those art forms, if a puzzle does not achieve its goal (that of challenging and entertaining the player in a fun and fair manner), then it is bad, no matter what language or vocabulary you use.

Let me give you a practical example: you can’t say English is better than Spanish because the former has a richer vocabulary borrowed from a lot of other languages and the latter had been artificially constrained for centuries by the Royal Spanish Academy. Because the very limitations that the Royal Spanish Academy imposed on the language throughout its formative years is precisely the reason that Spanish poets and novelists ventured outside simple words to express the human condition.

Where an English poet would choose from a hundred words to describe the beauty of a lady’s hair, a Spanish poet had to resort to rich and complex metaphors and similes in order to convey hyperbolic feelings; for instance, comparing the impact of looking at its shine to the brilliance of the sun. This is by no means a bad thing.

It is definitely different, but these differences is what makes each language their own. So it is with adventure games: one approach is not necessarily better than another: as long as it is fun and fair, and interesting to the player.

-dZ.

[seguso]

Are you saying that bad languages cannot exist?

If a language is not good for my purpose, can’t I say “it’s a bad language for my purpose”?

[DZ-Jay]

@seguso

Are you saying that bad languages cannot exist?

Not at all. What I am saying is that languages with different limitations from other languages are not necessarily bad due to those limitations. In other words, to say “more is always better” is not correct.

@seguso

If a language is not good for my purpose, can’t I say “it’s a bad language for my purpose”?

That is a very valid point and goes with what I am saying: You must define a vocabulary that fits the style of game you are making and the puzzles you want to design. The two (puzzles and vocabulary) go hand in hand, and grow organically and naturally to support each other.

However, this means that you have to be concrete in your design: apply the language and puzzles that fit your particular game. What you are trying to do here is “generalizing” this to apply to any game, and then turn around and say “my solution is better because, xyz.”

It may be better for a specific type of game, but you are not talking about a specific type of game, you are talking in generalities, and I object to that.

-dZ.

[seguso]

@DZ-Jay

It may be better for a specific type of game, but you are not talking about a specific type of game, you are talking in generalities, and I object to that.

You object. But it’s only natural that, before I look at a specific solution, I look for a general solution. When, and if, I have a reason to believe that no general solution exists, then I start to look for an ad-hoc solution. And that’s why, a few moments ago, I asked for concrete examples of good puzzles that would be lost with my proposed UI. (Or of something else of importance that would be lost). (I apologize if I have missed some example on your part— it’s possible I did)

[DZ-Jay]

@seguso

@DZ-Jay

It may be better for a specific type of game, but you are not talking about a specific type of game, you are talking in generalities, and I object to that.

You object. But it’s only natural that, before I look at a specific solution, I look for a general solution. When, and if, I have a reason to believe that no general solution exists, then I start to look for an ad-hoc solution. And that’s why, a few moments ago, I asked for concrete examples of good puzzles that would be lost with my proposed UI. (Or of something else of importance that would be lost). (I apologize if I have missed some example on your part— it’s possible I did)

I’m not objecting to generalized solutions as a guide. I’m objecting to you saying “but my solution is better…” Better for what? Why? It’s just another possible solution.

[LowLevel]

@DZ-Jay

However, it is true that if an object is not useful for interactions or for solving puzzles, then why is it in the world at all?

I’ll add to the answers that have been already given a modern one: “Because adding an object to the world was a backer reward.”. It’s interesting to observe that nowadays game design can sometimes be influenced by decisions made by future players or people outside the development team.

@Guga

If you get an object early that is vital for the endgame, it doesn’t cost much to give an alternative use to that in the middle of the game.

I agree that reminding the player of the object can be useful, but I’m not sure that this kind of help is necessary to the point that without this help the final puzzle sould be considered a bad designed one.

Many adventure games have inventories full of objects and even if the player doesn’t always remember all the objects that he/she has, observing their list should be enough to realize that one of them is exactly what the player needs to solve a puzzle. That’s why I think that reminding the player of an object is not necessary.

---

@DZ-Jay: I have read your posts in which you express how important is to trust the player and assume that he/she will invest time and efforts in the game if it is well designed. I’m not sure I have understood correctly your point, so I apologize if my questions are not relevant:

1. Which assumptions do you make about your players when you decide to trust them? What do you expect from them?
2. What if I want to design a game for people who don’t want to invest too much mental effort and actually prefer an easy road or an “other” verb/command/option?

[DZ-Jay]

@LowLevel

@DZ-Jay

However, it is true that if an object is not useful for interactions or for solving puzzles, then why is it in the world at all?

@DZ-Jay: I have read your posts in which you express how important is to trust the player and assume that he/she will invest time and efforts in the game if it is well designed. I’m not sure I have understood correctly your point, so I apologize if my questions are not relevant:

1. Which assumptions do you make about your players when you decide to trust them? What do you expect from them?
2. What if I want to design a game for people who don’t want to invest too much mental effort and actually prefer an easy road or an “other” verb/command/option?

1. First, I assume that they are playing in good faith. That is, that they are playing for fun and want to follow the rules, and that they are pre-disposed to follow my (the designer’s) lead and not to fight against the mechanics.

Second, I assume that they have a knowledge about the general world around us, which can inform the game mechanics. For instance, that fire melts ice, that water is wet, that a fridge keeps food cold, that a microwave warms food.

I know this seems sort of basic, but this is the first thing that as designers we can hold on to in order to make a sensible and logical interface: if it already makes sense to the player, then half the battle to teach him the interface is won already.

Third, I also assume that they are at least somewhat aware with the subject matter. That is, if you make a game about Star Trek, then you could assume that people know about the phasers and teleporters, etc.

2. Well, that’s why you start with an interface that already makes sense to the player.

When I said I didn’t like “Other” verb, it’s because I think the term “other” is much too generic. However, I think a case can be made for grouping all interactions of a class within a single verb, for instance, “Use” or “Do Action.” The idea is to convey the notion that the verb does something. I guess my objection is to the term “Other,” since it itself is not a verb.

[N_N]

@seguso

Now that I think of it, isn’t “use” in scumm exactly the same as the “other” verb? (e.g.: indy4: use totem = climb totem)

Partially, in the same manner that “mouth” also has some “use” functionality, with “hand” being the main icon with use functionality. So “use” can be spread over several icons depending on the manner in which one needs to interact with something. I’m not sure how much I like that but that’s the intention of my earlier scheme; that the icons cover more types of interactions which increases the amount of lateral thinking that has to be used to solve problems, such as mouth being able to do more things than talk and other being a special case of use which in the case of this suggested scheme would not involve one’s hands, mouth, ears or eyes.

[N_N]

@seguso

Let me point out that my solution is actually better in that regard. Because you cannot combine any object with any other, as you can with most existing adventure games. In scumm, you can combine any pair of inventory objects (e.g. use bottle with invoice). And you can give anything to anyone. In my proposed UI, you click the bottle, and you see: open, drink, break, give.

So you can’t use it with the invoice.

And not all objects will have “give”. The bottle has it, because the puzzle is that you must give it to someone. But some other object class will not have “give”.

So, it seems to me you believe that my proposed UI would give too much freedom, whereas it allows to give just enough freedom not to give away puzzles, but no more than that.

I think you could make every puzzle case-by-case with enough options as to not make solutions obvious, yes.

If you combine that method with more typical interactions, such as needing to do something with an object before being able to solve the puzzle by using its specific definitions, you’ll have plenty of scope for crafting puzzle difficulty.

[DZ-Jay]

By the way, @LowLevel, please understand that these are only ideas that occur to me and make sense to me. I am not an authority in any way.

-dZ.

[jrial]

@seguso

You follow them, only to see they shut the door in front of you. Now, the puzzle is to understand you need to “listen to door” or “eavesdrop”.

Not a good puzzle, because it’s obvious. In order to make it a good puzzle, the door must muffle the voices so you need to find another way to eavesdrop, or the door must be “guarded”, so you must find a way to lure the “guard” away, … Simply using the listen verb on a door behind which a secret conversation takes place is not a puzzle.

@N_N

It should take one very little time to learn the moves and it might be much better suited to mobile devices.

Yes, but why not just stick to the already established iconography? A semi-circle for open? How about a half open door? And close could be a closed door. A circle for look? How about an eye? A cross to talk? How about a mouth? Etc… These icons are already familiar, and used in countless other adventure games. What would you gain from introducing a non-intuitive iconography? More importantly: what would the player gain from this?

@N_N

I like the idea of listening (listen verb or otherwise) being an integral part of an adventure because a thorough integration would produce an extra layer to dialogue puzzles and would greatly increase the immersion of the game world because of the extra layer of interactions between NPC’s (who you would often have to listen to rather than talk to).

If you need to hear casual conversation between NPCs, you make them talk to each other spontaneously while you’re around. If you need to eavesdrop, you make it a puzzle to figure out a way to get close enough undetected.

@seguso

Suppose at one point you need to hide in a wardrobe. You have a “walk inside” verb that appears on all wardrobes, not just on that one. Is it a big problem if you need to have 2-3 wardrobes in the game? I can see it being kind of a problem, but it does not seem that much of a problem.

Or you simply walk to a spot that’s inside the one relevant wardrobe, and use “close” on the doors, rather than littering your world with unnecessary wardrobes just so you have an excuse for cluttering the UI with the “walk inside” verb that you need to solve one single puzzle in the entire game.

@N_N

Other does crazy things and provides some solutions to puzzles also

Great example: the “use the rabbit” mechanic in Sam & Max Hit the Road, if someone has trouble visualising the concept, take a look at this scene:

PC Longplay [016] Sam & Max Hit The Road

You have no idea what’s going to happen when you “bunny” the object, but you know that if it’s a valid action, it’s going to be gross, violent and hilarious.

@seguso

What if you make it artificially difficult to press “other” ? Say, you need to press and hold for 10 seconds?

Because again, you’re punishing your players for your bad game design by making the user interface artificially complex. That’s your solution to everything: pile extra complexity onto a user interface to the point where the player is not struggling with the puzzles, but with the game mechanics.

No! Just no! First of all, this is lazy. Second, it is mean spirited. Third: it’s punishing others for your failure to design a game properly.

[gamechuck]

Unrelated but still related… I made some “market research” (read: gave dozens of friends my game to play). This when I was making a classic point and click game a couple of years back. These were people who never played a PnC in their life! The results were that most of them were most comfortable with the coin interface, it was most ‘intuitive’ to how other computer programs work (right clicking on Windows also opens something etc). They were confused when I used context sensitive verbs (for example the Kick button was disabled when you couldn’t kick something, e.g. a fan on the ceiling), they kept saying ‘why is this grayed out now? how do i ungray it?’ instead of accepting it’s a design choice. The other things I tried was the verb interface on the bottom of the screen (with cute pictures of verbs), which went horribly, even with a tutorial, people forgot about it after some time and kept using the default. Then when I disabled the default (put it to Walk instead of Look) they got frustrated for having to go all the way to the bottom of the screen to click on something and then go back to click on the object in the room. I also tried a streamlined interface where there was only one thing you can click per object, but they felt constricted with it (“wait, I kicked the oven, can I kick the door too? why can i only try and open the door?”). So that’s my experience with complete novices - just a super normal coin interface is the most intuitive. Of course, a good learning curve and tutorials can fix any problems ever. And I know this doesn’t help at all when the question is related to experienced gamers.