Tag Archives: if

Why no dialog trees in Go, Jill!

My current side project is a text adventure tentatively called Go, Jill!. I want it to be a mostly-free roaming world with a main linear story where the player character, the titular Jill, will be able to talk about a lot of things to a lot of people. But one thing I don’t want is dialog trees.

Interactive story and branching

Dialog trees are very similar to the concept of branching stories. Usually, when people hear the term “interactive story” they think of branching story. It seems to make sense, right? How else is a story going to be interactive? In fact, there are many arguments that can be made both in favor of and against branching in interactive stories. Most of them were masterfully presented in the book Interactive Storytelling for Video Games.

In general, branching gives a better sense of agency, and that’s a good thing. But, as counterbalance to that, branching carries many downsides, some of which are:

  • It’s hard to write one good story, let alone several good ones.
  • Similarly, in a scripted story (as opposed to an improvised one), a good plot is usually made by planting narrative seeds that will bear fruit later. This is further complicated if the story branches.
  • A story should generally be surprising. If it branches, people will either be progressing at random or not be surprised.
  • Generally, the end of a story either presents a conclusion or a clearly purposeful sense of non-conclusiveness (like The Sopranos). If the story branches, one may always have the impression that the conclusion they saw is only one of many and that often feels wrong.

An ending being only one of many if fine if the game one plays is really set to make people construct their own narrative. Several role-playing games are made precisely to allow that. However, while they are clearly set in a narrative-like world, they don’t have an actual narrative in the generally accepted sense of the term. The ending the players arrive at simply did not exist before they played. It is not one of many pre-existing ones.

Dialog trees

Dialog trees are mostly a form of branching. Even if great care is placed in making sure that they never have negative consequences (like Ron Gilbert did) every time a choice is made it usually prevents another one. In a game of strategy that’s good, but in a narrative context, that’s bad. Furthermore, most dialog trees don’t take the care Ron Gilbert did and actively use dialog trees to alter the course of the story and branch it out.

And here, we have many problems. The first one is that characters usually know more about their own world than the player does. That’s something that very visible in David Cage’s work. A character can open a drawer and find a photo than makes him sad. The player had no way of knowing that the photo would be there, but the character did. At the end, such choices are just random to the player.

Dialog trees are just like that only more so. When we talk to someone in life, we usually have a good idea of what will offend them and what will make them happy. In games, it’s mostly luck. It’s actually worse than luck because the narration of the games forces it to be surprising, on an innocent-sounding phrase is unpredictably likely to turn out to be offensive to a character for the sake of drama. If it weren’t, the story would be boring.

Also, some of the choices offered in dialog trees might be a lot less subtle than what the player has in mind. Let’s say a character asks the player “Should I go talk to my friend about her husband being unfaithful?” and the possible choices are “Yes,” “No,” and “I don’t know, maybe.” And answer like “Yes” can lead to

  • “You totally should. You’d be a horrible friend if you didn’t.”
  • Or “Yeah. I think so. If you don’t and she found out you knew, she’s going to blame you for it.”
  • Or “If you want. I mean, it’s your decision.”
  • Or “Sure. I’ll go with you. I can’t wait to see the bitch go down!”
  • Or “Yes. Let’s go to the café that just opened downtown.”

Even if the whole first line is given, the conversation might end up having the player character say things that the player never expected.

This is randomness, and randomness and storytelling don’t go well together. This is one of the areas where it is particularly tough for story and gameplay to merge. As Jesse Schell is very found of teaching, randomness is generally good for games. He also likes to say that story is often good for games as well. For my part, I’ll add that randomness is usually terrible for stories.

My alternative

Let’s be sensible: for point-and-click games, dialog trees are still the best solution. But Go, Jill! is going to be a text adventure. For that medium, dialog trees can easily be a bad decision. It’s very important to use one’s medium as much as possible. And I have a blog post about just that topic. For a text adventure, I always found dialog trees to be clunky. A sort of haphazard interface inside of the main interface. Text adventures do not have a perfect interface, obviously, but throwing a dialog tree in the middle of it takes away their main attribute: free exploration or at least the illusion of it. If I’m playing a text adventure, I like to feel like I can type anything. I know that only a few words will actually work, but if I play along and the game is well made, that feeling can still hold.

Some people often like to say that text adventures are misleading because they claim the user can type anything in the input field but only very few of these commands will work. First of all, a list of suggested commands were usually distributed with games at the time. Second, all games restrict actions. Try and have Mario walk in front of a pipe in the 2D games! Get Nathan Drake to talk the people who are shooting at him into changing sides! Take a saw and try dividing up those Tetris tiles! Go ahead, do it! Games are restrictive by nature. Text adventures, like all games, try to use their limitations to be better from them, as opposed to artificially build clutter and pretend that those limitations do not exist.

