FWIW, I never had the conversation with Val in the car until you just now suggested that was possible and I went back to try it. The first several times I played, I looked at her and then waited, so I immediately arrived at the house. One way to address this would be to put the game into a conversation state with Val automatically, so the player receives the conversation prompts while they’re in the car. (I do this a bunch in Counterfeit Monkey.)
At this point I don’t remember why I didn’t talk to her in the car on playthrough 1. Maybe I was busy looking at her and didn’t try; maybe I tried the usual ASK/TELL options and found they didn’t work. If I try now, I get
ask val about val
I wasn’t talking to anyone right then.
– so for a player who hasn’t been taught the TALK TO CHARACTER syntax, this may be an issue. (The intention is that, if you ask someone about something when there’s no interlocutor, TC should automatically assign an interlocutor and then re-parse the command. But it’s possible that something is broken here or that you made your own hacks; I’m not really sure.)
Generally, it looks to me as though your game benefits if the player reads the HELP right away, rather than trying to stay away from it as a source of spoilery hints: doing so right at the start might have gotten me to use TALK TO and EXITS sooner, resulting in a better experience with those first scenes. A conventional way to handle this is to have a line right at the beginning recommending that first-time players read the HELP.
I agree with this in general. The biggest issue I had with this when testing (and I only did a partial transcript–sorry about that!) was the undescribed exits–I had to stumble around trying different directions to get into the house, and then to move around in the house, and then I think when I found the EXITS command I suddenly realized that there were a lot more rooms than I thought. This is a real problem for me in a way that unimplemented scenery isn’t; if the scenery is unimplemented then at least I know I don’t have to interact with it, but if I don’t know what the exits are then I just don’t know how to interact with the game. (Analogy: when I first tried Cave Story and I didn’t know that you had to hit Z to get off the start/quit screen.)
As for the thing you said about moving away from standards of total implementation–one thing that I thought actually worked in Terminator was that I decided to implement only a very restricted set of verbs, with a flat refusal if you tried anything else, but I started things out with a tutorial that made it pretty clear what those verbs were. I didn’t even implement “examine,” but I only got about one piece of feedback complaining that I hadn’t implemented stuff (well, and some people said “We want a ‘take off’ verb!” so I put that in). Now part of the reason this was possible was that Terminator is all the way game rather than story, and it’s also in a setting where it makes sense that there would be a training mission–it’d be hard to do this while building up a sense of mystery that starts in medias res. But it shows there’s a way to get parser IF players to not expect a full suite of implemented stuff.
(And I had violated everyone’s trust by having a persistent bug, too.)
Also: I really feel what you’re saying about game jams and competitions. I often feel like “Dang, the time frames for these things are set by people who do not have small children.” For me if I don’t get involved in them I’d never make anything–it’s not that I work better with a deadline, it’s that I don’t work without one–but it seems like you know the scale of the things you want to make, they’re big and complicated, and they need a lot of time working on them and also a lot of time to get feedback and incorporate it. So maybe the competitions aren’t for you. Like lots of other people, I’d really like to see you keep working on this!
So I went and played “9:05” (It’s great) and indeed it is a situation where the protagonist knows more than the player.
What keeps me from being able to directly apply it is that the conceit of “9:05” is dependent upon two playthroughs, one where (2) is true, and one where the player knows everything the protagonist does. However, in this first playthrough, the player is expected to reach a particular ending because of this lack of knowledge, which in turn has implications as to the reason for this “illogical” behavior on the part of the protagonist. I don’t think this would work in A Long Drink unless the player could outright fail to solve the mystery and then get information that would help the next time through. I opted not to do this to avoid frustrating game overs due to the player’s lack of knowledge. My attempted approach at dealing with this was to make the game relatively easy to clear, but more difficult to fully understand.
Hmm, interesting, I assumed that players would be curious or confused at this point in the story, so talking to Val would be their initial response. From a game design perspective, this was intended to be the introduction to the “You will need to talk to people during this game” moment, so that was my reasoning behind not starting the conversation automatically, but maybe that needs to change.
It’s a fair point that making help explicit helps the experience (maybe I was too stubborn to plaster that all over a cold open), but as you say, it’s also worth thinking about who uses “help” and why. A new player might use it right away, or not know to use it in the first place. A more experienced player might assume they don’t need it, or that it would contain spoilers, is that why you didn’t?
That ends up strongly implying that what “help” does is provide spoilery help with solving the game’s puzzles, whereas what it actually does is provide basic usability help. In fact, the game is all but unplayable without typing HELP; there are no exits listed anywhere in the game, and apparently the design expects players to rely constantly on EXITS, which is nonstandard - people are much more likely to think “oh, this is badly implemented, there are no exit listings” than to assume that for some design reason (??) they’re supposed to type EXITS in every room.
I had that as the convention in Terminator Chaser at one point, but eventually just wrote exit listings into all room descriptions because from what I understand, putting crucial information only on the status bar is really inconvenient for users on screen readers.
I usually try HELP only if I am stuck, unless the author has put in advice saying I should read it when I start the game. Sequitur is exactly right: your phrasing made me think “okay, the help in this game is a hint menu. I don’t need a hint menu yet, so let’s see how this goes.”
But there are plenty of games that do have an explicit read-me-first portion, especially if the author is introducing some special verbs or restricting the verb set to a smaller number of options than the full default set; it’s also useful if the game is meant to be played in an unusual way (like Øyvind Thorsby’s play-it-only-once game) or if the author wants to warn players about content that might be inappropriate for some audiences.
One way to avoid having the help contaminate your cold open is to start with a title screen, where the player first gets a menu with something like “INTRO - READ FIRST” and then “START A NEW GAME” and “RESTORE A SAVED GAME”. I believe Jon Ingold wrote an extension to handle exactly this.
Another option is to skip the readme and lard the game itself with instructions when the player first gets into the relevant situations: for instance, “[TALK TO VAL if you’d like to start a conversation.]” when you first get into the car. As an author I sometimes resent the intrusion of such bits onto my nice prose, but sometimes it feels like the best solution anyway, especially if I’ve got enough to introduce that I don’t expect the player to be able to take it all in/remember it all from an up-front readme. I rarely mind such guidance as a player, unless there’s really a huge amount of it. Your mileage may vary.
In a case like that, I wouldn’t continue the game until the player has talked to Val and got that introduction. The drive would just keep on until they do. (Probably adding a subtle hint if they after a few turns still haven’t talked to her.) But I’m one of those players who usually don’t like time passing in the games I play. I want to be able to take the time I need and usually don’t enjoy timed sequences. I know others disagree and feel that the world is more alive if there are timers involved.
Yeah, I opted not to do that because it doesn’t read well from a usability perspective-- even aside from screen readers, there’s no reason a player should have to flick their eyes away from the game text to a different screen area. I also just wrote exit listings into room descriptions. I think I’ll also use a minimap and “Exits On” for automatic exit listing.
Funny you should mention-- I actually tried this and eventually gave up trying to get Title Screen working with whatever in the latest Inform7 build that had broken it.
I’d prefer having the EXITS listing be on by default with an option to turn it off to having the exits listed in the status line without any mention in the main text.
Man, really? Huh. I kinda love the >exits command. I tend to type >look over and over again when I am thinking about a game’s obstacle, and exits (when available) lets me do a similar thing.
I like having an EXITS command as well, but I don’t like being required to use it. I think that’s the main concern here. (That was an error I made in the IntroComp release of Scroll Thief: the minimap in the status bar was broken because of a glitch, so players needed to rely on EXITS in some cases to see where they could go.)
Okay. I have updated Title Screen for 6L02 and enhanced it slightly; the new version has been sent to Mark and should appear in the Public Library shortly-ish. (There are a few other things I might have done with it had I been writing it from scratch, but I wanted to get it working again in more or less its old form.)
Going back to unimplemented scenery for a second, is there a best practices for how to handle the fact that scenery is globally scoped? Windows, for instance, is something many of my rooms have, and while all the windows in the house could be the same backdrop, the windows in the car obviously can’t. I can’t call them “car windows” either and hope the parser sorts it out because “car” is already an object.
Is the solution simply that every object and piece of scenery should have an internal name in the code like “house_windows” and a list of “understand windows as house_windows” type synonyms? Or is there a more elegant way to do this?
Giving every object a unique internal name is a simple plan, yes.
For windows in a house, you might create a kind and then say “Understand ‘window’ as a window.” You’ll probably wind up writing some common rules that apply to all windows (touching, breaking) and then maybe some ones for individual windows (searching/looking through).