I want to start off 2017 by playing around with the idea of exploration. I gave an example of how I applied exploration while testing a particular game as well as creating a game to test the exploratory abilities of testers and even a little bit about reframing interviews with gamification in this context. I want to start taking this to the next level.
Back in 2014, I provided a series of posts about Inform 7. I digressed here and there about how this might be useful for testers. I finally figured out what I think is a good way to start this off.
I definitely need to provide some context here. Let’s start by talking a little about interactive fiction, then a little about Inform, and then a little about the design process. This will lead us to something that we can explore. As I go through this, you might want to pretend that I’m a business person telling you about the business context and problem domain.
Let’s Talk Interactive Fiction
Interactive Fiction is a form of expression which involves programming such that a reader is presented with a story that can be explored. There are a few distinctions that you might come across:
- Textual Interactive Fiction (often called “text adventures”) present the vast majority of the story in a textual form.
- Graphical Interactive Fiction (often called “adventure games”) present the vast majority of the story in a non-textual form.
- In the context of textual interactive fiction there is a division between so-called “parser-based stories” and “choose-your-own-adventure stories.” The main distinction there being between a game where you type commands (like “go north”) and a game where you choose from a list of options.
In this series of posts, we’re going to be looking at textual interactive fiction of the kind that provides a parser.
In all cases, when operating at its simplest level, an interactive fiction is simply simulating a physical world to explore. It’s this exploration that we ultimately have to allow and thus test for.
Let’s Talk Inform
Now let’s talk a little about the system we’re going to use to build this out. Here you should probably imagine that I’m a developer explaining the tooling that will support what the business analyst expects us to provide.
Inform is a specific form of tooling used for translating textual descriptions of interactive fiction into “story files” which, when put in a story interpreter, allow players to explore the model world. These story files can be played on any major platform (MacOS, Windows, Linux variants, and Unix variants). The story files can also be played via just about any browser.
Inform works by using natural language programming. This means that “natural” language is the code. The reason for the quotes there is that while Inform does provide natural language, it is still a constrained form of it, as you’ll no doubt see. Another thing Inform does is use a rule-based programming model. You can read more about Inform’s rule basis from one of the contributors.
So There’s Your Context!
We now have the basic business domain (creating text adventures) and the tooling that will be used to do it (Inform). We know what value we want to provide to users: a model world that can be explored via a parser where the player types in commands to the game, which causes the game to react in certain ways.
Regarding this series of posts, it’s that exploration aspect that we’ll work on together and see if this can be used as a fun exercise for thinking about testing and perhaps as a means to engage testers in becoming better at their discipline.
Beyond just that, I’ve often wondered if a rules-based system would be handy for testing, in terms of tooling, and I still wonder that. I’m absolutely convinced, however, that it provides a fantastic framing device for thinking about testing.
Let’s Talk Designing
Here’s where you, as a tester, have to start understanding how these text adventures are designed. This is important because any application that is built is subject to various sensitivities (behavioral, interface, etc) due to the nature of the type of application it is and due to the tooling that is used to create it. So let’s get to it.
Designing an interactive fiction is divided into two interleaved activities.
- The first thing you have to do is create the model world as it appears at the start of play. This means you establish where and what everything is.
- The second thing you have to do is to specify the rules of play. These rules effectively shape and determine how the player interacts with that world you just created.
All of this has to be presented to the player, of course. The displaying of text is fundamental to Inform providing an experience. Inform controls the flow of text being said so that it will read, to the player, in as a natural a way as possible.
During play (or during user interaction, if you prefer), Inform and the player will alternate in writing messages to each other. In the player’s case, these are short instructions; basically commands saying what to do next. Inform then has to display text indicating what happened as a result.
However, this is more complicated than it seems. As just an example, printing the description of a room to a player can be quite complicated because Inform has to consider a few things:
- All the objects that the player might have brought into the room.
- All the objects that the player might have dropped in the room.
- All the objects on visible supporters.
- All the objects in visible and open containers.
- All the ways objects may have changed due to the command.
- All the interactions of any non-player characters.
Inform then has to decide how to group and list all of these things as well as provide an updated game state for the player to interact with.
As a tester, that should intrigue you and give you some idea of the challenge. For this first post, I just want to introduce you to the mechanism. Then I’m going to leave you with a bit of a challenge.
Let’s See the Game
First, let me show a web site I created for a game I’m calling Omnia Autem Probate. You can see a basic description of the game on that page. Notice the links off to the left as well. I’ll cover a few of those here.
The game source code is freely available if you want to look at it. And you should. Please notice that the source text is broken up into volumes, books, parts and so forth. Clicking on those links will show you the source code. There’s also a link to see the complete source text should you prefer that. There’s relatively little source text there right now, but we’ll be adding to this as we go on.
And, yes, all that English is in fact source code. As stated earlier, Inform relies on true natural language programming as opposed to just natural language processing.
I recommend just playing the game in the browser although if you are familiar with the interpreters for various systems, feel free to use those, by downloading the compiled story file, which is also provided via a link on that page.
You will see a solution file for each example I post. For this first example, the “solution” is simply a set of directions that walk you around the basic map of the game and the command to look at a few objects. That map is in fact a stylized rendition of Kensington Gardens.
What this solution does, however, is give you some idea of how to interact with interactive fiction. You navigate by typing in one of the cardinal directions (“north”), including diagonals (“northwest”). You’re also seeing an example of how to examine objects (“look at the statue”). As you’ll learn, certain commands can be shortened. For example, you could type “n” for “north” and “nw” for “northwest”. You could also use “examine statue” (or even “x statue”) in place of “look at statue”.
What you should do here is take some time to look at that source text and understand how it is constructed. It is this source text that I’m going to be adding to as these posts go on. Here’s a visual of the contents of the current story:
The parts that come under “Volume – Story World” are what I’m going to have in place to make the game playable. This is what our hypothetical developers are developing based on the desired design.
Notice there is also (at the top) empty areas for “Volume – Story Mechanics”, “Volume – Story Presentation” and (at the bottom) “Volume – Story Plotting”. These are where bits of source text are going to be added as we go through some challenges.
So What’s the Challenge?
Notice how the source text mentions that the player is carrying a camera. Also notice that in this condensed version of Kensington Gardens there are a few things around (statue of Queen Victoria, Albert Memorial, ‘Physical Energy’ sculpture) that we might want to allow the player to photograph.
So that’s going to be our challenge. How do you implement a “photographing” action?
Now, I don’t mean that you have to understand the source text of Inform — although feel free to read up on my previous posts, which should get you all the information you need.
What I do mean is this: you’re a tester for this game we’re designing. We want to allow a photographing action. So what are some things to consider? What commands, as a tester, would you want to try to make sure this functionality works?
Imagine you had to write your own solution file like the one above. What commands would you provide? How would you make sure the player is in the right place to try the command?
How do you get into the head of a player of the game, anticipating what they are likely to try if such an action is available to them? And how should the game respond in those cases? You saw how the game responds to “look at” commands for the objects so consider what a “photograph” command might do or respond with.
You might feel you have way too little information to undertake this challenge. You absolutely do not. There is plenty of fodder here for exploring the idea of “photographing” in this context even without an implementation.
That being said, to help you out, besides the previous posts I mentioned and besides just thinking about the challenge of how to model a photographing action, I’ll provide you with a concise summary here of how Inform constructs its model world. These are (some of) your requirements. These are the requirements that will hold regardless of the type of action we are considering.
Let’s Talk Modeling
First a few basics:
- Inform divides space into places called rooms.
- Those rooms can be grouped together into regions.
- Inform divides time up into turns.
- Those turns can be grouped together into scenes.
In this context, time is like space. The beginning and ending of scenes are like map connections leading from room to room. The rooms are a map of geography. The scenes are a map of time.
Inform groups all nouns that it finds in the source text into groups called kinds. (If you’re wondering, the answer is “yes” — the notion of “kinds” is very similar to the idea of “classes” in an object-oriented language.) Here’s an illustration of the default hierarchy that is provided by Inform out-of-the-box, as it were:
Think of those as the available “classes” that “instances” can be created from. You can see that in the source text. There are a series of locations created (“Palace Gate”, “Flower Walk”, etc) and those are all instances of the room kind.
The passage of time in interactive fiction is broken up into a succession of turns. Each turn is composed of the the player typing a request and being given a response. After each turn, but before the player is allowed a next turn, Inform must make sure the world model is consistent with whatever happened as a result of the previous turn.
The exploration of an interactive fiction is made by a sequence of actions. The designing process comes down to responding to these actions. That’s what the first challenge is, in fact: responding to a photographing action. Every action must end in success or failure.
In Inform, rules are imposed on actions to determine whether the action succeeds or fails. The idea is that rather than objects sending messages to each other, you have a series of rulebooks in which are zero, one, or many rules. Those rules contain information about the context by which they would activate. That context is a situation or circumstance in the game state. There is a bit of a high-level distinction that it might help to keep in mind:
- There are a set of action processing rules that are used whenever an action is tried.
- There are also a set of turn sequence rules that are used at the end of each turn.
Regarding those action processing rules, there are certain rules that Inform provides which govern actions:
- Check: does the action make sense
- Carry Out: perform the action
- Report: describe the result of the action
- Before: allow preliminary activities to happen before the action is tried
- Instead: block or divert the action
- After: allow for unexpected consequences after the action has taken place
Inform starts with hundreds of so-called “standard rules” already in place. That being said, the existing, built-in rules provide a very basic sort of realism. A good example here would be that you can’t take something that you are already carrying. Another would be that you can’t drop something that you aren’t carrying.
So for the challenge, we’re looking at the idea of supporting an action (“photographing”) and providing rules that govern how this action takes place.
Here’s a big hint: defining actions means establishing, at minimum, Check, Carry Out, and Report rules that say how the action should normally take place.
This first challenge is really introductory and I’m more using this to spur thinking than I am in the hopes that people will be able to derive an actual solution. In the next post, we’ll cover a possible implementation of the challenge, which will put a lot of this in better context.
That will let me discuss a bit more about designing these model worlds, which will in turn allow us to explore testing more deeply by getting into more challenging ideas, such as implementing ropes, or things that can burn, or people that can be conversed with.
But for now … explore!