I’m developing a prototype for a game about software projects. My current game genre to experiment with is interactive fiction. With game’s basic premise set I’ve started to reflect on the types of problems presented in traditional interactive fiction games. The standard template looks like this:
- Motivation (the door is locked, the avatar cannot get to the other side)
- Material for possible solutions (is there a toolbox nearby or does it look like I have to search for the key)
- Exploration to come up with a solution (maybe sub-problems with the same structure)
- Solution (door is open, I can advance).
It is easy enough to deduce why this is the prevalent pattern of problems in interactive fiction. When the motivation is presented to the player clearly, he doesn’t wonder off o
r try to achieve something that the game doesn’t support. In order to have multiple solutions to a problem or more vague or complex problems a lot more would have to be built into a game.
Interactive fiction isn’t traditionally particularly system-oriented, rather there are specific things which can be manipulated in specific ways. All interactions between different objects in the game environment are declared explicitly without abstraction and thus there is not much room for emergent problems or behavior.
For the uses I aim at this simply doesn’t do. What I’ve come up instead is the systems thinking model of problems:
- The player comes into contact with symptoms of the problem (the key to the storage is lost once again, shelves of the store are empty, customers asking if you are out of a certain product)
- The player seeks out more information about the problem to form a hypothesis (player asks the employees when the key has been lost, examines the shelves, the work shifts, where the key is stored, what’s in the storage etc.)
- The player, having made a hypothesis, makes an action to impact the problem (3 copies of the storage keys are made)
- The player studies the changes if the system to see how the change has affected it (at first the shelves stay full but one by one the keys disappear again)
- If the changes did not have the desired effect the player starts all over (with more information and maybe a different kind of situation)
In the traditional problem model the problem diagnosis and the working solution are scripted into the game. In the systems thinking problem model I propose, the system itself has to be modeled into the game to interact with. This presents a number of problems, one of them being how to guide the player towards the potential problems and through the problem-solving process.
The big problem with this design-wise is modeling the whole system inside the game. Interactive fiction deals with language, conversations and objects and is not that well suited for building systems or simulations. For example in Inform7 there are limitations in instantiating things (objects in the game) at runtime. As the Inform7 language is flexible and object-oriented, it should however be possible to do a simple model with emergent properties.
The other option would be to make a traditional game with problems that would mimic the model of systems-thinking problems I’ve described above. That would require designing problems with more material to explore and more kinds of solutions / changes to try, but without modeling a functioning system. In short: more shovelwork, less engineering.
Both solutions have their advantages and time is an issue too. I plan to have something to show in Play4Agile 2011, so I’m leaning towards only building a partial model and mocking other facets with option 2. But I’ll keep all avenues open for now.