Player Experience Report (Theme: Protagonist Mental Model)

I thought some of you may be interested in some of the game design discussions that stemmed from some of my classes that worked on the “Trinity Reimagined” concept. (For those who don’t know, the idea was to take Infocom’s Trinity and rework it with a more defined protagonist and putting some of the more fantastical elements of the game into a better story framework that was backed up by moral premise.)

In short, there was a dual focus in this class on crafting the game with a storytelling focus (i.e., using effective storytelling techniques) and playing the game as a story. It’s the latter that I’m reporting on here. (These observations are not just confined to Trinity as other works of textual IF were played to gather opinions and to make speculative forays into the player experience.) This was interesting because, of course, it shows what people not used to some of the conventions of textual IF from the past will expect or at least attempt. This is probably going to be a long post.

[size=150]LOCATIONS / MOVING AROUND[/size]

People always, always, always expected to be able (and wanted) to do things like this:

  • Go to the {room}.
  • Find the {room}.
  • Get to the {room}.
  • Go to where the barrow wight {is|was}.

That’s not too hard to understand. A lot of related elements came out of this, however.

People, for the most part, did not like location descriptions that mentioned a slew of exits. They would rather have a list available that just showed the exits, but where the list was situationally updated. Here’s how that broke down:

  • If you (as player and protagonist) didn’t know where an exit went, the list would just show “EAST”.
  • If you (as player and protagonist) did know – having been there before – then have it say “EAST - TO PALACE GATE”.
  • If you (as player; from past play) knew but you (as protagonist) did not know, the list would just show “EAST”.
  • If you (as player) did not know but you (as protagonist) did know, have it say “EAST - TO PALACE GATE”.

This was not something people wanted in game text, such as in the room description. Rather this information was displayed in a separate window or on the status line. That being said, people weren’t often thrilled with the “status line” – which they felt didn’t really offer “status” of any sort. (Yes, score and turns could be considered status but most people felt that reflecting the turns was hardly something that mattered – I agree – and that scoring didn’t make a lot of sense, in that scoring detracted from the story.)

What people indicated they really liked was what we initially ended up calling a “situational location/compass window.” (This name got shorter and combined with descriptions; more on that later.) This window would show your current location name. It would show exits from that location with the above mentioned context based on player or protagonist knowledge.

People did like the idea of relative directions (“to the right”, “to the left”) but more so in terms of descriptions. They liked the ability to “turn around” and “look to the right” or “look up”. They didn’t mind typing “go to the right” or “go straight” or “go back” but they also preferred to just type “go to the {room}” when the room name was known or something like “go to the left exit” if the room name wasn’t known.

I found this interesting simply because “go east” or “go west” seemed much easier. When I brought that up, people agreed it was easier but then said, in that case, they found it easier to just say “go left” or “go right” assuming it was clear where exits were. Then once the connecting room name was known, they would use that room name (“go to {room}”) from that point forward, not having to rely on “right”, “left”, “east”, “west”, whatever. (They also felt this helped keep stories paced a bit better because someone could traverse lots of geography relatively quickly.)

“But,” I said, “I thought we didn’t want exits listed in descriptions? So how would you know whether to go right or left?”

The response (boiled down and paraphrased):

  • If the protagonist or player does not know where connections go to, it’s fine to have this: ‘To the left and right are doorways leading out of the room.’
  • If the protagonist or player knows where connections go to: ‘To the left is the entryway to the living room; to the right is the hall leading to the bathroom.’

However, people really only wanted to see that once. Once the information was known, it was felt it should go in the situational/compass window and not have to be displayed in the room description again.

So what I did is go with the idea that you as player (acting as protagonist) would make a mental model of the room and then store that in your mind, not having to have it “described” each time. You would simply “know” it as you went into the room. The situational/compass window would represent sort of “your protagonist’s mind” or “your contextual knowledge.”

Keep this in mind because this “mental model of the protagonist” comes up a lot.

[size=150]EXAMINE vs. LOOK AT[/size]

