As a parser player, what's your preferred way to enter a password into a computer?

Not vorple. I like it a lot but I want the ‘base’ experience of this game to last as long as possible (and standard z-machine/glulx have seemed more resilient than cockroaches so far)




If anyone needs Inform code samples for this, Counterfeit Monkey understands an impressive amount of ways to enter a code into a locked barrier – in addition to opening the barrier automatically if the player tries to go through it after having seen the code:

Because the temporary barrier is the first real puzzle the player faces, it is especially important to handle all attempts at interaction as clearly as possible. In addition, the point of the puzzle is to figure out how to get the code, not to make the player do fiddly things – so anything that could reasonably be construed as an attempt to use the code once it’s been discovered should be redirected towards opening.

If that isn’t enough, there is a different kind of password puzzle later in the game:

One of the things I set out to do with the puzzle system in my previous game Savoir-Faire was to duplicate all the dull standard puzzles I was sick of seeing, but with some new twist on them that hadn’t been done before. The one that there was really no way to include, however, was the password puzzle: too many IF games use password puzzles as a form of riddle (where you have to guess on the basis of some hints) or a cheap search puzzle (where the answer is written down on a note near the computer). Never in IF does anyone follow good security protocols with strong passwords that aren’t written down.

So, I thought, what about a puzzle where people do use fairly unguessable passwords, but the whole concept of a ‘password’ is compromised by some other law of the universe?

EDIT: The second sample uses the Computers extension.


I think that the correcto way is to show “ENTER PASSWORD CODE:” and show a prompt.


I miiight suggest that PRESS A. PRESS C. (with single letters) could be omitted. There’s potential confusion between PRESS A, TYPE A, PRESS ACCARDI, TYPE ACCARDI and it might be better overall not to lead players down that path.


I just had a look at what I did when I made a password-protected computer. It looks like I went the route of having “type password on computer” as the main action, with synonyms covering everything I could think of, including a few weird ones. I know you were a tester, Mathbrush, so you might have suggested one or two of these synonyms in the first place!

Typing it on is an action applying to one topic and one touchable thing.

Understand "type [text] on [something]" and "type in [text] on [something]" and "guess [text] on [something]" and "try [text] on [something]" and "input [text] on [something]" and "enter [text] on [something]" and "password [text] on [something]" and "give [text] to [something]" as typing it on.

(now that I look at this again, it’s missing the reasonable synonym “type password INTO computer”. Oh well.)

Plus a couple of extra actions for less specific attempts: one for just “type password” which tries to redirect the input to the nearest computer-type object, and one for just “type” which asks the player to say what they want to type in an out-of-world message (which may not be what you want if you’re trying to avoid immersion-breaking messages to the player).

Singular-typing is an action applying to one topic.
Understand "type [text]" and "type in [text]" and "guess [text]" and "try [text]" and "input [text]" and "enter [text]" and "password [text]"  and "give [text]" as singular-typing.

Carry out singular-typing:
	if a computer (called the target) is touchable:
		say "(typing '[the topic understood]' on [the target])";
		try typing the topic understood on the target;
		say "You don't see anything to type that on."
Objectless-typing is an action applying to nothing.
Understand "type" as objectless-typing.

Check objectless-typing:
	say "[bypass every turn][italic type][bracket]Type what? You'll need something to type, and something to type on, e.g. TYPE TEXT ON COMPUTER, or just TYPE TEXT if you're near a computer.[close bracket][roman type][paragraph break]"

(That “bypass every turn” bit is borrowed from this climbingstars post.)

I think this scattergun approach worked in the end, but I’m not sure because I forgot to download the player transcripts while the game was in IFComp. I don’t remember the computers being a complaint though.


I’m inclined towards just password, because programmatically can follow Clarke’s 3rd principle and behave like the most-abused magic word, teleporting the player into the shell, implemented as a room where the only valid commands are the shell ones (this allow a nifty set of trickery, EXAMINE became MORE/TYPE/&c. LOOK became DIR/LS and so on, abusing doer/instead…)

Best regards from Italy,
dott. Piergiorgio.


This one gets my vote. I’ve used it myself and I’m sure I’ve played other games that have used it and it felt pretty intuitive. You could optionally provide for the indirect object (e.g. ON LAPTOP, ON COMPUTER, WITH KEYBOARD) and even allow for manual implicit actions. I tend to do that a lot nowadays.


Like others have said so far, as many as you can. Usually I’d do >TYPE [password] ON COMPUTER, though if the computer is important or complex or includes AI (basically more complex than a laptop), I might use the command version: >COMPUTER, THE PASSWORD IS [password]. That one would be very difficult, I can imagine.


If the computer is an AI (that is, analogous to an NPC), I might try TELL COMPUTER THE PASSWORD IS [password] or just TELL COMPUTER [password] if it has just asked for it.

That said, as an author, I would change the prompt to say I want the password, and hope the player realises that it is only the password to be typed!


I think this is probably ideal from a usability standpoint, and if you’re really worried about the fraction of players who will kvetch about immersion you could always make the bracketed tooltips an option you can disable.

I think from a general gamedev standpoint what you want to do is draw a circle around all the gameplay elements that are so common that anyone familiar with the gamplay genre will know them without having to have them explained. The instructions for using those go in the documentation (if you’re enough of a traditionalist to do documentation) or in an optional tutorial.

Then you identify the bits that aren’t part of the “default” gameplay mechanics. Some of those are going to be puzzles or something else the player is supposed to have to work out for themselves. Those get cued/hinted in the gameplay. The remaining bits…the things that aren’t part of the standard mechanics of the genre and aren’t intended to be puzzles…should probably get hinted/cued proximate to their first use. Depending on how confusing you expect the mechanic to be you can either cue once (display the suggested usage the first time the laptop is examined) or every time.

