I don’t know what the rest of your design looks like, but it sounds almost like you could lean into the modal stuff and make everything modal. That is, intentionally break up the gameplay into different kinds of tasks or whatever (instead of just specific things like dialog). Think something like Suspended, only instead of just getting different kinds of information from the different robots, you were also using a different vocabulary and syntax in your commands.
4 Likes
I’d say Pinkunz is right. If it’s me, I’d just do it every way and pick the best one. If it’s just modal, my opinion is that you can do it anyway you like: Status line, room description, and prompt.
“You are in a forest (confused)” is an example of status line modality.
4 Likes
I think there are some very interesting concepts lurking if people want to play with it. I’m currently idly working on a remake of my jam game reMemory - the original version (the devlog goes into more about this) was me trying to construct memories, inspired by Scents and Semiosis. I’m now working on twine (via a personal website) APIs to see how gpt3 (4 is expensive) handles creating memories versus me trying to code beautiful sentences.
1 Like
Has anyone attempted any of these techniques yet? I don’t recall seeing anything similar in games I’ve seen go by.
3 Likes
I believe most of the ideas discussed here can fall into one of three categories: (1.) user interface design, (2.) parser engine functionality and (3.) best practices. Some might be best served by a combination of those points even.
I’ll use my idea for my dislike of multiple command errors being displayed in the story text. (“You see no such thing, You see no such thing, You see no such thing, etc.”)
1.) When it comes to user interface design, I imagine a Twine-like browser experience where a template can be made in HTML/CSS with specific areas tagged for parser output. So you could have a parser game of unlimited presentation possibilities. For example, just above the command input (which is also positioned by the template), a hidden area could be programmed to hold only error messages. It’s always at the bottom of the scrolling story (via CSS), but every time it’s written to, it’s content is replaced (only the last error is displayed) until a valid command is accepted; upon which the error area is cleared and doesn’t take up space.
2.) The parser engine’s output should be able to target any specific area in the template. Commands that are accepted go to the story output; errors go to the error output (or the story, if you want). You might even have a table of RPG stats on the side where you’re not redrawing the whole table each time, but just outputting specific statistical values to areas within the table. The classic “header bar” takes on a whole new life and isn’t constrained to the top anymore either.
3.) Then again, the other two points can be made less important by providing more interesting errors that don’t feel like an error. If you can’t go in a specific direction, perhaps make fun of it and tell the player, try as they might, the wall does not open; nor will it ever. You can even have a random error message from a pool of “you can’t go there” messages so it’s always a little more interesting. Or you can output the error as normal, but with a different colour/font so that it feels more like a subtle comment, rather than a bold result. (Generic errors should not feel like story prose, in my opinion.)
I really do appreciate you bringing my attention to this topic again, Pinkunz. I think it might be useful when it comes to programmers wanting to build their own parser engine or for those who wish to push the limits of current engines.
Another thing that can be talked about (unrelated to this post though) is the way authors can build text adventures. I recently played with ifSpace and really liked just filling in form fields to construct a text adventure. I found it kind of liberating to not hunt down a misplaced semicolon syntax error. Are there any other examples of text adventure authoring engines that don’t require coding?
Edit: Also, are there any JavaScript parser APIs that could be integrated into a Twine story? I think I remember Manon mentioning that she built a parser game in SugarCube. I’m not sure how that was accomplished though.
3 Likes
I’ve given more thought to what you’ve described, Hanon, and it really helped me envision a slightly different method.
I like the idea of incorporating a Maniac Mansion command construction. Screen real estate is always a problem though, so it might be best served by icons instead of words (like how point and click adventures evolved into that state). Verbs on the bottom half and nouns are in the upper story prose. I can see this working fairly well for a Twine-based game.
Here’s an idea to keep the space required much smaller for a full word verb menu on the bottom. Like, instead of OPEN and CLOSE being two separate buttons, make it OPEN with a little symbol in the corner of the button denoting that there is a toggle option. Tap it again, without tapping on anything else, and it will switch to CLOSE. Above the verbs, the command being created is shown. So OPEN… changes to CLOSE… and tap on the noun in the prose and you see CLOSE DOOR appear as the final command and it can be executed. Nouns in the prose could look like targets for commands somehow, if it improves the experience. Maniac mansion had PUSH and PULL, OPEN and CLOSE as separate buttons, but I could imagine you could extend this toggle idea to other similar verbs groups, such as:
LOOK / EXAMINE / READ (eyeball stuff),
PICK UP / DROP / PLACE ON ,
TASTE / SMELL / LISTEN / FEEL (senses),
USE / USE WITH (use with = good for combination actions with inventory and/or scenery items that require 2 nouns to work)
and even LICK / UNLICK , if your game required it.
I don’t know who would make such a silly game like that, but to each their own. 
The grid of verb options might change depending what you are doing too. Like if you are operating a vehicle or robot, the choices change, but you essentially are still building parser commands. The nice thing about this approach though is you are never playing find the verb or find the synonym. It would also be way easier to author, I believe. In fact, I think this would work very well in a non-coding authoring interface, like how I mentioned ifSpace in the previous post.
I might make a prototype of this in Twine or iffinity one day. It seems quite straight forward, to be honest. I think it has merit.
Oh, boy… TALP Adventuron game or Verb/Noun clickable Twine parser interface. I need to clone myself. That’s it! 
4 Likes
Quest 3 5. (Apparently I’ve misremembered this number every single time I’ve ever written it on this forum. Kill me now. Also, good luck to anyone looking for docs on Quest 3; a VR headset of a similar name has completely taken over Google.)
QuestJS. Basically Quest 5 but modified for pure JavaScript development.
3 Likes
If it’s a button, push.
If it’s a handle, pull.
If it’s a closed container, open.
If it’s an open container, close.
If you double click on an object, use.
If you drag an object onto another, use-with.
Are Verbs really necessary?
Edit:
If it’s a container, examine and look inside.
If it’s the room, examine and search.
If it’s me, examine and take inventory.
If it’s compass rose or doors, go that way.
3 Likes
Verbs are “necessary” because they allow the player to indicate their understanding of the puzzle and prevent unsatisfying accidental solves. If you accidentally use the right item in the right place and the game does something you never expected, maybe you never had the chance to get your head around the puzzle enough to appreciate it once spoiled.
But I think games should generally have a use command to make particular items with stereotypical uses linguistically easier to operate. USE OAR should paddle the boat you are in but not fish an object out of the water with it.
6 Likes
I absolutely love this question. When building something new or unconventional, we really should question everything; even the basics.
Are they necessary? No. But I feel like they are preferred for the same reason Paul @paul-donnelly mentioned. I absolutely hate when a puzzle is unexpectedly solved. Of course, that can never be fully avoided with choices, but the more direct (involved) you make the command, the more the intent is established, and hopefully the more satisfying the result becomes.
Though I like Hannon’s idea of clicking on nouns and getting the actionable verb list on them, I feel it will present the answers too easily. Like, when you mentioned pulling a handle, maybe it’s even those “duh!” solutions that players initially struggle with and yet that simple command executed gets them one more step further in the story/adventure. I used to feel those little “aha” moments of triumph in the original Monkey Island. I found it to be satisfying, at least.
In another thread that talked about puzzles, I got the third-degree for championing a parser-like experience in choice based IF. But what came out of it was the concept of narrative puzzles versus object puzzles. The less precise (easier/convenient) you make the navigation and manipulation of the story’s world, the more you should lean on a solid narrative purpose and hinting of a puzzle’s solution. I think I had mentioned that parsers don’t really need a story to have puzzles be functional, but the more stream-lined your choice engine becomes, the stronger your writing needs to be when constructing puzzles. One of my favourite adventure games is Shadow Gate. It relies heavily on object orientated puzzles to drive the narrative… instead of the narrative driving the puzzles.
I never got to play the Macintosh version, but the NES cartidge game was superb and the new remake on Steam and GOG is so beautifully done and the painterly art style is to die for.
3 Likes
I really struggled with suggesting USE as a verb (Yes, Harry, I did. ). Absolutely, that should cover the conventional uses of an item (hammers hit, crowbars pry, knives cut).
You can also use nouns with items in unconventional ways, but I think it still has to be a more basic unconventional thought. Like, if a small chasm must be crossed, you could USE a LADDER on the CHASM. That makes sense that you would try to bridge the gap and cross it that way. Ladders carried in pockets are a different discussion though.
2 Likes
Might be fun to write an experimental game with no verbs except “use” and what it does is only determined by, one, what you’re using and, two, with what second noun.
> use lantern
The room is filled with a warm diffuse glow.
> use lantern on sunstone
You hold your lantern close to the sunstone embedded into the cave wall. A soft click is heard and a portion of the wall including the sunstone slowly swings into the darkness on hidden and silent hinges. A foul odor emanates from within.
> use lantern on ogre
You hurl the glass kerosene lantern at the snarling Ogre’s face and it explodes into a ferocious fireball of shattered glass and burning oil.
> use
You made a promise to yourself long ago that you were done doing that forever.
6 Likes
I really like that idea! You would have to have some non-productive combinations of USE give a response that’s interesting, I feel. Then the player would still be rewarded in some manner for even trying the combination.
> use lantern on book
Are you trying to burn it? That sort of thing is frowned upon in most cultures!
1 Like
I designed a game in this mode and got partway down implementing it. Interestingly different design problem from the standard verb-noun parser.
Because I was considering a drag-and-drop connection UI, I decided to allow any number of nouns. But incrementally – the point is to let the player explore assemblages. Something like:
> USE BOOK
The book is enormous, creakingly ancient, and sealed with a heavy padlock.
> WITH KEY
You unlock the book and heave it open. The pages are blank.
> WITH ULTRAVIOLET LIGHT
You click on your UV penlight and shine it on the pages. Strange purple glyphs flicker in the glow.
> WITH KLINGON SYLLABARY
You begin matching up the glyphs with your dictionary. The text has something to do with a hunt for some kind of beast…
(I wasn’t planning to distribute this with a parser-based UI, so the clunkiness of WITH is purely for illustration.)
7 Likes
I hope the game sees the light of day sometime soon! I’d love to try playing something like that!
2 Likes
The nice thing about this approach is that you can handle conversation with the exact same interface. (Assume that both topics and physical objects are in scope.)
> USE GUARD
You approach the gate guard, shaking rain from your cuffs. The guard offers, “Can I help you, citizen?” with little veneer of civility.
> WITH APPOINTMENT
“I have an appointment to see the Lady.”
“I’m sorry, citizen,” the guard replies stiffly. “Lady Fethermondeley is seeing no-one today.”
> WITH WEATHER
“Dreadfully raw out today, isn’t it?” you remark, eyeing the guard’s soaked spats.
“All in a rainy day’s work,” the guard sighs.
> WITH COIN
You let the edge of a silver mark shine between your fingers. The guard frowns meaningfully.
> WITH ANNIVERSARY DANCE
“Isn’t tonight the capital’s centennial ball? I could get you on the advance list,” you say artlessly. The guard does not respond, but you see their eyes flicker.
The classic parser discourages using USE in this completely general way. But once you commit to it, it opens up some interesting avenues.
7 Likes
There seems to be a strong assumption that a parser game must be a puzzle game. Something I’m exploring lately is what changes can be made fundamentally to the gameplay and interface if this assumption is false, and I’m definitely implementing a USE verb as part of this.
4 Likes
I’d say paul-donnelly stated it too narrowly. The aim is to offer the player a explorable (combinatoric) range of things to do. This may be solving a puzzle, having a conversation, exploring a landscape, acting in a social/dating simulation, or, you know, lots of other game genres.
In the classic parser, the combinatoric range is verb x noun (or verb x noun x noun). In my examples above I drop the verb and rely instead on noun x noun (or even noun x noun x noun…).
4 Likes
This is kind of how Texture works.
My blue-sky desire for a parser adventure is that the player clicks on words in the description text to form sentences, or drags them on each other to combine or use-with.
See also:
A “click anything” style interface:
A game done with glyphs:
4 Likes
Early on with one of my parser WIPs, I wanted to see how far I could get with hyperlinks for default commands: Clicking a ball would EXAMINE BALL, clicking a sign would READ SIGN, clicking the name of an adjoining location would GO TO <location>, etc.
It works well for basic navigation and exploration, but breaks down for more specialized actions. So, I thought it would be mostly a link-driven game, where the player must occasionally take their hands off the mouse and type more specific commands.
The “assemblage” approach goes some way toward completing the last mile, in that the player would simply keep clicking nouns to continue an action. I would probably want to include a panel/side window with the player’s inventory, and perhaps a list of other clickable links they can access, such as conversation topics and available NPCs.
(It’ll have to be something I try with another game, I eventually abandoned the link approach.)
4 Likes