Well, I’ve done a search, and it seems I imagined it, so I’ll change the topic heading! (For the benefit of newcomers, it used to say “Split Screen vs Conversational Presentation”)
I never really liked the very traditional form of split-screen. I much preferred having my inputs displayed alongside the responses, as a back and forth between the player and the computer/game world. (I admit that the traditional split-screen presentation did seem to work well for real-time adventures, where the game world progressed and updated while you were typing)
The homegrown adventure community gravitated to a sort of hybrid solution on the ZX Spectrum. There was a long period of time where virtually all authors locked the location text in place and had everything else scroll underneath; reducing the need for redescribe/look. If new objects were discovered, the unwritten convention was “anykey” then clear the screen and reset the location text.
However, with long location descriptions you could often be left with very little “working space” at the bottom of the screen. I’ve noticed one or two instances in my own games where the poor player had only a few lines left for the input and response, thanks to my waffling prose!
(Edit… just to add that I think the label of “conversational” is perfect for the conventional presentation… It echoes the Spanish term for the genre and perfectly describes the way the input and responses are printed as a conversation between player and computer)
2 Likes
I think this is more of a problem with games that use the 8-bit look - the text tends to be a lot larger. Nevertheless, I’ve deliberately kept the room descriptions shorter in my WIP, as I have a tendency to waffle too. It’s been quite a good discipline.
So do I! And I’m still convinced I’ve seen it used somewhere.
(Whenever I think “split-screen” I tend to think of the three section split-screen where the location, responses, and input line each have their own section. I appreciate that this isn’t necessary the Scott Adams format so the comments regarding not keeping input and response together aren’t necessarily applicable.)
Yeah, I realise it varies. I played the Scott Adams games on a BBC Micro, and you got a section at the top for the location description, updated every time it changed, and a scrolling section at the bottom for all the other responses. This is what I’ve replicated with the I7 code, except that I’ve added another window at the side for the inventory. What prompted me to do this was Robin Johnson’s Draculaland, which I’ve played numerous times with my nephew. It just seemed like a good idea.
An update on the screen reader issue - having reviewed my code this morning I notice that it updates both the location window and the inventory window every turn, which could be deeply irritating if you use a screen reader. I’m going to look into amending that. It will still require thorough testing, though.
1 Like
I know I used the term “conversational” here. But I’m not clever enough to come up with that myself so I also must have seen it somewhere…
That’s almost certainly where I saw it! I knew it was quite recently, and it must have struck me as apt.
For Kerkerkruip we had side panels showing inventory etc, and had a screen reader mode that would turn them off. It was also an independent option because for various reasons someone else might want to turn them off too.
I suspect that it’s not so common because it disrupts that most nebulous of things: immersion. As odd as the parser format is, it’s still one stream of text back and forth.
2 Likes
I personally prefer the conversational mode, because it reflects the idea of the player and game-maker writing a story together. The resulting body of text can live on as a transcript, to be reviewed, replayed, quoted, and discussed.
I’m following Jason Dyer’s All the adventures project, and it’s always a little annoying to have to decipher screenshots (like in this post and many others) to figure out in what order the various lines were printed.
4 Likes
I always liked the split screen concept, but i agree this only works well when there is the minimum of content in the upper view, as it tends to be in Scott games.
But i think the idea can be taken further;
A split view is part “live” and part “historical”, whereas the “conversational” view is all historical.
So what if it were all “live”?
This is something I’ve been working on recently as part of building the “universal canvas”, ie a 100% live view. The additional complication comes in when you have graphics and indeed animated graphics.
People want the graphics to be a “live” view. ie what the situation is now! And so if the graphics are live and the text occupies the same screen space, then the text must be a live view as well, whence the “universal canvas”.
4 Likes
I think… I might need you to explain this in more detail! 
I don’t like the split screen view as much because it means I have to look at two different places to find out what’s happening. Usually when playing IF my eyes are locked to the bottom of the screen, more or less, and when information pops up at the top of the screen it’s distracting or I may not notice it. This particularly happened in Reliques of Tolti-Aph where at a certain point a critical hint pops up in a boxed quote and I failed to notice it was even there.
However as jkj says this is much less of an issue in a minimal interface like the Scott games. IIRC the emulator I’ve played them on on archive.org sort of flashes when the top updates, which is a sign to look there.
For some reason I don’t feel like I have this issue with things like Robin Johnson’s game with a bunch of side panels, maybe because IIRC the side panels are for action links so I go and look over there when I actively want to do something. Similarly I don’t mind exit lists in the status bar.
1 Like
The idea of “all live” for a text mode would be to display the current status of everything only and no historical scrolling.
- Your top line might be the current location and possibly score
- Perhaps a brief description of the location
- List of visible objects.
Similar to the existing Scott system. Below this, a Scott system will have a scrolling text region.
Instead, dispense with the region separator, dispense with the scrolling region and turn it into a live text area that just shows the result of what you’ve just typed.
Now, for a modern view, take all the “above the line” information and put that on a title bar and a sidebar along with the inventory (which is live of course), and put the text entry box at the bottom.
What you now have is one central area that just shows the result of your last command. If it had a scrollbar, it would be to scroll just that one message, but it would probably be better to have “MORE” in such case. If you have pictures, they also occupy the central area rather than be on a separate panel.
You might ask, how might you go back a review some earlier text. Perhaps you want to read a message again?
I’m solving this by having the whole system on a timeline so you can just rewind the game. Generally, you can “scrub” backwards and forward like a movie. This concept also unifies undo and save game.
It now seems incongruous to me that a UI should scroll back the text but not scroll back the state. These should be one and the same thing!
And this is especially pertinent if you have stateful graphics. Do you want to scroll back the picture? Well yes, but not separately and not with a picture scrollbar like you do text.
Instead take your “scrollbar” and turn it horizontal into a timeline and make it into a “movie cursor” that “scrolls” the entire game back and forth. Moving the cursor changes the text, the picture, the game state, the sidebar, sound etc. Basically everything.
I think it’s the way to go.
3 Likes
I saw “conversational” used in this thread on an ScottKit issue on GitHub from 2017.
I knew I couldn’t have come up with it myself…
1 Like
Interesting! I’m half-tempted to change the topic heading back, now.
2 Likes
Do it!
2 Likes
Reading Jason Dyer’s blog, it’s been interesting how common the split interface was. I always thought of it as “Scott Adams style” but it really was the default IF UI for a couple of years. Infocom’s conversational UI was an outlier until their market success shifted the center of gravity. (And, of course, Infocom retained the split screen in vestigial one-line form.)
I still prefer conversational and straightforward history scrolling. Mind you, I’m typing this on a Mac which has eight terminal windows up, most showing “conversational UI” shells with history scrolling.
3 Likes
I think that’s because so many people bought/borrowed/stole Adams’ code/concept during that period.
This discussion does shine a spotlight on why the split-screen approach seemed like a natural evolution at the time.
Early mainframe experience: a good chance you’re playing on a teletype. Why LOOK again when you can just physically look at the printout in front of you?
Personal computer (once you’re in the PET/TRS-80/Apple II class): definitely assuming your own CRT. So of course you should get more information about the room you just revisited.
4 Likes
This is why I disagree that having the separate window breaks immersion. IRL, if you’re fortunate enough to be sighted, “looking” isn’t something you consciously have to do, it’s something you’re doing all the time. For me, having to keep LOOKing is immersion-breaking.
2 Likes
Which is one of the reasons why VERBOSE is always my first command. 
(That, and as the discussion unfolds, it’s starting to feel like Infocom’s choice to make BRIEF the default was partially motivated by reducing load times from slow floppy drives but also partially “meh, this is how we played it” inertia.)
(although I also use VERBOSE as a nervous time-wasting free command while flailing to come up with a new idea, so.)
2 Likes