Nothing wrong with all-caps in that context, it’s the most effective way to separate the command grammar from the rest of the language in the player’s mind.
I have been secretly peeving about the shift (NPI) away from representing player commands in all-caps, for a long time now though I don’t recall exactly when the convention changed from representing player commands in all caps to representing them in no-caps (latter Infocom itself most likely), but I have never liked looking at those no-caps command lines one bit. Italics are definitely not right either. The best solution is the original solution on this; I saw plenty of games in the early days with lower case in the descriptions but always all-caps on the commands, and that was always pleasing to the eye, and there was never a good reason to reject it in the first place, except, ‘Oh we’re not restricted to upper case exclusively now, so now let’s not ever use it to dissociate ourselves from the past.’ There was an emotional/marketing reason to drop the all-caps commands, perhaps. But I would go back to what the First Imps did; there is infinite wisdom there, because the earliest conventions are often simple, obvious, and good, and might not have been discarded for good reasons, or for reasons that seemed good at the time but aren’t really an issue anymore. For example, nobody looks at an all-caps-set word, heading, or phrase today and thinks, ‘Wow, dude, haven’t you ever heard of an 80-column card? Welcome to the late 80s.’ That particular flavour of snark died long ago, so there’s no reason to avoid now what was avoided (perhaps for fear of seeming obsolete) then. It just isn’t a sign of obsolescence anymore to print player command in all caps. It never should have been.
Well I’ve made the best case I can for all-caps command lines. My MUD has them and my Inform game will probably have them if it’s not too difficult to replace the printing of the player’s command.
I probably will not use your extensions though because my game is in third person objective (Jack does this. Jack does that. Mud-style.) Which means I can’t even use Ron’s version of CLM because it doesn’t account for MUD-style objective naming; it wants to use pronouns all the time – so I’m still using David Fisher’s CLM for now but I now think of the CLM extension as merely an early stage shortcut. In the end I’m fairly sure I will have to rewrite every standard library message by hand to represent the protagonist’s personality, anyway (and it’s decidely non-neutral), so that probably will put me deeper under the hood than your extension operates and it will probably only get in the way with the whole ‘neutral’ philosophy which is not appropriate for my game. Great idea. But I don’t think your goal of universal adoption is going to be workable because at least in my case my protagonists aren’t likely to be neutral and I can’t see myself wanting my parser responses to be neutral, at least not most of the time.
Well I've made the best case I can for all-caps command lines. My MUD has them and my Inform game will probably have them if it's not too difficult to replace the printing of the player's command.
I wasn’t able to do it myself. It was one of the things I was poking around with related to my topic here about ‘can I intercept the player’s last command?’
I couldn’t actually replace the player’s command with all caps (or anything), because it’s not possible to tell Inform to print on ‘the current line minus 1’ I.E. - you can’t print over stuff. The closest you could do is to print it all-capped on the line after the prompt. That is unless there’s some I6 method I don’t know about.
Here’s a list of the extensions I call up in the beginning, and I’m using the latest release of Inform7:
Include Player Experience Upgrade by Aaron Reed.
Include Keyword Interface by Aaron Reed.
Include Automap by Mark Tilford.
Include Glimmr Automap by Erik Temple.
Include Glimmr Automap Tileset by Erik Temple.
Include Glimmr Bitmap Font by Erik Temple.
Include Locksmith by Emily Short.
When I run Player Experience Upgrade without anything else in a test I don’t get that error, it seems fine. But when it’s included with the extensions listed above the error occurs. So I’m not sure what is conflicting with what here - or if it’s something else entirely, maybe something somewhere buried in my code causing it.
Can this extension also make entry of the magic word ‘Zowie’ result in the game entering an archived player’s command as if they had just typed it now and pressed enter? … As that’s the idea I was fumbling around in my searchings. But I already changed my mind a whole lot on numerous topics since yesterday, and pretty much been wrong on every punt I’ve taken.
Thinking back, I think the reason player commands used to be in all-caps was that most people left caps-lock on when they were using their 8-bit computers. I don’t remember how much case sensitivity there was in the OS, but it’s possible that keywords and filenames had to be all-caps, so it didn’t make sense to turn caps-lock off.
The practice of leaving caps-lock on continued for a while afterwards - remember how people on usenet and early web forums would get in trouble for “shouting” in all caps? I’m not sure it had anything to do with the code at all.
this looks like an awesome approach. I’m pretty far into my first game and I’ve done something like this with several of your extensions as well as those from other sources. How much trouble do you think I’m gonna run into switching to this mega pack? (Or maybe that’s the purpose of this soft launch.)
Here’s what I currently use:
[code]Section - Extensions
[ Requires Z8 or larger story file to compile]
Include Exit Lister by Eric Eve. [ Display exits in status bar ]
Include Keyword Interface by Aaron Reed. [ Highlight objects in text ]
Include Measured Liquid by Emily Short. [ Overkill for Bourbon & Cola? ]
Include Telephones by George Tryfonas. [ Not fully implemented ]
Include Menus by Emily Short. [ Basic help & hint system ]
[ Extensions to help with parsing errors. They also make the game larger ]
Include Extended Grammar by Aaron Reed.
Include Small Kindnesses by Aaron Reed.
[ Source of “I didn’t understand that number” errors – maybe this is now fixed ]
Include Numbered Disambiguation Choices by Aaron Reed.
Include Assumed Conversers by Michael Martin. [ Ask About defaults ]
[ Though it does not disambiguate ASK ABOUT Topic with multiple NPCs ]
[ Doesn’t work properly with objects - possibly worth skipping ]
[ Note - Smarter Parser requires Glulx interpreter ]
Include Smarter Parser by Aaron Reed.
Include Poor Man’s Mistype by Aaron Reed.
If you’d like me to test it I can, but I may need to get the game to a safer state before I do so.
Like I expect most people do I leave it off for convenience, so I don’t have to keep switching it when I switch apps. It shouldn’t be up to me to hit a button every time I switch the app so the font will look nice. That’s not good thinking on the part of the dev. The result is a big flaw in current interpreters, in terms of their visual design.
There were a number of games in the old days when lower case first appeared, that assumed caps lock would be off, but would force certain things you typed into upper case, anyway. I much preferred that approach but it died.
Zach-- yes, the soft launch is definitely to try to tease out some of these issues.
I know “Keyword Interface” is still not 100% compatible yet, due to issues with how it and Custom Library Messages both set the style of parser error messages. The solution to this is mostly implemented, but still has a few holes such that if the player changes the style of parser messages the change might not be reflected. This is on my list of things to fix.
As far as I know, none of the rest of the extensions should conflict-- If you see anything that indicates otherwise, let me know.
I think I’m younger than you, so it’s not surprising that I disagree with you about what’s visually nicer in this case: I don’t associate all-caps with command line input, I associate it with ANGRY INTERNET SCREAMING. I admit that I did use caps in the How-to-Play-IF card, but one of the major reasons I used the Arno typeface for it was that I could have a caption-proportioned font for the caps, since the standard proportions seemed overly aggressive to me. I’m not sure if it would really bother me if interpreters used capital letters for the input lines (if my fonts are antialiased and hinted properly and the colors aren’t eye-searing, I’m pretty content), but I certainly don’t mind lowercase and would think of caps as a bit atavistic.
It looks like thorough and thoughtful work, Aaron, so: many thanks and keep it up.
To respond to your query, the two reasons I could think of, off the top of my head, are 1) the aforementioned z5 limitations, and 2) personally, my IF work tends to be kind of meta, and I think that leaving in a lot of the default messages is part of the aesthetic for me (which is not to say that I don’t try to be good about synonyms and novel types of puzzles and such). So far, my games have been blatantly made for people who are already familiar with the genre and its conventions, and subtle changes to the Graham Nelson phrasings are part of the in-jokes and cluing – if you’re not fairly used to IF, you’re definitely not going to enjoy my (existing) games, and I don’t think a friendlier parser is necessarily going to change that. For future games, in which I’m potentially trying to make work for a more general audience, I will be much more likely to include this kind of extension.
Aaron, I just noticed something interesting. We were discussing how to name rooms in the Remembering extension. Did you notice that Eric Eve’s Exit Lister (you’re using that in your mega-pack, right?) gives rooms a destination name property that’s pretty much the same thing?
I’m thinking maybe I will write a “relative room names” extension, just so it can work with that…
Yeah, a lot of games have done things like this… Blue Lacuna had a special property for rooms to store their “prose name”… the problem is that I most authors don’t want to go through the hassle of creating a custom field to support this. That’s why I like the “activity” approach we’ve been pm-ing about, because it would provide a nice hook for authors to change the default behavior if they had some better approach like this.
(I’m not using Exit Lister as part of the default package, since there are a couple different contradictory opinions about what should go in the status line these days. “Small Kindnesses” includes a bit that lists valid directions after an attempt to go in an invalid one.)
An activity is a good approach. Another idea would be to initialize the custom text field at startup to use the value of the printed name property if the author doesn’t specifically set one, e.g.:
[code]A room has some text called the prose name. The prose name is usually “@@@@”.
When play begins:
repeat with place running through rooms:
if the prose name of the place is “@@@@”, now the prose name of the place is the printed name of the place.[/code]
An activity is more flexible (unfortunately, it also seems to be one of the things that authors come to understand later in the learning curve rather than sooner, but that’s not a reason to avoid activities here–at least, I don’t think so.)
True, true and true. Something perhaps to hope for in future versions of the documentation - encouraging the creation of new activities, and making it less intimidating.
Creating activities was one of the last things that I learned to do, and it totally didn’t need to be. Once I understood what they’re good for, it was a no-brainer.
Now let me think… someone, probably Ron, gave me a rule of thumb about when to create an activity. Although it’s intuitive to me now, I don’t think I could explain it like he did. I wish I could remember what the rule was…