itch.io

All games have an inventory limit. (You probably don't like that either.) The implicit TAKE prior to DRINK causes all sorts of inventory management issues. If your inventory is full prior to DRINK COFFEE, do you:

• Tell the player they can't carry any more (and cause them some confusion because they weren't trying to pick something up).
• Allow them to exceed the inventory limit in order to carry out the action (and possibly break future inventory limit checking in the process).
• Drop a random object in order to allow them to pick up the coffee (and break the precious Ming vase in the process).
• Allow them to drink the coffee and put down the empty cup so as not to exceed the inventory limit (but do they put down the empty cup when they were already carrying the coffee).

There are all sorts of other scenarios, but this gives you a small sample of some of the problems involved when you allow implicit actions. This all requires a hell of a lot of extra coding that is not needed when you don't allow implicit actions and is far less confusing to the player in the long run.

Inform has the concept of a "sack" object. (This idea is taken from Zork.) If you try to pick something up when your inventory is full and you are carrying the sack object and it is not full, then it picks an item at random and puts it in the sack, then picks up the coffee so that you can drink it.

I remember a game where you couldn't pick up the coffee because it was too hot. What do you do then?

In my last game (a future entry in IFComp 2020), I wanted the player to be able to PUT WATER IN BUCKET. The library would not allow anything to be put in a container unless it was held first, so it would implicitly try to get the water (this is similar to your implicitly getting the coffee), but you can't get the water. That's why you need the bucket in the first place. So it was impossible to put the water in the bucket without modifying the standard grammar.

Do you see what I mean yet?

My point is that you have to be consistent. If you're going to allow an implicit action in one particular scenario, then you have to allow it in all sensible scenarios. This leads to a hell of a lot of extra coding and possible confusion to the player. In every game that I've ever played that allows implicit actions, I've actually ended up taking more moves than had there not been any implicit actions. This is because I am very thorough when playing a game in order to write up the solution for CASA.

In the old days of two-word input, the indirect object was always implied. This was unavoidable because of the limitations of a two-word parser. But implicit actions are quite different to implicit objects. Think it through carefully before you decide to go the implicit actions route.

In case you haven't worked it out by now, I love writing about game theory as it applies to adventures. This comes from 40 years' experience playing, writing and writing about adventures. So please forgive me if you find this boring, but it's meant to be thought provoking.

Here's some more thoughts on the problems of an implicit OPEN after UNLOCK.

How many turns does it take to do an implicit open after unlock? One or two? With non-implicit unlock and open, it takes two turns, as there are two explicit commands resulting in two explicit actions and these actions can be separated in time. A common sequence would be UNLOCK DOOR WITH KEY. DROP KEY. OPEN DOOR. That's clearly 3 turns. With implicit actions, it should be the same, so you have to manually increment turns after the initial UNLOCK.

What happens if you attempt to UNLOCK DOOR when it's already unlocked? You can't unlock it again. Do you just give an error response or do you open the door, even though that's not what the player asked for?

From the above, it should be pretty obvious that you can't just make UNLOCK and OPEN synonyms, otherwise you would be able to say UNLOCK DOOR when it wasn't locked in the first place.

Earlier, I said that you must be consistent so as not to surprise the player with seemingly nonsensical responses. Therefore, if you have a locked box or a locked chest, these should also be automatically opened after an UNLOCK command if you have an implicit OPEN. But what happens if you don't want them automatically opened? Consider Pandora's box. You need to unlock it, but you don't want to open it or you'll unveil the horrors within. I recall a game like this where you had to unlock the box, but not open it and give the unlocked box to a monster. When the monster opened the box, the monster was killed when the contents of the box escaped. With your automatic OPEN after UNLOCK, it would be impossible to complete the game, because unlocking the box also opens it and the contents kill you.

Chris mentioned 'The Witch's Apprentice'. It contains a puzzle near the beginning where you need to unlock the front door, but you don't do it using a key. Are you suggesting that the unlock operation should also open the door, even when there's no one in the vicinity to do it? I don't think so.

What happens with LOCK and CLOSE? If you close the door, is it automatically locked? You were suggesting that it should be because that's what you would "naturally" do in the real world. But what if you've dropped the key somewhere? And what happens if you try to LOCK the door when it's open? You can't do this in real life. Are you suggesting that you should automatically close the door first, then lock it? Then we're back to the same problem the key is missing.

So, carefully consider ALL the consequences of using implicit OPEN after an UNLOCK.