RSS

Journey

15 Jul

Journey

The parser is and has always been both the text adventure’s ace in the hole and its Achilles heel. Devotees will tell you, correctly in my opinion, that it offers possibilities for interaction — even, one might say, possibilities for interactive wonder — allowed by no other interface. Detractors will tell you, also correctly, that it’s too persnickety, too difficult to use, that in its opacity and inscrutability it violates every rule of modern interface design. Devotees will reply, yet again in my opinion correctly, that if you take away the parser you take away the magic. What can compare with typing some crazy command and seeing it work? What, the detractors reply, can frustrate more than figuring out what to do, not being able to get the parser to acknowledge your efforts, turning to a walkthrough, and finding out you were simply using the wrong verb or the wrong phrasing? And so we go, round and round and round. This waltz of point and counterpoint says as much about the text adventure’s decidedly limited mass appeal as it does about why some of us love the form so darn much.

For most of the text adventure’s lifespan people have been devising various ways to try to break the cycle, to capture at least some of the magic without any of the pain. Even Infocom, whose parser was legendary in its day, had a go in their final days at doing away with the gnarly, troublesome thing altogether, via a game called Journey.

The idea that became Journey can be dated to November 6, 1987, when a proposed “new project” emerged from an internal planning meeting. By that point, attitudes about Infocom’s future prospects had broken into two schools of thought. One view, still dominant inside Infocom’s own offices but viewed with increasing skepticism in the headquarters of their corporate masters Mediagenic,1 held that the fundamental model of interaction that Infocom’s games had always utilized, that of reading text and typing commands in response, was still commercially viable in the broad strokes. What was needed was to make that model a bit more visually appealing and accessible, by adding pictures and other audiovisual pizazz to break up their walls of text and by making the parser smarter and friendlier. The other view held that Infocom needed to throw out all their old approaches — among them their parser — and tackle their new role as Mediagenic’s designated “master storytellers” with an entirely blank slate. Conservatives versus radicals, denialists versus realists — call the camps what you will, the lines were drawn.

True to the dominant internal opinion, Infocom put the majority of their resources into one last kick at the can for their parser-based games, putting three new illustrated but still parser-driven text adventures into development. They hedged their bets just a little, however, by making sure the new version 6 Z-Machine they had in development to power those games could support purely mouse-based point-and-click interaction as well the traditional keyboard-driven approach. And then they started this “new project” of theirs to see what the possibilities for non-parser-based adventuring might really be.

The meeting notes read that said new project should be “true to [the] corporate philosophy”; that it should “embody the concept of ‘interactive storytelling'”; that it should “employ a simple, intuitive user interface unlike the one used in our traditional IF games”; and that, while initially “intended for use on existing home computers,” it should be “readily adaptable to other interactive media, such as CD-I, DVI, Nintendo, etc.” Finally, the plan called for “minimal (or optional) use of text.” This last would fall by the wayside in light of Infocom’s limited resources and complete lack of experience working in anything other than text; instead they would settle for lots of pictures to accompany the text. Otherwise, though, the game Marc Blank wrote in response to this plan would hew quite closely to it.

Ironically, it was Blank who had been the mastermind behind the magnificent parser, first implemented as part of the original Zork at MIT, that had been so key to Infocom’s ascendancy during the first half of the 1980s. Now he would be working on the interface that might just become its replacement if the conservative camp should prove mistaken in their faith in the old ways. But then, Blank wasn’t much of a sentimentalist. Assuming he thought of it at all, the idea of sounding the death knell of the traditional Infocom game didn’t bother him one bit. On the contrary, this new project was a perfect fit for Blank, exactly the sort of medium-advancing technical challenge he loved. He insists today that throughout his work with Infocom game design and story were always secondary in his mind to the technology that enabled them. Thus virtually every one of the games with which he was most intimately involved, whether as the officially recognized Implementor or the self-styled “wizard behind the curtain” enabling the creativity of another, pushed Infocom’s technology forward in one way or another. That would be more true than ever of Journey, which Blank created as he had Border Zone from the West Coast, working as an independent contractor rather than an Infocom employee. Blank:

Journey was an experiment to find out whether you could play an interactive story without having to type. It was all about whether you could still have people feel they had the ability to do a lot of different things, but not force them to guess words or use a keyboard. A lot of people just don’t like that; they aren’t good at it. It’s a turn-off. For me, the idea was to just experiment with another style of evolving the story — a different interface, just to see where it would go.

Even more so conceptually than technically, this new interface of his was going to be a tricky business. A bunch of hard-branching links in the form of a computerized Choose Your Own Adventure book was likely to appeal to no one. At the same time, though, to simply write a traditional text adventure in which the parser was a menu-based labyrinth of verbs and nouns would be both technically impractical — there wouldn’t be enough space on the screen for such a thing for one thing, and even the new version 6 Z-Machine didn’t support scrolling menus — and unplayable in its sheer complication. Blank would need to thread the needle, staking a middle ground between the extreme granularity of Zork and the huge irreversible plot swings that accompany almost every branch in a Choose Your Own Adventure book. To a rather remarkable degree really, he succeeded in doing just that.

Blank’s first brilliant stroke was to make Journey, if not quite a full-fledged CRPG, at least a CRPG-like experience. You the player identify most closely with a single character named Tag, who also serves as the author of the past-tense “chronicle” of the adventure that you’re helping him to create. You’re responsible for managing several of his companions in adventure as well, however, each with his own strengths, weaknesses, and special abilities. Most notably, the wizard Praxix can cast spells, each of which requires a certain combination of reagents which you’ll need to collect over the course of your Journey. Many problems can be solved in multiple ways, using different spells or combinations of spells, the special abilities of one character or another, and/or your own native cleverness. While the scope of possibility in Journey is undeniably limited in comparison to a traditional Infocom game, in practice it feels broader than you might expect.

Journey

To understand a little better how that might be, let’s have a closer look at the interface, as shown in the screenshot above. You’ll notice that the menu at the bottom of the screen is divided into five columns. The first contains possibilities that apply to the entire party — usually involving movement — along with access to the “Game” menu of utility commands. The second column, which isn’t actually clickable, lists each character in the party; the party can include up to five people, who can come and go according to choices and circumstances. The third, fourth, and fifth columns contain “verbs” applying only to the individual party member whose row they inhabit; these also come and go as circumstances change. Many verbs will lead to a further menu or menus of “nouns.” For example, asking Praxix the wizard to “cast” leads first to a direct-object list of available spells, and then on to an indirect-object list of possible spell targets, as shown in the screenshot below. Clicking on the name of Bergon to the far right on that screen would complete a command equivalent to typing “cast elevation on Bergon” in a traditional Infocom game. The whole system is elegant and well thought-through. Limited though it may be in contrast to a parser, it nevertheless presents a vastly larger possibility space than a Choose Your Own Adventure story, not least because it has a world model behind it that’s not all that far removed from the one found in any other Infocom game.

Journey

Journey is, as you’ve doubtless gathered by now, a high-fantasy story, a quality that, combined with the CRPG-like flavor, delighted a beleaguered marketing department still searching desperately for a counter to the huge popularity of the Ultima, Bard’s Tale, and Advanced Dungeons & Dragons series. Looking for a way to distinguish it from Infocom’s more traditional “graphical interactive fiction,” marketing dubbed it a “role-play chronicle” — not exactly a phrase that trips off the tongue. Blank:

I wanted to call it ‘role-playing fiction.’ They came back with role-play chronicle, and I said, “What does that mean?” They said, “Well, it’s like a chronicle,” and I said, “Yeah, it sort of is because it’s told in the past tense.” So they just sort of invented a phrase. It’s not my favorite, but it’s passable, and I don’t think Journey will stand or fall on what category you put it in. There are a lot of games that are called this type or that, but what really matters is what people think of them.

Awkward though marketing’s name may have been, there is indeed some truth behind it. One of the more interesting aspects of the game is its commitment to the idea of being a chronicle — or, if you like, a novel — that you, through Tag, are creating as you play. If you choose to make a transcript of your adventure, you can opt to have it not include your explicit command choices if you like, just the text that appears in response. The end result can read surprisingly well — a little disjointed at times, yes, but far better than would, say, Zork in this format.

There is, granted, no denying the story’s derivative nature; this is a game that absolutely oozes Tolkien, a fact that Infocom’s marketing department, far from concealing or denying, trumpeted. Journey, runs the game’s official announcement in Infocom’s The Status Line newsletter, is “a classic narrative in the exciting tradition of Tolkien” that “plunges you into an uncharted world of dwarves, elves, nymphs, and wizards.” True to its inspiration, Tag, ultimately the hero of the story, is seemingly the meekest and weakest of a group of disparate companions who form a fellowship and set out on a lonely quest to save their land from an encroaching evil that threatens their civilization’s very existence. Sound familiar? Name a proper noun in The Fellowship of the Ring, and chances are it has an analogue in Journey.

Journey

For instance, in place of Tolkien’s magic rings Journey has magic stones as the key to defeating the Dread Lord, its version of Sauron. In this extract, Gandalf… I mean, the great wizard Astrix tells the party of the true nature of their quest.

"I have been following your progress with great interest," the Wizard said, stroking his stringy gray beard. "You are a very resourceful group, that is certain!"

His voice then became dark. "The question is: Have you mettle enough to make siege on the Dread Lord himself?" And then, smiling, the darkness fell from his voice, and he answered his own question, "We shall see, I suppose; we shall see."

Leading us to his hearth, he sat us in a semi-circle around the blazing fire and spoke. "There is a story I must tell, a story of Seven Stones. Created in a time lost to living memory, these Stones contained the very strength and essence of our world. Of the Seven, Four were entrusted to the races of men who could use them best: Elves, Dwarves, Nymphs, and Wizards.

"These are the Four: the Elf Stone, green as the forests of old, and the Dwarf Stone, brown as the caverns of Forn a-klamen; the Nymph Stone, blue as the deep waters of M'nera, and the Wizard Stone, red as the dark fire of Serdi.

"The four races are now sundered, and the Four have long been kept apart, but now, with the Dread Lord rearing his misshapen head in our lands, we must bring them together again. For with them, we can hope to find the Two, and then, finally, the One with whose help we can destroy all Evil.

"For it is told that having the Four, it is possible to find the Two; so, also, do the Two give witness to their master, the One that in elder days was called the Anvil!"

Yet somehow Journey is far less cringe-worthy than it ought to be. For a designer who stubbornly, almost passive-aggressively insists today that the technology “was more important than the story” to him, Blank delivered some pretty fine writing at times for Infocom. Journey is full of sturdy, unpretentious prose evoking a world that, overwhelmingly derivative though it is, really does manage to feel epic and interesting in a way too few other gaming fictions have matched in my experience. I was always interested to explore the world’s various corners, always happy and genuinely curious when the opportunity arose for Tag to learn a little more about it from one of the other characters. Coming from me, someone who generally finds the real world much more interesting than fantastical ones, that’s high praise.

Indeed, when I first began to play Journey I was surprised at how much I enjoyed the whole experience. Not expecting to think much of this oddball effort released in Infocom’s dying days, I’d put off playing it for a long, long time; Journey was the very last of the 35 canonical Infocom games that I actually played. Yet when I finally did so I found it a unique and very pleasant experience. It felt very much like what I presumed it to be attempting to be: a more easygoing, relaxed take on the adventure game, where I could feel free to just take in the scenery and enjoy the story instead of stressing too much over puzzles or worrying overmuch about logistics. The game’s own rhetoric, obviously trying to wean players of conventional interactive fiction into this new way of doing things, encourages just such a relaxed approach. “Try to play as much as possible without overusing Save,” says the manual. “There are no ‘dead ends’ in Journey; feel free to experiment and take chances. Every action you take will cause the story to move forward.” This idea of a text adventure with no dead ends encourages comparisons with the contemporary works of Lucasfilm Games in the graphic-adventure realm, who were working toward the same goal in response to the notoriously player-hostile designs of Sierra. Marc Blank’s contemporary interview comments make the comparison feel even more apt:

We’ve learned a lot about interactive storytelling, but it’s been sort of clunky and not directed. I thought it would be interesting to design a story in which you really couldn’t get stuck. The choices you have to make are more tied into the story than into the minutia of manipulating objects. That really led to the whole style of telling the story and the interface. All that came out of the desire to try something like that.

So, yes, Journey and I had a great relationship for quite a while. And then it all went off the rails.

The first sneaking suspicion that something is rotten at the core of Journey may come when it hits you with some puzzles mid-way in that suddenly demand you type in phrases at a command line. Not only a betrayal of the “no-typing” premise that Infocom had hoped would make Journey amenable to game consoles and standalone CD-ROM players, these puzzles aren’t even particularly worthy in their own right, requiring intuitive leaps that feel borderline unfair, especially in contrast to the consummate ease with which the rest of the game is played. But, alas, they’re far from the worst of Journey‘s sins.

For there inevitably comes a point when you realize that everything Infocom has been saying about their game and everything the game has been implying about itself is a lie. Far from being the more easy-going sort of text adventure that it’s purported to be, Journey is a minefield of the very dead ends it decries, a cruel betrayal of everything it supposedly stands for. It turns out that there is exactly one correct path through the dozens of significant choices you make in playing the game to completion. Make one wrong choice and it’s all over. Worse — far worse — more often than not you are given no clue about the irrecoverable blunder you’ve just made. You might play on for hours before being brought up short.

