This has much more to do with design ideas then concrete code, but I wonder if drop down menus to select different verbs and objects would be an elegant implementation of this (having objects appear in the menu once they’ve been mentioned so you always know what verbs and objects you can use but not know exactly what might work). I had mentioned the game Degrees of Lewdity in the original post on agnostic design and that was another thing I thought was interesting about it compared to an inform game, as during it’s “combat” encounters you can select in a drop down menu several different verbs for your different body parts to do.
I think a strength of this sort of approach is you can get the unique uses of verbs one might not expect exactly such as in inform. One example that just came to my head is having look as a very from the beginning,perhaps it’s usually just used to get more info about the location one is in, but then when in a room with a telescope you could then look at other rooms you aren’t in. So all of the possible choices are still presented to the player so they are never truly lost, but you can still have these sorts of puzzles or just dynamic usage of verbs.
Edit: Another thing to note with this aproach is that I believe this would follow the Match-Cond-Action format more so then Cond-Match-Action as you could have actions that do not match that the player can try. For example with the look example, trying to look at a room you aren’t in while not in a room with the telescope could be attempted by the player but result in a failure. But obviously if there is never a telescope in the game and thus never added to the menu the player can never try to use it, where as in parser games you could try to look through the telescope in any game even if the parser just yells at you (I don’t think this is a big difference but for some people with some designs this could be important).
Final edit I promise: Another thing that occured to me is that this can also be a great way to ease players in to new verbs, instead of having them all available at the beggining, new mechanics through verbs can be slowly added to the menu through the course of the game. Obviously some games will be fine having all the verbs available from the beginning but I could definitely see how this could be helpful in a puzzler for example where puzzles may start off very simple with only one or two verbs to use to solve them, and then slowly over the game more are added until at the end of the game you are using dozens of verbs to solve them.
Definitely. If you’ve played any Legend games, they had parser and elevator menus for verbs and nouns. Some people did complain the explicit list could be spoilery.
I’m also a huge fan of early SCUMM. Even though they were graphic adventures, you could construct a sentence clicking verbs and images in the picture or items from inventory. This led to some very satisfying haptic interaction, such as searching a dark screen for a light switch since the sentence would complete with whatever object the mouse was on, even if you couldn’t see it.
I’ve always thought the ideal interface would be SCUMM-like but without pictures, where the player could click any word in the prose to create a sentence which would then be parsed.
I have played a game where there were no explicit links, but clicking any word would bring up either a authored “nothing to see here” message (perhaps the definition of the word, or a treatise on conjunctions) or interaction links for interesting words. It was unique because it discouraged lawnmowering. Any reference to a character would let you talk to them, clicking an noun might give a message for examine, or allow you to open a box or pick something up if it were allowed.
I think the slow introduction of objects and verbs over time can help with spoilers, the problem I think is balancing that with design philosophies such as fallouts, go anywhere any time kind of philosophy. So it becomes a matter of balancing the characters knowledge of locations, objects, people/creatures and the players. I think an example of an elegant solution in this regard is having places reachable through both exploration, and knowledge of the place. So for example a character who knows where Blue Hell Bar is could ask about it and could travel quickly to it such as through clicking GO TO then BLUE HELL BAR but then a player who’s character doesn’t know about the bar could still traverse to it because they know the directions they need to follow to get there (here you could also gate content by difficulty such as fallout where experienced players can still get there through skill but inexperienced players are dissuaded). I think with verbs this can balance can be less important since it’s possible to use verbs in a lot of interesting ways, the hurdle that immediately comes to mind is you can’t have some crazy verb thats only used to solve on puzzle in the sidebar but I think thats actually a good thing, in that verbs then need to be more generally applicable, so I guess what I would suggest is just having a smaller pool of very general verbs so you have an idea of what they should do most of the time, but they are general enough where you can create scenarios where they work slightly different to have the player think outside the box. (In the other thread an exmaple scenario was having the character swallow a key card to bypass a lock, including swallow as a verb and only using it here would stick out to the player but in a game where the eat verb was somewhat regularly used along with a few other verbs this then goes from a wacky puzzle that no one would probably think of in a parser, to a kind of spoiler option, to then being a unique way to use one of the verbs in your tool belt thats is thinking out of the box but isn’t as ridiculous).
Again I should state I have 0 experience coding in twine but I think this could be doable in it in a hybrid system of what I’ve mentioned before where one could instead select a verb from a drop down menu in the passage then click the object in the passage. (Not to say using twine instead would be better necessarily but just to bring it back to Twine). A problem I do see here though in this hybrid approach/ is that all interactable nouns have to be in the passage which would break the telescope example, or at the very least make it spoilery.
This might actually work in parser with a continuous scroll (no screen clearing except for major scene changes?) Though I can foresee if we want to ASK AUNT MATILDA ABOUT THE MYSTERIOUS COAT, one would have needed to open the closet to generate the text to know that there is a mysterious coat, and they may have to scroll three rooms back from where they encountered Aunt Matilda to click on the coat to complete their input!
That’s kind of the point where ideally you’d like the player to be able to type in MYSTERIOUS COAT if necessary, or at least have an inventory item “memory of the mysterious coat” to click on.
I think this would work amazingly for games that have this design as their core but would not work well as a general agnostic design. I think the main limitation is that this would work best with only a few rooms, or at least only a few available to the player at a time. I think this would especially be a good system for a game set in one house such as a murder mystery or even paranormal game (perhaps you can actively see doors in other rooms getting opened and closed and so then have to rush over to investigate, or in a murder mystery you can see the description of the room you are about to enter as it was the last time you were there, then when you enter you try and figure out what all has changed). I think this would also work very well in a puzzler where each puzzle may be a room or two split into a couple of rooms you can see at all time so that when you flip a switch in one area you see how it changes the mechanics in other parts of the room.
With too many rooms though I think it would quickly get overwhelming for the player if it was a often used mechanic and if it wasn’t used often it might be hard to know when is the right time to use it.
Just a little hint in case people are actually interested in implementing Twine Parser.
The COND-MATCH-ACTION is useful in staging input, too. Simply put, add these CONDs:
If VERB==“” then ShowVerb
If VERB!=“” and NOUN==“” then ShowNoun
If VERB!=“” and NOUN !=“” then ACTION.
Depending on how you implement it, there may be lots of copy and paste source code involved, and you’ll need to filter out duplicates. But this is an easy way to create 2 word parser in Twine.
Note:
You can use explicit verb in number 2 e.g.
If VERB==“GO” and NOUN==“” then ShowExits
to properly show only valid nouns associated with the verb.
Edit:
Number 3 is basically standard MATCH, so it should be normal pattern. This suggests the appropriate placement for these checks. Just a suggestion.
Edit:
Come to think of it, this method can be useful for something like ScottKit/Adventuron/Quill too. You can use it to hint available VERBS as well as NOUNS associated with said VERB.