“Examine” is very, very rarely used. In fact, it was never used unless someone already knew that convention or had read instructions saying to use “examine” as a verb. “Look at” was always attempted first.

[size=150]LOOK AT / EXAMINE vs. READ[/size]

When “look at” was used for paper, sign, or anything with writing, the expectation was always that an “automatic read” would take place. As people (rightly) pointed out, it’s hard to look at writing without reading it. It’s sort of built-in to our brain. Again, the mental model of the protagonist: once you’ve seen it, you’ve read it. Even seeing it again means you would naturally and inevitably read it again.

[size=150]WHO IS / WHAT IS[/size]

Commands like these were tried very often:

  • Who is {character}?
  • What is {object}?

The responses to these, it was felt, should always be part of the narrative, and not the “game talking at you.” So the protagonist might say, “Oh, that’s Jones. He was my best friend. Well, sort of.” If the protagonist didn’t know someone or something that should be indicated, even if it’s just a simple “I had no idea what that was.”

What people also expected were commands like these to work:

  • Who have I met?
  • What have I seen?
  • Where have I been?

Having a separate window that could show the “who have I met” was found to be something people liked, since it sort of kept a list of characters (from a game perspective) but also matched a person’s mental model (such as when you are introduced to people at a new job or a party or whatever and you try to keep straight who’s who). Players didn’t like the information overload of the other two elements being shown in a separate window, however, but they did like if the above commands would then produce a list. (Some suggested that “Where have I been” could bring up a graphical map.)

Here’s another one people expected to work, based on the number of times I saw it (or something like it) tried:

  • What has {character} {talked about|mentioned}?

This obviously only mattered in games where the conversation actually mattered. Players responded well to in-context clues about whether a subject was worth exploring. Something like the protagonist (via game) responding with:

“I’ve talked to the butler about the murder weapon that was found, the messed up room, and the rudeness of the police. I got the impression that there was nothing more to ask about the weapon or the room. He did seem to want to talk more about the police, though. I also might want to ask about when the police were called.”

Notice I’m doing the first person thing there? This will come up more in a bit. But as I’ve long argued, textual IF seems well-suited to being a conversation between the player and the protagonist, such that the player is almost acting as the subconscious of the protagonist. (More shades of the mental map.) Writers that I’ve worked with are particularly intrigued with that aspect and readers/players – while not indicating this was desired in those exact words – seemed to prefer levels of description and narrative that suggested it nonetheless.

[size=150]COMMAND PROMPT[/size]

People hated that it was called a “command prompt.” I ended up using “interaction point” and that at least seemed to work better. (Earlier I mentioned people didn’t like “status line” either. Textual IF, I believe, really needs to rethink some of its conventions if it wants to be relevant to new and different audiences. That being said, I still think “interaction point” might be too much of a mouthful.)

Beyond nomenclature difficulties, more variation in the command prompt/interaction point was preferred. People responded well when the interaction point was contextual to some extent about what interaction is occurring. So if you’re in a conversation with an NPC, for example, have that reflected in the interaction point ("[TALKING TO NED] >"). A prompt/point that always was the same thing was found to be annoying and quite off-putting for most audiences.

Some even liked the idea of having the prompt/point reflect a goal if that was what the player was doing. That proved to be really tricky, though, in that if the player started doing other things, they might be going off on a different goal – without even realizing it. In Trinity this was easy in some locations (i.e., “[ESCAPE SPACE STATION] >”) but not in others, such as when you were exploring the land of the toadstools. The player could be doing numerous goals of their own that don’t quite match to the game goals. Some players felt this was a way, however, to direct the player. So in areas where it was more “free play” until a goal was found, have the prompt/point be just nothing or something simple like “[EXPLORING] >”. Others felt that perhaps “story rail lines” could be established as part of the game that would recognize when a player seemed to be trying to achieve a given goal. This would serve as a clue to players that they were on one track versus another and may serve as a form of constant “hint.” We’ll be exploring this in the next class. Oh, and people did agree that the prompt/point should be allowed to be “simple” or “contextual” based on a setting. That way you could just have the simple “>” if you wanted it.

