Despite never actually having finished a game (<sob>), in my efforts to try and get there, I have realized some things that, at least to me, were interesting and caused a shift in how I looked at my approach to IF. Since I actually have all three in my head at the moment, I thought I'd get them down in case anyone else finds them interesting as well. (Keep in mind that these are just how I look at things. If your view is different, that's fine. Nothing is absolute.)

An IF game is a conversation

I covered this in my earlier "Conversations" thread, so I'll distill it down. In an IF game, the player enters text, and the game responds with text. This back and forth (ideally) is more than just static descriptions of rooms and objects, rather verging on a dynamic conversation with a counterpart sitting in the game world and relaying information back to player queries. And the varied, engaging responses you'd want with any in-game character applies to the main in-game narrator as well. Instead of looking at it as room descriptions, object descriptions, character dialogue, etc, we can look at it all as the same sort of thing and, in an ideal world, apply the same tools to them all, creating a truly interactive experience.

The progression of game responses should form a narrative

If you imagine the game responses as being someone sitting on the other end of the screen, sending text back, then your expectations of the responses changes from just being canned responses to something much more dynamic and in tune with game world state. In particular, I always wanted my responses to seem like something someone would say (as much as reasonably possible), and one thing that people don't do is long-winded repetition.

Let's look at a canned response to a simple action, eating a candy at a party.

> eat candy
You eat a candy from the dish.

> eat candy
You eat a candy from the dish.

> eat candy
You eat a candy from the dish.

> eat candy
You can't eat any more.

Take the responses and put them together: "You eat a candy from the dish. You eat a candy from the dish. You eat a candy from the dish. You can't eat any more."

You would never see that in a book (I hope) nor would you expect someone to speak that way. Now here's another sequence, with more "progressive" text:

> eat candy
You eat a candy from the dish.

> eat candy
You eat another candy from the dish.

> eat candy
Looking around to be sure nobody is watching, you take a third candy from the dish and pop it in your mouth.

> eat candy
You can't eat any more.

Take these responses and put them together: "You eat a candy from the dish. You eat another candy from the dish. Looking around to be sure nobody is watching, you take a third candy from the dish and pop it in your mouth. You can't eat any more."

It's not the most exciting text, but the key thing in this to me is that the game responses are changing based on your actions and responding to what has occurred in the past. What I always wanted in my games was that level of responsiveness, where the game is "aware" of what has happened and makes intelligent responses based on that. What I noticed with that, though, is that the responses can end up being a narrative, where you could take the responses to the player's actions, string them together, and end up with what is nearly a story of what the player has done.

Here's another example. Let's say you have a door and a key. Depending on the order you encounter them, you'd want the text to be different:

> x door
The door is solid and, unfortunately, locked. There is a strange star shaped hole in the door that looks like it could take a key.

> x key
The key is star shaped. It looks like it would fit the hole in the door.

Other order:

> x key
The key is star shaped. You wonder what it might unlock.

> x door
The door is solid and, unfortunately, locked. There is a strange star shaped hole in the door that looks a lot like the key you found.

Now, you might not want to be so transparent in making connections for the player. But the key thing (no pun intended) is that the responses evolve based on what has happened. As your knowledge of the game world progresses, the responses progress in step with that knowledge.

Exploring conversation space can be analagous to exploring rooms

In a typical IF game, you explore rooms. You are here and then you go north and then you're somewhere else. And you can proceed from there and explore more rooms, or you can ask more about this room, or you can go back and explore where you were.

I began to see NPC conversation as following a similar pattern, where "room" can be replaced by "topic". You start off with a topic, and the associations from that topic lead you off to other topics, which lead you on to others. Or you can dwell on a topic or return to previously explored topics. But it's the associations and topic exploration that could make an NPC conversation seem like an actual conversation, and not just canned reponses to queries. (And, of course, you'd want the topical responses to change over time based on what you have already discussed. It doesn't make sense to me to ask a character about the murder, get a response like "She bursts into tears. 'He was a cruel man, but I loved him. I could never hurt him.'", and then when you ask about the murder *again*, get the exact same response "She bursts into tears. 'He was a cruel man, but I loved him. I could never hurt him.'")


Again, these are just some things that occurred to me as I explored making games. Various aesthetics that I couldn't put into words suddenly, at some point, crystalized into handy catch phrases. Maybe they can be useful for someone else or just make you ponder things in a different way for a while (or maybe they all already make sense).