What I intend to do with Go, Jill! is to encourage the players to have Jill ask about and tell about as many things as possible to the non-player characters, with a specific focus on relations between people. It’ll be a lot of content, but I’ll try to make it work. Again, this will mostly be about exploration. The main consequence to most of that content will be the way the player explores and understands the story. With some exceptions, the actual gameplay will be unaffected. So, for example, Jill will be able to ask character A what he thinks of his romantic partner’s relationship with his mother. This will not be a suggested topic, just not I’ll throw in there. If the player tries it, there will be a response.

The idea is that from one same mass of text, each player will be able to explore the parts of the story that they want at will. Progress will depend on them following the main story path, but it will truly be an interactive experience in the way most of the backstory and underlying relationships will only emerge if the player seeks them out.

There is no negative consequence to picking the wrong option because there is no option to pick. There is no frustration for getting to the wrong ending because there is only one ending. But if a player is not interested in an aspect of the backstory or a character’s opinion, they simply won’t have to pursue it. If, on the other hand they want to learn all they can about what most of the characters think about things, that will be available to them with no in-game downside.

This will definitely not be a game one plays to win but one that one plays to explore.

First steps: Frotz in Eclipse

I’ve looked at a lot of the Frotz source code. It’s undeniably simple and yet, it’s a big challenge for me. First of all, it is a virtual machine, no matter how you want to put it. Second, it’s not really that well commented. I’m still pretty enthusiastic about the whole thing. One aspect I had actually completely overlooked is how this project is getting me much close to Eclipse.

Eclipse

Eclipse logo

Eclipse is a very popular Java-based IDE, or Integrated Development Environment. Originally made for Java, it has been adapted for most languages one could reasonably expect it to work with, including of course C and C++. The needs of this project and the time constraints encourage me to use Eclipse and to use it in a more efficient way I have so far.

I’m using it to find out where variables and functions have been declared automatically, for example. It has more than one feature that help with that.

Real-life code

Frotz is definitely real-life code. I’m not in a world of textbooks anymore. This is an example of a comment I found:

For a very different example, I found this nifty piece of code that takes a full filepath and only keeps the basename:

This uses pointers and the fact that in C, there are no strings but zero-terminated character arrays. I actually like seeing a real-life example of this sort of thing.

To be continued.

My topic: analyzing and extending Frotz

Ah, Frotz. The most popular Z-machine and now glulx interpreter out there… Let’s back up for a while.

Z-machine

The first commercially available text-based adventure game was Zork I by Infocom in 1980. It was based on its almost-namesake Zork, that was made at MIT and only ran on big mainframes. For the commercial version, Infocom needed a very simple and versatile format. So they created the Z-machine format. Its only output was text, so interpreters for it could be made for pretty much any platform — and it was.

After Infocom

To my knowledge, the last commercial text-based adventure game was Eric the Unready. After that time, a new interpreter for Z-machine files ended up being necessary. A few appeared. The most popular ended up being Frotz, a command-line tool for Unix. Frotz was eventually ported to many systems, including Windows and more recently iOS.

Adventure games are not dead. Well, maybe not

Even though the number of people who play adventure games has shrunk and the number of people who play text-based adventure games or “Interactive Fiction” or simply IF is now tiny, a small community remains. New tools were made for creating new pieces of IF. Some were brand new, some compiled to the old Z-machine format. At the forefront of that latter category was the Inform programming language and its accompanying system, both created by Graham Nelson, a British poet and mathematician.

As the Z-machine had never been meant to be used by the public before, there was never a standard for it. Graham Nelson established one, aptly called the Z-machine standard in 1997. It has been updated since to version 1.1 in 2004. These standards are now used by most Z-machine interpreters.

A short note about Inform

Graham Nelson’s Inform language was very simple up to version 6. What made it a very powerful tool is that it came built-in with IF-specific rules. IF does require many rules to for the world of the story to behave in the way we as human players expect. These rules could be overwritten, but Inform did not require the programmer to write them. Example of rules could be that if an object is marked as being a container, it can contain other objects. However, an object cannot contain itself. This seems obvious to humans, but has to be coded in order to be in the world. Inform 7 goes much further and actually reads like English. It can still compile to the Z-machine format.

What I intend to do with all that

My independent study this semester will be the following:

  • analyze the Z-machine, using existing interpreters as well as Graham Nelson’s standards,
  • expose parts of the story inside the Z-machine and
  • display the information I gathered in the Windows interface in the Frotz for Windows interpreter.

I don’t know for sure how much of these I’ll be able to do, apart for the first one. But the Z-machine has such a reputation for being a very simple virtual machine that I hope I’ll be able to do all of them.