Int Fic Transporter

Transporter

[Note: until more people sign off on this, it is one of the ProtoPatterns, according to the RulesOfThree]

Purpose: To transport an actor between different locations.

Problem: The actor needs to be moved from one room to another, but in so doing, the actor moves on/through/over an object which may or may not block the actor's progress, or which might trigger some other event to happen.

Context: Two rooms exist with an item (not a location) between them. This could be a door (potentially closed and/or locked) a bridge (which might collapse if too much weight was carried over it), a stairway (which might be one-way, like an escalator), or some other such object.

Forces: The player wishes to move the actor from one room to another. The author wishes to constrain this movement in some way. These constraints may take on a wide variety of instances, all of which need to be easily implemented.

Solution: A transporter object is created, with special routines which are called whenever the object itself becomes the target of a normal 'Move' or 'Go' action. These routines can check to make sure certain conditions are met before allowing the actor to move from one room to another, spawn new processes, or set new conditions after the actor's attempt.

Examples: In the InformLanguage, GrahamNelson has created a 'door' attribute. An object with the door attribute can be the target of a 'dir_to' routine, instead of the normal case, where the target of the routine is the actual room object itself.

Here's an example straight from the InformDesignersManual:
 Object Corridor "Stooped Corridor"
   with description "A low, square-cut corridor, running north to south,
            stooping you over.",
        n_to Square_Chamber,
        s_to StoneDoor;

Object -> StoneDoor "stone door" with description "It's just a big stone door.", name "door" "massive" "big" "stone" "yellow", when_closed "The passage is barred by a massive door of yellow stone.", when_open "The great yellow stone door is open.", door_to [; if (location==Corridor) return Shrine; return Corridor; ], door_dir [; if (location==Shrine) return n_to; return s_to; ], with_key stone_key, found_in Corridor Shrine, has static door openable lockable locked;

It might be noted that since StoneDoor was created without the attribute 'open', by default it is '~open', or closed. Therefore, the message under 'when_closed' is displayed in the Stooped Corridor when the actor first arrives. Since it is locked and openable, the actor must find 'stone_key' and use it to unlock it (see IntFicLockedItem)

Here is another example, again from the InformDesignersManual:

 Object -> PlankBridge? "plank bridge"
   with description "Extremely fragile and precarious.",
        name "precarious" "fragile" "wooden" "plank" "bridge",
        when_open
            "A precarious plank bridge spans the chasm.",
        door_to
        [;  if (children(player)~=0)
            {   deadflag=1;
               "You step gingerly across the plank, which bows under
                your weight. But your meagre possessions are the straw
                which breaks the camel's back! There is
                a horrid crack...";
            }
            print "You step gingerly across the plank, grateful that
                   you're not burdened.^";
            if (location==NearSide?) return FarSide?; return NearSide?;
        ],
        door_dir
        [;  if (location==NearSide?) return s_to; return n_to;
        ],
        found_in NearSide? FarSide?,
   has  static door open;

Essentially, Graham has provided Inform users with a pre-made pattern, so authors don't have to create one themselves. The source code from Inform about items with the 'door' attribute would probably be closer to describing exactly how to implement the transporter pattern, but this is the level at which most authors will be programming.

Counter Examples (Anti-Patterns): Instead of creating a door object, the room itself might have a routine under 's_to' which checked whether or not the door was open before moving the player to the next room ('Shrine'). This would probably work just fine for simple cases but if more fancy things were to happen (i.e. the actor could smash a hole in the door which he could squeeze through if he didn't carry anything else), it would have been more logical to implement it with all that code contained in the transporter object.

Resulting Context: Once a transporter object has been created, the object itself takes care of making sure the correct conditions have been met, or which trigger off the right routines at the right time.

Rationale: [incomplete]

Relationships: None (yet)

[Note: The Relationships section is supposed to be a pointer to other, related patterns. Since not many IntFic Patterns have been written yet, there aren't any here. If you write a related pattern, be sure to add it here. --LucianSmith]

Known Uses: Examples of transporter objects abound. In addition to the examples above, see the 'stone-cut steps' in the InformDesignersManual, the iron gate in 'Balances', and the many doors in 'Advent'.

[Please edit for clarity or content--this is my first attempt at writing any sort of pattern --LucianSmith]


CategoryIntFic
EditText of this page (last edited June 16, 1997)
FindPage by searching (or browse LikePages or take a VisualTour)