Occassionally, you may want to have a dynamic room transition when moving from one room to the other for the first time, or after a special event has occurred. Normally, when you move between rooms, only the new room's description is displayed. However, if you create a Task to override a direction based on certain restrictions, you can display whatever text you want instead of the standard text and room description displayed with direction commands.

As an example, let's say we have two rooms, one of which is to the north. We'll call the room we're in the Hallway and the room to the north will be Vault B. Inside Vault B is a prototype for a new and deadly weapon of unknown purpose. You have cracked the various codes and locks to the vault door and have just succeeded in opening it. Now, as the writer, we will introduce two scenarios. Inside the Vault, the prototype weapon is secretly guarded by an invisible laser system. The scenarios are based upon whether or not the player has found out about this laser system and successfully disabled it.

Scenario #1 - Player Disabled Laser System: When the player types "north" to move into Vault B, the default System Command is executed and the room description for Vault B is displayed.

Scenario #2 - Laser System Was Not Disabled: In this scenario, the default "north" command is overridden by a Task Command, and the player receives some rather bad news about the end of his or her life.

To override the default System Command for Scenario #2, first create a Task. Set the Task to work only in the Hallway (the room we started in) and no other room. This prevents this Task Override from working in another room when all the other restrictions are met (I'm sure our player doesn't want to die when moving north before he even gets to this building). Now, enter a description, like the following:

With great hesitation, you step into the vault. As you get inside, the vault door slams shut behind you and you hear several strange sounds before the smell reaches you. At once you recognize the poison gas, but have no recourse in this sealed vault. In great despair you lean against the wall and slide slowly to the floor, awaiting the sudden, violent seizures which will soon overtake you...

You, of course, need to make sure that your Task Restrictions and Task Actions are set up appropriately. For this tutorial we will concentrate solely on the Description Tab. Therefore, the last items we need to enter are the commands themselves. This is the most important part, because if it isn't perfectly right, then the player may accidentally find a loophole and get around your task, or the player may die when they shouldn't. The following are all the possible things the player can type to move north into Vault B:

To accommodate for all of these, you need two commands in your Task Command list:

That's all there is. You should now have a successful Task setup to override the default System Command for "north" and setup our Scenario #2!

There are a two primary ways to deal with "hidden" rooms. One way is on the Directions tab of the Room dialog box. There, it can be set to prevent the player from moving a certain direction unless a specific task has been completed. I have found that a more versatile way to accomplish this is by creating a Task Command to override the default System Command for the specific direction in question. For example, we have a room with a closet to the east hidden by an illusory wall. To accommodate for the hidden closet, we create a Task with the commands:

Then, we set the Task to happen only in our particular room. The two keys here are the Description and the Task Action. Sent our player isn't allowed to move "east" normally, we need to create a Task Action moving our player to the Closet if the Task is completed. Finally, we need to give the event a description, such as:

Whether it's courage or stupidity, something in you encourages you to walk into the wall to the east... <put a wait time here for suspense>

As your breath catches in your throat, you pass right through the wall and into a secret closet.

In this scenario it would also be appropriate to set the room description to be displayed after the Task is completed. Congratulations! You've just made a hidden room using System Command Overrides instead of room directions!

Probably the most troublesome System Command to override is the GET command. In this example we will discuss overriding the GET command for one or two tasks (allowing the default System Command to take care of the rest).

The most likely situation in which you'll want to override the default GET command is when you want to control when and how an object is retrieved. For example, you may have an object "firewood" which you want the player to be able to pick up unless it's burning. There are two ways to handle this scenario.

(1) If you DON'T want to override the default GET command, you can create two objects, a dynamic "firewood" and a static "burning firewood". Whenever the player lights the firewood, you would move the "firewood" object to hidden, then make the static "burning firewood" object visible. The player can then pick up the dynamic object, but not the static object!

(2) Override the default GET command when you don't want the player to pick up the burning firewood.

Since we're more concerned with Number 2 right now, let's discuss it in more detail. First, make sure you include all the related System Commands in your Task Command list for our Task. To successfully override the GET command, you must include each of the following commands in the list:

The asterisks are not required, but important when considering the level of realism which you would like your adventure to portray. Now, set the Task to occur in any room where the player is allowed to light the firewood. Since this Task is designed to prevent the player from picking up the burning firewood, we need a Task Restriction stating that the wood must be burning. A good way to do this is to use a variable which numerically describes the status of the firewood. But that's not all! You also need these restrictions as well:

Player must not be holding firewood
Firewood must be visible to player

Without these, then a loophole would exist allowing the player to get the firewood before they even know it exists, or allow the player to get what they are already in possession of.

Finally, include any appropriate actions (not required) and give your Task a description such as "Now you've burned your hand! How did that feel?"

There are several reasons you may want to override a System Command completely, if nothing more than for the reason that you don't like the default response. For a simple example (which is not so simple), we'll look at the DROP command. Normally, when you drop an item, you get the default response, "You drop the <object>." But, let's be a little more creative and change the response to:

Tired of carrying the <object>, you toss it to the ground, stomp on it a few times, then kick it out of your sight.

As you may have guessed, there's a lot to consider to completely override a System Command. First, and most important, you want to make sure you are using all related commands in your Task. This is important in two ways:

(1) If you don't include overrides for all the related System Commands, your Task Override will not always work. This can best be seen in the GET command. To successfully override the default GET command, you must include "get", "take" and "pick" in your task commands. The same applies to our DROP command. You should include the following:

Notice that I used "put down" instead of just "put" (as used in the main Adrift Tutorial). If we used "put", then we might accidentally override some of our own PUT tasks, such as "put jewel in eye" to open a secret door in a statue.

(2) You also want to think of commands the player might use, even if they aren't default System Commands. For example, what if the player types "throw <object>" or "throw <object> down". Try to think of ways in which a player might drop something and be sure to include those as appropriate in the list of Task Commands for our Task.

The second most important consideration, when completely overriding default System Commands, is to set up the proper Task Restrictions and Task Actions, both of which are equally important. It would be prudent to first make sure the player has an object before you let them drop it. It would also be ignorant on your part if the player has an object and your task executes successfully, but you forget to move the object out of the player's inventory using a Task Action.

In our example, you should also consider what type of object the player is dropping. If they are dropping a liquid, then you have to consider where they are dropping it. If dropping onto the ground, the liquid should be moved to hidden (so they can't pick it up again). But, if the liquid is water and they are dropping it into a well filled with water, then the player should be allowed to pick it up again.

See how complicated it can get! These type of overrides are the reason that Beta Testers exist. Many times a second or third party can find a loophole or scenario that you might have missed. A good writer will always get at least one additional opinion to make sure they find as many possible errors as they can.