I’d like to get people’s reactions to an approach I’m thinking of using:
I’m writing a game which will include a “manual.” The player will be told that the manual contains “everything you need to know.” This is, of course, an exaggeration, but the book will contain a lot of background information on various topics which are useful (and, in some cases, essential) to playing the game.
Among other things, the book would contain entries for most of the objects that the player will encounter in the game, which entries will, among other things, tell the player how to use them. The format of this information will clarify the proper command syntax for any actions which are specific to the object.
My thinking is that if I do this, I don’t really need to go overboard in including “understand” statements to cover every possible other way a player might try to phrase a command. I would pick up the obvious ones, but that’s about it. My thinking is that the player can always avoid a “guess the verb” situation by looking at what has been described to him as the repository of all knowledge in the game, and that fairness therefore does not require that I also deal with every possible command syntax.
Am I just taking the lazy way out, or does this sound reasonable? (By the way, the manual is not included just for this purpose; it makes sense that the character (a spy) would have an agency-issued manual, and the book performs important functions in the game whether or not I use it as an excuse(?) to skimp on the synonyms).
Hm. While I personally would appreciate a book object to look up stuff, I could imagine it could ruin the atmosphere you want to create if that book takes refernce to game mechanics by displaying syntaxes. In my personal opinion the description of syntaxes is something for tutorial-like introductions, but shouldn’t come up later in the game. Feels a little like “my parser is limited, so I’m revealing you the syntax”. Just my 2ct.
How about a manual feelie? If there’s a lot of look ups, it might be more practical, and you could make it look nice. (Otherwise it might feel like a less convenient version of “examine.”)
The feelie idea might work if the book were not otherwise an important part of the game, but it doesn’t work in light of some of other functions that the manual will have in the game. Basically, the player will have to solve a major multi-part puzzle before he can get the book open – which is important, because a certain necessary object will only appear once the player reads a hint about its location in the book. Also, certain codes, which will change randomly from game to game, will only be found in the book. Making it a feelie would make it too easy to get this information, and eliminate the whole puzzle on how to get it open.
It looks like the consensus is to deal with the synonyms the hard way. I’ll probably also try to use the book to give hints on how to use the objects (while keeping it “in character”) but I won’t rely on it as a substitute for “understand” statements.
Maybe I’m misunderstanding the inquiry and the dissent. I don’t think a manual is unreasonable or would break the atmosphere of the game, provided it was addressed properly. For example, you wouldn’t want the response to be:
“This is the XL-3000 laser. To use it, .”
Not to say that Grueslayer was insinuating anything this direct. You could, however, say something along the lines of:
“The XL-3000 is the ‘cutting edge’ of innovative covert entry technology, quietly and quickly slicing through even the thickest glass obstacles. Its highly focused rotating beam array requires only that it be adhered to a surface and activated.”
While an in - game manual for supplementary hints would be fine with me, if I were playing a game (particularly as a comp judge) which substituted “look up the verb” for “guess the verb,” it would go like this:
If you’re worried about missing some synonyms, don’t be – you will – but that’s precisely the sort of thing that having plenty of beta testers is designed to mitigate.
To clarify, my intention was never to use the book as a “how to play the game” manual (which would indeed confuse the Player Character’s “in-game” world with the player’s out-of-the-game world). Rather it was to make the manual very much a part of the game world itself (which the Player Character would need to consult from time to time as a normal part of his job in the game world), but also to work into it some clues which an even moderately experienced player would recognize as suggesting commands – along the lines of what I4L has suggested.
Nonetheless, I’m getting a clear sense that most players would be pretty pissed off if I relied on that as a substitute for fully developed parser instructions, so I will write the game with that in mind.
I would be fine with saying “To use it, point it at something” or even (and maybe preferably" “To use it, POINT it AT something.” It doesn’t break my immersion too much if some command syntax is highlighted in one of these things – certainly it doesn’t break it nearly as much as being unable to guess the syntax later.
Similarly, I don’t much like the latter example. What is it I’m supposed to be doing? ADHERE XL-3000 TO DOOR followed by ACTIVATE XL-3000? I suppose it’s more likely to be PUT XL-3000 ON DOOR and SWITCH ON XL-3000, maybe with a puzzle about how I can get it to stick, but the description shouldn’t make it harder to guess the syntax.
Anyway, I agree with the general consensus that you need to implement the synonyms anyway.
Well, to be fair, my point was in regards to breaking game immersion by blatantly quoting the necessary syntax to make the item function. I wouldn’t want to check the manual to be given a list of commands that I was supposed to type in order to use a particular item.
I also wasn’t expecting people to read too deeply into my hastily cobbled together example checking for whether it gave convoluted or multi-part instructions.
Oh, no offense intended – just trying to make the point that it’s nicer if the command is fairly clear from the text you’re given. Not just in manuals; if you climb up on something and the next command is “Throw rope at stalactite,” it’s better if your text reads “You could probably throw the rope at the stalactite from here” than “You could probably reach the stalactite with the rope from here”; that kind of thing.
Your betatesters will let you know about any commands they would want to have understood. Including “just the obvious ones” is wat everyone does anyway, because players have been trained to go for the obvious commands. The only problem is when the author’s idea of what is obvious and the player’s idea of what is obvious are different – but that is what testers are for.
I try to follow Postel’s Law: Be conservative in what you send, and liberal in what you accept. In other words, I’d include all the synonyms you can think of that won’t make anything else more confusing. Of course WHEN you add them can make a big difference in your workload. If they’re distracting you from developing something important that you don’t want to lose track of, save them for later. They’re not like description text that would be odious and difficult to come back to.
Eventually, after you’ve added all the synonyms you’ve thought of, you’ll need to add all the ones your testers thought of. As most everyone else has mentioned, I think playtesting is the key.
By the way, I’ve been reading “Twisty Little Passages,” and the introductory transcript is from “For a Change.” I’ve never played it, but it has a guidebook that sounds a little like the manual you’re describing. It’s accessible right away, though.
