Maybe my searching skills have utterly failed me, but I couldn’t find a topic discussing typical beginner’s mistakes. So, in that vein, I am asking:
What are typical beginner’s mistakes (=bugs) when designing/programming parser games?
I don’t mean the contentwise/stylewise things, like being too ambitious or unfair puzzles, but rather the real bugs/mistakes new designers tend to make because they don’t think of testing for them/implementing them. Like making sure that all scenery stuff defies attempts to pick them up.
Forgetting to check for repetition is a very typical mistake. If we want to, say, have a gold ring that drops when opening an umbrella, it’s easy to forget the check so the player can:
get the ring once
lose it elsewhere and
have it teleport to the current location by closing and opening the umbrella.
the true classic beginner’s mistake: takeable doors !
then, messing with directions, ending with rather escheresque maps (ex.going east from room A to room B, and east of room B returns to room A instead of west; a mistake not to be confused with winding maps.
Writing code that does something on the exact phrase “GET LAMP” without thinking that players will also type “TAKE LAMP”, “PICK UP THE LAMP”, “GET THE LANTERN”, “TAKE ALL BUT SWORD”, “CARRY BRASS”, or any of a thousand other variations.
Forgetting default behavior.
Many times it seems convenient to use something that already exists to implement a behavior you want, but then you can forget the way those things act by default. A great example is containers. If the player is meant to get an object from something, you could make it a container and put the object there. But don’t forget about opening, closing, searching, looking or reaching in, etc.
Many’s the time I’ve gotten past the puzzle where you’re supposed to purchase the golden key from the merchant by saying LOOK IN MERCHANT.
I thought I had self-tested my first game to near perfection but then beta testers pointed out mistakes which – if I know myself – I’m likely to make again:
Not supporting convenience commands properly, such as TAKE ALL FROM.
Objects having the wrong pronoun so the player cannot X IT but must X THEM.
Not making a final pass over the game and disallowing putting things inside things that cannot hold them (I had disallowed some of the early things, but not some of the newest items I added – this is probably an opportunity for generalisation).
Having sneaky containers (that are containers but sort of pretend not to be) behave like regular containers when they are put on something else.
Allowing weird repetition, like closing a door when it is already closed.
Not allowing synonyms for directions: exit, out, leave, etc. in addition to the current cardinal direction of out.
Lots of errant punctuation from variations of text substitution.
Lack of noun synonyms – even words used in descriptions.
Lack of verb synonyms.
Unimplemented scenery.
Entirely unimplemented actions mentioned in flavour text.
I think the most common mistake for Inform 7 programmers is overuse of INSTEAD rules. It’s easy to write them, but they short-circuit a lot of Inform’s built-in machinery. Ultimately, this leads to a high level of customization that can be hard to troubleshoot–or get help troubleshooting–because Inform isn’t behaving the way it does out of the box.
The more serious, long term problem is that it prevents use of the entire action sequence. This might not matter at first, but it can become a problem later on. It also prevents authors from learning about the entire action sequence.
For instance, instead of entering the bag of tricks is not realy governed by Inform’s logic regarding entering or containers; it’s a one-off that could do anything. That might sound good at first, but t’s hard to manage these things in a full-sized game.
Inform 7 INSTEAD as you describe it is basically Inform 6 Before ?
Yours,
Deathworks
P.S.: Everyone - those are really interesting things you point out, and there are already a few that have surprised me - like LOOK IN MERCHANT, I never would have thought of that O.o . Thank you all for sharing your insights (let’s not bet how many of those I am still going to make myself (^_^;; ).
Probably. I have no experience with Inform 6, but if I6 BEFORE (edited) comes early in action sequence and prevents the rest of the sequence from executing (check, carry out, report), then yes.
However, in I7 BEFORE gets its own phase and is separate from INSTEAD. So maybe not one to one
Forgetting what verbs are built into whatever development system you’re using and allowing them to provide misleading default responses. For example, if the player is supposed to be transported to a magical land when they TOUCH MIRROR, a player who tries PUSH MIRROR or LICK MIRROR or HIT MIRROR and is told that nothing interesting happens as a result would be forgiven for concluding that they’ve already tried touching it.
Well, at least it sounds, close enough. Inform 6 Before is a property linked to an object and invoked once the parser knows that the object is the target of an action but before check, carry out, and report. Before can stop the sequence, so pretty much what you described.
I have read this before, and I understand rule processing on a technical level, but I still don’t have a good intuition for when to do what. I have gathered this much:
When defining the generic default behaviour for a new action, create check, carry out, and report rules.
When defining special cases for specific actions on specific things:
Create after rules to add behaviour that should happen “simultaneously” with the default carry out behaviour, and remember to continue the action if you also want default reporting.
Create instead rules for things that should override the default behaviour entirely.
Create before rules for things that should happen before the default behaviour, e.g. if a prior action is needed to make sure check prerequisites of the action attempted are met.
Don’t use check, carry out, and report since these are meant to contain the generic default behaviour.
But I’m not sure this makes at all sense. For example, I see very little difference between adding a carry out rule and adding an after rule with a continue the action. I see very little difference between adding an instead rule and a before rule with stop the action.
I contend the whole “instead” thing is poor design. I mean from the system, not the author. It’s basically a glorified hook into otherwise monolithic logic. This is what you did in the 90s basically. As pointed out, the problem is that it short circuits a lot of logic. And you’re on you’re own with no system support.
An IF system needs a way for the author to short-circuit all the built-in logic and write their own. Then it needs more ways to short-circuit some of the logic. Managing this problem is the entire hard part of writing an IF tool.
Inform is pretty good at it. Better than I6 was, anyway.
Trying to get back to the original topic, although being a beginner myself, I have one potential oversight that might also be easily made (yes, inspiration “struck” me while working on my project (^_^;; ):
Missing implicit actions (and their effect on messages and actions).
What I mean is things like Take in I6, which can be triggered implicitly by the system to complement commands like EAT BISCUIT if the BISCUIT is in scope but not in possession of the player as required by EAT. If you have something attached to Take, you need to make sure that it responds correctly to implicit actions (in my case, I had an After routine for Take to give a flavoured message upon success replacing the original, and that caused the original action never to take place at all as the After routine ended the entire handling). I can see how such cases might be missed in testing. Or am I underestimating my peers?