What if, as part of solving a puzzle, the player has to put object A on object B?
What if the player types something that is almost right–put object B on object A?
In the particular case I’m thinking of, my guess is that the player is probably trying to solve the puzzle and probably has the right general idea but might just be phrasing it differently. This interpretation might make more or less sense depending on the exact words the player uses in the command.
Is it best to
Respond as if the player typed it the “right” way? Though saying “You put the A on the B” when the player has just typed “Put B on A” could end up looking like a bug.
Respond with a suggestion? (“You could try putting A on B”). But maybe that would be annoying. (“If you know what I meant, why are you making me retype it?”)
Accept the command, but add command clarification in parentheses, like this
I think it depends on the situation. Does the player really have the right idea? Consider two examples:
>put doll on hat
You put the doll on the hat.
>put hat on doll
(first taking the hat)
You put the hat on the doll and it magically comes to life!
or
>put stamp on glue
You place the stamp against the glue, putting glue onto the stamp.
In the second example, we might want the player to “put glue on stamp” but saying it the opposite way makes sense and shows the player has the right idea. In that case it should simply be redirected, perhaps with a hint to what the “correct” phrasing would be. Giving the preferred phrasing wold be especially useful if the situation might come up again in the game.
EDIT: Of course in that example, trying to put things on the hat would most likely yield an error, but it wouldn’t be an unfair failure. The idea is that in that case the two options are obviously very different, whereas with the stamp both ways of putting it are reasonable and equivalent in intent.
I think my situation falls somewhere in between those two examples. In my case, it seems plausible that the player had the right idea, but it’s also possible the player was just randomly trying things.
(I guess another possibility would be to set a flag for when players see the clue that might prompt them to try to put these two things together. If I knew players had seen the clue, that might make it more likely that they had the right idea in this case. But maybe that’s overcomplicating things.)
I like this idea and depending on the tone or genre of game (like a mystery) it might work well. You could even reference the fact that the player had seen said clue in the clarification response. In any case, I would generally go with:
As a player, I really dislike thinking “If you know what I meant, why are you making me retype it?” but I don’t ever remember thinking “That’s not what I meant and I probably never would have tried it, so now you’ve spoiled it for me.”
My philosophy: when in doubt, always be on the player’s side.
For example, if I know the player has seen the hidden combination to a safe $knows.combination = true, I can implement mechanics SET FIRST DIAL TO 5, TURN FIRST DIAL TO 5, SET COMBINATION TO 534, and that can all work, but if the player knows the combination and has tried four times to set the combination unsuccessfully, it’s worth giving them a nudge. “After playing with the safe dials in different ways, you realize it must be that combination you saw in the picture frame and enter 5-3-4. The safe clicks, verifying it has unlocked.”
That’s a step too far for my tastes, you are taking away the player’s agency, almost saying “you were too stupid to solve the puzzle, so I’m gonna do it for you.” Why have a puzzle at all then?
I’m not trying to take away agency or solve it for the player; I’m looking for signs the player knows what they need to do but are having trouble with how to do it.
In my example, I’ve set a variable that knows the Player read the letter where Uncle Percy specified “The new code to my safe is 5-3-4, Chauncey. Make sure you don’t let the other servants know because they will gossip!” So it would stand to reason that subsequent to this, if the player is in the Study with Uncle Percy’s safe, and they’ve unsuccessfully tried three times to input the correct code, the pacing could definitely be improved by just getting to the chorus instead of spinning wheels waiting for the player to find the right verb.
And this, of course, will depend on the style and tone of the game. Is the world-simulation model the fun part of the game, or is it the plot and advancement of the story?
If the player has a letter with the code, then yeah, I would accept just OPEN SAFE or UNLOCK SAFE and the game can just take care of the details.
If the player is meant to remember a number they saw somewhere, and enter the code manually, then I’d rather get a hint over the game taking control.
(fwiw, my game in PunyComp had a safe in it, originally with a six-digit code, though I changed that after negative feedback. So this is one puzzle I’ve thought a lot about)
I think this is an important goal, but assuming that if the player is trying to interact with the safe and has seen the code some time in the past then they must have realised what code to use is still sidestepping the main part of the puzzle. I think the better approach is to make it really obvious how to interact with the safe; for example, if the player tries any verb on the safe or dials other than “SET DIALS TO 123” then just have the game respond with “[If you know the correct combination, you can open the safe by typing SET DIALS TO 123.]”
Yeah, since you have to anticipate the problem in order to implement auto-solving anyway, why wouldn’t you just print instructions upon examining the safe? But this is more of a UI issue than the original question.
I find the PUT A ON B example confusing. I can think of PUT MOUTHPIECE ON LIPS and PUT LIPS ON MOUTHPIECE, which are totally equivalent. PUT HOOK ON FISHING LINE. I can’t come up with an example where switching the objects produces a command which isn’t equivalent but is also closer than “generally on the right track”. Seems like the best response depends very much on the details.
That’s a great idea as well. Again I think it depends on the tone of the game. For my preferences, getting a “You’re doing it wrong, here’s what to do…” message feels more like parser taking pity on the dumb human and giving them a hint rather than organically realizing the player means to do the right thing and advancing the story automatically.
And as I said, it depends on the tone. In a classic “snarky parser” mode it makes sense that the parser would roll their eyes and spell out the command for the player.
And it depends on the action. In real life, the player would probably understand what to do with a physical safe, and if the complication is the interaction to accomplish that as opposed to knowing the combination, authors have different options for dealing with it.
And depends on how the PC/player relationship is structured. It’s possible that the PC is an experienced safe cracker with skills the player might not have and should never have trouble with their “brain” saying “okay you gotta put in the first number, how does that even work?”
Maybe I’m just lazy, and I’m the person who migrated to choice from parser to not have to deal with this kind of thing on a regular basis. But different games have different styles and philosophies of interaction-depth.
I remember in Monkey Island appreciating so much when they could predict what I was doing and cut out the boring parts for pacing. One puzzle in that involves gathering a group of things on a specific island and traveling back and forth by graphically rowing around several islands on a map. Once the game can tell the player knows what they’re doing, upon entering the boat there’s a title card “After several minutes of furious paddling…” and they teleport the player where they need to be next without making them physically navigate the map for the third or fourth time. To me that felt like the creators rewarding me for knowing what to do and confirmation I was doing it right and not that they were solving a puzzle for me.
I think the question you have to ask yourself is do you want your game solvable by “combining items” or do you want players to be more explicit?
I’ve said before, the only forgivable command I acknowledge is with the verb USE and a game should only assume the most common sense interaction with the item (or items) in that case, if at all.
PUT is already explicit enough and reversing the nouns has an entirely different meaning. PUT means you’re placing something; and that can be either ON or IN something. (Sure, it can mean to wear something, but typing PUT ON COAT is pretty clear. PUT COAT ON SELF is odd, but could be allowed; though maybe the player meant put the coat over their character’s head? PUT SELF ON COAT means you want to stand on the coat.)
I wouldn’t allow PUT to be a magic wand that solves puzzles. Otherwise, USE HAT WITH BEAR would place the hat on the bear’s head… and then you might be making the equivalent of a point-and-click adventure game in parser form.
Point-and-click adventures are about combining things. When the hand icon can mean climb a tree, pick up a rock, place the jewel in the statue’s eye socket… you’re basically applying something to something (even your character to things or vice-versa). However, a parser game typically asks “HOW are you combining things?” And with that freedom comes the responsibility of being explicit… and the author must reward that behaviour.
Note: My favourite graphic adventures are the older ones that had the parser. When they went full-on point-and-click, I started to lose interest in the genre.
I see your point, but they usually had a very primitive parser, and seemed to be more prone to frustration. I sometimes think that they moved on from the parser because the parser was getting dumber - or, less facetiusly, because not enough time was being spent on the parser and the parser-specific aspects of gamplay; time and money were instead spent on graphics, animations, music…
EDIT - The Leisure Suit Larry 7 game had an interface that allowed you to enter a verb yourself, and although it was not required for any puzzle, it recognised a serious amount of verbs (not sure how deeply they were implemented). I always thought it was the best marriage of parser and graphical adventure I’d seen. Sadly, it absolutely, totally and utterly failed to take off. I ranted a bit about it in the AGS forrms, I could put it here too.
*Tangential rant about parser as a graphical adventure interface, and the “barrier of interface*”
I read an article about GUI design and they said the best adventure GUI was in a Larry game (sorry, don’t know which one).
Must be Larry 7, if for no other reason than all the other Larries using the standard GUI.
I fully agree, and I think it’s totally untapped potential. Sure, the game developer suddenly has a lot more to think about since the player can enter any verb, but it’s not so different from what interactive fiction (text adventures) have always been doing. It’s very possible to reasonably predict all the possible verbs that can be used in a given situation, and then testers find out a few more. The result is not, as one might fear, diminishing returns, but the opposite: you give the players the illusion that they really can do anything they want. Obviously they can’t, but if you put in the effort to make them believe the illusion… you have won them over completely, and have their total trust, and can do all sort of crazy shite.
The thing is, when you are free to write out your verb, as long as the author has made an effort to ensure that reasonable stuff is understood and has synonims, your possibilites expand. Also your game design responsibilities; if your puzzle involves not just clicking on something but actually using a specific verb, you have to focus the player’s mindset towards that. I don’t actually think LSL7 used that to its fullest potential.
Interestingly, a game that could have made good use of that in AGS is, say, Trilby’s Notes, in which it was pointed out that at least one puzzle could not possibly have been implemented in point-and-click fashion. But it could have, with this LSL7 interface.
In a text adventure, the parser is an amazing thing, because the game is talking to you in words, and you are replying in kind. Just like I read your post and am replying the same way. After a few commands, if the game is solid enough to reasonably understand you, it’s like the barrier of interface disappears. It feels no different than texting someone. You’re issuing natural commands in english, and being given responses in english.
Graphical adventures have a bigger hurdle, because they communicate to the player via nice pictures and audio, and the player communicates by clicks. Even when you add the parser, it’s not the clean connection that it was before, so the transition from parser to point-and-click was the best thing that happened to the graphic adventure.
LSL7 was a daring step in a direction that no one followed in. I am unutterably sad about that.
(…)
Come to think of it, as regards communication between the game and the player, and the barrier of interface, touchscreen panels and first person adventures actually work extraordinarily well to achieve this, for the first time since text adventures. You see; you touch; things happen. It doesn’t have the variety of parser-based interaction, but it’s very well suited to these graphical environments.
David Cage has famously been trying to break down this barrier by associating player controls more directly with the movement we see on-screen, and I think he’s been successful as far as he can be with using a controller, but I still don’t think it came nearly as close as text adventures (and we are still heavily text users, messaging and texting and whatnot). Touchscreen + 1st Person View really is a step beyond. Myst III in a touchscreen device is… a wow. Just a wow.
…
…one thing I’m excluding is VR, because I never tried it. I suppose that would be the proper next step. I never tried stuff like “PS3 Move” or the Wii or stuff like that.
I think the safe puzzle is an excellent example, because it illustrates where the line in the sand could be. A game that waits for you to set the combination? Great. A game that reduces you to “open safe” and responds with “You turn the dial to a few settings which seem promising, but nothing works. You’ll have to find that combination somewhere!” until you see the combination, at which point “open safe” will work? Great. A game that, erm, yanks the rug from under your feet by figuratively saying “Well, since you clearly did not grok that you have already seen the combination, I’ll just enter it myself”? Aaaaah, not so great.
It’s always possible, but usually - from what I’ve seen and experienced - a game that tries to stop the player from randomly guessing the answer can be pretty infuriating, because it may more often than not guess wrong, and the player will go “But I KNOW that this it! I KNOW it!. Anything more than simply “saw the clue? set a flag” is inviting frustration, I believe. Yes, there are very good reasons to block interactions until there is a reason for them, sometimes, but those reasons should probably be story-reasons. Not “I want to make sure you’re not just guessing” reasons. For one thing, puzzle-solving IS guessing. Let the players guess. It’s all about how you reward that guessing.
I would prefer it if the game didn’t try to guess at what I meant, and just responded clearly to what I try to do. I put the doll on the hat; period. (or maybe, “the hat is too small to balance the doll on”). I put the stamp on the glue; yep. “You place the stamp on top of the glue.” We can be clearer about how the game interpreted the command, too: “You place the stamp on top of the glue; it doesn’t seem to balance well, so you take it off again.” And we can throw the player a bone: “You place the stamp on top of the glue; it doesn’t seem to balance well, so you take it off again. Still, it feels like you were on to something.” This last message would definitely clue me into the fact that these two objects were related, and I just had to try something else. It would also definitely tell me how the game interpreted my command; so, if I meant for the command to be interpreted differently, I’d have to be more specific.
Anyway, apart from a clear response, if I can tell that it’s a non-default message, then that’s already a hint that I’m on the right track. And if PUT A ON B was accepted by the game but didn’t have the result I’‘d hoped for, it makes sense for me, in these examples, to try PUT B ON A. But I would hope that the game would allow me to GLUE STAMP TO ENVELOPE, as well.
Still! Let’s say that I have the glue, the stamp, and the envelope. If the game accepts GLUE STAMP, and I have all three, and it just goes ahead and does it, I think we’re gold! That would be a good example of a situation where the game would simplify the actions of PUTting GLUE ON STAMP and PUTing STAMP ON EVELOPE. Of course, nothing should stop us from PUTting GLUE on STAMP either. Or indeed, on the envelope.
A game that went to the lengths of having GLUE as a verb and to implement this nicety would impress me, but it’s the sort of thing that most people migth not notice, so it feels like unappreciated work.
In some games, when I’m stuck and I notice the game is implemented a certain way, I try putting things on other things precisly like a magic wand. Some actions are hard to express, and “put on” seems to have become the equivalent of “use on”, sometimes. I hate it when I have to lean a ladder against something, for instance… “put” is a default that works. Unfortunately, it makes it a magic wand.
EDIT:
Oh, never played The Nemean Lion, then?
FINAL (hopefully) EDIT - I totally managed to disprove my own point by getting the STAMP and GLUE the wrong way around when I first speak about them! Corrected that.
I agree. However, I accept discomfort when using a parser. I just expect it. I really enjoyed playing Violet, even though I banged my knees and stubbed my toes throughout that game.
The inherent friction with the freedom of a parser is a delicate balancing act, for sure.
Regarding the excellent Leisure Suit Larry 7, I found that interface of an optional parser only clever on paper. Because 99% of the game is played without it, it felt tacked on and became an obscure command hidden in plain sight. I think the designers realized this and pretty much removed the requirement for using it. It was definitely brilliant, but not implemented well.
There’s a memorable scene in Police Quest II where you find Marie tied to a chair. She’s frantic and hinders the rescue if you don’t CALM MARIE down first. How would a point-and-click interface facilitate such an explicit command? Click mouth, click Marie, automatically calm her down verbally would probably be it… though player intent is completely nebulous there.
You’ve reminded me that even though the parser creates friction, it’s worthwhile to reduce that as much as possible. We’ll never build a perpetual motion machine, but the mechanical efficiencies discovered in that pursuit are so worthwhile. It’s nice to see some passionate discourse here about parser implementation.
Even before graphic adventures had mouse support and therefore clicks, games like King’s Quest and Space quest were on this course.
Many graphical games in the 80s and 90s built the levels out of tiles, which are an abstraction. But in King’s Quest, each screen was a custom full-screen illustration. In a 2d arcade game, there is the understanding that you view the action from this distance, at this level of detail, because that’s how the engine works. Cutscenes are possible, but in general, players are very happy in this tile-based world, with consistent rules that enable rewarding arcade gameplay. Sierra went the opposite way, with freeform illustrations, which as a side-effect provided a motivation to make the player’s control less direct, since direct control without consistent rules is not much fun. (Technical challenges would have originally been a motivation as well.)
Maybe you could say that these graphical adventures chose to put the abstraction in the controls, rather in the world, which would have enabled more literal controls (literal control of an arcade character, or literal choice of verbs). This wealth of visual detail and relative lack of clear rules puts the player in the mode of scrutinizing the screen, then poking the game to see what it will do. Arcade games, and text adventures, have less of this, because the player is always told what they are working with (in words or in known abstractions), and always specifies exactly what to do (in words or with arcade controls).
The graphical style they chose, while a natural fit for “what adventures were doing”, was maybe not the best for the retention of parser input in graphical adventures. It’s a shame that parser input in more abstract graphical games hasn’t been explored in depth. But I guess intentionally simplifying the graphical elements of a game in order to gel better with parser elements wouldn’t have been a natural idea in the past. Parser/arcade mixtures have traditionally alternated parser and arcade sections.
Uhh, bringing this around to the original subject, are we making a “tell the game exactly what to do” game, or a “look for interactables and see what the game decides to do” game? The middle ground seems apt to come off as glitchy and inconsistent.
Absolutely. I fully agree. And it makes me sad. When I next replay LSL7, I’ll try using my own commands exclusively and see how it plays.
Excellent example. I’ll get around to it one of these days - I hope there is sufficiently direction in the game that the player can think of that, even if it means dying a few times (that’s ok, that’s part of the design of the time). You’re right, with point-and-click you’d TALK TO MARIE and then you’d either calm her down atuomatically or be given a dialog tree in which that was one of the choices. It’s less… visceral interactivity.
Absolutely, but then you had a brand new hurdle, which you also allude to but to which I will give more prominence: I, the player, see a blob on the screen that seems to be an interactible object. What is it? What’s it called? How do I find out? This hurdle, in IF, only really existed with poor implementation. With a screen full of graphic elements, you are not being told what there is; you can see for yourself. If you can see for yourself, a) your expectations are being able to interact with it at least for the sake of examining, and b) it can be a real struggle when the game doesn’t understand what you’re trying to refer to. And you don’t know whether it’s because you typed “cabinet” when you should have typed “wardrobe” or “closet”. Unless the game used the word first; which eventually stopped being a given. Anyway, for such an obvious object as a closet/wardrobe, there would probably always be something in the description; the trouble is when you’re trying to interact with scenery, which the designers know to be scenery - but you don’t, because you’re trying to solve the game, and you don’t know what could be useful. The mouse came to solve this problem. It’s natural evolution, pretty much. I have very clear memories of a particular screen in KQ4 where there was a patch of screen that had a certain shape and was a different colour, and so it certainly looked like something that I could interact with. But I could never find out what it was called. I believe now it was just a graphical blotch, really. But this is the peril, and it’s worse than in IF. In IF, you type the name of something in the room description, and the response makes it clear to you whether or not it’s implemented. If you are trying to type a name and you’re not sure what it is you’re trying to interact with… well, again, I do believe the mouse makes a lot more sense for graphical adventures.
And everything you say about abstractions is spot on, and it makes the parser even more amazing, because it was never an abstraction. It was never “tiles that represented a forest”, or “a drawing that represented a castle”, or a funny-looking yellow knight you could move with the arrow keys. Text was always “I’m talking to you, you’re talking to me. You see this. What’choo wanna do?” In the sense that it is an abstraction, it’s the abstraction we’ve known since children from reading books and being told bedtime stories, and which continue on into our adulthood. It’s ingrained as deeply as the concepts of literacy, of words representing things and concepts. If it is an abstraction, it’s one with which we engage daily, and which feels as natural as breathing.
So much so that I believe the comparable thing in graphics for it is, as mentioned, the touchscreen - “touch and it happens” is natural as breathing - and VR, which I haven’t actually tried, so maybe it words and maybe it doesn’t. It is true that using the mouse has become extremely natural, but only as an interface, an intermediary, a go-between. The parser is ALSO such a go-between, but it makes a wonderful job in deceiving us, because we are (if it’s doing its job well) not thinking about how to communicate what we want to the game; we are thinking about what we want to do, and we communicate it naturally, by just saying it. Well, typing it.
Quoting just to bring back on track. I don’t want to distract from this.
Yes, and here’s another place abstraction could help. An arcade game doesn’t have any particular objection to text floating unnaturally on the screen, if it would be useful. Simply labeling the objects on the screen would clear this hurdle, but it’s not something graphical adventures traditionally allowed themselves.
Quoting just to bring back on track. I don’t want to distract from this.