Time to open those doors

After dealing with the open/closed/locked situation in containers in my last post, I think it is time to take a look at something that is fairly similar in its mechanics… doors.

I already created Exits a little while ago that I use to connect rooms, but any adventure game worth its salt also has doors, and like containers, these doors have different states.

My first step is, therefore, to define the necessary states, just like I did for the containers.

Since doors are a special kind of exit, the next step is to set up a class that derives from my Exit class.

Nothing spectacular here at all, and as you can see, I’ve already brought across the TryUnlock() and TryOpen() methods that are virtually identical from the containers, because like in those cases, I think it is an important game feature that the game is smart enough to open a door automatically, if the player tries to walk through it while it’s closed or if he tries to open it while it’s still locked.

There is a call to a SetState() function that needs a bit of explanation, I think.

When you have a door in the game, the door actually appears in two rooms, technically. If in the room you’re currently in there is a door leading West, for example, it means there also has to be a door in the room it leads to, leading in the opposite direction. If I open the door in my current room, by definition, the door in the other room will also have to be opened.

That’s what this function does. It looks where the door leads to and then grabs the definition for that adjacent room. There, it searches the exits for one that leads in the opposite direction and flags it as Open as well. I hope this made sense…

The function to invert the direction, is a rather crude little bit of code. It may not be elegant, but it gets the job done, and since it’s in a method of its own, I can go back at any time and expand it to allow for more directions.

With all that in place, it is now time to implement the actual actions.

As you can see, the logic of these actions is essentially identical to the one I used in my Container class. After all, the behavior of a lid compared to a door is not all that different.

Catching the respective actions in my Evaluate() function allowed me to make the necessary calls and before I knew it, I had doors I could open, lock and close. Neat.

One key ingredient is still missing at this point, however. Since we are talking about a type of exit, I want to make sure that player can actually walk through doors and, as I mentioned before, I want the game to automatically open doors if necessary. In order to make that happen, I had to modify the Move() function that is part of my Room class.

And just like that, the player can move through doors in the game and he can manipulate doors as well, which adds further depth to the game. Throw in a couple of additional responses when the player tries to break down a door, or when he tries to put his ear to it to eavesdrop, and you have some more powerful game features your player will enjoy.

Leave a Reply

Your email address will not be published. Required fields are marked *