4 ms·

I'm curious what you've identified as the root of the problem for making these sorts of parser-based games. It sounds to me that you'd rather it be a choose-yo

• gravypod 10y ago
  >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 http://i.imgur.com/mAENC.jpg Example of describing spacial directions with state machine: http://i.imgur.com/qVnEH.png 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/Fallout-New-Vegas-flowchart.png 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 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.
  • kmill 10y ago
    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