Knocking on doors problem

Hey All-

I have doors in my game which occasionally need to be knocked on to enter them the first time. But after that they don’t need to be knocked on.

I’ve implemented a “knock” command. But if the player simply tries going through the door, I don’t want to stop them with a “You have to knock” message, because that’s annoying, so I’ve implemented checks that just say “You knock and then enter”, like so:

Check going north to first floor:
	if the first floor is unvisited:
		say "You knock on the door, and a voice says 'Come in!'";
        continue the action;
        continue the action.

But some players will be attentive to the rules and will knock as requested. So I’m not sure how to have both (knocking AND just entering with implicit knocking) without doubling all code for the “knock” command. I’ve tried this:

Check going north to first floor or knocking on the solid front door:

But that doesn’t work. And I’ve tried making a general rule for knocking like so:

Understand the command "knock" as something new. Understand "knock on [something]" as knocking on. Knocking on is an action applying to one thing.

Does the player mean knocking on a door: it is very likely.

Carry out knocking on a door (called the entry):
	try entering the entry instead.

But of course that bypasses the check for entering the first time. What I want is something like this (which of course does not work):

Carry out knocking on a door (called the entry):
	try going the direction of the entry instead.

This would cover all knocking situations, so that whether the player knocks or just goes north, the action is subject to the same check. What is the syntax for this so I don’t have to double my code?

I might not have my head fully wrapped around exactly the behavior you’re looking for, but it sounds like you want KNOCK ON DOOR and ENTER DOOR (or GO N or whatever direction) to basically be interchangeable, such that whichever one the player types, the first time the player sees the “you knock on the door and a voice says come in” and then you go in, and second and subsequent time you just enter, right? If that’s the case, maybe simpler is better and you can just do:

Understand "knock on [door]" as entering.

(If the doors start out closed, you might need to to reorder when the “(first opening the door)” response gets spit out – or reword it – since of course the player automatically opens doors before entering them).


Well, duh, Amanda. Sigh. I’ll have to rewrite a bunch of stuff because naturally I made everything very convoluted, but this should work. Why do I have to make everything as complicated as I can?

1 Like

If the door has previously been knocked on and entered but the door has been closed again, should the player knock? (I assume you want the game to mention knocking when it’s implicit, right?)

And will the player ever have access to both sides of a door prior to knocking, or will there be no other routes into the rooms behind closed doors?

I don’t know I7, but if knock is synonymous with entering, what about knock on

  1. Car
  2. Phone booth
  3. Hole

Anyplace you can go, you can knock, and maybe that’s not an appropriate behavior depending on the game world.

If I were to do this with I6, I’d just add Attribute KNOCKED, and check that. That is, assuming it is an important aspect of the game.

I need the player to knock the first time (or have an implicit knocking) because the doors lead into NPCs’ houses. So it would be weird to just allow people to bust in. I think it’s probably OK to let them just go in again after the first time (maybe again with the implicit “you knock and are admitted”).
No other routes into rooms behind closed doors.

If that’s all, then I think it makes more sense tying the action to OPEN DOOR instead of GO action.

Which means it can be thought of an unlocking action, except instead of using keys, you simply knock.

Well, hmm. I replaced all the “Check going north (or east or whatever)” with

Check entering the room:

and implemented “Understand knocking as entering”, but it’s not reading my checks when I knock or enter.

I don’t want to just have it on the door, because then there are two directions going through the door to consider and I’d rather not mess with that if I don’t have to.

I don’t know why the commands “knock” or “go north” aren’t showing my checks.

I hate having to “open door” and then “go north”. I want that to be implicit, so that you can just enter in one command: “go north” or “knock on door”. But can it be easy? Noooo, of course not.

1 Like

Not able to test this ATM, but I think the issue is that the room isn’t actually being entered – the player is probably just going a direction into it (ACTIONS would let you see what’s going on under the hood, dunno if you’re testing with that?) Maybe rules of the form “Check going DIRECTION when the location is PLACE” would work for you?

There’s not a good way to put a hook into the implicit open by the enter action, so I think there’s no way around replacing it. I’m sure you’ll want different output details, but this was my stab at a framework for it:

Lab is a room.

A door can be knocked or unknocked.
The wood door is a closed openable door. The wood door is north of the Lab. The Conservatory is north of the wood door.

Before opening an unknocked closed door (called the ingress), instead try knocking the ingress.
Before going when the door gone through is not nothing and the door gone through is unknocked and the door gone through is closed, instead try knocking the door gone t\

Knocking is an action applying to one thing.

Understand "knock on/-- [thing]" as knocking.

Check knocking something (called the knockee) when the knockee is not a door (this is the knocking non-door rule): instead say "That accomplishes nothing."

Carry out knocking something (called the ingress) (this is the knock door rule):
  now the ingress is knocked;

To knock is a verb.

Report knocking something (called the ingress) (this is the report knocking rule):
    say "[We] [knock] on [the ingress].";

After knocking a closed door (called the ingress):
  say "[We] [knock] on [the ingress].";
  try opening the ingress.

Check an actor going (this is the can't go through unknocked closed doors rule):
  if the door gone through is not nothing and the door gone through is unknocked and the door gone through is closed begin;
  if the actor is the player, say "(first knocking on [the door gone through])[command clarification break]";
  try the actor knocking the door gone through;
  if the actor is the player, say "(first opening [the door gone through])[command clarification break]";
  silently try the actor opening the door gone through;
  unless the door gone through is open, stop the action;
  end if;

The can't go through unknocked closed doors rule is listed before the can't go through closed doors rule in the check going rules.

After opening a door (called the ingress): say "[We] [open] [the ingress]."; try entering the ingress.

The entering action applies to things, so one never actually enters a room. One can enter a door, which action gets converted to the going action on that door.

1 Like

This is really interesting. I have to pick it all apart, because there are later times when some doors will be locked against the player in some cases, and times when just knocking will trigger an event, but the player never goes in after knocking. A lot of the game’s actions are triggered by going through, or knocking on, doors, and of course it’s different for all doors, so I have yet again made for myself a major headache.

I figured this would be the easy part. HAHAHAHA.

1 Like

For now I’m just doubling up the code for going in a direction and for knocking, because of all the various complex events I have triggered by doors and knocking.

But some extremely useful advice to play with. Thanks, all.

I’d’ve said this initially but for knowing your preference for trying first to go without extensions: Implicit Actions by Eric Eve provides a really nice framework for establishing action preconditions and handling implicit actions; I’d much rather approach a problem like this with it than without it.

1 Like