Most parser games are alt-games designed by a single person over the course of weeks. I don’t think it’s fair to demand total newbie-friendliness out of all of them; not everyone is necessarily playing to a broad audience.
1 Like
I think that the answer is “yes and no.” That is, the parser does not have as much potential for a broad audience as choice does. (For one thing, ‘the choice-based audience’ is not a unified bloc, but a number of somewhat-discrete audiences with specific tastes. If the average Twine enthusiast is not particularly interested in Choice of Games’ output, and the average SilkWords reader doesn’t think of what they’re doing as a computer game, we can’t really expect that anything would make parser appealing to all of them.) But this does not mean that parser doesn’t have potential for a considerably broader player base than it presently enjoys.
(There are other considerations to bear in mind. I’m interested not just in the audience size, but in the conversion rate - the proportion of players who go on to become proficient authors.)
1 Like
I think of the original Monkey Island as pretty accessible. You had the actions listed on the screen, and you also knew exactly which objects you could use those actions on–if I remember correctly, pointing to an interactive object would make its name appear.
It seems to me you could go quite far in this direction, without a lot of extra work from a game author, if you allow an optional mode that would (1) list actions on the screen that are useful in your game, and (2) automatically list the visible non-scenery things in the location. (Highlighting the nouns would look nicer, but I’m guessing would require more effort on the part of the author.)
1 Like
I would like to stick to the question of making better tutorials for parser IF as we have it, rather than designing a new game interface (and thus a new kind of game). I strongly believe that these are different questions and lead to very different places.
1 Like
Yes. And I’m not sold on colored words in the text. How would that work for blind people?
1 Like
Aaron Reed’s Keyword Interface has an option that lists the items nearby for cases where highlighting won’t work for a player.
Yeah, my problem with that is that it coddles the player too much. Sure, it’s fine for a beginner-friendly IF like Blue Lacuna. But as a standard practice, it would coddle the players and make them not use any intuition or guess work besides to lawn-mower nouns on a list.
I don’t see how highlighting the nouns would be coddling the player. By modern parser IF standards, every noun in a room description should be implemented, and therefore experienced parser players are lawnmowering the existing nouns anyway.
1 Like
I hear you, but I still feel it would because if a person is reading a paragraph about a kitchen and the only highlighted word is “toaster”, what need is the player going to feel about looking out that window, or opening the stove? None whatsoever.
1 Like
But if the window and stove aren’t implemented, attempting to interact with them will likely just frustrate them anyway. Especially if the game says something like “you can’t see any such thing”.
1 Like
No, silly, I’m not saying not to implement them. Everything (ideally) should be implemented but not everything is important to the story. Part of the fun of IF is being in a story and being allowed to explore as you will and stop and examine something you see as interesting even if it’s not a propellant to the story. Again, in my kitchen example, everything can be implemented, but TOASTER in color automatically tells the player that that’s the important noun in the kitchen. Screw the window and stove. Idk. I still liken IF to literature and the books I read don’t have colorful words in them (anymore). Allow the player to be in the story without hunting for colored words to get thru the story faster. I’m not trying to be a jerk, I’m just trying to give my point of view on that aspect.
1 Like
In that case, if you’ve implemented the window and the stove, why not highlight them as well? I think we’re disagreeing about the use of “important”–by “important words” I mean ones which can lead to interactions. If the player can examine the window, then the word “window” in the room description is (in my opinion) important, even if it doesn’t actually matter to the puzzles or the plot.
1 Like
I hear ya. But wouldn’t that lead to every noun being colored until the paragraph looks like a circus exploded? 
1 Like
I tend to agree with Marshall–if everything is highlighted it feels like I’m being led by the nose. (I played Enigma with the highlights off.) There’s also a question about whether players are getting the intended experience if they’re lawnmowering highlighted words–I’d like it if people were typing “fill kettle from sink” rather than seeing that “kettle” was highlighted, typing “kettle,” and getting a prompt saying “one thing you can do is fill it,” and then typing “fill.”
(I also think that it’s not automatic that a player who sees a paragraph with a bunch of words highlighted is going to know that the thing they’re supposed to do is type one of those words at the prompt.)
Also part of the question for me is whether there’s anything distinctive to be gained from the parser, or is it just something I’m using because implementing hyperlinks in Inform is annoying and doing anything else i want in Twine is annoying. The keyword-highlighting model seems as though it’s basically hyperlink-through-the-keyboard; which is fine in some ways, it’s more natural for me to use keyboard shortcuts than mouse interface for everything, but I think it’s worth at least trying to come up with tutorials that don’t rely on keywords only.
A lot of the platformy games I like have visual directions of some sort–in the background or somewhere they’ll have an arrow when you need to walk, an up arrow or space the first time you get to somewhere you need to jump, and an “S” when you need to use “S.” I wonder if there’s a way to achieve a similar effect. One problem is that text games don’t have a background in the same way.
1 Like
Even without using an interface that lists or highlights the nouns, mentioning some of them specifically could be incorporated into error messages in a tutorial mode. E.g. instead of saying “You can’t see any such thing,” saying, “That’s not something that’s described. Try interacting with things mentioned in the story, for instance, X, Y, and Z.” In general it might be helpful to steer “You can’t do that” messages in the direction of “but you can do this.”
Actually I think that’s what some of Aaron Reed’s extensions try to do–steer the player toward syntax that works.
1 Like
I’m not sure there is a big problem with the quality of parser tutorials. I think within-game guidance is a good idea, with links to other resources. I think that if someone wants to learn, that person will learn. The best way to learn is to play. People learned to play Zork 35 years ago. Surely the learning curve is much easier now? We have more resources and friendlier games. But there needs to be a desire to take the time to learn, too, and I’m not sure how to create that.
I think we have to be careful about removing what makes parser games attractive to a lot of us in the first place. Colored text, a list of on-screen commands … these seem to detract from what the experience of a parser game is meant to be.
Neil
1 Like
Is “highlighted nouns” on topic, in your opinion?
How about making it so verbless “noun only” commands would do a default action, ideally “examine”?
How about suggesting verbs when you examine an object?
I demand nothing, but my point stands that there’s no way to “solve” this problem except to do something to the platform to make all games more usable.
The conclusion I draw is that the problem therefore won’t be solved. Nobody much wants to solve it, especially not by changing the platform.
Yes, just because mimesis is no longer really discussed in the community, it doesn’t mean it’s not there. Also the aim to give an off-the-rails feeling to the work should remain.
Dan, I find this a little passive-aggressive seeing as how you described as “the sad thing”:
That sounds as though you’re accusing any author of a game that lacks newbie documentation of not caring about newbie friendly. But just because someone hasn’t included an attempt at a solution to a problem doesn’t mean they don’t care about it. It may be that they’ve concluded that a good solution would take more effort than they can put in. (For instance: I often wish that disambiguation worked better in my games. But getting it to work the way I really liked would require an immense amount of I6 hacking, so I don’t do it.)
A lot of games used to include a menu about “How to Play IF,” which was from a standardized extension I think. I also think it’s fallen out of favor somewhat because it wasn’t effective (and also it put up another layer of menus before the hint menus). I would like it if there were an effective system of newbie help that I could implement in less time than it takes me to write the rest of the game. The fact that I haven’t found one for every game doesn’t mean I don’t care about it. Nor does the fact that I haven’t yet chosen to write a game in a particular style that doesn’t capture what I often like about parser games.