For the game I’m working on, which (intentionally) has a number of idiosyncratic gameplay conventions, I’m thowing a couple of general techniques at this sort of problem:

  • Displaying a tooltip (like what you’re talking about here) the first time a new mechanic is introduced
  • Implementing a >TOOLTIP verb that gives usage information (as opposed to hints) about the specified object/topic…so for example >TOOLTIP LAPTOP would display your bracketed usage message.
  • Having a system of in-game “reference materials” for nearby puzzles that includes meta-game-y hints and suggestions. So in this case the room with the laptop might have a bookshelf that has a copy of New Laptop User’s Guide or something that provides a pseudo-in-game, pseudo-meta-game tutorial on the various ways you can interact with the laptop.

Basically the “gimmick” is that when the player encounters a new widget they’re either going to already know how to interact with the widget or they’re going to have to learn a new gameplay rule about interacting with the widget…and (unless figuring out how to interact with the widget is a puzzle) you want to provide the player with a general scheme for figuring out how to interact with things. That is, you want to give then a rule for how to handle rule acquisition, rather than look at it as an isolated one-off about how to cue an individual puzzle.


I would dislike anything that made it effort to enter individual letters.

I think you should use the setup to enhance your story. Is the player hacking into an evil corporation? Have the prompt for password be impersonal and cold. Are they infiltrating a government agency? Have it be convoluted, outdated and buggy.

I would look at modern web design standards for password entry fields and then skew those concepts to reflect the narrative you want to convey.


My two cents:

I would expect this to work - or at least provide a helpful error message - and start looking for hints if it didn’t.

Ideally, this should also work unless it is important that there are several computers/keypads/whatever in the same room.

In a perfect world, this should also work.

This is totally fine with me since, as you say, there’s no real standard for entering passwords.


TYPE PASSWORD [ON COMPUTER] is the first thing I’d try. I would never come up with the phrase ATTEMPT PASSWORD. Whether to make the parser prompt become the computer’s prompt, that depends on what further interaction there might be.

If there’s a realistic command line (like Dunnet), maybe prefixing every command with TYPE is not great. But if the player will also CLICK OK or something like that, it’s more consistent not to take over the prompt. I like the idea of accepting just the password as a command, without the word TYPE, but more as an easter egg for adventurers. It’s not really intuitive.

If there’s no further interaction it matters less, but I’d think that taking over the prompt makes the computer system more real, but TYPE makes it more real as an object.


/old curmudgeon mode ON

I suspect that you’re young…

I don’t want to bash(1) you :wink: but computers and OS always have a thing called “command line interface/shell”, e.g. here:

in particular, this passage ought to be read by everyone implementing computers in an parser IF:

The commands given to a CLI shell are often in one of the following forms:

  • doSomething how toFiles
  • doSomething how sourceFile destinationFile
  • doSomething how < inputFile > outputFile
  • doSomething how | doSomething how | doSomething how > outputFile

where doSomething is, in effect, a verb, how an adverb (for example, should the command be executed “verbosely” or “quietly”) and toFiles an object or objects (typically one or more files) on which the command should act.

Best regards from Italy,
dott. Piergiorgio.


What I mean is that if the prompt becomes the computer’s prompt, the player character and their environment temporarily vanish, and it becomes just the player at a realistic terminal.

If computer operations are accomplished through commands to the player character, they remain more present, as well as the rest of the room and the computer as a physical object.


partly concur with paul above:

You take a good gulp of your favorite coffeine-based drink.

With your brain’s gears well lubricated from coffeine, you manage to implement 27 rooms, 19 objects and 8 puzzles into a working testing IF.

More a testing & messing arena than a release-grade IF; one object you have still unimplement is a computer.

It’s still incomplete; you haven’t figured the best implementation for the concluision of your epic password-gathering puzzle. But the disambiguation between the computers was a major challenge… perhaps browsing the intfiction community can help ?

In the forum you found what you really needed ! actually more than you really needed: in a long 28-posts forum you get at least three different ways to implement a password-entering mechanism !
[your score goes up 25 points !]

(I 'fess up: I actually drinked hack fluid prior of replying, generating the rather elaborate example script above…)

Best regards from Italy,
dott. Piergiorgio


Infocom’s game, The Lurking Horror, managed this by implementing two special commands, “LOGIN” and “PASSWORD.”


Login 872325412

…gets you into the terminal at the start of the game.

(Post Scriptum: It says something about me, that I entered both the login number and the passwoed itself, from memory.)

(Post Post Scriptum: This implementation always irked – and still irks – me, because the game has already prompted, “Login Please:” and “Password:”. What is the point, when the computer has already explicitly asked for a password, of forcing the player to preface his entry with “Password”? When the computer prompts “Login:” or “Password:”, that should be precisely all that the player should need to enter! And that would be my advice to YOU, too.)


Hahahahaha :rofl:

Agreed. This is why in a puzzle I’m working on (which uses interactive computers), all computer commands are prefaced with TYPE as in >TYPE CD ~/DESKTOP and >TYPE LS.

It was more important to me to have the player participating in the room, and be able to smoothly access inventory and examine stuff, as opposed to needing to start and stop a computer session, so that the input prompt is piped correctly. I suppose a workaround for this is to treat computer contents as true world objects, but you would need to figure out how to safely handle commands specifically for these. You wouldn’t want a weird response for >EAT TEXT FILE, for example.

But again, that’s why I made my own parser for handling computer commands, and simulated files and folders as actual data, instead of world objects in the room.


Okay… And how do we handle a Windows PC or Mac? Should I look to implement: