Hi folks. Saw this forum via usenet, so I reckoned I’d chime in…
I’ve cobbled together a small adventure titled Jove’s Cavern .
While I enjoy coding, I’ve never before built anything IF related, so its certainly not start of the art (honestly just wanted to explore the mechanics of the process). At any rate, some game info…
nothing to install
requires a recent browser
uses only html/javascript
assumes a keyboard
not yet (if ever) built for tablets/handheld devices
I did have some difficulty with the parser, though. Instead of giving me an error message for commands it doesn’t like, the game appears to ignore those commands - even for commands that have previously worked (like going “north” in a room with no north exit). I wound up quitting not very far into it for this reason.
Let me think aloud here… the logic behind movements (thus far):
Directions you can’t currently move are ignored… That means for instance if one has (say) moved north once, moving north again is not necessarily a valid direction within the next context. Imagine a room with only a northern entry, logically you’d need to turn south to exit. The parser is 100% correct here (built an automated test unit to verify that ran 4 hours straight without error). But… the effect of ignoring bad commands from a user’s perspective is the exact problem I’m seeking to solve.
How to educate your user without bombarding them with too much info. Would you that the parser additionally offer valid exits for each context? (I’m guessing that’s what you mean). What do you suggest?
The problem is not limited to compass directions. The parser should show an error message when the action fails. The more detailed the error is, the better. Otherwise the player gets no feedback why their command was discarded. At minimum the player needs to know if the action failed because the word is not in the game’s dictionary or because the action is not available at that point of the story.
So in this case going to a direction that isn’t available should say “There is no exit in that direction” or something similar. Commands that don’t exist at all should say “That command isn’t available.” Otherwise the player is just fumbling in the dark.
Since you seem to be struggling with the parser itself (and I’m saying this because you yourself italicized “the effect of ignoring bad commands from a user’s perspective is the exact problem I’m seeking to solve”) I think you’d find it easier to use an existing language, like Inform (7, probably), or TADS if you like things programmer-like (in which case you can also try Inform 6), or Quest, or ADRIFT, or Hugo, or…
…thing is, the problem you are trying to solve has already been solved. Most (all?) Inform (and other systems) games have a default “You can’t go that way” message when trying to go somehwere invalid… not to mention the dozens of already-existing and easily customizable stock responses for every other parser failure. Tailored responses, relevant responses.
Well, the parser is only yet 3 days old, so I’ll hang in there just yet =) And speaking only for myself, I want to understand the code (these are the types of puzzles I enjoy solving if that makes sense) & honestly, I don’t mind so much getting my hands dirty even if the price is reinventing the wheel. A writer I am not chuckle, but a coder? Yep. sure enough. I earnestly hope this doesn’t come across as crass, because I’m all ears & am mighty appreciative. So please, always feel free to offer up your expertise. With me, its all about the brainfood.
In that case, just like Juhana said, ignoring a player’s command is not what you’ll want to do. You’ll want to reject it, yes, but provide an explanation. You can’t go that way; You can’t see any such thing; I don’t know that word. These are all functional “error messages” that tell the player exactly what went wrong, and the player will then parse that accordingly. “Ah, my bad, there isn’t actually an exit to the north from here”; “Ok, this noun must be just scenery, I can’t interact with it”; “What the… Oh, whoopsie, typo. Let’s try this again”.
Without this back-and-forth, as has been said, IF becomes a tedious, non-fun guessing game.
Yeah, I’d compare it to having a compiler ignore errors. You don’t know whether you did something wrong or there was just no result. And even once you know something is wrong, you don’t know what. Sure, examining your code again will likely reveal the problem, but it’s far, far more helpful to be told “missing }” or “redefinition of constant”.
Yeah. Basic tenet of software design: Fail early and loudly.
In many ways, conventional parser IF works by giving the player a mental model of the game space (Rather than a direct representation), and the care and maintenance of that model is what occupies a lot of the design of parser games. Every response from the parser, whether the input was successfully parsed or not, should reinforce the model for the player. So producing a blank message at any point is very bad; the only thing worse would be an outright misleading message (Eg, “I don’t understand that command” in response to “GO NORTH” in a room with no northern exit.)
I centralized all messages including bad commands (‘you cant go that way…’) in a dashboard of sorts, which ought to provide at-a-glance intelligence I’m hoping. Here’s a screenshot:
If anyone pokes around on this little game, would be best to ‘hard refresh’ the page (key combo ctrl+f5 in most browsers). As all pages at my site are compressed & browsers may need a little cajoling in that case to display the newer version.
Most (all?) Inform (and other systems) games have a default “You can’t go that way” message when trying to go somehwere invalid… not to mention the dozens of already-existing and easily customizable stock responses for every other parser failure. Tailored responses, relevant responses.