jaynabonne wrote:Despite never actually having finished a game ...

My first instinct is to respond by saying that it's a crime you haven't finished a text-adventure for us to enjoy! Although, I do seem to recall a gamebook called The Haunting that was quite sharp.
I think everything you said made a lot of sense. I tend to think of IF's that do NOT follow those concepts as more "game-like" and IF's that DO as being more "story-like." But I'm not usually very critical of, well anything. So, there's a lot of things I'm willing to call different rather than bad. I will say that games which are more dynamic and adaptive to the player feel more "classy."

On a side note, game or no game, I'm glad you're here. There's only so many people who regularly provide solid advice/answers on the boards, and you are certainly one of them. Many thanks to everybody that helps those of us with less experience figure out how to make better games.

Jay, I think that insight about event/command order is very interesting. Thinking about how to write it the first thing that popped into my head was a mess of conditionals. Thinking about it more I wonder if you couldn't write a lower layer that would make stringing it all together a little easier.

Like if you wanted this kind of conditional examine response text, you could create a tree-like object the object would reference. The examine responses would be leafs on the tree and object references would be branch nodes, and to get to that examine response you'd choose a path based on what objects the player already had examined?

I'm not really sure how you'd go about it but it's interesting to think about .

I did think about it and wrote a library for it: my response library. But it's a completely different way of looking at things, so I don't expect it to get much use.

For example (from the ResponseLib sample), there is a machine that needs a key. When you look at it, the following responses can kick in:

    <!-- The response given when the machine is examined. The first eligible response is selected. -->
    <object name="MachineLook">
      <topics>LOOKAT</topics>
      <usechildren>first</usechildren>
      <!-- The response given when the machine is examined when it's on. -->
      <object name="MachineLookOn">
        <needs>machine_on</needs>
        <text>The machine is blinking and making noise.</text>
      </object>
      <!-- 
           The response given when the machine is examined when it's off.
           Note that when the machine is looked at the first time, the keyhole is noticed.
      -->
      <object name="MachineLookOff">
        <text1>The machine looks complicated. There's a hole that seems to be missing a key.</text1>
        <sets1>sawkeyhole</sets1>
        <text>If you turn it on, something interesting might happen.</text>
      </object>
    </object>

Note the one called "MachineLookOff", which is the one that is processed when you look at the machine when it's off (which is the case before you find the key to turn it on). It sets a state variable called "sawkeyhole". The response for the key uses that:

  <!-- The "look" response for the key. The response is conditional on whether the player has seen the keyhole. -->
  <object name="key responses">
    <topics>LOOKAT</topics>
    <usechildren>first</usechildren>
    <object name="KeyLook_SawKeyhole">
      <needs>sawkeyhole</needs>
      <text>It's a key. It looks like it would fit the keyhole in the machine.</text>
    </object>
    <object name="KeyLook_Default">
      <text>It's a key. Now you need to find where it goes.</text>
    </object>
  </object>

If the keyhole in the machine has been seen, it prints out "It's a key. It looks like it would fit the keyhole in the machine." Otherwise, it prints out "It's a key. Now you need to find where it goes."

Of course, you could do it all with Quest if statements as well...

TriangleGames wrote:My first instinct is to respond by saying that it's a crime you haven't finished a text-adventure for us to enjoy!

It will happen. I just need to get back to it and stop trying to make games beyond my ability or time. And thanks for your other kind words.

Learning about ResponseLib in more detail is on my to-do list . One thing that jumps out at me though is it seems like tracking what's been seen or not could be handled automatically; maybe a lower-level lib to track that would be in order, so you wouldn't have to manage it manually?

I'm surprised Quest doesn't track this actually, I think this is standard in Inform.

I cannot disagree that these are great ideas for an interesting text adventure experience, and I think it's well worth the effort to include varied responses of the kind suggested.

A couple of caveates though, mainly applicable to games that have a very strong focus on puzzles:

When questioning characters in the game, it is of course unrealistic that they always give the same response but it might be rational, allowing the player access to the same clues. When changing character responses (assuming the response contains a clue) we are either closing down access to the clue (if you didn't pick it up, note it down, or remember it the first time it's lost), or we might be making a clue more obvious than we'd like it to be by repackaging it in various different ways.