The worst offenders to all notions of fairness and fun cluster around the magic system and its reagents. Remember those puzzles I mentioned that can be solved in multiple ways? Well, that’s true enough in the short term, but in the long term failing to solve each one in the arbitrary right way — i.e., solving it by using a spell instead of your wits, or simply by using the wrong spell — leaves you high and dry later on, without the necessary reagents you need to get further. Playing Journey becomes an exercise in stepping again and again through the story you already know, clicking your way hurriedly through the same text you’ve already read ten times or more, making slight adjustments each time through so as to get past whatever dead end stymied you last time. This process is exactly as much fun as it sounds. In contrast to this exercise in aggravation, Shogun‘s summary halting with a “this scene is no longer winnable” message when you fail to do what the novel’s version of Blackthorne did suddenly doesn’t seem so bad.

How incredible to think that Journey and Shogun stemmed from Marc Blank and Dave Lebling, designers of the original Zork and Infocom’s two most veteran Implementors of all. These two of all people ought to have known better. Both games’ failings feel part and parcel of the general malaise infecting everything Infocom did or tried to do after 1987. Absolutely nothing that anyone did seemed to come out right anymore.

Like those of Shogun, Journey's 100-plus pictures are the work of artist Donald Langosy.

Like those of Shogun, Journey‘s 100-plus pictures are the work of artist Donald Langosy.

As bizarre as it is to see such frankly awful game design from a company like Infocom and an Implementor like Marc Blank, the disconnect between the rhetoric and the reality of Journey is still stranger. “Unlike other games you may have played, there are virtually no dead ends,” the manual promises. “Any action you take will advance the story toward one of its many endings.” I suppose there’s a germ of truthfulness here if you count a dead end only as being stranded in a walking-dead situation; the nature of Journey‘s interface means that you will always get a clear message that the jig is up once you’ve run out of options to move forward, sometimes even accompanied by a helpful hint about where you might have messed up way back when. Still, the assertion seems disingenuous at best. When people talk about multiple endings and multiple paths through an interactive story, this isn’t quite what they mean. Ditto Blank’s contemporary claim that there are “dozens” of “alternative endings,” and “very few places where you get killed.” Really, what’s the practical difference between a losing ending that involves death and one that leaves Tag and his friends defeated in their quest? The Dread Lord wins either way.

Today, none of the people left at Infocom during this final unpleasant period of the company’s existence are particularly eager to talk about those painful end times or the final batch of underwhelming games they produced. Thus I’ve never seen anyone even begin to address the fraught question of just what the hell they were thinking in trying to sell this sow’s ear of a game as a silk purse. Part of the disconnect may have stemmed from the physical distance between Marc Blank and the people at Infocom who wrote the manual and did the marketing; this distance prevented Blank from being as intimately involved in every aspect of his game’s presentation as had long been the norm for the in-house team of Imps. And part of the problem may be that the rhetoric around the game was never modified after the original vision for Journey became the cut-down reality necessitated by time pressure and the space limitations of even the latest version 6 Z-Machine. (While Journey‘s text feels quite expansive in comparison to the typical parser-based Infocom game, Blank was still limited to around 70,000 words in total; the perception of loquacity is doubtless aided by the fact that, Journey‘s scope of player possibility being so much more limited, a much larger percentage of that text can be deployed in service of the main channel of the narrative rather than tributaries that many or most players will never see.) Regardless of the reasons, Journey stands as the most blatant and shameless instance of false advertising in Infocom’s history. It’s really, really hard to square marketing’s claim of “no dead ends” with a game that not only includes dead ends but will end up being defined by them in any player’s memory. Infocom was usually better than this — but then, that’s a statement one finds oneself making too often when looking at their final, troubled run of games.

True to the Tolkien model to the last, Infocom planned to make Journey the first of a trilogy of games, the latter entries of which would likely have been written by other authors. Blank proposed starting on an untitled sort of narrative war game as his own next project, “a variant of traditional FRP [fantasy-role-playing] games in which the predominant activity is combat on the battlefield level, as opposed to the hand-to-hand level.” It would use the menu-driven Journey interface to “make a complex game simple to use and learn” and to “provide a narrative force to the unfolding of the war.” But events that followed shortly after the concurrent release and complete commercial failure of Journey and Shogun in March of 1989 put the kibosh on any further use of Journey‘s interface in any context.

And that’s a shame because its interface had huge potential to bridge the gap between the micromanagement entailed by a parser and the sweeping, unsatisfyingly arbitrary plot-branching of a Choose Your Own Adventure book. It’s only in the past decade or so that modern authors have returned to the middle ground first explored by Blank in Journey, constructing choice-based works that include a substantial degree of world modeling behind their text and a more sophisticated approach to interaction than a tangle of irrevocable hard branches. In the years since they began to do so, the quantity of choice-based works submitted to the annual Interactive Fiction Competition has come to rival or exceed those of more traditional parser-based games, and commercial developers like Inkle Studios have enjoyed some financial success with the model. While they provide a very different experience than a parser-based game, my own early engagement with Journey demonstrates how compelling games of this stripe can be on their own terms. And they’re certainly much more viable than traditional text adventures as popular propositions, being so much more accessible to the parser-loathing majority of players.

Unsatisfactory though it is as a game, Journey marks Infocom’s final mad flash of innovation — a flash of innovation so forward-thinking that it would take other developers working in the field of interactive narrative a good fifteen years to catch up to it. Perhaps, then, it’s not such a terrible final legacy after all for Marc Blank in his role as Infocom’s innovator-in-chief — a role he continued to play, as Journey so amply proves, right to the end.

(Sources: As usual with my Infocom articles, much of this one is drawn from the full Get Lamp interview archives which Jason Scott so kindly shared with me. Some of it is also drawn from Jason’s “Infocom Cabinet” of vintage documents. Plus the May 1989 issue of Questbusters, and the very last issue of Infocom’s The Status Line newsletter, from Spring 1989.)


  1. Mediagenic was known as Activision until mid-1988. To avoid confusion, I just stick with the name “Mediagenic” in this article. 

 

Tags: , ,

