My apologies - I accidentally made this a private message instead of splitting it publicly, should be fixed now. - Hanon
That would be a keyword parser. There are successful games like that, like Starborn or Walker & Silhouette. But they suffer from a problem: when you type “table”, does that mean you want to examine it, climb on it, flip it, what? The philosophical question isn’t even new. Jonathan Swift points out the problem in the Laputa episode of Gulliver’s Journey. And pure OOP languages infamously run into the issue that in the real world not everything is an object.
3 Likes
Supplemental points and responses:
[1] I agree that commercial success is not what parser games are about. It is the fun of developing them, even if users might find them off-putting. However, writing for the sake of writing for yourself and expecting others to enjoy it is “ambitious.” I don’t think you will find the Great American Novel in someone’s diary.
[2] During the early 80’s, Adventure and Zork were popular among all of us at Bell Labs. We wasted miles of thermal paper on heat printers (digital screens were not available then) playing those games. Then Rogue came out (developed at Bell Labs) and it took off: it was graphic, worked on a digital screen, and visual cues were more intuitive than trying to figure out what the author wanted us to type in a parser game. (Rogue has many many more than 9 commands, but they’re more intuitive. They use natural responses to visual cues, like using arrow keys to move in certain direction.) It think that is the key to good parser and choice games: what the user thinks is a natural response.
[3] Elaborating on this: parser games need to be made more intuitive. Choice games (like Twine) use menus that are already familiar to people. Parsers require the proper verb noun combination; users do not care to second-guess the author’s (or IF 7’s) choice of phrasing. If these games are suppose to simulate the real world (as much as feasible), then we authors need to do a better job of making the input natural and intuitive. This point was made repeatedly above.
3 Likes
At this point of the debate, I think that is a good idea assessing if is worthwile dusting off an old initiative:
https://www.ifarchive.org/indexes/if-archive/starters/
I think that a new set of ready-to-play easy/introductory IF packaged together, updating the mix for the 20s, is a good idea, both for parser and choice games.
Best regards from Italy,
dott. Piergiorgio.
5 Likes
Writing games in a niche like parser IF is a bit like writing poetry. The commercial prospects are unlikely, and the audience is small but very enthusiastic. A large number of players are authors themselves and the critical engagement is much higher than you’d get commercially releasing something. Writing a text game is an entry into a rarefied scene, but it often has little traction outside that scene.
9 Likes
I dunno. What do those graphic adventures do? Just do likewise. 
The one verb in modern graphical adventures amount to “poke”. It means whatever the author wants it to mean, no more and no less. Makes sense when your input device is a mouse, but otherwise it’s not ideal. In fact graphical user interfaces are the same: the digital equivalent of pointing and grunting, as Joel Spolsky (I think?!) once wrote.
2 Likes
There’s really not much to it.
LOOK (noun): Room/object description.
LOOK me: Status and inventory. Equivalent to clicking on player icon.
USE noun: Use the item. Poke, if you will.
USE noun1 ON noun2: Drag item1, and drop it onto item2.
Note:
- Room, player, and navigational directions should be usable/clickable object.
- Conversation Topics is extra.
- If set to verbose, then room description also describes all exits and item, instead of just noting them.
- Context dependent action is good option to provide richness of actions.
That’s about it, other than go to MAIN MENU.
Of course, these are dependent upon the kind of games you want to create, but with only these, you can easily simulate 80% of graphic adventure games without having to draw pictures/sprite. Therefore, this is a good option if you want to know whether your game is fun, before spending a lot of time creating the graphics, IMHO.
Bonus:
Some interpreters allows you to click on displayed words. You can use mouse, too! Well, drag and drop kind of not supported. Hopefully that will be overcome in the future.
Edit:
Regarding conversation:
- When you drag and drop object to character, you GIVE object to character.
- When you drag and drop character to object/topics, you ASK character about object/topic.
And you end up with a hypertext game that might as well be made with Twine. Which is fine, but doesn’t solve the original problem. It just illustrates how point-and-click ate the parser’s lunch.
Try Texture, it was one of the most interesting experiments with hybrid interfaces ever attempted.
2 Likes
I tried Space Pizza Delivery. Unsure about what I think of it. Different from Twine and PnC. I’d say it’s an interesting thing that belongs in its own separate classification.
3 Likes
This is the responsibility of the author. Authors need to ensure that there are sufficient synonyms implemented, and, in the case of verbs that require two nouns, that a with-nouns-reversed version of the command is also available; POUR GUNPOWDER INTO KNOTHOLE / FILL KNOTHOLE WITH GUNPOWDER etc. This is why a parser game can take between three and ten years to make. If you’ve got guess-the-verb issues then your game isn’t finished yet. Beta testers will find these kinds of issues.
4 Likes
If you’re looking for a parser-like experience with a point-and-click interface, look no further than Gruescript. I have two Gruescript games in the works, and the process of planning and making a Gruescript game is pretty much identical to planning and making a parser game. The difference is in the playing - guess the verb (and indeed typing) are eliminated completely. I’m a little surprised that Gruescript hasn’t been more popular, for this very reason.
8 Likes
Parser games might not be commercially viable, but I believe they are actually somewhat easier to sell than “regular” games?
If I spend several years developing an FPS and release it on steam with zero marketing, it’s very likely no-one will buy it.
If I spend a year writing a parser interactive fiction in French (a niche within a niche within a niche) and release it on itch with zero marketing, maybe at least 10 people – my fellow French parser IF enthusiasts – will insta-buy it.
Sure, I won’t live with this, but 10$ is still better than 0$. (I’m sure it’s not as simple as that, but you get the point.)
Caveat: it’s possible those 10 would-be insta-buyers will have playtested my game, so I might have to gift it to them as a thanks, so in fact I will not make any money. 
7 Likes
It baffles me too. I wrote a similar engine right after DetectiveLand won the IFComp, and a demo game to go with it. People thought it was a neat experiment, but nothing more. After another failed attempt to make the engine take off, I ended up porting the game to Inform 6… and it was a lot better received.
I think maybe people who like parser games like them the way they are, and don’t need any crutches, while everyone else is just going to play a choice-based game. I’m not sure what it will take for other modes of interaction to become accepted.
5 Likes
I think part of the conundrum based on these comments is scope. All of us are familiar with rooms and what “being in a location” means - that you are allowed to interact with anything mentioned in that room’s description, except where limited by containment or special rules.
The selling point of parser is often “You can do anything you want” which isn’t quite true. A good parser will let you try anything you want but usually tell you that’s not a valid thing to do outside of standard actions. A civilian’s concept of “room” isn’t always the same as what it means in a parser game and how they are built. We don’t usually deal with granularity of position in a room and it’s assumed if you’re interacting with the throne or the table that you’re implicitly moving over there and don’t need to be so pedantic as to APPROACH THRONE. The normal “game node” of parser is a whole room unless the author has made locations like “Near the Throne”, “Near the Table”…
Parser isn’t really “do whatever you want” it’s “use the typical 8-10 basic verb commands with nouns mentioned in the description” - unless the author has made custom verbs and actions. Most authors work within the 8-10 verbs and rarely get as granular to predict things like TOUCH THRONE or MOVE THRONE or WALK AROUND THRONE - which are the types of commands a player who is told they can do “anything” might try.
I think we all work within this framework without realizing that it’s not clear to new players. It’s like when I tried to teach my mom how to use the computer and told her “Move the mouse up” and she lifted it up in the air - she didn’t have the same concept of me that the mouse is controlling the arrow on the screen and it wasn’t at all natural to her that pushing the mouse forward moved the arrow up on the screen. So I had to back way up and teach fundamentals that I wouldn’t need to with a more computer-experienced person.
8 Likes
Possibly this is a generational thing. People who discovered graphical point-and-click games first might try to apply the same rules to a text-based parser game. You and I are about the same age and encountered text adventures first. I had the first two Discworld games in the 90s and I actually found it quite tedious waiting for Rincewind to walk over to the table only for Eric Idle to tell me it was just a table. Having everything in the location be in scope is much more efficient.
7 Likes
Definitely. It’s more like the full-motion node-based MYST style adventures where movement travels the camera between “nodes” where you could turn in place and interact with anything accessible in that node.
It’s more efficient, but new people of course don’t grok that efficiency right off the bat.
3 Likes
Which, I might add, is a programming concept, complete with nesting and visibility rules. Text adventures are a programmer’s medium, not just in the mode of interaction, but the most fundamental concepts. Of course most people aren’t going to get it. Even some programmers (my friend was also a programmer). Oops!
4 Likes
Re analogies to graphic adventures and the ways that parser mechanics can start to resemble choice based ones when suitably constrained, hopefully it’s forgivable for me to plug the longish Rosebush article on these topics I wrote a couple months ago:
I think there are a lot of similarities and overlaps, and some areas where some focused theoretical and practical work could be really useful (much of it about how to avoid the lawnmowering problem of mechanically clicking USE X ON Y through every possible combination).
8 Likes
I think you’ve hit the nail on the head here. This forum is a fusion of narrative games enthusiasts of different ages and backgrounds. There are people who grew up on Infocom and kept the flame alive throughout the nineties, people like me who played text adventures as a kid and only discovered this community in the noughties, people who were part of the Twine revolution in the 2010s, retro-gaming enthusiasts that love inventory limits and looking under and behind things, and younger people who discovered all of it at once. We’re all learning from each other, finding common ground, trying different things and creating hybrid forms. We all have our own ideas about what IF could or should be. I don’t think we’ll ever agree, but the dialogue is healthy and can only enrich the medium. Long may it continue.
9 Likes