Most parser games have a scrolling text output so you can see previous commands/responses. Most choice games don’t: you tap a choice, and the response replaces the previous content on the screen.
Which do most users prefer, and why? I’m asking for a project I’m currently working on. Thanks!
Great question. With choices embedded in the text you have the problem that you need to alter the previous content or you’ll have a bunch of invalid links and bugs.
Choice games normally don’t need scrolling because the text isn’t that long. Off course, there are exceptions.
I personally don’t like if the scrolling is done fully automatically when there’s lot of text. Instead it should stop when the text area/window is full and say something like “Press any key to continue” (or in choice games press a button for that.)
I like it if a game let’s you go back in the window and see “old” text (important if the puzzles/quests build on something an NPC said or so). But since I didn’t use it for a while now, I think it’s not important for me.
Edit, worth mentioning: I really dislike long text walls, except when something really special happens. So scrolling is generally the wrong direction (for my games taste).
As a person who writes about interactive fiction, my experience is that the lack of scrollback/transcript functionality makes research and citation more difficult. “How much text should a game made out of text have?” feels like an aesthetic question that might be answered differently.
Perhaps ironically you might “need” scrollback less for typical puzzle based parser games since you can re-examine everything, compared to story based twine games. An example of an aesthetic reason not to include scrolling are games that emulate a web page eg Configuration Uploader.
I want to push back on this a little bit; most Twine games don’t, true, but Ink is another choice engine that does have built-in scrollback (see, for example, the recent Xanthippe’s Last Night With Socrates). And re: parsers, while Inform and TADS games have built-in scrollback, Adventuron games don’t. (I know this is kind of beside the point, but it feels important to the discussion to note that it’s not inherently a parser/choice divide, but is rather determined by the specific engine used for either.)
To answer the actual question, as both a writer and player, I do like having the scrollback and have been frustrated that Twine’s Harlowe and Sugarcube formats (the two most commonly used) don’t have an easy (any?) way to include it. But that said, I think with some choice games it wouldn’t really make sense to have it, because the text isn’t meant to be read as a linear story.
So basically, depends on the game! But typically, I would prefer having scrollback.
Didn’t one of the original Twine 1 templates do a scroll? Jonah?
Yep, that’s what I’ve heard. And Paloma is apparently a Jonah-style format for Twine 2.
Regardless of format, it really depends on how much the game is going to depend on recall and callbacks. I might not remember if I frotzed the frugle three chapters earlier. I might not be able to effectively travel back and check, as forward progress may have made backtracking to that point impossible. Being able to scroll up and remind yourself of something can be useful, if not very mimetic.
The other thing scrollback, and specifically transcripts, helps with is saved games. In a larger game, I may save my game, get distracted, and come back months or years later. Having a play transcript saved along with my saved game allows me to refresh where I was. Otherwise, I either muddle ahead, functionally struck with in-game amnesia, or I start over, rendering the save pointless.
With those two points made, also screw both of them. I could counter that scrollback defeats the need to take notes or use my noggin, which is arguably the point of some games. Also, those same notes taken with saved games can render transcripts unnecessary.
Scrollback works as an Ease-of-life UI feature, but I wouldn’t see it as required in any means. Including it might make the game easier, but maybe that runs counter to your intentions.
It would be interesting to see certain types of IF have different difficulties that take those sorts of amenities into consideration. Finishing the game on a harder difficulty might disable scrollback, granting the player some sort of acknowledgement or achievement if they managed it, etc, etc.
With that last point made, also screw that one too. I’m sure there’s crossover with accessibility needs and intentionally disabling scrollback on an engine that typically supports it might negatively impact the experience of some players beyond an incremental difficulty increase.
In conclusion, screw all the points I’ve made thus far for various reasons.
Please carry on.
I’ve come to the conclusion that my favorite way to handle these kinds of dilemmas is to add a setting to enable/disable it. You can have it turned off by default and most people will play it the way you want and the few who care can play it the way they want. That is assuming you want to put in the effort to implement the feature in the first place.
And another problem with infinite scroll back is saving. Generally it is not saved even for parser I don’t think, and any additional markup the text has will only make saving harder.
Wait. Are you saying save usually stores transcripts or are you saying you normally manually store transcripts as well as your save?
The latter. Although having that as an automated option when saving would be nice.
Most choice games (Twine-format, as Tabitha points out) use short passages of text because scrolling isn’t available! Authors write what works in the UI. Change the UI, change the form.
If the game is designed for it, it’s required. Try playing Zork with a UI that clears the screen after every input. “In theory” you can take notes, but in practice you’ve made the game unplayable.
(Mind you, Zork was designed for terminal displays that had twenty, twenty-four lines of scrollback at most. Different from none, but also different from a modern IF interpreter. That’s one reason modern parser games are more verbose.) (Game file size is the other, of course.)
Solvable problem if you’re building the UI for it. You can mark the “current” passage, or separate it from scrolled-out text, and deactivate links in the latter.
Again, solvable. Lectrote does this for formats that support autosave (Z/G).
(To be clear, “infinite” scrollback doesn’t mean infinite. You don’t want save files, or display buffers, to grow without limit; the system will eventually become unusable. You trim old text after a certain point. This means you need a separate log-to-file feature for true academic-style history-saving.)
Not gonna lie, that sounds like a throwdown to me, lol.
Let’s… scroll back, for lack of a better term. I think it’s reasonable for someone reading a text to say, “I’d like to look at some of this text again.” Sure, we could gatekeep or police that sort of thing, or ask the player if they’ve rigorously explored alternatives, but I think it’s worth taking such assertions at face value.
I also think “should this feature that I wouldn’t use exist?” is a question with problems. I don’t use most accessibility features, for instance, but I think they should exist. My own personal utility really shouldn’t be a deciding factor.
Ultimately, I think this is a question about platform or architecture features that players might or might not use. I don’t think that anyone is suggestiing that someone go back to Birdland and remove all of the “clear screen” events between episodes. I don’t see anything like that in the OP, anyway.
Possible solutions include a separate window/button/file for transcription. The question is just about a feature that could exist. It isn’t about vandalizing games or imposing design requirements on authors.
I’m not really worried about it either way. People are pretty set in their ways and not much is likely to change anyway other than some outliers.
As long as we’re being pedantic, suppose someone generates 1k of text per turn every second. That would be 24x60x60x1k=86m per day, so even assuming they have 8g of ram they can continue for 100 days before running out of memory. If someone wants to break the game, you aren’t going to stop them.
Thanks everyone for your feedback. It really helps me to get outside perspectives.
I see a couple of paths here:
A log system that outputs to a transcript file. To make it really robust, maybe a data schema that informed the viewer what type of properties they’re looking at: here’s a player command, here’s a response that returned a new turn, here’s a response that saved the game, etc…
A built in note taking system. One thing people requested on Black Walrus was a in-game note taker. I think this is a really cool idea that can theme in with the game–say you encounter a valuable clue, and the note-taker would put it down in the words of the protagonist. This aids in immersion and cuts down on the player scrolling through dozens of command/response pairs looking for clues.
If I’m really ambitious I might implement both.
I use scroll back all the time. Constantly. Games that don’t have it (even choice-based) are not as good for me if there’s puzzle-solving or a complex narrative.
If people don’t like scroll back, they could just, y’know, not use it.