Repeated responses to certain actions are certainly...repetative. However, they may also be rational. In the example given what is the reason why the character needs to eat all the candy? If it's a puzzle that he solves by eating the candy more than twice (becoming full) then giving a different response gives it away somewhat; if he eats it twice, he will spot the different response, understand that he's onto something, and continue eating until reaching a resolution. In this case the varied responses have negated the puzzle. You might as well make the response to the second "eat" something like "You decide to eat some more, and find you cannot stop eating until you are full." I think sometimes repetative responses can be useful as they play with a player's expectations. We tend to assume that when a repetative response is received we are not progressing. This is an opportunity to hide a solution (maybe the player will find a clue explaining the benefits of over-dosing on sugar and wonder whether he gave up on eating candy too soon...)

So, I don't think repetition is always a bad thing so long as it's not just sloppiness (e.g. when a character wants something, they shouldn't keep telling you they want it after you've already given it to them...) One can guard against the absurd by careful wording too. For example, instead of "She bursts into tears and tells you X", it might be better to say "Tears stream down her face as she tells you X" - giving us the option to imagine she might have burst into tears the first time you asked her, but when you ask her the same question after that, her water-works are an on-going feature...

it comes down to the amount of detail~depth~description, and thus the amount of time~work, that a person wants or can put into their game. More detail~depth~description greatly makes the game better (and it can be crafted while keeping out any negative side effects, such as mentioned by the above poster about the issue with puzzles), but it also adds exponentially or quadratically to the amount of work and time that is needed for making the game.

So, again, it's a balance of practicality (how much work and time someone wants to put into their game making), functionality (for the customer of that game being able to thoroughly play it fully and hopefully be able to finish it, without any frustration: Clear explanation and instruction on the game controls, aspects~elements, objectives, and etc. Ease of use ~ good ergonomics or design ~ of the game's UI, menus, windows, and etc), and enjoyment (the level of detail~depth~description of the game) by the customer of the game.

The two extremes:

no detail~depth~description game: "you go west", "you kill dragon", "you win the game" = horrible experience (why did you even make this "game"... ?)

too much detail~depth~description game: you never finish making the game, it literally can take an INFINITE amount of time and work to complete-finish making the game, lol.

One thing that jumps out at me though is it seems like tracking what's been seen or not could be handled automatically

That's an intriguing idea, george. It dovetails nicely with some other things I've been thinking about, which would fall under the category of "the gradual acquisition of knowledge" by the in-game player character (which has to somehow mirror what the player knows). For example, let's say you've been dumped into this environment with unknown characters walking around. You wouldn't know who they are at first, so any description would have to be based on what is (hopefully uniquely) visible about that. It might be "the red-haired boy" or "the girl with the purple tattoo on her arm." After some time, perhaps you learn their names by overhearing conversation, perhaps you go up and introduce yourself and ask their name. However it happens, at some point you will learn additional information that can be incorporated into your game world view - their name, where their office/room is, who their friends are. And the game text would change from "the red-haired boy" to "Ron" or from "Room 314" to "Dr. Smith's office."

Not to get too out there or technical, but I had contemplated something that would store such knowledge - in what form, I have no idea. You could even somehow represent facts, such that if Dr. Smith knows about Ron's mother, that info could be stored in Dr. Smith's "memory", and if you asked Dr. Smith about Ron's mother, then the "fact" could be transferred directly to your in-game "memory" along with some text to let you know about it in the "real world". I know that's all a bit extreme, probably not relevant to most IF games, and probably beyond my abilities to create (short of some sort of inference engine), but it's interesting to explore conceptually.

Back to your point, it would be handy to have some sort of internal representation for such things: "saw object X", "heard topic Y", etc. such that when you encounter such things in the game, they're automatically recorded and then usable for checking state later. Given that responses are generic, it might be a bit tricky to identify when you have actually, in fact, "seen" something without explicitly marking it as such. But that gives me something to think about.


privateer: That is a very good point about clues. You probably don't want to only provide access to a clue once (though I can imagine some game designers who would think otherwise, based on how they want their characters to respond and the requirements they put on a player). Especially for things like descriptions, you must maintain some level of consistent text, since what you are seeing always looks the same, and it wouldn't be fair to the player to have such things reduce or basically become "You already saw that." That concept can apply to conversation as well.