[size=150]VIEWPOINT and TENSE[/size]

Everyone – literally everyone in these classes and studies – felt that the game itself (by which they meant the parser) should be in second person: “You can’t refer to that.” and so on. People were fine with being addressed as “you” in that context and didn’t feel it detracted from the story; on the contrary, it kept them focused. However – the narrative itself was overwhelmingly found to be disengaging when in second person – except for those who already had familiarity with the convention. Having “you” be both “you the player” and “you the protagonist” was found to be a way to quickly get people disengaged in the game except as a brief diversion, almost no different than doing a crossword puzzle.

First person, past tense was the overwhelming preference by just about everyone. First person, present tense was the second runner up. Third person, past tense was the third runner up.

[size=150]IMAGES / SOUNDS[/size]

Images/pictures were found to be annoying – unless the images were very well done and conveyed the location accurately. When images that did this were provided, too much text describing the location was found to be annoying. What was preferred in these cases was more atmospheric text that couldn’t be conveyed by the picture. But what about the locale information? (I.e., the “You can also see…”) People much preferred that to be off in a separate window, except to the extent that people had good description skills and were able to weave what was in a room with effective text describing the other elements (like atmosphere and so on).

Sounds and music were pretty much universally disliked and found to be unnecessary.

That point about weaving locale elements in with the description led to something I was curious about and experimented a lot with and that’s the next point.

[size=150]CHANGING DESCRIPTIONS[/size]

People didn’t mind if the descriptions had to change and thus they had to read them again to find what may have changed. However, this was only the case if the descriptions were well-written and served to bring the player into the “mood” and “atmosphere” of the location. People liked the following idea that we tried with “Trinity Reimagined”:

Upon first visit to a location, have the full mood/atmosphere description, along with any relevant locale information interspersed within that text. (This builds the mental map/model of that location.) Then have that information populate a “locale window.” The locale window would, of course, change for each location. This then led back to the situational/compass window I talked about earlier. Was the “locale window” and the “situational/compass window” the same?

Yes, people ultimately felt that it was. So the goal was to have the window present something like this:

NAME OF ROOM
[list] exit list [in the contextual way mentioned earlier]
locale items
[/list:u]

The main window could still display the atmosphere and mood text. People liked this because they quickly trained themselves to read the main text to ground themselves in the geography as they played (and to keep themselves in the story), but to glance at the “Locale Window” to remind themselves of game specific stuff. People felt this didn’t take them out of the story at all – rather, it allowed them to focus on story where necessary but also actually play the game. The idea of the window being the “mental model” of the protagonist seemed to serve this well.

[size=150]SUMMARY[/size]

I have no summary of all this really. This was more just to present it for what little it might be worth. There’s obviously a lot more detail but I was worried this post was getting too long as it was. This should, at the very least, give the flavor of what people seemed to respond well to, what their expectations were, and a general idea that was settled upon as a metaphor for a textual IF experience.

Very cool, thanks!

Do you think “input point” might work and save a couple syllables? I’m a little intrigued that they had such strong opinions; I don’t think I ever thought about what that thingy where you typed your stuff was called until I started looking at the I7 documentation.

That’s awesome - both the class concept and the report. I’d definitely like to hear more as the class continues.

The mental model is very interesting.

Thanks for this; it’s fascinating.

I have a question that might be worth exploring or revisiting:

I’m glad that the students felt confused by the dissonance of referring to both the player and the protagonist as you, because this is one of my biggest IF pet peeves. However, I also like the interesting immersion/identification effects that second person narration can have, if used well, so I’m currently working on a solution that, rather than narrating in a different person, alters all error and out of game messages to a non-person-specific response. In the IF I’m currently writing, all out-of-game messages are written in the perfect tense, exclusing the person, italicised and in square brackets. So instead of “You can’t go that way”, we get “[It is not possible to go in that direction.]” or somesuch. ( I seem to remember Blue Lacuna doing something similar.) This has the additional advantage of removing the need to come up with context-appropriate custom library messages that also fit the game’s tone.

