What are some of the strongest parsers out there, and how do they work?

I’m very glad you caught onto that! Yes, my initial question was very much about this, though as you clarified, the natural language processing is a fascinating part of that whole.

Which feeds into this. I’m very curious how this is handled. I can likely think of some data model which implements rudimentary physics (OBJECT has property .weight, which makes it more difficult to handle if too high, so the description on the GIVE command changes), but someone must have thought about this for a good long time and figured out a better way to do this, which handles commands like REMEMBER INSERTING TWELVE COPPER PENNIES INTO COIN ACCEPTOR or TAKE PATANQUE BALL AND THROW AT TROLL'S NOSE elegantly. Or at least with sufficient smoke and mirrors.

Because, knowing what I do about open source software and passionate communities, I could imagine at least one system has a community maintained object definition library, so all the writer needs to do is declare the list of objects and definitions in a given room. And this might be a weird parallel to draw, but Scribblenauts had this in a way, where an object would have a set of properties that allowed it to act with or on other objects.

You might like Emily Short’s Some Observations on Using Inform 7 about how it offers more ease and power than Inform 6 (article on Brass Lantern, not her own site, so you may have missed it).

2 Likes

This seems either not that different from what systems usually do—except in much more detail—or else is poorly explained.

1 Like

Possibly, I am currently reading into how different parser languages handle different objects or world states. Please understand I have very little understanding of parser architecture at the moment, and don’t know how much comes packaged in by default or how much an author needs to explicitly define.

1 Like

Not sure if this helps, but: Parsers have some builtin flags/booleans for objects like if it can be taken, if you can put something on it, or in it, if it provides light, etc. Edit: The game writer defines the flags for each object (and there are default values).

Afaik there’s no library with readymade items like “bucket”, “torch” etc.

2 Likes

From an historical perspective, you might find Ken Reed’s seminal article that featured in Practical Computing magazine in 1980 interesting. It was inspired by the “original” Adventure and the work of Scott Adams.

That article, either directly or indirectly, inspired the majority of parser-based adventure systems in the UK; such as The Quill, PAWS, Trevor Toms, Adven-80, GAC, etc.

This sort of system (where the input is extracted to its key words, conditions are checked and then specific actions carried out) is very simplistic but still quite powerful.

2 Likes

Inform 7 has kinds of things built in. For example, you can create a new object and declare in the code that it is a room, or a door, or a container, or a supporter (something that can have other things put on top of it), or an animal, or a person–those are all recognized kinds. When you say in the code

A dusty cardboard box is a container.

that will create a new thing called “dusty cardboard box” and will assign it certain properties based on the fact that it’s a container. You can also customize the properties of an object, and create new kinds of objects with their own default properties.

Inform 7’s documentation has code examples of how to make various things (like identical objects that the player can paint different colors), but like Pebblerubble, I’m not aware of a library of pre-made objects.

In designing puzzles and the game world, though, I would think that even authors who were starting with pre-made objects would want to make changes to them and customize them. Designing the game world is part of the fun.

Also, in my experience, parser games don’t tend to have lots of generic objects lying around in the game world. If an object is important, I would expect it to have a custom description and possibly custom behavior. If an object is not important to the gameplay, it may simply be left out of the world model. Trying to account for all of the ways objects can interact with each other, and what actions the player might try on different objects, and what might go wrong, is a lot of work for the author. Having lots of extra objects around can also be more work for players as they are figuring out what to do next.

2 Likes

This unfinished series of blog posts has an overview of how ZILF’s parser works:

3 Likes

It’s handled less than you think! In most games, this weight property would be entirely irrelevant. Any restrictions on giving particular items to particular NPCs are very likely to be implemented by making particular NPCs only accept the items they are supposed to take.

I totally agree with @Draconis that the big draw is systematicity, but much of the time, the system is in your head. A general model of the system is only in the code if implementing that model is necessary to enable the actions the player is supposed to take.

I actually meant that as an example of a linguistically complex command, rather than a command that’s involved to model. It’s not obvious what REMEMBER would do—maybe this game is about discovering trivial details about your character’s prior actions in order to trigger “cutscenes” about those events—but suppose I hadn’t written this word. You’d probably model inserting coins into a coin acceptor by removing the coin object from the world, and incrementing a coins_in_machine variable.

Not really, or at least not in the way I understand you to mean. I think you’re picturing parser games as being more general, and more generic than they normally are. Throwing a bunch of assets from an asset store into a room just wouldn’t connect at all with what authors are generally trying to accomplish.

