I’m an amateur developer and I am trying to write a simple parser. I do not need any coding advice, but since my choice is an IF parser, I have a couple of questions about the minimum required in interactivity for a game to be able to present puzzles. So in my parser I can take items, drop items, open doors and some basic cosmetic things like look or examine. I am going to add a use option so once a player picks up an item of course its important to be able to use it. This is not too difficult. Other than that, a player can go from room to room for basic travel. Now, in terms of the parser having those minimum options and also moving around, if you think in terms of puzzle design, then is this enough to create complex game puzzles? I am not looking at this from an authors point of view, since I have little experience in that. From a programmers point of view, many things can already be done with this. So what kind of examples should I be looking at online at both the developer level and designer level to be able to say that → This game can be made in this system and it can be rewritten in that system. Is there a rudimentary design specification that is common ground on the subject?
There are solid IF puzzles that rely on nothing more than TAKE, DROP, and movement commands.
Really, you can create complex game puzzles with clickable hyperlinks. You can create complex game puzzles with four arrow keys and the space bar. That isn’t the barrier.
When we talk about requirements for an IF parser, it’s a matter of what allows the author to feel comfortable building and customizing the game world. That’s hard – a really good parser is a lot of work. But if you’re making a simple parser for your own satisfaction, that’s fine too. You just need to think about what kind of puzzles (or other story) you want to write, and then figure out how to build it.
I will add that DROP is optional. It used to be GET X, USE X, although USE can actually be automated 
. LOOK command is also appreciated.
But it’s helpful to also have HELP, and QUIT.
For more actions that are commonly understood in parser IF, you could check out the How To Play IF postcard: http://pr-if.org/doc/play-if-card/
Some commands from that card that I think are notable, and that I don’t think have been mentioned yet in this thread:
- inventory
- put something in something
- put something on something
- push/pull something (like a button or a lever)
- open something (you mentioned opening doors, but a player might expect to be able to open a drawer or another container as well)
Maybe also “unlock something with something.”
“Push,” “pull,” and “open” could be covered by “use,” but players who are familiar with IF might expect the more specific words to be understood. I don’t think the command “use” is very common in parser IF.
And if there’s an NPC, I think it would be very common for players to try to talk to the character or give something to the character.
Zarf’s play-if-card mentioned by bg above lists most common commands found in parser IF.
You can also check Jason Dyer’s verb list that he uses in his All the Adventures project.
Standard/alternative libraries of Inform/TADS/Dialog and other development systems might contain more choices if you are willing to delve into them.
Awesome, that’s plenty for me to digest for a while. I will be working on NPCs next and the mention of USE as not being common in parsers is interesting, I am trying to understand that at the moment.
I’ve been looking into this same sort of question and the best (and most accessible) resource I could find for a rudimentary authoring system is Adventuron. You can read the documentation and use the online editor to see it in action.
Instead of trying to figure out all the basic verbs, allow the author to create their own verbs and apply code/conditions to matched verb + noun commands. Then you aren’t limiting the author or story at all.
Food for thought.
One of the problems with use is that it is a general use verb with a lot of applicability, similar to search/look under/look behind.
All of those commands increase tedium for players. For example, once they find out that search is a required verb for the game, they start trying it on everything mentioned in addition to examine. Such brute-force methods effectively turn the game into a non-spatial maze-fest.
Edit: Typo.
Thank you for setting that straight, it was so obvious I missed understanding it. That is immensly helpful though. I am only now updating from a switch/select to a more organized word sort for parsing.
I did just that when I wrote my parser.
First, it checks the line the user inputs for correct English syntax by using a state machine (hey, I wrote it 30 years ago).
E.g. “article - adjectives - noun - preposition - adjectives - noun”.
The interpreter has some very basic functions like move(), print(), owns(), setflag(), testflag(), ….
The author uses these functions to create their own verb handling, depending on the situation.
E.g getting a subject:
if (owns(player, subject) then
print(“You already have the subject”)
else
if ( not(testflag(subject.takeable)) then
print(“You cannot take that.”)
else
move(subject, player)
print(“Taken.”)
And you can write specific handlers for specific objects. Let’s say picking up a sharp object;
print(“Better not, It’s very sharp. You might hurt yourself.”)
So, there’s no knowledge about the world in the interpreter, just the basic actions. The author brings in the world’s properties in the game code.
Hope this helps.
I’ve not long written a simple parser myself - one that I wanted to be general enough to allow players to experience objects across which they encountered in an expected way, regardless of whether it would be relevant to the plot/story/puzzle. For example, if there’s a chair in the game, it is reasonable that a player would expect a custom response to SIT CHAIR, even if they do not need to sit in the chair to progress the game. So SIT entered my parser’s general vocabulary (which means you can also SIT on other things, too, not just chairs).
There are some useful perspectives and resources you might find interesting in this thread:
It seems what you’re really asking is not, what is the minimum parser, but what is the minimum world model.
Ie what is the minimum set of properties for a nontrivial game.
Because, regardless of the set of verbs supported by your system, commands must nevertheless map onto representable changes of world state.
Let’s start by considering verbs like: inv, get, drop, go, put. These are all supported by the property “in”. If A can be “put in” B, then;
- get X = put X in player.
- drop X = put X in here.
- inv = what is in player
- go X = put player in X
So we get a long way just from “in”.
Adding the property “on”, allows things like wearables and tables or surfaces. also chairs.
- wear X = put X on player
- sit on X = put player on X
After that, you can add open/closed for doors and containers.
And i think with just these few properties you can support a wide range of verbs and commands.