So the question is: How would your students respond to this alternative solution?

I’ll throw a few responses in one here.

Input point could work. The writers in my class were trying to grasp for something that would be less mechanistic in some sense. Along with “interaction point,” some shortened it to “action point.” As far as why they had such strong opinions, I think it’s just that when they heard “command prompt” it meant nothing to them in terms of writer interacting with reader, even though they realized a “command” could be what the author was waiting for from the reader.

Good question and interesting approach. I can certainly bring it up. I can tell you that with the example you gave – about going a direction that can’t be traversed – people seem to want this to be contextual rather than the game telling you about it. So in the case of your example, what seems to be the preference is something like this:

“It wasn’t possible for me to go wherever that led; the door was locked.”

That’s for an exit that it might seem like you could go in but could not. For en exit that was “soft” – in the sense that it was just a world boundary – this kind of thing was preferred:

“There was no reason for me to leave the estate.”

My class felt that the context and description should make it clear to the player where they can and can’t go, whether to due to “soft” or “hard” boundary. When the player tried to go that way anyway, the protagonist should respond. For example, let’s say the player keeps trying to have the protagonist leave the estate grounds. Then perhaps a response comes up like this:

“Why did I keep wanting to leave the estate? I knew I had to figure out what Edward was hiding. The fact that I continued to try to leave told me how scared I truly was of him.”

So you disallow the action, but you have the protagonist at least respond to it. Further, you characterize the protagonist a bit. Then the player has to start working to solve the game in the context of that characterization. You (as player) have now learned something important about the person you are “inhabiting.” They have limits, at least for now, given the situation. (Maybe later those limits will change as the protagonist grows along their character arc.)

In my own case, I used the example of “You can’t refer to that” as something that people felt was “okay” for the parser/game to respond in second person for. While this was true, there was some debate about this. My class felt that the more you had to use the game/parser to indicate something, the more you weren’t crafting the story world. So for anything that was mentioned but wasn’t useful to the player/protagonist, you could again do situational responses:

“A butcher knife? Was I seriously going to take a knife? Yes, I suppose I was. I was that scared of Edward.”

Now here’s another place for characterization. Maybe you let the protagonist take the knife or you don’t. You could argue: But won’t the player get ticked if I disallow things they want to do? Not necessarily. As long as the protagonist can give story-contextual reasons for why they are doing what they are doing. Consider that kind of response vs. this:

“You would never want to use a knife against someone – even Edward.”

To any writer or reader I worked with, the latter was basically just the game showing through even though it was worded as applying to the protagonist.

The only time game mechanics were felt to be “allowable” was to indicate incorrect commands, such as:

“Having the actor take that action is not allowed in this story.”

Along with this, however, it was felt that it was necessary to guide the player in terms of what the actual problem was. We found this a bit easier in TADS 3 than in Inform 7, but the idea was something like this. Let’s say the protagonist is in some room other than the Library and types: > FIND THE LIBRARY. The game could say:

“You tried to ‘find the Library.’ Presumably you meant to ‘go to the library.’”

However, if the player was in the Library and performed that command, then the message would be different:

“You tried to ‘find the Library.’ Since you are already in the Library, did you mean that you want to ‘search the library’?”

My writers argued that the extent to which the game could help the player along, based on context, was a good use for parser/game messages. However, they also argued that things like the above should be handled by the author rather than relying on informing the player of an issue. So, for example, if “FIND {ROOM}” was a common alternative for “GO TO {ROOM}” then the game should just accept that.

In fact, some of what you are seeing here were the test heuristics we used for beta testing. Analysis was done of playthroughs and design decisions where made as to what to allow and disallow. The focus of the testing was always to make sure that the protagonist (story) voice was heard as much as possible except in those cases where that would have been more confusing than having the parser (game) voice heard. Even then, the testing then focused on how to incorporate the game (voice) situation into the parser (story) voice or how to provide clues to what specifically the game got confused on and then offer a possible hint.

