I offered one of my usual hacks today, to a poster who was asking how to gain access to a room by entering a specific command.

As always, I knew in the back of my mind that I wasn't doing it the 'correct' way, and that my solution didn't cover all possibilities.

This was my method:

msg ("There is a guard here. He asks you for the password. The locked door is north. East is an unguarded exit.")
get input {
  if (result="e") {
    MoveObject (player, room 3)
  }
  else if (result="1234") {
    UnlockExit (locked)
    msg ("The guard steps aside to allow you access.")
  }
  else {
    msg ("\"Wrong password.\"")
    ShowRoomDescription
  }

Which works, but only to a certain extent.

The problem with this is that the player really only has the option to enter the password, and any other command will return "Wrong password." which is why I added the extra if for the unlocked exit to the east.

So, out of interest, and just because it will be a handy script to store, how would this be done correctly?

Ideally, the player would have the freedom to enter any other command (and receive either a positive response or an unresolved one as with any other room), but how would this be achieved?

You can mostly get away with it like this:

	msg ("There is a guard here. He asks you for the password. The locked door is north. East is an unguarded exit.")
	get input {
	  if (result="1234") {
	    UnlockExit (locked)
	    msg ("The guard steps aside to allow you access.")
	  }
	  else {
	  	if (not result = "l" and not result = "look") { 
	    	HandleCommand(result, null)
	    }
	    ShowRoomDescription()
	  }
	}

However, if this is the room description (which I assume it is, since you show it repeatedly), then it still refers to the looked door and password even once you've unlocked it. That would probably need to change. The special case for "l/look" is to prevent a double room description being dumped out if they type those commands, plus a double entry into "get input" which is a no no.

Ahem... I would force the player to interact with the guard and then run the get input script. That way, all other input would work until you typed 'talk to guard' at which point you would print a message like "The guard grunts at you, points his club at your skull and says, 'Password please.'" What will you say? Then, I would use the get input script.

In some parts of my games, I might even include a closing line like "If you don't want to offer this kind guard a password, you might want to retreat to the east." Then in the get input you can use an if/else to accommodate for an exit from the conversation.

I might even include a command for the room something like - tell guard 1234; say 1234 to guard; tell guard 1234; say 1234; etc... with an appropriate response for a correct and incorrect password. That way the player can address the guard voluntarily or be questioned for the password by talking to him.

Anyway, that is my butchered approach! There's more than one wrong way to skin a cat!

XanMag wrote:
I might even include a command for the room something like - tell guard 1234; say 1234 to guard; tell guard 1234; say 1234; etc... with an appropriate response for a correct and incorrect password. That way the player can address the guard voluntarily or be questioned for the password by talking to him.

Anyway, that is my butchered approach! There's more than one wrong way to skin a cat!

No, I like this.

Jay, what does the (result, null) do? I mean what doe the game throw out, just a blank non-response?

HandleCommand(result, null) will process the text in "result" as if the user had typed it in at the command prompt. It's the basic command handling entry point for the Quest parser. So, in a sense, you're taking the input you got and handing it off just as it normally would be if you weren't handling the input yourself. It will process any command just as usual, including movement commands, examining things, "help", etc.

Ah, I see. Useful. Thanks.