This is kind of similar to the IFComp tips, except it’s more particular to game development. I just wanted to throw out a couple things here, and see how well others may agree or disagree.
You have to be really careful with what you say to players, during the course of the game. It’s really easy to send them down the wrong path, without even realizing it’s possible. Part of this is in really thinking about how players might interpret what you’ve said. For example, if you have a table, and you describe it has having “four legs – the cheap kind that screw on and off”, then some players are going to try interacting with the legs – either by merely looking at them, or by trying to “remove” or “unscrew” them. If your intent was just to give a good description of the table, then you may be misleading players.
The rule of thumb I’ve started following (or, at least trying to follow) is to either (a) not mention the individual pieces of an object at all, and don’t phrase things in a way that implies an action, or (b) mention the pieces but also implement them, including whatever action I might have implied in the text. It may be something as simple as:
“You twist and turn one leg, then another, only to discover that that they’re too tightly attached.”
The trap here is that this may just firm up the player’s resolve to find a way to remove those darned legs. You could follow up with something like “Oh well. It wasn’t important anyway” or “Oh well. You don’t need to mess with the table, anyway.”
And that brings up another point. Be careful when saying “it’s not important.” I think it’s fine to say that sometimes, but some players are going to get frustrated if nothing in your game is important, or if they’ve made up their mind that a thing is somehow important and you tell them it’s not. It’s even worse if you say “that’s not important” in response to a particular action, when there actually is something important about it (maybe a different action).
And, be careful telling players “that’s not here” or “you don’t see that.” Usually, that’ll happen for nouns that just aren’t implemented as objects (or “extra_scenery”, as is the case in Hugo). For simplicity, say “you don’t need to refer to that” (or something) instead. Ideally, they player will be able to refer to it, but if not, at least don’t tell them it’s not here.
Also, be careful telling players “you can’t do that.” Players want to know why, because it might be something they could do, in that situation. As an example, if the default response for “hit” is “you can’t do that”, then they’re going to be told “you can’t do that” when trying to hit anything you haven’t trapped. This may be (like the “you don’t see that here” messages), a throw-back to the earlier days. What’s more likely – and probably more acceptible to players, it something like “venting your frustrations on that won’t help anything.” It’s the same result (nothing happens, nothing is done), but at the very least, it doesn’t tell the player that they “can’t” do something that they can. The “you can’t do that” is probably fine for totally impossible things – hitting the sky, eating a car, etc. Even there, you’d be better of coming up with a custom message, if you can.
If your IF language supports grammar extensions, pay close attention to them. Setting up the right grammar can be the difference between a robust, playable game, and one that’s a nightmare of guess-the-command. In the example about unscrewing the table legs – assuming perhaps that your game needs the player to do this, you might expect players to do it in a number of ways:
remove legs
remove legs from table
take off legs
take legs off
take legs off table
unscrew legs
twist legs
twist legs off
twist legs off table
twist off legs
twist off legs from table
pull legs off table
… and it just goes on and on.
You shouldn’t have to catch every single possibility, if you’ve grouped synonymous verbs together, and if your grammar definitions are correct for each one. It might seem like overkill, but it can make the difference between good game flow, and bogging the player down (even if for a little while) trying to figure out how to do an action. For simple things, it’s less important. Still important, yeah, but less important. But, when you’re requiring more complicated and non-traditional actions, you need more complicated handling.
Anyway, just some random thoughts. When (and if, at this rate), I finish my next game, it’ll probably be full of things that completely contradict my advice. It’s really hard to guess how everything you tell a player might be interpreted. I guess that’s where beta testing – and lots of it – can be really helpful!