You might like to browse through the TADS3 Library Reference, which goes pretty far in the direction of providing classes which implement things you might want your objects to do. Then you could compare to the Dialog Standard Library, which is 5261 lines of code and doesn’t have most of that stuff. Dialog is pretty popular these days, which is an indication of how much world-modeling the average game actually uses. And notably, neither makes an attempt to include a library of real-world objects.

3 Likes

Even the simplest parser systems, like the Scott Adams database format, basically always have some way of flagging whether objects are portable or not: being able to take things and drop them in different rooms has been a hallmark of the genre since Colossal Cave. State tracking in a Scott Adams game is limited to the locations of the player and each object; a big pile of boolean flags; and a small number of integer variables. So the game handles picking things up and moving them around, but beyond that, the author has to do everything themself—there’s no conception of objects having individual properties, for example, beyond their location and whether they’re portable. So if you want three different pieces of clothing that can be worn, you need to make three separate global flags and track them individually.

More advanced systems typically extend this portable/not portable distinction to other things. Most of them will have a “container” option in the standard library, for example; set this flag on an object, and you can put other things inside it. Or “light source” (lets you see in the dark), or “edible” (lets you eat it), and so on. The majority of objects in your average parser game are singletons (there aren’t a lot of identical copies of the same thing), but these represent traits shared between many objects: there may be only one apple and one pear, but they’re both edible, both portable, both lightweight, and so on.

Dialog, for example, has standard traits for various linguistic purposes (“name starts with a vowel”, “proper noun”, “plural”, “pair”, “unique”, “uncountable”, “belongs to you”) and world-modelling ones (“can put things in it”, “can put things on it”, “player can fit in/on it”, “counts as a location”, “connects locations”, “vehicle”, “is a direction”, “is a relation”, “animate”, “can be opened”, “can be locked”, “opaque”, “portable”, “wearable”, “male/female/gender-neutral”…and more!).

This means that, while there’s no standard definition of a mailbox—the details will depend on the game, after all!—you can build your singleton mailbox and immediately tag it with “unique”, “belongs to you”, “can put things in it”, “openable”, “not portable”, “not lockable”, and so on. That’ll get you a lot of the behaviors you want without needing any special treatment. Authors can also create their own traits for their own purposes, and most do!

3 Likes

Thanks @paul-donnelly and @Draconis, this clarifies a lot. I have been reading the Dialog manual (as it seems especially popular in this community) and information on both TADS 3 and Inform 7. This all clarifies a lot, and I think I might dig around in the source code for Dialog to see what I can learn from it.

1 Like

I will say, part of Dialog’s popularity at the moment is that I’m talking a lot about it! Inform 7 is still significantly more popular overall. But if you’re looking for a well-documented world model and parser, I maintain that Dialog and TADS are a better choice than Inform; Inform’s is very powerful, but also very opaque.

1 Like

I must admit, I like the way Dialog maintains a rigid logical model of the world. I think I’ll run some experiments with it.

Yeah, this is why I linked those two in particular. Inform is very popular, but maybe the library is less easy to browse online. ZILF deserves mention for a having a pretty simple world model as well, and for using a straightforward functional style (as opposed to a complex object model or rule engine).

4 Likes

Yeah, the fact that you can open up the source of the Dialog standard library and read how everything is implemented is huge. And the language, while initially weird-seeming if you’re used to imperative programming (hello choice points and automatic backtracking), isn’t that large, so you can get your head around most of the relevant details in a couple of days.

I gather T3 has the same open stdlib with a possibly more conventional programming language, but I’m sorry to say I’ve never looked at it in detail. Inform 6 (standard or PunyInform) also gives you the option of looking under the hood in a way that Inform 7 doesn’t, although to properly understand Inform code you need to know more about the architecture of the Z-machine.

2 Likes

And of course, modifying the standard library is easier in both TADS 3 and Dialog than it is in I7.

2 Likes

There was a school of thought in the early 2000s that this kind of detailed world modelling was the obvious direction of development for parser games. The idea was that having a kind of “physics engine” that could model interactions between objects based on their material properties would open up new options for puzzle design.

That gave us Metamorphoses, but otherwise didn’t catch on to the extent some people expected. I think most people find it more rewarding to solve puzzles that have been designed by the author to have a specific solution, rather than by throwing a bunch of objects into the world that happen to combine in a way that does what you need. If good puzzle solutions are “surprising, but inevitable in hindsight”, the physics engine approach has trouble generated puzzles that meet the “surprising” part.

3 Likes