I pronounce it parallel with “loch”, the scottish lake, (so “plooch” would be closest, I guess) since I interpreted “hollow voice” to mean that the environment spoke the word by means of shifting air currents/a breeze or something, so the ending would naturally be aspirated.
I tend to overthink things sometimes. 
One seemingly obvious one that a lot of authors forget about: EXAMINE ME.
Even if the description of the player isn’t important, changing it from the default response gives an insight how thorough the author is.
One thing I like to try is EMPTY. I’ll do it to drinks, wheelbarrows, bags, or any container. In my own WIP, empty breaks my bag right now. I’ve seen REMOVE take things when I didn’t want them to be taken. Like on a pedestal. REMOVE might have been changed in the verbs, so it works now, but I still see EMPTY messing with authors.
The Infocom games had a lot of bugs with EMPTY. When you implement a new useful action, it’s important to think through the implications.
The game I’m playing now reminded me of a frequent irritation I have in adventures:
If you try to KISS someone in an appropriate narrative situation (attraction, farewell, consolement), you’re often told to “Keep your mind on the game!” or accused of perverse behavior outright. (HUG gets this too sometimes)
Indeed one of the very first things I implement is the player char’s description…
Best regards from Italy,
dott. Piergiorgio.
I’ve spent many years designing chatbots, and I can assure you that every last one of them will get users who will “swear” or “curse” at the chatbot and say all kinds of other things.
It became so ubiquitous that I created a list of “mandatory responses” to off-piste things users will say, including:
I’ve yet to see a log file that didn’t have people asking and saying most/all of these things.
Not sure how relevant it is to the parser-playing crowd, though.
My girlfriend has played one or two of my games, and has a “berserker” approach (her word) to solving puzzles. Usually this means resorting to violence (eg. trying to throw Hubert Booby out of the balloon) and trying them repeatedly. In my current WIP I’ve anticipated this by adding different responses for commands (especially violent ones) that are tried over and over again!
Would it be useful to produce a starter / template I7 file with overrides for the common responses already set up? (Or has this been done?) Stuff like:
Instead of examining the player:
say "TODO."
Might make it easier for an author to remember to customize these cases that might not be top of mind for everyone, but add to the overall polish.
When play begins (this is the run property checks at the start of play rule):
repeat with item running through things:
if description of the item is "":
say "[item] has no description."
I use the above at the start of my games to show me what I have missed. I think I harvested it from someone’s post. It certainly helps my forgetfullness.
That’s a great idea. One other trick if you’re using Inform 7 is you can put that rule under it’s own header with the “Not For Release” label and it won’t show those messages in a full release, but you can leave it in your original source for post-release updates.
For example, at the end of the source:
Volume - Debug - Not for release
When play begins (this is the run property checks at the start of play rule):
repeat with item running through things:
if description of the item is "":
say "[item] has no description."
This is good if you have testing skips or other debug commands. They will be available in a test compile for your testers, but won’t show up in an official version produced by the “Publish” button.
Maybe you got it from Emily Short’s Property Checking?
To expound on @Hanon’s good suggestions, I’d like to share something I never really organized into a formal testing module. It’s helped me a ton.
One finesse I have for items that are meant to have no description is to have a “useless” variable. For instance, in Shuffling Around, I had some items that weren’t supposed to be seen.
I also designate certain rooms as “abstract.” These include ones that temporarily hold items that need to go off-stage and ones that permanently hold them.
The code below is heavily based on Emily Short’s Property Checking, so give that a look. It just filled in some special gaps.
volume properties
section definitions
[must be included for release if we want to say "X is a useless thing" in the main file.
We could include test properties in another module later, but that gets sticky.]
a room can be abstract. a room is usually not abstract.
a thing can be useless. a thing is usually not useless.
a thing can be blank-appear-okay. a thing is usually not blank-appear-okay.
section rules - not for release
When play begins (this is the run property checks at the start of play rule):
if the description of the player is "As good-looking as ever.":
say "The player has the default description.";
repeat with item running through rooms:
follow the property-check rules for item;
if undescribed-rooms is 0:
say "DEBUG Yay all rooms described.";
repeat with item running through not useless things:
if item is a person, follow the property-check rules for item;
repeat with item running through not useless people:
if item is not blank-appear-okay and initial appearance of item is empty:
increment init-mt-ppl;
say "APPEARANCE IN ROOM [init-mt-ppl] [item].";
repeat with item running through things:
if item is not a person, follow the property-check rules for item;
if undescribed-objects is 0:
say "DEBUG Yay all objects described.";
if undescribed-people is 0:
say "DEBUG Yay all people described.";
if init-mt-ppl is 0:
say "DEBUG Yay all people have initial appearances.";
A property-check rule for a thing (called the target) (this is the things must have description rule):
unless target provides the property description:
do nothing;
if the description of target is non-empty:
do nothing;
else if target is not abstract:
if target is a person:
increment undescribed-people;
say "PERSON [undescribed-people]";
else:
increment undescribed-objects;
say "OBJECT [undescribed-objects]";
say " [target] [if target is plural-named]have[else]has[end if] no description.";
A property-check rule for a room (called the target) (this is the rooms must have descriptions rule):
if description of target is empty:
unless target is abstract:
increment undescribed-rooms;
say "ROOM [undescribed-rooms] [target] has no description.";
(Also, I also like having, say, Shuffling Around Tests.i7x for Shuffling Around, which includes stuff like the above code, so my main story.ni focuses on the story. Even a small bit of organization really helps me!)
As for what verbs people might try, Standard Rules should have the lot, if you want brute force.
grep -i "understand.* as " "Standard Rules.i7x"
If you find any verbs not fun, you can always add, say,
understand "jump" as something new.
One data point on the pronunciation of “plugh”: Yon Astounding Castle! of some sort included sound effects created with a text-to-speech synthesizer in the ADRIFT Runner version that iirc pronounced the word like “pluh.” (Four days late, sorry)
Some sources claim that PLUGH is short for plughole. If true, that would seem to indicate a hard G. I don’t think that’s been confirmed, though.
I’ve always said/thought “plug” and “ex-why-zee-zee-why”. They’re so entrenched in my mind that I’m finding it deeply weird that people use other things! (which of course I know is silly.)
I’ve always thought of it as “pluff” (as in rough) and down here we say “ex-why-zed-zed-why”
KSIZZEE in my mind.
And PLUHHH (soft but audible exhalation at the end).
I like knowing how these sound to others. It made me realize that one of my favorite responses to XYZZY works because of the way I internally pronounce it.
—>XYZZY
Bless you.
Yeah, I definitely pronounce it like the word “plough” with an OO vowel instead of a diphthong.
But I guess English is pretty inconsistent here. It could be “pluff” too, like “rough”…
My dad played mainframe ADVENT in the '70s. Before he ever introduced me to Pirate Adventure on our TI-99/4A in 1984, he had told me about ex-wye-zee-zee-wye and ploog.
On the rare occasion when I have to say weird IF terms out loud for someone to comprehend, I spell XYZZY out “ex why zee zee why” because any pronunciation I attempt would probably make them go “huh?” 