53 Responses to Journey

  1. iPadCary

    July 15, 2016 at 12:15 pm

    Loooooove “Journey”!
    Can’t wait for the “Quarterstaff” piece!

     
  2. Jayle Enn

    July 15, 2016 at 2:41 pm

    My strongest memory of Journey, besides the honestly quite pretty artwork, was finally resorting to a walkthrough in order to successfully complete it. Even then, I was still one or two reagents short at the last critical point and lost. I never tried again.

    It’s frustrating, because it really was an intriguing little world, and because so much of the detail seems (in retrospect at least) to be hidden within the game’s meandering failure branches.

     
    • Jimmy Maher

      July 15, 2016 at 3:06 pm

      I could be wrong, but I don’t think there’s really much detail hidden in the failure branches. I believe that wrong choices almost always cause you to *miss* things rather than heading off down the wrong path entirely. So, if you make all the right choices, you should end up with a very complete “chronicle” of the whole.

       
      • Jayle Enn

        July 17, 2016 at 5:30 am

        It’s very possible that I’m misremembering, too! My memories of the game aren’t at all recent, and my perception of its flaws have probably grown worse from there.

        On a less negative note, looking at the UI now makes me think of Japanese console RPGs, both in layout and the process of selecting characters and actions. Maniac Mansion too, come to really think about it.

         
  3. Alexander Freeman

    July 15, 2016 at 6:26 pm

    I’ve always found it odd how hard so many people seem to think the parser is. LOOK, GET BALL, and PUT BALL ON TABLE capture the three basic syntaxes that are expected the vast majority of the time (i.e. verb, verb direct object, and verb direct object preposition indirect object). Even as an eight-year-old, I could figure this out. Sure, some games have a lot of “guess the verb” moments, but those are usually poorly tested and not so well designed games anyway. Infocom showed sufficient testing can make those moments a rarity.

     
    • Sniffnoy

      July 15, 2016 at 11:53 pm

      One common problem I’ve had with parser-based games is offering things for trade. I don’t think I’ve ever played one that recognized any variant of “Trade ball to Bill in exchange for dart”. Instead they seem to rely on you just giving the ball to Bill, and just saying, oh, Bill recognizes that you’re trying to trade it for the dart, he’s going to give you the dart now. But you can understand why I would be reluctant to enter such a command! And it’s really not explicit at all. Parsers should be able to handle that, IMO.

      (Not that point-and-click adventure games are any better on that front. But you’d expect parsers to handle it better.)

       
      • Alexander Freeman

        July 16, 2016 at 4:11 am

        Hmm… interesting. One possibility would be to allow TRADE BALL WITH BILL FOR DART or TRADE BALL FOR DART WITH BILL. It could also even be done with current parsers:
        >TRADE BALL FOR DART
        With whom?
        >BILL
        Or
        >TRADE WITH BILL
        What do you want to trade with him?
        >BALL
        What do you want to trade that for?
        >DART

        Still, it couldn’t hurt to have the parser transform IN EXCHANGE FOR into FOR.

        I have thought about it accepting an additional indirect object that would be used with the preposition WITH as in SCREW SCREW IN THREAD WITH SCREWDRIVER or TIE CART TO HORSE WITH ROPE. However, I have wondered if that’s worth enhancing the parser for seeing as it can already be told to ask what with.

         
        • Sniffnoy

          July 16, 2016 at 10:59 pm

          Wait, they *don’t* already let you do that? Can’t you already e.g. “kill dragon with sword”?

          …or is the problem there that that’s only one prepositional complement, and the parser just thinks, “oh, this thing is the indirect object / prepositional complement”, rather than, y’know, distinguishing by preposition? So you can “throw ball with sling” or “throw ball to Bill” but not “throw ball to Bill with sling”?

          I think this might be a problem I’ve run into before, actually. “Tie cart to horse with rope” is pretty natural; how is one supposed to use rope if one can’t tie X to Y with it? I think I have failed to use rope in that way before.

           
          • matt w

            July 17, 2016 at 3:07 am

            It isn’t necessarily that the parser fails to distinguish by prepositional complement–current parsers, at least, would be perfectly capable of recognizing SET PHASER ON TABLE and SET PHASER TO STUN as different actions. In Inform 7 it’s as simple as writing:
            Understand “set [something] to [something]” as putting it on.
            Understand “set [something] to [text]” as setting it to.
            and in fact the latter of those commands is built in to the standard library.

            The problem (in Inform at least) is that the parser isn’t set up to handle three nouns at once. This is surmountable, though, with some hacking. The other problem is that the player isn’t going to know that you need to use that syntax–either they’re a parser aficionado, who knows that commands take two nouns max, or they’re a parser non-aficionado, who is probably going to be flailing around before they get in a position to “Tie cart to horse with rope.”

            In games I’ve played where you need to do something like that, I think you either have to type “Tie cart to horse” and the game will use the rope if you have it and refuse the command if you don’t, or you need to type “Tie rope to cart” and then “tie rope to horse.”

             
          • Sniffnoy

            July 19, 2016 at 1:34 am

            either they’re a parser aficionado, who knows that commands take two nouns max, or they’re a parser non-aficionado, who is probably going to be flailing around before they get in a position to “Tie cart to horse with rope.”

            I don’t think that dichotomy is accurate at all? I’ve played several IF games and I honestly never realized before now that commands take at most two nouns, whether as objects, indirect objects, or prepositional complements. It’s not too hard to see someone else play and get the gist of it — you enter commands that you want your character to do, and these generally have to be unambiguous and granular in nature (and, y’know, understandable by a computer). But nothing about that rules out “tie cart to horse with rope”. That’s something that you could reasonably expect to be an atomic action, and it’s not even a complicated sentence. There’s no reason that this shouldn’t be handleable except for the limitations of the particular parsers that have actually been written; implementing it doesn’t require solving an AI problem or anything.

             
        • matt w

          July 17, 2016 at 2:55 am

          The thing about this sort of thing is that the player has to know somehow that a command like TRADE BALL FOR DART or TRADE BALL TO BILL FOR DART will work. (Or type it without knowing–but if you’re relying on a player typing syntaxes that they won’t know then you’re going to wind up with players typing a lot of commands the parser won’t understand.) At least people who’ve been brought up on parser games are pretty well habituated to GET THIS and X THAT and PUT THIS IN THAT and UNLOCK THAT WITH THIS and some of the other things, but even with that kind of background you have to be pretty good at hinting the verb and syntax you want to use if you want the player to come up with TRADE THIS FOR THAT.

          (Though I’m also wondering how this is supposed to work from a puzzle design standpoint–how do I know that trading Bill the ball for the dart is a good idea? If it’s that Bill has a dart I want and I can recognize that he needs the ball, I guess I expect GIVE BALL TO BILL to produce the result I need to move things along, on the general principle that if there’s something you can do in a game it’ll accomplish something…. taking on board Jimmy’s caveat about the Magnetic Scrolls games. If you have a game where the puzzles are that you really need to figure out which things to trade for what things according to some system, then the game should be explaining the verb you need to use.)

          I have found that the parser really is a problem to people who aren’t used to the parser in some way (in my case I had to start getting used to it by going through a few games consulting walkthroughs very often). I made a fairly puzzleless game (if you go long enough without encountering anything it gives you a sharp nudge as to what to do next) which I’m pretty sure didn’t give any problems to the parser people who played it, and gave it to my non-IF writing group with some reasonably detailed instructions about the kind of commands that work. None of them could play it at all. One of them started out by typing “look out the window,” when all my testers knew not to try anything with the window because it wasn’t in the room description; then just typed “hint” until there wasn’t anything left to do. The one who was most committed to taking it seriously did some stuff but wound up typing “the kettle boils” when it was necessary to wait a little bit for the kettle to boil. Even if that had been an imperative mode command like “wait for the kettle to boil,” can you imagine what a nightmare it would be to implement that perfectly reasonable thing to want to do?

          So yeah, in my experience even if you tell people what the syntaxes are you can’t just expect them to figure everything out. We’re depending on more familiarity with the parser than we may think.

          As for the last point, I think if you’re making the player type a two-noun command and then quizzing them for a third noun (which, again, is something that you’d have to hint if you want anyone to divine that they need to do it), they could reasonably ask why you didn’t just implement the three-noun command instead of putting them to the extra trouble. “Because it’s hard to implement in the Inform parser” wouldn’t be a good answer.

           
          • Alexander Freeman

            July 17, 2016 at 3:37 am

            “…or is the problem there that that’s only one prepositional complement”
            Well, yes, that’s why I said an ADDITIONAL indirect object.

            “The one who was most committed to taking it seriously did some stuff but wound up typing ‘the kettle boils’ when it was necessary to wait a little bit for the kettle to boil.”
            Huh, that’s funny. Didn’t your game say to enter COMMANDS?

            “Even if that had been an imperative mode command like ‘wait for the kettle to boil,’ can you imagine what a nightmare it would be to implement that perfectly reasonable thing to want to do?
            “So yeah, in my experience even if you tell people what the syntaxes are you can’t just expect them to figure everything out. We’re depending on more familiarity with the parser than we may think.”
            Well, if you say so. I suppose you’d know from that experience. I just don’t see how someone could that would fit any of the syntaxes I’ve just mentioned.

            “As for the last point, I think if you’re making the player type a two-noun command and then quizzing them for a third noun… they could reasonably ask why you didn’t just implement the three-noun command instead of putting them to the extra trouble. ‘Because it’s hard to implement in the Inform parser’ wouldn’t be a good answer.”
            Yeah, good point.

             
          • Alexander Freeman

            July 17, 2016 at 5:39 am

            You know, thinking about this some more has given me an idea. Why not follow the example set by modern user interface design? Possibly have a few options for someone to choose from.

            One would be having a bunch fields where the command line is. The first box would labeled VERB, the second DIRECT OBJECT, the third PREPOSITION, and the fourth INDIRECT OBJECT. Allow for both an adjective and a noun in each OBJECT box as needed.

            Another would be to have something like Journey’s interface, but there’d be an “Other” option so that you can enter something not listed, making it less like a CYOA.

            Finally, maybe below the command line, you could have some floating text saying VERB when it’s blank, ADJECTIVE or NOUN right below where the next word would be, and so on. It would serve as a real-time syntax checker.

             
          • Jimmy Maher

            July 17, 2016 at 8:13 am

            I think that using a parser successfully requires a certain frame of mind that programmers have learned out of necessity but that can be a huge struggle for others. Those others aren’t stupid; they just quite literally haven’t learned to think the right way. Of course, the parser can be learned, and by most people within a few hours. But it can be a hugely frustrating experience in the beginning, and a completely foreign one at that. Most people today have no experience whatsoever with *typing* a command to the computer. The point-and-click paradigm attained absolute domination many years ago.

            So, what we have is a uniquely foreign, opaque, and frustrating interface that causes most modern players to bounce off long before it clicks. I don’t have any solution to offer for this. As I wrote at the beginning of this article, I think it’s just the nature of the beast, meaning parser-based interactive fiction will always be a tiny niche hobby. Which is fine really.

             
          • matt w

            July 17, 2016 at 4:45 pm

            “Most people today have no experience whatsoever with *typing* a command to the computer.”

            I feel like this isn’t absolutely true. Most people probably have typed things into Google at some point, and in some ways IF parser commands are more like Google queries (especially ones like “What happens if Britain leaves the EU?”) than command-line things like cd C:\games\infocom\ or whatever. But Google has a lot going on under the hood to try to get meaningful results out of any old thing you type in, and can get away with keyword matching because it doesn’t afford you the kind of control that you need for a parser game to not be totally frustrating. (I don’t expect to type “show me that picture where Steve Nash and a bunch of other basketball players look totally goofy in the middle of the game” and get what I want. Though if anyone knows where I can find that picture please advise.) And also Google has a hunormous variety of possible responses, whereas a parser can only do what you’ve programmed in–the problem with “wait until the kettle boils” wouldn’t so much be parsing the command as programming in that behavior, and all the other similar behavior someone might expect.

            And in its way the parser doesn’t really call on the habits of the programmer, IMO. The point is that if you’re able to get into the frame of mind where you’re able to interact with the parser then it relies on the extremely powerful language centers of your brain. It’s much more natural and quicker for me to type “put tea in teapot” than it would be to accomplish the same thing using a menu interface. But it’s only natural in that way because I’m not tempted to go outside the syntax I know the parser accepts.

            (Alexander, that’s part of the reason that I didn’t include COMMANDS in my game, the other parts being that it was something I had written in a very short time and also that my testers, being people who played parser games, never needed a list of commands. The point of the game, whose source you can see here, is in large part that you’re supposed to be able to interact with it pretty naturally–you see a loaf of bread, you see a bread knife, you type “CUT THE BREAD WITH THE KNIFE.” And if you’re not getting things done the game will prompt you with something like “You’ll have to fill the kettle up with water.” whereupon “FILL THE KETTLE UP WITH WATER” works–though there’s some fussing with the bread box at the beginning where this doesn’t work as smoothly as I’d like. But giving an explicit list of commands felt like it would disrupt this smooth interaction, or at least an interaction that’s smooth for people who are a little used to it.)

            So the frame of mind that you need for the parser is really that of someone who can use a restricted set of language in a precise way to obtain specific effects. Which means it’s like programming… if you’re programming in Inform 7.

             
          • Jimmy Maher

            July 18, 2016 at 2:27 pm

            It’s a complicated topic, and it’s easy to get yourself into a hopeless tangle of likenesses and metaphors, but I would personally say that a command to a parser-driven text adventure is really more similar to an MS-DOS or Unix command than a Google query. You are, after all, issuing an imperative statement telling someone — the computer or your avatar — to do something. And, whereas a Google query that includes at least one or two recognizable words will always return *something*, a text-adventure parser can respond only to an extremely small, circumscribed subset of vocabulary and grammar. This, again, makes it much more similar to a command line or a programming language. But at the same time, a problem may very well be that, because the language of the parser superficially appears to be conventional English (or some other human language), there is an expectation created that the program will understand much more than it actually can. (Inform 7, brilliant as it is in so many respects, also suffers from the same syndrome.) And things like Google may also contribute to the notion that you can essentially type *anything* and expect a response.

            I think programmers have an easier time with parsers because the text-adventure command line is really a language or language subset of its own that, like most programming languages, borrows from English (Inform 7 is only an extreme example of this phenomenon). But it’s heavily, rigidly structured to not only to make it easier for the computer to interpret but also — and this point is usually missed — to remove all possibility of ambiguity, which it accomplishes partly by forcing the player/programmer to think in a ridiculously granular way, something programmers are used to doing but many others are not. One could take this comparison even further by equating objects with which one can interact in a text adventure with variables, which must be declared beforehand in many programming languages. Again, programmers innately grasp that you can’t start messing about with the windows or the walls in a text adventure if they haven’t been “declared” via a mention in the text. This thought process can I think be more or less hard for many non-programmers encountering it for the first time to grasp.

            I would say the closest thing to a parser used on an everyday basis would be something like Siri rather than a Google search. And I do think it’s perfectly possible to make a much, much smarter and more responsive parser. But it would require a research effort which makes sense for a global search engine or a widely used mobile-phone interface, but just doesn’t for a text adventure.

             
          • Alexander Freeman

            July 17, 2016 at 5:40 pm

            I think you misunderstood what I meant, Matt. What I meant is that I thought your game made it perfectly clear that one is supposed to enter commands at the command prompt, not a COMMANDS verb that lists all the different verbs recognized.

            Anyhow, I think I may be on to something here with using modern features to make the parser more user friendly. Once I have it working, I think you all will see what exactly I had in mind. Maybe I just didn’t do a good enough job of describing it in that comment.

             
          • matt w

            July 18, 2016 at 4:11 am

            Ah, I did misunderstand about commands–I thought you meant to enter “COMMANDS” (which I have seen in some games). The game itself didn’t say to type commands at the prompt, but I did say that in the e-mail I sent out to the non-IF players with the game… but either it’s too hard to read the manual, or (somewhat my pet theory) it’s just hard to break the habit of typing what seems natural. Though in this case maybe the problem wasn’t even the syntax, as that the “kettle boils” person was frustrated at having to wait at that point and the person who examined the window just didn’t know what the conventions were for what was implemented… dunno.

            Your ideas sound intriguing but the text field one would likely, for me, run into a problem were entering commands wouldn’t be like just typing my thoughts in the relevant way–typing PUT (tab) BREAD (tab) IN (tab) TOASTER (enter) just isn’t like typing PUT BREAD IN TOASTER. As for the real-time syntax checker, you might want to check out the Inform 7 extension Interactive Parsing by Jon Ingold (found here, only compatible with older versions of Inform I think, but you can get older versions from the Inform website). It tries to do something like that… didn’t catch on for whatever reason, and I’m not sure the demo Jon made of it is available. Jon went on to found Inkle, of 80 Days and Sorcery!, so he’s left the parser behind himself.

             
          • Alexander Freeman

            July 18, 2016 at 5:22 am

            Yeah, I have thought about how to enter commands into the fields. one way would be to use tab, but it could also use space to achieve the same thing. I’ll have to look into what Jon Ingold did, though.

             
          • Sniffnoy

            July 19, 2016 at 1:49 am

            The thing about this sort of thing is that the player has to know somehow that a command like TRADE BALL FOR DART or TRADE BALL TO BILL FOR DART will work. (Or type it without knowing–but if you’re relying on a player typing syntaxes that they won’t know then you’re going to wind up with players typing a lot of commands the parser won’t understand.) At least people who’ve been brought up on parser games are pretty well habituated to GET THIS and X THAT and PUT THIS IN THAT and UNLOCK THAT WITH THIS and some of the other things, but even with that kind of background you have to be pretty good at hinting the verb and syntax you want to use if you want the player to come up with TRADE THIS FOR THAT.

            As I said in my post above, I don’t think your dichotomy here is correct. And I think it’s a mistake to say, well, everyone’s gotten used to how things work with these particular technical limitations, so we can’t improve things or it would be too confusing to existing players. Like… that seems like a fairly minor problem by comparison. Maybe just, y’know, put in big letters on your game, “This game has an improved parser that can handle more complex sentences, so you might want to try some!” Maybe more detail than that.

            I don’t really understand why it would supposedly be so hard to come up with “trade this for that”. A number of adventure games involve trading things; if you want to trade for something, why would you not just say so? It’s basically the most direct way. I mean, above I used the phrase “in exchange for”, which is a more natural way IMO, but it’s possible you can program that to work too as a special case. Rather than having to hint the verb and syntax, maybe you can just allow permissive verbs and syntaxes. This is what games already do quite a bit of, though with simpler syntaxes, admittedly.

            (Though I’m also wondering how this is supposed to work from a puzzle design standpoint–how do I know that trading Bill the ball for the dart is a good idea? If it’s that Bill has a dart I want and I can recognize that he needs the ball, I guess I expect GIVE BALL TO BILL to produce the result I need to move things along, on the general principle that if there’s something you can do in a game it’ll accomplish something…. taking on board Jimmy’s caveat about the Magnetic Scrolls games. If you have a game where the puzzles are that you really need to figure out which things to trade for what things according to some system, then the game should be explaining the verb you need to use.)

            I agree there is a puzzle design challenge here — though I think it’s less a matter of actual puzzle design, and more a matter of “puzzle interface design”. But what you’re doing here is essentially metagaming, and I don’t think the player should have to rely on metagaming to such an extent. It’s easy to expect the Magnetic Scrolls result instead if you don’t! But I agree there’s a potential problem here; if you allow the player to explicitly trade the ball for the dart, then it makes less sense for Bill to refuse your gift (so that you’re not stuck) if you want to just give him the ball, or to decline your offer if you try to trade two balls for the dart, or whatever.

             
          • Sniffnoy

            July 19, 2016 at 8:25 pm

            Actually, I guess in games with more separation between the player and the character, this is just handled by having the character refuse to do such a thing. This can get a little frustrating if there’s no obvious reason for the character to refuse, but it’s no worse than having the game refuse. Unfortunately this solution doesn’t work as well with the standard second-person style, though I’ve seen it used there; it just reads kind of weirdly.

             
      • Jimmy Maher

        July 16, 2016 at 9:49 am

        The worst offenders here are the Magnetic Scrolls games, which in the name of simulation will let you give anything to anyone. If the action isn’t necessary to the plot or a puzzle, the character will just take the object, and you have no way to ever get it back.

        Modern games do at least offer undo. If you aren’t sure exactly what the parser will do with a command, you can just try it and see, then undo if it goes wrong.

         
        • Alexander Freeman

          July 20, 2016 at 1:14 am

          “I’ve played several IF games and I honestly never realized before now that commands take at most two nouns, whether as objects, indirect objects, or prepositional complements. It’s not too hard to see someone else play and get the gist of it…”

          Yeah, my memory of my very first experiences with adventure games is a little fuzzy, but I think my very first adventure game ever was a little known game called Castle Adventure, but that only had a simple two-word parser. But I was able to pick it up quite easily. My next three adventure games were Hugo’s House of Horrors, Zork 1, and some obscure game called Enchanted Castle. I think it was in that order. I think I might have read sample commands and got the gist of it after entering various different commands. HHH had a keyword search. I think Enchanted Castle had a two-word parser like Castle Adventure.

          But, yeah, my experience was getting the gist of it from examples and maybe seeing other people type in commands. (It was a long time ago.) I just thought everyone would pick it up too. I didn’t think about how many nouns a command would accept until I decided to make my own parser modeled after Infocom’s.

           
    • Felix

      July 17, 2016 at 6:56 am

      The problem with the parser is that people have different cognitive abilities, and they can miss instructions even while earnestly reading the manual — every book is full of little “blink and you miss it” bits that can easily prove important down the road. Sure, that’s what beta-testing (and beta-reading) are for… but testers are human too.

      Besides, when you have an UI that implicitly (and sometimes explicitly) encourages people to experiment beyond what the manual says, is it any surprise that some players will try wacky stuff? Doubly so if they’re not completely familiar with the genre conventions… something a lot of us are only because we also tried authoring.

      Look, I grew up with line-number BASIC. I’m a long-time Linux user. I love command lines. But in interactive fiction, the parser is by and large a lie, and after decades of experiments it should be obvious that’s a fundamental trait.

       
      • Alexander Freeman

        July 17, 2016 at 5:48 pm

        “Besides, when you have an UI that implicitly (and sometimes explicitly) encourages people to experiment beyond what the manual says, is it any surprise that some players will try wacky stuff? Doubly so if they’re not completely familiar with the genre conventions…”

        Well, that’s not necessarily a bad thing as long as there are no penalties for experimenting. That’s how one learns. Besides, I still like trying wacky things after having played adventure games for more than 25 years! ^_^

        Still, you bring up a good point about how different people learn differently. I think a short, thoroughly tested game with the features I’ve suggested might serve as a good tutorial for how the whole thing works.

         
  4. M. Sean Molley

    July 15, 2016 at 6:26 pm

    Is there an easy way to play this? “Journey” and “Quarterstaff” are the only two Infocom-published titles that I have never gotten to play (or if I did, I don’t remember anything about them!)

     
    • Jimmy Maher

      July 15, 2016 at 7:34 pm

      I don’t like to give out direct links to such things here, but it’s not hard to find by searching for something like “abandonware Infocom Journey.” The story file is playable in any modern Z-Machine interpreter that supports the .z6 format. It will be the largest single file in an MS-DOS (or any other) version of the game. If you’re using Windows Frotz and possibly some other interpreters, you’ll also need the graphics in a format the interpreter supports. These you can download from http://www.ifarchive.org/indexes/if-archiveXinfocomXmediaXblorb.html. Make sure the .blb file has the same name as the story file and is in the same directory. Then just load the story file into your interpreter like any other Infocom (or Inform) game.

       
      • Michael Davis

        July 16, 2016 at 11:36 pm

        Err.. right after clicking ‘Post Comment’ I thought, erp, maybe I misinterpreted what you meant when you said “I don’t like to give out direct links to such things here”. I took that to mean sketchy abandonware or piracy sites, but maybe you just meant, like, any links at all, and if that’s the case, please delete my comment: I definitely didn’t mean to be mutinous or insubordinate!

         
        • Jimmy Maher

          July 17, 2016 at 8:04 am

          archive.org is legitimate enough to be in order. I’m always forgetting that collection exists now…

           
          • Michael Davis

            July 24, 2016 at 6:13 pm

            I have gotten a TON of mileage out of that collection. It was particularly helpful when gathering reference for ICBM :D

             
  5. Andrew Plotkin

    July 15, 2016 at 6:31 pm

    My memories of _Journey_ boil down to three things:

    – Running out of a reagent. When I was planning _Hadean Lands_, I was thinking in equal measure of _Enchanter_ and _Journey_ — Infocom’s two models of resource-limitation puzzle. _Enchanter_ is a shining beacon of Doing It Right, and _Journey_, well, isn’t. But I was sure that _Journey_ had *something* worth exploring.

    – The cod-Tolkien setting. I’m afraid I didn’t find it even as interesting as you did. It managed to feel more bland and boilerplate than the Zork milieu, which is a low bar to clear. (Quendor is literally nothing but cornball jokes and anachronisms held together with fantasy pastiche, but I remember wishing that _Journey_ had been set there.)

    – And yet, one of those type-an-answer puzzles — the “Doors of Moria” puzzle — remains near the top of my favorite Infocom puzzles ever. Yes, it requires a leap of intuition. It’s a classic riddle; those require such leaps by definition. But it’s a *great* riddle, with an answer that is simple and obvious once you see it (or it’s explained), and it’s completely original to Infocom as far as I know.

    (You could accuse me of liking that puzzle because I had the classic riddle-solving experience: I stared at it and sweated for hours, then gave up, went to take a shower, and the answer assembled itself in my head apparently by itself. This accusation would be accurate. You gotta treasure those moments when they happen.)

     
    • Lisa H.

      July 15, 2016 at 8:05 pm

      I like the Quendor setting enough that I’ve sometimes wanted to ask for gift fanfic written there (though always gave it up as probably too obscure). At least you can say that it’s unusual and colorful; Journey’s is rather off-the-rack in comparison.

       
      • S. John Ross

        July 16, 2016 at 6:04 am

        I love Quendor so much that there’s a faint squeaking noise in my head when I think of it.

         
  6. Lisa H.

    July 16, 2016 at 3:37 am

    It’s really, really hard to square marketing’s claim of “no dead ends” with a game that not only includes dead ends but will end up being defined by them in any player’s memory.

    Ayup. It took me a long time to play through this enough to my satisfaction to put a walkthrough for it up on my website. One of the things that annoyed me the most about the limited reagents was not just that it was easy to run out of them, but that you began the game with only JUST enough of one, so that you would come up short of it not even through flailing around trying to solve puzzles, but by exploring all the menu options available to you at the start of the game! It seems excessively cruel to me that you should be punished plotwise for following a menu branch that otherwise just adds background color, especially since it might not become apparent until the absolute end.

     
  7. xxx

    July 16, 2016 at 4:49 am

    “It’s really, really hard to square marketing’s claim of “no dead ends” with a game that not only includes dead ends but will end up being defined by them in any player’s memory.”

    Exactly! That’s the main thing which stands out to me about Journey in my memory: the constant fear that anything I did would lock me out of winning. I had so many damn saved games. Eventually gave up because that fear hanging over my every move and the constant repetition of the earlier parts of the game were about as fun as food poisoning, despite the interesting interface and pictures.

     
  8. S. John Ross

    July 16, 2016 at 6:07 am

    “…A bunch of hard-branching links in the form of a computerized Choose Your Own Adventure book was likely to appeal to no one….”

    Speaking of: will you be writing about the Infocomics (or have you already and I missed it?)

     
    • Jimmy Maher

      July 16, 2016 at 9:45 am

      I wrote about them in passing earlier, but no, no detailed reviews of the individual titles. You have to draw a line somewhere. ;)

       
  9. matt w

    July 16, 2016 at 4:00 pm

    The great wizard Asterix? Did you have to defeat the fearsome dragon Tintin?

     
    • Jimmy Maher

      July 16, 2016 at 4:45 pm

      :) I had some snark to that effect in the article at one point, but wound up cutting it — mainly because Astrix isn’t quite the same as Asterix, and I could imagine a bunch of people correcting me for that, but trying to explain I knew that in the article would just make the whole thing too labored and unfunny.

       
      • Alexander Freeman

        July 16, 2016 at 5:41 pm

        Is that from the Comic Asterix or the comic Tintin?

         
      • matt w

        July 17, 2016 at 3:14 am

        Ah. In the article you do call him Asterix with the “e.” Also on the typo patrol, you mention “Dave Lebing” which I think should be “Lebling.”

        (Alexander below–each character is from their respective comic–I went for a different comic for the dragon’s name because all the Asterix characters have names ending with -ix which would spoil the joke, unless I’m going for really obscure ones like Zebigbos or Tullius Detritus.)

         
        • Jimmy Maher

          July 17, 2016 at 8:03 am

          Woop! Should have known I’d screw that up somehow.

           
  10. matt w

    July 16, 2016 at 4:03 pm

    From that passage one does suspect that there were originally Eight Stones, one of which was sundered. First one finds the Four, which leads one to the Two, and thence the One, and the One-Half, and the One-Quarter, and so on for infinite replay value.

    OK, the capitalization of significant Nouns is a well-established enough trope that it can be Useful in setting the stage. I’ll stop snarking now.

     
  11. Bob Reeves

    July 16, 2016 at 4:33 pm

    Enjoyed it and solved it pretty quickly at the time, but I need a walkthrough now (and even following it faithfully, can still lack what I need to cast the last spell, I’ve discovered).

     
  12. Dave Gilbert

    July 17, 2016 at 5:22 pm

    Not only could you run out of reagent, but you could also get stuck if you didn’t write down what color residue appeared on Praxix’s fingers when he cast a spell. When Tag has to cast his own spell at the end of the game, he doesn’t know which reagent is which and has to guess based on their colors.

    God this game is flawed for this reason alone. But also GOD did I love love love this game. I got lost in it. I replayed it several times to get to the proper ending, and I didn’t care.

    Of course I was like 11 at the time. Perhaps I didn’t know better.

     
  13. Lisa H.

    July 18, 2016 at 6:59 pm

    Off topic: Jimmy, I’m a little confused how you were able to make this reply: http://www.filfre.net/2016/07/journey/#comment-248979 I don’t see any reply link on the comment of matt w’s you were replying to. I do see them on some other comments (is it a question of depth? max 5 levels?) and of course I’m able to leave an entirely new one, but… ?

     
    • Jimmy Maher

      July 19, 2016 at 8:12 am

      Although WordPress supports comments nested up to 10 deep, my current settings limit them to nesting no more than 5 deep. Otherwise there just isn’t enough screen space, especially on mobile. The way WordPress accomplishes this restriction is simply by not offering a reply link after the 5th level. However, I reply to comments a little differently than you folks do. I normally receive an email, and if I wish to reply I click a link right there in the email which takes me to my administration panel to enter a reply.

      So, in short, I can do it but you can’t. ;)

       
      • Lisa H.

        July 19, 2016 at 6:21 pm

        Speaking of screen space, the central column seems awfully narrow on 1920×1080. Lots of plain brown background with the content filling les than half, maybe about half if I include the sidebar. I could be wrong but thought that was a fairly common monitor size these days? I don’t suppose WordPress supports dynamically serving different versions based on detecting the reader’s window size?

         
        • Eric Lundquist

          July 19, 2016 at 10:27 pm

          On my screen, the web browser is 21″ wide, and the blog uses up 9.75″ of that, leaving the rest brown. The actual white text column is under 6.75″, or 1/3 of the field.

          Thankfully, it uses the full screen on my phone.

           
        • Jimmy Maher

          July 20, 2016 at 7:28 am

          You’re right that that’s a very common resolution, but most people find reading wide columns of text to be very uncomfortable. Thus most commercial sites and blogs, like this one, keep the text width limited to roughly that of a printed page even when browsing full-screen. Most of the sites I read regularly follow this practice; about the only exceptions, for what it’s worth, are Wikipedia and Planet IF.

          I would venture to guess that most people running 1920×1080 on a desktop are like me in that they usually don’t browse with the browser window maximized. And those running that resolution on a laptop screen with much higher pixel density will usually employ a magnification factor to keep everything from being *really* small. Again, that’s my usage pattern anyway.

          Not to say you’re doing it wrong, but… well, you may be doing it differently from many or most of us. ;)

           
  14. Ibrahim Gucukoglu

    July 22, 2016 at 4:57 am

    Hi Jim,.

    Thanks as always for a concise and decisive look at this Infocom game, it brings me many happy memories as all your articles on Infocom do. I spent many happy hours trying to solve Journey, and it was the only game I didn’t end up using a walkthrough to get me past the final few hurdles. I agree with you re the unfair puzzle solving which forced you to look at your reagents pretty much every. Spell casting to make sure you hadn’t overused your allowances. You often had more of some reagents than you strictly needed while if I remember rightly, the water essence was one of the hardest to come by and for which you needed to solve the final puzzle where you need to cast a lightning spell yourself. Speaking of this puzzle, does the latest version of journey let you complete it as I could never do so. Whenever you mix the final bunch of reagents together, before you can cast them, the dread Lord always kills your dwarf and you end up with Ann in satisfying ending. Could you help me here are as I still have my last save game point somewhere on floppy disk. Thanks.

     
    • Jimmy Maher

      July 22, 2016 at 7:19 am

      I’m afraid I gave up in frustration and sheer boredom myself before managing to see the winning screen, which makes Journey still the only Infocom game I’ve never actually won. But perhaps someone else can help.

       

Leave a Reply

Your email address will not be published.