Again, if well done, I’m sure it’s great. Thing is, I’ve only seen it well done once. Badly done it either exposes the non-implemented items, making the player feel implementation is shoddy, or the whole text becomes a potpourri of scattered highlights.
More directly:
Surely this can be arranged? Create your own Help Menu, or Options, or whatever, to do as you suggest? I believe Blue Lacuna did it that way.
Ok, I was being lazy. Now I have implemented KEYWORDS ON and KEYWORDS OFF commands which enable or disable the use of Keyword highlighting. The command KEYWORDS lets you cycle through different fonts/colors as appropriate for a given interpreter.
–Zack
All the talk of bolds and highlights reminds me of some of the graphics/text hybrid adventures such as Eric the Unready. There, the objects of each room (or at least the more important ones) were conducted into a list, and there was a column of screen space devoted to printing that out. You also had an adjacent column devoted to the many verbs. I’m sure this was done primarily to make the games mouse-accessible, but lists can be very enticing in much the same way as emphasized words. To those without as much patience, they can be an excuse not to read the room description so thoroughly, if at all.
I think it comes down to this: the more visual aides you’re going to have, the more important the regular text has to be to balance things out. Like others have said, good writing can encourage the player to keep reading beyond the emphasized bits. Making the plain portions of a description just as crucial to the player’s goals can also help.
As for the topic of how room descriptions and objects ought to be handled, I have no strong opinion one way or another. Acceptable practices vary greatly based on a lot of factors. Yet as a player, I do prefer that room descriptions be on the smaller side and give more of a general impression. Descriptive hints about the areas of interest in the location then give me starting points to explore at my own pace. It requires more effort for everyone involved, though.
I’m not a big fan of the whole “object revealed by object revealed by object” thing, myself. I tend to get frustrated if it starts getting more than a few levels deep, unless it’s done in way that is fun and/or engaging.
Going off-topic, and just so I can say something in this thread without sounding like a lecture, all this talk reminds me of a French game called simply “Escape”. It was all about examining parts of an item - a photograph. That would trigger “memories”, and the entire game revolves in remembering things from your memories, and examining every detail of the photograph.
That’s a very specific example, of course. Only goes to show that, again, however you do it, if it’s awesome, it’s awesome.
I care a lot about accessibility, and so, though I’ve never done much with text highlighting, this is particularly interesting to me. Are there any other conventions that we could adopt to make IF more screen-reader friendly?
Hi,
Another accessibility issue for screen reader users may be the use of multiple windows. I think I can access them with my screen reader (JAWS), but some users may not know how, or they may have a different reader.
The only other issue that I can think of is more of a hassle than impediment. Screen reader users need key-presses to “see” the status bar. It can be annoying to have to key up to the bar, then key down again if you want to read the main window text. This is obviously more of an issue if the bar contains innfo that is important and continually updating, and there is no indication in the text that it has changed. And it is possible that some screen readers won’t even read the status bar.
The only solution I have come up with is to include status info as part of the room header. This may clutter the screen, but I don’t think that will matter to most screen reader users.
Neil
Inform’s normal menus are bad for screen readers because they say everything several times. Wades new Menus extension should help in that regard.
Dude, you’re already using JAWS, you can make your computer say bad words in a robot voice anytime you want, I don’t think you have a right to ask for anything more. (Working here under the assumption that robo-swears are as hilarious now as they were when I was twelve…)
Swear words in a Robo voice? Try a dirty-talking female Robo voice.
Another screen-reader-friendly nicety that authors could include for games with cover art is an option to read a description of the art. I, at least, would appreciate that.
Neil
Some of the “One Uber Puzzle” games have very sparse description, but the interaction is focused on the puzzle. The one that jumps to mind is 65,001 Keys (or however many were in that game) where all you’re doing is figuring out which of a ridiculous number of keys opens a lock.
Another thing to think about: Good IF authors will lean on evocative brevity. There is such a thing as overdescribing a room. You want to draw the reader to the important things they can interact with. You want to avoid telling them how the PC feels. Ideally, you want to inspire the player to feel as the PC does with your prose. If you have a lot of detail in mind, why not write the description shorter, and then include that detail only if the player starts examining the scenery carefully as a reward? That also gives the advantage that the next time the player enters the room, they don’t get the James Michener-esque wall of mood text, but they can expand it to read more if they so desire.
The thing you want to absolutely avoid is writing an evocative paragraph about the amber waving sheafs of wheat and have the player type >X SHEAFS only to have the game respond “You can’t see that here.”
I think you’ve nailed it here. What’s important is not that you’d need to describe every item in every room description twice just to prove to some hypothetical picky reviewers that you’re not lazy – it’s that you need to avoid giving an inappropriate response like “You can’t see that here.” when the player tries to interact with something that you’ve just told them they can see here. That’s just jarring and breaks immersion.
The proper fix is not to describe all those objects, although of course you’re free to do that if you want to. Rather, you just need to provide a more appropriate error message, like, say, Peter Pears’ “That’s not something you need to concern yourself with.”
Actually, that would even be really easy to do e.g. in Inform 7, where you could write something like:
A thing can be boring or interesting. A thing is usually interesting.
Instead of doing something with a boring thing: say "That's not something you need to concern yourself with."
Does the player mean doing something with a boring thing: it is very unlikely.and then just say:
The junction, the countryside, the dusty path, the old king's main road, the fields of brown stubble, the piles of golden hay, the sunlight, the air, the fragrance, the flat land, the slope, the trees, the barely visible gleam of a lake, the green hills, the distant Greyholm Mountains, the smoky haze, the vivid blue of the sky and the bright cloudless day are boring scenery in the Crossroads.Of course, in practice you’d make some of those things backdrops so that you can, say, place the sky in all outdoor locations. But even then, you don’t need to describe them as long as you just mark them as boring.
Well, of course, it all depends. I remember a comp game a year or two ago which had a location called “Bramble patch”, where the location description said that the path was “choked by brambles” or some such comment, but the brambles were … not visible. That is really sloppy. But basically I agree. It’s a question, in my mind, of letting the player down gently – giving a warning as s/he approaches the boundary of the implemented world.
This was actually an area where Inform6 makes life rather easy, because you can attach names to rooms (in which case the parser would always respond that this was “something you do not need to refer to in this game”) or include an extension which would enable “lightweight” objects with similar effect to be created, except that they could have a description. That’s quite nice, because it means you can have something that the player can look at but otherwise won’t be able to interact with, and all at fairly minimal cost of time to the writer. (It also saved space, because what really happened was that a monstrous super-object roamed around dispensing appropriate responses. But let’s assume we’re not really worried about space, what with glulx and all …)
Now Inform7 is rather more prolix when it comes to dealing with this sort of thing, but with a bit of work one can end up with something almost as economical, and rather more flexible. It would be even shorter if I hadn’t hijacked the initial appearance in order to save myself from having repeatedly to type “The description is …” (which is IMO a flaw in the design of Inform, since descriptions are far more common than initial appearances, but there we are.)
"Test bench" by Paul S
A flimsy is a kind of thing. A flimsy has some text called the action-refusal. The action-refusal of a flimsy is usually "". A flimsy is usually fixed in place, undescribed.
To say brush-off of (n - a thing):
Say "You don't need to worry about [if n is plural-named]those[else]that[end if]."
Rule for writing a paragraph about a flimsy (called x):
now x is mentioned.
Instead of examining a flimsy:
if the initial appearance of the noun is "", say "[brush-off of noun]";
otherwise say "[initial appearance of the noun][paragraph break]"
Instead of doing anything to a flimsy:
if the action-refusal of the noun is "", say "[brush-off of noun]";
otherwise say "[action-refusal of the noun][paragraph break]".
Cornfield is a room. "You stand in a vast cornfield. The crop has been harvested and amber sheaves of corn are stacked as far as the eye can see."
Sheaves are a plural-named flimsy in cornfield. "The sheaves of wheat are piled every few yards."
Sheaf is a flimsy in cornfield. "A tall sheaf of wheat, bound with a bundle of straw." The action-refusal is "Better leave the grain for the farmer." Understand "wheat/straw" as the sheaf.
Test me with "x sheaf / x wheat / x sheaves / take wheat / take sheaves"You seem to have conflated wheat and corn.
More relevant, you can define new verbs for shorthand ways to refer to properties:
[code]The verb to be seen implies the description property.
There is room.
A banana is here, seen “A beautiful ripe banana.”
Test me with “x”.[/code]
Not in English English, in which a wheatfield is a cornfield (the corn laws were not about maize!).
That’s an interesting suggestion!
Do you have an idea how to implement this?
Could the description of the cover art be added to the game description in the iFiction file?
Or ingame in an about text?
The above description would cause me to consider ragequitting the game.
Let’s see if I can transform this to a better description:
Yes, this is more like something a ten year old would write, but you’re still there, aren’t you? You can still picture the same scenario, if not even more vividly, thanks to the power of imagination. You can also spot something odd: Why is the main road going from the mountains to the lake? There is obviously a city of mountain dwelling people in those mountains, who come down to the lake every mourning to get their water. See how less is actually more? The more you describe the types of boring freaking trees there are, the more the player also feels obliged to try to chop them down or climb them, because they follow the novella rule that if it’s mentioned, it’s important to the story. …so just don’t describe anything more than
Now you only need to handle the keys and the (scenery supporter) table.
Maybe every game should come with a tl;dr option. So instead of a wonderfully long and evocative description of everything the player can see, you could have:
Yes, much better.
What I’m trying to say, is that there are no “evocative descriptions”. Descriptions only serve to lock the imagination in place. Yes, your no doubt sarcastic example would be much better. See, It’s not the lack of descriptions that’s the problem in your game example. It’s the emptiness of the world. You could describe granite rocks and dense spruces and chirping birds, but those descriptions are just going to be padding to fill out an eventless journey. Why not remove the “outside a cave” location completely, for instance? Caves are interesting, and rivers are interesting, but being outside a cave isn’t.
For example, here’s an example to explain my point:
You’re currently high on LSD. That’s how a kitchen looks to someone high on LSD.
Actually, I agree with Andreas here, and I think I said so earlier in this thread - the original description seems, to me, to be a bit much, and given that the poster was asking “Is it really necessary to implement all these nouns?”, then that description is asking for trouble.
I don’t think, though, that we should lose that original description entirely. Personally, I would show it differently after the first time. Hmm, something like:
Or, an alternative: Pick up everything I deleted from my edit and do this: