I figured out how to clear the screen at each command:
[MAKE THE GAME CLEAR THE SCREEN AT EACH COMMAND -- REQUIRES Include Basic Screen Effects by Emily Short. ]
After reading a command:
clear the screen;
say "[line break]";
Before reading a command:
say "[line break]";
I think it has its advantages, but there are weak points too. Here is my list:
WEAKNESS:
Tradition! Clearing the screen will turn off hardcore IF players.
Usability. It is a weakness that the player can no longer see his past choices. The player lacks the visual memory
Short feedback messages such as Taken! only makes sense because they come after the text that describes the action: >take bottle. They will look wierd on their own. The player might feel he misses something when he type go south and then get a description of a new location with no text indication on how he got there.
Clearing the screen constantly might be irritating, compared to a constant text that keep growing.
STRENGTH:
Cleaner: You only see a paragraph of text describing what you experiences right now.
Realism: In the real world, what happens right now is radically different from incidents in the past. Only being able to read what is happening right now is more realistic than being able to read which room you was in 2 minutes ago.
Traditionally, IF has been designed based on the standard the (super-)user had with a console screen. This makes the design closer to coding than to gaming. I think clearing the screen is a more gamey approach.
I think it could be the right choice, but only in an IF game that was radically different from the standard patterns of IF gameplay. It’s obviously a good choice in, say, The Space Under the Window, or one-turn games. I can imagine other kinds of game where it’d be appropriate. But in the conventional IF setup - exploratory, detail-oriented, puzzly, gently paced, lots of reversible actions - its biggest effect would be to piss the player off.
Whenever you find yourself arguing ‘we should do X in a game because it’s more realistic’, you need to stop and reconsider. Games are not ever going to be perfectly realistic (and shouldn’t be: apart from anything else, reality is mostly too boring for a game). Realism in itself is not a justification for anything. The real answer should be about why you’re concerned with this specific aspect being more realistic - what effect does that have on player experience? what does that realism express?
(If I made an FPS where all the guns were pretty much the same, but bullet injuries had extremely detailed, unpleasant, long-term effects on the player character, that wouldn’t be much of a net change in realism - but it’d say a great deal about the things I think are important.)
Maga, I totally agree … come to think of it, I didn’t really meant ‘realistic’ … what I meant was that it might enable the player to better immerse himself into the fictive world: Only showing what the player experiences here and now will make the game itself more “here and now” … the cost is that the player can’t read back. Hey, I have never played Space Under the Window … will try it out!
Have anyone played Cypher? Any thought to that approach?
Come to think of it, IF is the only turn based games where the player can see his past actions.
Traditionally, it was designed based on the interaction of a user with a potentially unlimited scroll of fan-feed printout. That’s how I first played Adventure.
Then it switched to console screens, without the ability to scroll back. Then the scrolling window UI was invented, and everybody agreed that it was better.
(I have no explanation for Windows Frotz.)
Anyhow, the most recent command in an IF transcript isn’t what’s happening right now. It’s what just happened – unless the command was “look”, in which case it’s what static situation you are in right now. (A slight difference in tense which we normally agree to overlook.) If you want to give the player the experience of the present, you’d have to pause and clear the screen before reading a command. Which would be even more annoying, of course.
(I could get into the analogy of a novel presented as a stack of read-once-and-shred index cards. Probably too much of a tangent, though.)
I think it’s important to identify User Interface/User Experience design as a part of your game development process. They are intertwined. So the questions you need to ask are:
Am I making a traditional IF game in a particular style (Infocom)?
Am I trying to build a new style of UI/UX?
If you’re doing #1, I would recommend sticking to the existing paradigms, as they are well-known.
If you’re doing #2, good luck. You’ll need to create your new UI/UX design and test it thoroughly, as much or if not more than you test your actual content. If you go down this road, I would recommend create a small game of not consequence that matches some small amount of your intended game. Build out the UI/UX using the smaller game and publish it so people can comment. Using all feedback, make adjustments and repeat as necessary.
Many turn-based games maintain logs. (And many of those that don’t really should.)
I get the kind of game that you’re thinking of - something that prioritises immediacy over the past, reaction over analysis. More action-y. That means throwing away a great deal of standard IF practice (which is fine, just a bigger challenge) and also downplaying some of the basic strengths of the turn-based, text-output format. But, as long as you keep that in mind and have a strong idea of what you want, go for it.
I believe that some Scott Adams games employed a Cypher-style display, with the top window always displaying room contents with a lower window accepting text input and offering dynamic output. This was probably an evolutionary dead end for a reason.
Dannii, I don’t know about that … I think Cyphers visuals are great! (Too bad the game itself is kind of broken, with spelling errors and “bad command or file name” feedback at the slightest command variation.)
I’m trying to make the game clear the screen after the players command, and have the location description fixed at top. Just to try it out …
After reading a command:
Clear the screen;
Try looking; [to show the location description at top]
If the player's command matches "look": [to disable the players look command]
Say "Please specify the object that you are looking at: 'look at chair'";
Reject the player's command;
… But when I go to the next room, the “try looking” detects the room I was in before.
And I would also need to disable the auto-look when the player enters a room.
The problem is that After reading a command happens after the player has pressed enter, but before the game has reacted to it.
A solution might be the code below, (Even though I don’t know how to access the games reply to the player)
RecordReply is a text variable. RecordReply is "Not yet changed";
Before reading a command:
Now RecordReply is "[whatever-the-game-replies-to-the-player]";
Clear the screen;
Say "[description of the location of the player][line break]";
Say "[RecordReply][line break]";
About that other problem - going somewhere automatically generates a room description - I feel it might be necessary to change some rule somewhere. Just a feeling.
Nice work, Biep - One problem though: Look would be executed before the players command had been executed - so if the player picks up a bottle, the bottle will still be visible at the look description.
Is there any way I can record the games reply to a command into a variable?
That’s how I first played Adventure.