>I'm curious what you've identified as the root of the problem for making these sorts of parser-based games

It's not a parser based game. It's a state based game. When you have to track complex interactions with massive sets of states, nodes, and interconnections you are writing a state machine.

To truely understand that this is the case you have to see an example. As such I recommend looking at the Fallout 1/2/3/New Vegas quest flow charts that have been generated. Here are a few:

Example of describing story with a state machine: http://i.imgur.com/mAENC.jpg

Example of describing spacial directions with state machine: http://i.imgur.com/qVnEH.png

A Fallout NV mod as another example of story-as-state machine: http://www.thumbsticks.com/wp-content/uploads/2015/02/Fallou...

These should all demonstrate what I mean. All that would need to happen is for the state machine to interface with a player "inventory" and check the states of that before actions are completed. It turns most of the game logic into walking a tree and checking conditions.

> but parser-based games tend to model a virtual world of objects which your character interacts with.

That's not what I'm talking about. I'm talking about modeling the game as a set of actions that can be taken but are blocked by sets of preconditions.

> Some complications are in expressing indirect objects for verbs and in rules which only apply to certain instances of objects in certain situations -- there is always a game which will complicate your simple world model

I'm not saying to create the human interface using a state machine. I'm saying to model the story as a state machine.

> Also, what is the harm in making it so that the data for the game is Clojure source rather than some other format? "Code is data" allows for data being code. It saves having to make a state machine interpreter which you have to extend with exceptions for particular games which will eventually become a poorly implemented lisp in Clojure in the JVM.

There are many reasons to do this. For one, it allows people who aren't programmers to create stories for your engine. To take a look at the interesting side effects of this I'd recommend watching this video: https://www.youtube.com/watch?v=FnFKEWCzVCo

It's again from one of the people involved with the fallout series but he goes into how the scripting side of things enabled story writers to create an entirely different experience. When you give non-programmers a safety-scissors equivalent of a programming environment they can create cool things without bothering you.

Another great side effect is that you've abstracted your problem. You could pull your state machine code out of your game, turn it into a module and interface with it there. Any other code that you need to use a state machine will be able to now interface with it.

This is, I'd say, the most fundamental idea possible in computer science. The idea of abstracting concepts to make the project being created simpler.

Finally, there is the problem of reusability. This game is pretty much locked to it's engine. It can't be reimplemented or updated by people who don't have knowledge of the code base.

On a side note this cannot be configured to run a story safely if it is clojure code that is executed.

Basically, you're removing reusability of this engine, you're not creating a solution to the root problem, and you're making it so the user cannot play other stories in this engine: it's entirely unsafe to redistribute alternative stories since the stories are executed at the same privileged level as the rest of the game.