Thanks for that; that helps me think through what I’m trying to do.

The tricky part, programming- and writing-wise, is working out when it’s best to try and give a contextual response, and when it’s best to give an error-message type response – and then to successfully program that contextuality!

Actually, thinking about it more, given your response, I think the reason with my qualms for the solution your class preferred is that it acknowledges the existence of the player within the narrative voice of the story. Now, unless you’re doing something very clever with the player-protagonist relationship (cf. Violet), I find that that itself tends to disrupt the immersion and narrative flow of the story – it breaks the fourth wall, or screen, maybe. That’s why I prefer a solution where through typography, person and tense we’re indicating that these messages are taking place outside of the story.

The key difference perhaps being that it’s not the narrative voice of the story insofar as how the story is being told. It’s a game mechanic. And readers are clever enough to forgive certain mechanics if those mechanics only intrude very rarely and are consistent in terms of how and when they appear. In that case, mechanics can guide the experience so that the story stands out even more.

Maybe a good example is why people are willing to accept that in first-person shooters you can take massive trauma and still survive. Clearly this is fairly ridiculous and yet people forgive it – but it is an intrusion of recognition that there is a player who will get ticked off if they die too easily. Even games that try to be a little more realistic in terms of the damage you take, like the Hitman series, have to make concessions on the part of the player. One such concession, in those games, is that players will often get shown a little “picture in picture” window of a target leaving a location, when in reality the protagonist is in no position to “actually” see this happening.

I can’t say we’re doing anything clever, per se, except trying things out. What we are doing is conflating the protagonist and the player to an extent. That extent being that the player is acting like some aspect of the mind of the protagonist; the protagonist is “talking to himself” in terms of describing what’s going on and what’s happening. (We’re not conflating the protagonist with the player in terms of actually being the protagonist in some categorical sense; this is what allows the protagonist to have a certain value base, moral stance, or personality that may differ from the player.)

But, again, we’re not doing that so much to remove all aspects of game mechanics. People do realize that they are, in fact, playing a game. The very act of turning pages doesn’t necessarily take someone out of a book, for example, or the fact that there are page numbers and chapter headings to structure the story even though those serve no purpose in the narrative itself. So people are willing to deal with certain mechanics if the story experience is worth it and if those mechanics help structure the story and streamline the experience.

Agreed on this. Certainly my class felt that when these messages that are outside the story had to be conveyed, one way of making sure they were so conveyed was through tense. In this case, it was the only reason that my class thought second person had any use at all. The story itself was told in first person in most cases. People did also like the idea of either bracketing the text or italicizing it, such as you had mentioned, just to set it off as being “out of story” game elements.

The goal was looking for when certain messages could be used effectively as part of the narrative. If they couldn’t – or if it would have been too contrived – then out of world messages were used in second person. A partial measure of success to was determined by groups in my class by the lack of out of world messages that were necessary. But the goal wasn’t to eradicate them entirely.

Fascinating as always, Jeff.

Regarding the command prompt: call it the “story prompt” perhaps? Setting the prompt to the currently-running (major) Scene seems workable.

For that matter, they’re fine with the “parser error” nomenclature?

Regarding FIND THE and GO TO THE, the extension Permission To Visit does these. Moreover, FIND will prefer a prop while GO TO prefers a room. VISIT prefers a person. But other than preferences they work identically.

I’m hoping then that my Custom Library Messages did its job well? Any snafus or requests?

This is great information to have. Thanks for sharing. It will be a challenge for the non-programmers among us to handle the suggested mechanics code-wise, perhaps somebody tech savvy would consider creating suitable extensions…?

Here’s to hoping that I can spend more time on design and writing, than on coding :slight_smile: (Yeah. Fat chance…)

