By "parser-based" I was referring to terminology from the interactive fiction community. A parser-based game is one whose primary mode of interaction is a pars

By "parser-based" I was referring to terminology from the interactive fiction community. A parser-based game is one whose primary mode of interaction is a parser reading user commands. I agree that there is an underlying state machine, but that's true of any program. I was saying that modeling the state transitions for these sorts of games tends to work out better for authors when using an OO-style model, since the game is simulating a player object interacting with other game objects. Making a system to help organize running certain logic on certain conditions is exactly one of the goals of blah-orientation, where "blah" is object, functional, state machine, or whatever. I've seen state transition diagrams like the ones you mention for the design of interactive fiction, but only for high-level design. The interactions between objects in these games tends to be too complicated to completely describe that way. For instance, does the player character see anything in a room if they put their only light source inside an opaque closable container? What if the player is inside that container? Puzzles in IF quite often use emergent behaviors of simulated environments, and there are large standard libraries for them in, for instance, Inform 7 or TADS. Ok, so what I'm gathering is that you have identified the root problem of these sorts of games as being organizing the story as a state machine, making it so that non-engine authors are able to make trusted content, and making it so the engine can be reused. But I think an adventure game engine is more along the lines of the underlying game engine for Fallout 4 than the code inside Fallout 4 which helps drive the story. For instance, where is the crafting system implemented? Is it really thought of as a giant state transition diagram? I find that difficult to believe. Again, I believe you are thinking choose-your-own-adventure rather than this genre of parser-based games. CYOA games tend to just disallow disallowed actions, but parser-based games with a modeled world tend to attempt reasonable responses to any (reasonable) action. Whether you agree games should support these sorts of interactions is a different question from whether these games should be implemented as state transition diagrams. And sure, with this Clojure-based engine arbitrary code can be executed. There are a couple differences between this and Fallout 4. The first is that the cost of making interactive fiction is much less than a game like that, so one or two people can easily produce one, reducing the need to abstract game logic to a separate language. The second is that the engine can be compiled into the game for distribution, just like most other games. Also, it's conceivable that the game could run in a locked-down virtual machine. The old Infocom games ran in a bytecode interpreter that their in-house Lisp-like language targeted. In the modern day, people still distribute interactive fiction in the same (but somewhat modernized) format. > 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. I agree that abstraction is powerful and can make things simpler. But it also requires the correct abstraction, and I'm just not convinced that modeling interactive fiction games using state machine diagrams is actually simpler. I found the discussion of ontology problems in the Inform 7 white paper interesting: http://inform7.com/learn/documents/WhitePaper.pdf http://inform7.com/learn/documents/WhitePaper.pdf