In the example given what is the reason why the character needs to eat all the candy?

I didn't say there was a reason. Perhaps it's just a result of the player exploring and interacting with things. In the example, it is simply what happens in response to the player doing something. If you as the game designer have a definite purpose to such an action, then what text you use comes down to what your purpose is. It's not possible to prefer one over the other outside a definite context (and it's a bit of a sidetrack from the main point, which is that of text progressing, not in a puzzly way but just to seem natural - perhaps I should have picked a better example).

It's a bit hard for me to explain, but I see at least two possible different thrusts in a game; they may not both be present in a game, and they don't have to be exclusive if they are. The extent to which you incorporate them is down to design. They may coincide, or they may be different implementation aspects within the same world. They are: 1) steps that advance the player toward the solution of whatever overarching purpose the work has; 2) things that expand or make real the game world. Not everything that is done necessarily needs to be for a purpose, in my opinion. There can be things in a game that simply add color, things that make the world richer, things that aid immersion. It depends on how large and how linear you want your game world to be. A larger game world has room for more elements that are simply there to be experienced. A more linear game world (of necessity) can limit how many tangents you allow since you're being forced a long an arc. I suppose my ideal would be a large (or at least rich) non-linear game world.

(An example of what I mean - and perhaps what has influenced my recent game thoughts - is the online game "Myst Uru Online". It has an immersive 3D world that you are dropped into with no knowledge and which you must explore and gradually come to know about. There are puzzles, but there is also a heck of a lot of other stuff. The basic premise is that there is this other world, with even more worlds linked to via "linking books". But you have been preceded by others who have left diaries, notebooks, histories, etc. Not all or even a lot of that is relevant to puzzles, and you could probably ignore most of it without impacting your completing the game, if that's all you care about. But it ends up being a body of work that transcends just the puzzles involved, and the player can spend a lot of time just getting to know this rich environment. And it has spawned all sorts of discussions, theorizing, and the endless occupation of a number of players who are obsessed with knowing all about the world(s). It's a mind-blowing thing, for me, to have such a response to a game, and I'd love to come up with something that rich and involving, where the journey is even more engaging than the ultimate destination, where the play is not just solving one puzzle after another to achieve a final goal.)

HK: As always, it definitely comes down to what the game/IF designer is going for. I felt a bit funny using words like "should" in what I posted originally, but I hope I indicated sufficiently that it was just some criteria I had developed for my own work, and that others might think differently - or I might think differently tomorrow myself. What I would love to see is a system that allows you to easily flesh out a game world without that exponential or quadratic amount of work. Perhaps that's an unrealistic pipe dream.

HegemonKhan: I don't dispute that on the whole repetition TENDS to come down to people being lazy and that there are ways of crafting a game to avoid repetition. But I was pointing out specific instances where repetition might be rational and deliberate. Not all repetition is a result of an author not being bothered. As Jaynabonne has just mentioned, we may be orbiting close to a conversation about the ancient schism between the old-school Text Adventure and Interactive Fiction, the latter aspiring to create an experience where the player is an agent in the creation of literature, the former aspiring to engage the player in a problem solving exercise, using (and subverting) certain game conventions. (Overly simplistic games such as you described are another issue, I suggest. They clearly involve repetition but their issues go much deeper in that there is really no game to play.)

Janyabonne:

RE candy: I was just using it as an example, my point being that If eating all the candy was a task with a purpose, then an author might decide that it's useful to have the repetition so that the player will not inevitably eat it all without having had an "ah ha!" moment. But I do take your point on that specific example, and your points in general about finding ways to reduce the mechanical feel of a player's interaction with the world - when producing a game where realism is important.

As you intimated, it does come down to individual games and what they are trying to achieve. What might be a distracting cosmetic appendage in one game might be a essential part of the game-play experience in another. Your ideas sound fascinating though, and I am very attracted to the game-is-conversation approach. It would be nice to be able to throw in some fuzzy logic and have something like AI at work - not only with in-game characters, but the game itself having a kind of AI in making decisions about how it describes things at any given point...

Incidentally, interesting idea to have a text-based Myst-type game. I get the feeling the Myst games grew out of the text adventure tradition, abandoning text in favour of a graphic interface because of the complexity of the game-world? Perhaps the relative simplicity of text games works because of the demands and limitations of asking a player to interface using text rather than graphics?