I’ll throw another “thanks” on the pile, and just add a brief comment: “prompt” sounds almost completely non-technical to me, perhaps because I am used to thinking of prompts in the context of a “writing prompt” or the thing you give at the beginning of an improv acting exercise. It’s almost like I imagine the interpreter pausing, blushing, and mumbling, “…line?”

“Point” sounds much more jargony to my ear. I could sort of see something like “turning point” capturing the feeling (though perhaps it implies too sharp a branching); “crux”? “Minicrux”? :slight_smile:

Very interesting.

For what they’re worth, here are some thoughts on the finds.

The very first pieces of If were modeled on D&D and suchlike role playing games, with the parser acting the part of Dungeon Master. In that context second person present tense is of course perfectly natural. The player actually pretends to be the protagonist.

But it’s also true that Adventure and Zork does not sport much of a story (except in a trivial sense). It’s all exploration – and in particular the protagonist is deliberately un-characterized.

In real life D&D players are of course free to characterize their PC:s as they see fit, but in IF the characterization is almost completely left to the author.

Characterization of the protagonist may not be an actual prerequisite for telling a story, but at least it contributes greatly to the efficient telling of good stories. And with a heavily characterized protagonist, the difference between player and protagonist becomes so much more marked – especially when the characterization is not up to the player himself/herself.

The preference for presenting the protagonist as an “I” distinct from the player (adressed at times by the parser (or the protagonist even – depending on the kind of game)) as “you” can perhaps be given some such explanation from the nature of games/stories. (There is a prediction here that players will feel more at home with second person present tense in games like Adventure.)

The mental model window was in a sense, I think, a stock feature of early IF – only it wasn’t realized digitally in-game but by hand using paper and pencil. It seems to be a request for automatized basic mapping and note-making. That certainly has some nice advantages – like (if properly debugged) it won’t miss to take important notes, and it can even be used to give the player hints. (There is a possibility, too, that such a feature won’t be acutely felt lacking in smaller, puzzleless games.)

Yeah, in acting or film you’ll have a cue, and so – close to Ron’s idea of “story prompt” – I did originally recommend “story cue.” That’s more used in a theater setting, going back to the idea of “autocue” or “cue acting”, but it’s also very much used in screenplay concepts as well not to mention on the set, in terms of “cueing {some action}.”

You are correct in that “turning point” was sort of what people were thinking about in terms of “interaction point.” The reason I was shying away from that is because turning points are very specific moments in film or book and are most certainly not present ‘all the time,’ as it were.

It’s looking like “story cue” or “story prompt” will probably win the day. (Not that it will matter in some wider sense, of course, since all of this will only really be regularly used by people in my classes.)

Essentially, I would agree. The idea is that the “mental model window” is meant to suggest what you, as a person, would logically immediately notice upon entering a room, particularly if you had been there before. As people, we categorize and sort information in our brains based on what we deem relevant and not relevant. But our subconscious does keep track of many more details than we consciously recognize at any given time.

So the idea here is really bringing in a game mechanic and allowing it to interfere as little as possible with the narrative being told. Allow the player a common place to look for the “mental model” information if and when needed, but otherwise all focus can be on the narrative elements. Another idea of the “mental model” that we want to explore in the next class sessions is storing “relationships” that the protagonist observes and makes note of.

For example: “Chrissy (seems to) dislike Jack.” and “Marcus disapproved of Danni’s actions.”

These would just be like the “thoughts” of the protagonist that are made available to the player, allowing the player to explore those areas further. So the “mental model window” is really that: a window into the thoughts of the protagonist. Note, of course, that part of the fun in telling these stories is when those relationships would have to change based on new information. So just as the protagonist learns more, so does the player. This also allows for intriguing narrative possibilities, such as the so-called unreliable narrator (in this case, the protagonist) as well as where the player ends up being able to make connections that the protagonist has not yet. This introduces a conflict not just in the game, but between player and protagonist. Likewise, you can have situations where the protagonist is clearly making connections that the player is not and so the player now has to figure out why the protagonist thinks certain things and then decide how to act based on that.

