We're making choice-based games. So let's think about how to model a world with choices. The first option that comes to mind is the venerable state machine. Player choices come in and determine transitions along edges. So, perhaps, we have a game where the player is exploring a few rooms: [ exit ] - [ ] - [ ] - [ start ] The state machine seems like a good abstraction so far. We can write displays for each state (say, a picture of the room and some description text), but if we get a bit more complicated we can see that the state machine runs out of descriptive utility quickly. Let's add two keys to the middle rooms and make it so the player needs them both to unlock the exit door. [ exit ] - [ red key ] - [ blue key ] - [ start ] Now a state machine abstraction has a problem -- our state space is now the product of ( position, has red key, has blue key ) 4 * 2 * 2 = 16 states. We can draw them all out, but that's cumbersome. So we need to start thinking of a formalism that's a bit more flexible. One I like for this is linear logic. Linear logic is a logic of limited resources. The idea is that we have a supply of resources, and a series of rules that transform those resources (consume some, produce others). So, in the room case, we might have resources like: in-exit in-red-room in-blue-room in-start have-red-key have-blue-key And rules like: start: start-the-game -> in-start walk-west-1: in-start -> in-blue-room walk-west-2: in-blue-room -> in-red-room walk-west-3: in-red-room -> in-exit walk-east-1: in-blue-room -> in-start walk-east-2: in-red-room -> in-blue-room walk-east-3: in-exit-room -> in-red-room take-key-1: in-red-room, ~have-red-key -> in-red-room, have-red-key take-key-2: in-blue-room, ~have-blue-key -> in-blue-room, have-blue-key exit: in-exit-room, have-blue-key, have-red-key -> did-win Note that ~have-red-key might seem like an extension, but we could easily "de-sugar" it to "not-have-red-key" and do the proper book-keeping. Notice how this is a much cleaner way to talk about choice in general. Indeed, with a bit of modification, I bet we could build a decent dialog/narrative engine around a linear-logic-like rulebook. Indeed, this formalism is *more powerful* than a state machine because it can represent infinite state spaces (how?). We might go further (read Chris Martens' thesis -- they did a good job of expanding out these ideas), but for now let's see if this inspires us to design a better narrative/dialog system. --------------------------------- Some ideas: (a) might make sense to maintain an overall state machine or several -- one of the things that's cumbersome in raw linear logic is modelling things like "where the player is". (b) probably want to associate words with transitions -- maybe a name for what they are, and words for what happens when they are activated(?) (c) think about what the main loop looks like. How does it print or describe the state? Does it look at tokens? Does it run a rule?