Source: http://inform-fiction.org/manual/html/s21.html
Timestamp: 2019-04-21 04:29:24+00:00

Document:
To recap on §4, an “entry point routine” is one provided by your own source code which the library may call from time to time. There are about twenty of these, listed in §A5, and all of them are optional but one: Initialise. This routine is called before any text of the game is printed, and it can do many things: start timers and daemons, set the time of day, equip the player with possessions, make any random settings needed and so on. It usually prints out some welcoming text, though not the name and author of the game, because that appears soon after when the “game banner” is printed. The only thing it must do is to set the location variable to where the player begins.
To equip the player with possessions, simply move the relevant objects to player.
The return value from Initialise is ordinarily ignored, whether true or false, and the library goes on to print the game banner. If, however, you return 2, the game banner is suppressed for now. This feature is provided for games like ‘Sorcerer’ and ‘Seastalker’ which play out a short prelude first. If you do suppress the banner from Initialise, you should print it no more than a few turns later on by calling the library routine Banner. The banner is familiar to players, reassuringly traditional and useful when testing, because it identifies which version of a game is giving trouble. Like an imprint page with an ISBN, it is invaluable to bibliographers and collectors of story files.
For the source code of the ‘Ruins’ TitlePage routine, see the exercises in §42.
The parent of the player object must at all times be “location-like”. An object is “location-like” if either it is a location, or it has enterable and its parent is location-like.
In other words, you can't put the player in an enterable cardboard box if that box is itself shut up in a free-standing safe which isn't enterable. And you can't PlayerTo(nothing) or PlayerTo(thedark) because nothing is not an object and thedark is not location-like.
▲ Calling PlayerTo(somewhere,1) moves the player without printing any room description. All other standard game rules are applied.
▲ Calling PlayerTo(somewhere,2) is just like PlayerTo(somewhere) except that the room description is in the form the player would expect from typing “go east” rather than from typing “look”. The only difference is that in the former case the room is (normally) given an abbreviated description if it has been visited before, whereas in the latter case the description is always given in full.
▲▲ It's perhaps worth taking a moment to say what the standard rules upon changing location are. The following rules are applied whenever a Look action or a call to PlayerTo take place.
If PlayerTo has been called then the parent of the player, location and real_location are set.
The availability of light is checked (see §19), and location is set to thedark if necessary.
The VC of a room is the value of location, i.e., either thedark or the room object.
If the parent of an object is a room or is “see-through” (see §19 for this definition), the VC of the object is the VC of the parent.
If not, the VC of the object is its parent.
The message location.initial() is sent, if the location provides an initial rule. If the library finds that the player has been moved in the course of running initial, it goes back to rule (3).
The game's entry point routine NewRoom is called, if it provides one.
The room description is printed out, unless these rules are being gone through by PlayerTo(somewhere,1). For exactly what happens in printing a room description, see §26.
If the location doesn't have visited, give it this attribute and award the player ROOM_SCORE points if the location has scored. (See §22.) Note that this rule looks at location, not real_location, so no points unless the room is visible.
The if statement needs to be there to prevent commands like “helena, listen” from being ruled out – after all, the player can still speak.
Why not achieve the same effect by giving the player a react_before rule instead?
(Cf. ‘Curses’.) Write an orders routine for the player so that wearing a gas mask will prevent speech.
The player object can not only be altered but switched altogether, allowing the player to play from the perspective of someone or something else at any point in the game. The player who tampers with Dr Frankenstein's brain transference machine may suddenly become the Monster strapped to the table. A player who drinks too much wine could become a drunk player object to whom many different rules apply. The “snavig” spell of ‘Spellbreaker’, which transforms the player to an animal like the one cast upon, could be implemented thus. Similarly the protagonist of ‘Suspended’, who telepathically runs a weather-control station by acting through six sensory robots, Iris, Waldo, Sensa, Auda, Poet and Whiz. In a less original setting, a player might have a team of four adventurers exploring a labyrinth, and be able to switch the one being controlled by typing the name. In this case, an AfterLife routine (see below) may be needed to switch the focus back to a still-living member of the team after one has met a sticky end.
The library routine ChangePlayer(obj) transforms the player to obj. Any object can be used for this. There's no need to give it any name, as the parser always understands pronouns like “me” and “myself” to refer to the current player-object. You may want to set its description, as this is the text printed if the player types “examine myself”, or its capacity, the maximum number of items which this form of the player can carry. Finally, this player-object can have its own orders property and thus its own rules about what it can and can't do.
As ChangePlayer prints nothing, you may want to follow the call with a <<Look>>; action.
▲ You can call ChangePlayer as part of a game's Initialise routine, but if so then you should do this before setting location.
▲ Calling ChangePlayer(obj,1); does the same except that it makes the game print “(as Whoever)” during subsequent room descriptions.
▲ The body dispossessed remains where it was, in play, unless you move it away or otherwise dispose of it. The player-object which the player begins with is a library-defined object called selfobj, and is described in room descriptions as “your former self”.
In Central American legend, a sorceror can transform himself into a nagual, a familiar such as a spider-monkey; indeed, each individual has an animal self or wayhel, living in a volcanic land over which the king, as a jaguar, rules. Turn the player into wayhel form.
Alter the Wormcast of ‘Ruins’ (previously defined in §9) so that when in wayhel form, the player can pass through into a hidden burial shaft.
To complete the design of this sequence from ‘Ruins’, place a visible iron cage above the hidden burial shaft. The cage contains skeletons and a warning written in glyphs, but the player who enters it despite these (and they all will) passes into wayhel life. (The transformed body is unable to move the sodium lamp, but has nocturnal vision, so doesn't need to.) Unfortunately the player is now outside a cage which has closed around the human self which must be returned to, while the wayhel lacks the dexterity to open the cage. The solution is to use the Wormcast to reach the Burial Chamber, then bring its earthen roof down, opening a connection between the chamber below and the cage above. Recovering human form, the player can take the grave goods, climb up into the cage, open it from the inside and escape. Lara Croft would be proud.
Write an orders routine for a Giant with a conscience, who will refuse to attack even a mouse, but so that a player who becomes the Giant can be wantonly cruel.
“There are only three events in a man's life; birth, life and death; he is not conscious of being born, he dies in pain and he forgets to live.” (Jean de la Bruyère again.) Death is indeed the usual conclusion of an adventure game, and occurs when the source code sets the library variable deadflag to true: in normal play deadflag is always false. The “standard Inform rules” never lead to the player's death, so this is something the designer must explicitly do.
Unlike life, however, interactive fiction offers another way out: the player can win. This happens if and when the variable deadflag is set to 2.
Capture was about the worst fate that could befall you in the unspeakably inhumane world of Maya strife.
‘Ruins’ doesn't, but many games allow reincarnation or, as David M. Baggett points out, in fact resurrection. You too can allow this, by providing an AfterLife entry point routine. This gets the chance to do as it pleases before any “death message” is printed, and it can even reset deadflag to false, causing the game to resume as though nothing had happened. Such AfterLife routines can be tricky to write, though, because the game often has to be altered to reflect what has happened.
The magic words “xyzzy” and “plugh” in ‘Advent’ employ PlayerTo. •‘Advent’ has an amusing AfterLife routine: for instance, try collapsing the bridge by leading the bear across, then returning to the scene after resurrection. ‘Balances’ has one which only slightly penalises death.

References: §4
 §42
 §19
 §19
 §26
 §22
 §9