Do you mean specifically displayed on a compass, as in (e.g) A New Life? (Though that didn’t list the locations you could go to, and in fact sometimes has another status effect.) A couple caveats about that:

  1. A compass rose might have trouble with up/down/in/out.
  2. It seems like something that would make screenreaders barf.

I think the ideal would probably be that the player could adjust the manner of exit listing to whatever they preferred – compass rose, list in the extra window, list in the main text, off. Of course that’s the maximum amount of work and programming overhead.

Definitely not a compass rose image. Or, at least, no one really wanted that. We had looked at games that did that, like the old Spellcasting series, but those were found to be a little intrusive. Plus the compass image couldn’t list things like “EAST - TO THE KITCHEN”, at least without being distracting, and what people really wanted is where the exit led, not just its cardinal direction. So the goal was always a list, similar to how information is categorized in our heads.

There was a brief debate about how positional information is stored in the mind and, in fact, that was what led more people to prefer relative directional information being provided in many cases. However, while some argued that a “compass rose” type concept might seem like what we normally do in terms of conceptualizing directions, people don’t do that. Cognitive theory shows us that at base level we tend to associate “ways to move” relative to specific landmarks in a given location, relative to ourselves. Taking that strictly, that would mean things like “go right” and “go left.” My class realized that could get tricky because then you have to account for the direction someone is facing as they move between locations.

That’s ultimately why the “go to {location}” was preferred, with the mental model window just showing a list of locations.

Some even argued that having “EAST - TO THE KITCHEN” was going too much into the cardinal direction mode again. But others argued that without that, locations would be in danger of seeming disconnected from any spatial relationship. In some stories that may be fine. But in others, the geography may be somewhat crucial. What was really preferred was if the games could present effective maps that would more closely match the visual images we make of our surroundings. Not so much as a series of connected lines, but rather like a blueprint. (Think back to the house maps provided with Infocom’s Deadline, for example.)

We actually used many notes from Stephen King on this (he wasn’t in these classes, I hasten to add!) regarding how he liked to establish geography for his stories, such as the Chester Mills setting in his recent Under the Dome. Writers tend to have a lot of ideas on how to model geography particularly because the level of detail required in various stories can differ, even within a specific context. (Such as one part of the area having to be meticulously defined while whole other swathes are left somewhat nebulous.) Writers are often of the opinion that “Setting” is one of the characters in the story. This was a particularly interesting challenge in Trinity because some areas could be relatively constrained in terms of geography whereas others – like Kensington Gardens and the Toadstool Realm – needed to be more expansive.

Also, it was recognized these maps would have to gracefully move down to pure text representations on devices like screenreaders. Since based on a few experiments at the time no one had any real faith in any current textual IF system generating effective, dynamic maps, the goal was to focus on text-based maps.

Infocom’s Arthur: The Quest for Excalibur is worth looking at for innovations like this: It had a wide top bar which could be changed qith the function keys, displaying at your choice a location image, a clickable map, an inventory (divided into carrying and wearing), or a room description. You could also revert to text-only with a standard location and date/time status bar. The location image added very little, of course, but the other options were a great innovation, for the reasons given here.

I think all that isn’t a substitue for well-clued writing, however: it should be an additional aid – for the sake of voth screenreaders and personal taste.

However, all this depends on the type of game being written. Games with any focus on exploration or puzzles would, I think, almost universally benefit from such systems, but they would also detract from games with a focus on narrative, especially fast-moving narrative. They make it more of a game and less of a story, basically.

The mental window seems to be a really good thing.

Mapping and taking notes DOES break story flow (even if it doesn’t necessarily break game flow - it can be too much a part of the way the game is played to do that);the mental window presumably won’t.

Come to think of it, there is one possibly important difference between notes taken by the player and the information in the mental window. My personal notes will be taken from my (the player’s) perspective; the mental window is (as you said) a window into the protagonist’s fictional mind. That, too, promises to help the player immerse himself/herself in the story.