whole of first pass

resources/Documentation/Examples/Identitytheft.txt

@@ -2,7 +2,7 @@
 (Name of player character selected at start of play; Identity Theft)
 Allowing the player to enter a name to be used for the player character during the game.
 
-Let's say we want to allow the player to enter any name he likes for his character. Moreover, we want to reject very long names (which are likely to be mistakes anyway), and we want to extract the player's chosen first name from the rest.
+Let's say we want to allow the player to enter any name they like for their character. Moreover, we want to reject very long names (which are likely to be mistakes anyway), and we want to extract the player's chosen first name from the rest.
 
 	{*} "Identity Theft"
 	
@@ -39,7 +39,7 @@ We also want to postpone the proper beginning of the game until we've gotten the
 
 	The player carries a letter. The description of the letter is "Dear [player's full name], [paragraph break]You have won the Norwegian Daily Lottery! ...".
 	
-If we are compiling for Glulx, this is enough to capture not only the player's name but also the capitalization he uses.
+If we are compiling for Glulx, this is enough to capture not only the player's name but also the capitalization used.
 
 If we are compiling for the Z-machine, the player's input will unfortunately be reduced to lower case before we can inspect it. If we would like by default to capitalize the first letter of each word of the name, we might substitute the following after reading a command rule:
 
@@ -53,4 +53,4 @@ If we are compiling for the Z-machine, the player's input will unfortunately be
 		say "Hi, [player's forename]![paragraph break]";
 		say "[banner text]";
 		move the player to the location;
-		reject the player's command.
+		reject the player's command.

resources/Documentation/Examples/Infiltration.txt

@@ -2,7 +2,7 @@
 (Room description changes at each of several visits; Infiltration)
 A room whose description changes depending on the number of times the player has visited.
 
-Suppose we have a location that makes the player uncomfortable, and we want its description to change slightly each time he goes there, to reflect his increasing unease. We also want the door to that room to show whether he is going there for the first time, or whether this is a repeat visit.
+Suppose we have a location that makes the player uncomfortable, and we want its description to change slightly each time they go there, to reflect his increasing unease. We also want the door to that room to show whether they are going there for the first time, or whether this is a repeat visit.
 
 We start with an ordinary room:
 
@@ -26,4 +26,4 @@ And finally, to be sure that the player does see our fancy changing descriptions
 
 	Test me with "look / open portal / w / look / e / look / w / e / w".
 	
-Notice that the description of the Secure Zone changes from visit to visit, but that looking repeatedly during a single visit changes nothing. 
+Notice that the description of the Secure Zone changes from visit to visit, but that looking repeatedly during a single visit changes nothing. 

resources/Documentation/Examples/Jesse.txt

@@ -1,8 +1,8 @@
 *** When play ends
 (Resuming play after an accidental death; Big Sky Country)
-Allowing the player to continue play after a fatal accident, but penalizing him by scattering his possessions around the game map.
+Allowing the player to continue play after a fatal accident, but penalizing them by scattering their possessions around the game map.
 
-Some older games allowed the player to be resurrected after a death, but punished him by distributing his possessions far and wide. Here we emulate that effect.
+Some older games allowed the player to be resurrected after a death, but punished them by distributing his possessions far and wide. Here we emulate that effect.
 
 	{*}"Big Sky Country"
 
@@ -58,4 +58,4 @@ In a fuller implementation of this game, we might make it possible to get by the
 			resume the story;		
 			try looking.
 		
-"If the player consents" is just a convenient way to ask a yes/no question that the player must answer before going on with the game.
+"If the player consents" is just a convenient way to ask a yes/no question that the player must answer before going on with the game.

resources/Documentation/Examples/Juggling.txt

@@ -14,7 +14,7 @@ We allow things to have prices, and the player's price to indicate how much mone
 	
 	The player has a price. The price of the player is $60.00.
 	
-Because we're allowing the player to order things that he can't currently see, we need to borrow a special kind of grammar from the Understanding chapter. All our orderable items in this example are toys, so "any toy" means any object of the toy kind, whether or not it is in view at the moment:
+Because we're allowing the player to order things that they can't currently see, we need to borrow a special kind of grammar from the Understanding chapter. All our orderable items in this example are toys, so "any toy" means any object of the toy kind, whether or not it is in view at the moment:
 
 	{**}Understand "buy [any toy]" as ordering. Understand the command "order" as something new. Understand the command "order" as "buy".
 

resources/Documentation/Examples/Kiwi.txt

@@ -2,7 +2,7 @@
 (Raised supporter kind that conceals its contents; Kiwi)
 Creating a raised supporter kind whose contents the player can't see or take from the ground.
 
-Suppose we want there to be some high shelves in our game, which the player can't get at unless he's standing on a prop of some kind. (This is a pretty hoary and over-used puzzle, but there may still be occasions when it becomes useful again.) 
+Suppose we want there to be some high shelves in our game, which the player can't get at unless they're standing on a prop of some kind. (This is a pretty hoary and over-used puzzle, but there may still be occasions when it becomes useful again.) 
 
 In order to resolve this, we want to set up a raised supporter kind. When something is on a raised supporter, it should be mentioned to the player only if the player is in the right position (i.e., standing on something) and otherwise omitted from the description entirely.
 
@@ -67,4 +67,4 @@ Finally, we need to tackle the case where the player types GET ALL FROM SHELF, b
 	The step-ladder is an enterable supporter in the Nursery. Understand "ladder" as the step-ladder.
 
 	Test me with "x shelf / search shelf / get dodo / get all from shelf / stand on ladder / get all from shelf / search shelf / get off / put all on shelf / get all from shelf / stand on ladder / put all on shelf".
-	
+	

resources/Documentation/Examples/Labyrinth-G.txt

@@ -55,7 +55,7 @@ How will ghosts manifest themselves? Because this is only a small example, we wi
 		repeat through the Table of Ghostly Presences in reverse sequence order:
 			if the haunted position entry is the coordinates of the location, say "You sense the ghostly presence of an adventurer, [manner of death entry] with a score of [score at death entry] in [turns at death entry] turns."
 
-(For instance, "You sense the ghostly presence of an adventurer, buried by a rockfall with a score of 10 in 5 turns.") That just leaves the rule for bumping off the player. When the Table is full, and there are already 20 ghosts, the one who died longest ago (with the lowest sequence count) is eliminated, and his row blanked out. (This will always be row 1 since we sorted the table in sequence order on reading it in.)
+(For instance, "You sense the ghostly presence of an adventurer, buried by a rockfall with a score of 10 in 5 turns.") That just leaves the rule for bumping off the player. When the Table is full, and there are already 20 ghosts, the one who died longest ago (with the lowest sequence count) is eliminated, and that row blanked out. (This will always be row 1 since we sorted the table in sequence order on reading it in.)
 
 	{**}To have the player (sticky end - a demise):
 		let the new sequence number be 0;

resources/Documentation/Examples/Lanista1.txt

@@ -14,7 +14,7 @@ We start by recording, for each person, a maximum number of points of damage the
 
 	The current hit points of the player is 35. The current hit points of the gladiator is 25. 
 
-Now our rule for the actual attack. We want first to calculate how much damage the player's attack does, inflict that damage, and remove the enemy if he's dead; then, if he doesn't die, the enemy counter-attacks, also for a randomized amount of damage, and if this kills the player, the game ends in defeat.
+Now our rule for the actual attack. We want first to calculate how much damage the player's attack does, inflict that damage, and remove the enemy if they're dead; then, if still alive, the enemy counter-attacks, also for a randomized amount of damage, and if this kills the player, the game ends in defeat.
 
 	{**}Instead of attacking someone:
 		let the damage be a random number between 2 and 10;
@@ -39,4 +39,4 @@ This last bit is a refinement to help the player keep track of how the contest i
 		now the right hand status line is "Gladiator: [current hit points of gladiator]".
 
 	Test me with "hit gladiator / g / g / g".
-	
+	

resources/Documentation/Examples/Lanista2.txt

@@ -22,7 +22,7 @@ In our simpler version of this example we set the current hit points by hand, bu
 		repeat with victim running through people:
 			now the current hit points of the victim is the maximum hit points of the victim.
 
-	Definition: a person is dead if his current hit points are less than 0.
+	Definition: a person is dead if their current hit points are less than 0.
 	
 	Section 2 - Diagnosis
 		
@@ -48,7 +48,7 @@ In our new system, we want to specify what is being used for an attack. This mea
 
 Here's why: If we leave the default attack command in place, Inform will continue to accept commands like >ATTACK GLADIATOR, but reply foolishly with the default "Violence is not the answer..." response. 
 
-A somewhat better approach would be to change the reply of >ATTACK GLADIATOR to say something like "You must specify a weapon to attack with." But this is still less than ideal, because it means that the player has to then rewrite his entire command. If, on the other hand, we take out "ATTACK GLADIATOR" entirely, the game will always prompt "What do you want to attack the gladiator with?" -- which teaches the player the correct command structure for this particular game, and avoids pretending to understand any command that is not meaningful within this game.
+A somewhat better approach would be to change the reply of >ATTACK GLADIATOR to say something like "You must specify a weapon to attack with." But this is still less than ideal, because it means that the player has to then rewrite the entire command. If, on the other hand, we take out "ATTACK GLADIATOR" entirely, the game will always prompt "What do you want to attack the gladiator with?" -- which teaches the player the correct command structure for this particular game, and avoids pretending to understand any command that is not meaningful within this game.
 
 This is a little bit of work because ATTACK has a lot of synonyms in the default library, but if we look through the actions index we can find them all:
 
@@ -116,4 +116,4 @@ Though our checks and carry-out rules are similar regardless of who is acting, w
 	
 	Test me with "hit gladiator with mace / kill gladiator / drop mace / attack gladiator / attack gladiator with mace / g / g".
 
-Those devoted to role-playing will note that our form of randomization is still pretty naive: most RPG systems use multiple dice in order to create more interesting probability curves. For a system that simulates actual dice-rolling, see the full "Reliques of Tolti-Aph" game.
+Those devoted to role-playing will note that our form of randomization is still pretty naive: most RPG systems use multiple dice in order to create more interesting probability curves. For a system that simulates actual dice-rolling, see the full "Reliques of Tolti-Aph" game.

resources/Documentation/Examples/Larva2.txt

@@ -28,7 +28,7 @@ To say phrases can be more complex, as well, since we can have them incorporate
 		
 Here where we have (speaker - a person), we are leaving a slot which we can later fill in, madlibs-like, with any person we like. That is why we can write "insult for the noun": we are summoning the To say phrase and telling it to fill in the identity of the unknown speaker with the noun.
 
-This differs from "insult of the noun" in the previous example; in that case, each person had his own insult property, and were merely printing that property out. Here we are actually telling Inform to calculate anew what the insult should be, and giving it some instructions about how to do that.
+This differs from "insult of the noun" in the previous example; in that case, each person had their own insult property, and we were merely printing that property out. Here we are actually telling Inform to calculate anew what the insult should be, and giving it some instructions about how to do that.
 
 Our instructions can also get arbitrarily complex:
 
@@ -46,4 +46,4 @@ Our instructions can also get arbitrarily complex:
 	
 	Test me with "kiss wasp / hit wasp / kiss wasp / kiss drone / hit drone / kiss drone".
 	
-So the effects we can get with text substitutions are quite flexible. We could even, if we wanted, fill in the substitutions by random choice, or by selecting items from a long list or table, should we have so bellicose a set of characters that they cannot make do with one or two insulting remarks apiece.
+So the effects we can get with text substitutions are quite flexible. We could even, if we wanted, fill in the substitutions by random choice, or by selecting items from a long list or table, should we have so bellicose a set of characters that they cannot make do with one or two insulting remarks apiece.

resources/Documentation/Examples/Leopard-skin.txt

@@ -1,6 +1,6 @@
 * Lengthening or shortening a list
 (Maze escaped by performing an exact sequence of actions; Leopard-skin)
-A maze that the player can escape if he performs an exact sequence of actions.
+A maze that the player can escape if they perform an exact sequence of actions.
 
 Suppose (as in Infocom's Leather Goddesses of Phobos) that we have a maze that the player can escape only by performing the correct sequence of actions in the correct order. One way to do this would be to keep a list of the player's most recent actions, and see whether these match up with the combination we have established as the maze's solution.
 
@@ -35,4 +35,4 @@ For instance:
 			say "That does it! You are instantly transported from the maze!";
 			end the story finally.
 
-	Test me with "hop / clap / clap / hop / kweepa / hop / clap / kweepa".
+	Test me with "hop / clap / clap / hop / kweepa / hop / clap / kweepa".

resources/Documentation/Examples/LongTravel.txt

@@ -1,6 +1,6 @@
 ** Commands consisting only of nouns
 (GO TO ROOM with automatic door-handling en route--Traveling by room name, opening doors on the way; Safari Guide)
-The same functionality, but making the player continue to move until he reaches his destination or a barrier, handling all openable doors on the way.
+The same functionality, but making the player continue to move until they reach their destination or a barrier, handling all openable doors on the way.
 
 The foregoing example moves the player one location towards his destination, and requires that rooms have been visited before. But suppose we wanted to be a bit more lenient about movement, and let the player make as many steps as necessary per turn. We will also show consideration about doors, using the "Locksmith" extension supplied with Inform. (Now every time the code attempts opening a door, unlocking rules will also be invoked.)
 
@@ -28,4 +28,4 @@ The foregoing example moves the player one location towards his destination, and
 	
 	Test me with "go to aviary / go to ostrich enclosure / african grasslands".
 		
-Notice that we continue the movement until one of two things happens: either the player reaches the room that is his destination, or the going attempt doesn't work. In the latter case we stop the action in order to avoid hanging the game up in a loop. This event might occur when the player runs into a locked door, for instance.
+Notice that we continue the movement until one of two things happens: either the player reaches the room that is their destination, or the going attempt doesn't work. In the latter case we stop the action in order to avoid hanging the game up in a loop. This event might occur when the player runs into a locked door, for instance.

resources/Documentation/Examples/MRE.txt

@@ -4,9 +4,9 @@ Hunger that eventually kills the player, and foodstuffs that can delay the inevi
 
 Many older interactive fiction games required the player to find food and eat on a regular basis in order to avoid death. This effect was often unrealistic (since most people can survive much longer than a few hours without eating) and is often seen as an annoyance. However, for the sake of argument, suppose that we do want to construct a hunger-and-death system.
 
-To make things a little more interesting, we will postulate that different foods are differently filling, so that if the player manages to find something really caloric, he is off the hook on his hunger search for a while.
+To make things a little more interesting, we will postulate that different foods are differently filling, so that if the player manages to find something really caloric, they are off the hook on their hunger search for a while.
 
-We will also implement the system so that the player gets messages when he is hungry, then dies a short time later. (The times involved are ludicrously short, but this allows us to see the effects within a simple example. In a real game we would want to allow a considerably longer timer for the hunger to play out.)
+We will also implement the system so that the player gets messages when they are hungry, then dies a short time later. (The times involved are ludicrously short, but this allows us to see the effects within a simple example. In a real game we would want to allow a considerably longer timer for the hunger to play out.)
 
 First, a little scene-setting:
 
@@ -49,7 +49,7 @@ The first of those two phrases, "now the player is replete", causes the player t
 	
 Note "if the player is hungry": it is possible that the starvation event will be set up but the player will eat before it occurs; in that case, we want it not to take effect.
 
-And now, since we really ought to give the player some warning of what is happening to him:
+And now, since we really ought to give the player some warning of what is happening to them:
 	
 	{**}Every turn when the player is hungry:
 		choose a random row in the Table of Hunger Complaints;

resources/Documentation/Examples/Menu.txt

@@ -30,7 +30,7 @@ After that, we can use "the topic understood" to refer to the text we read:
 	"monkfish liver"	"monkfish liver"	"Expert eaters only"	"The odds of Ichiro's having this unusual delicacy is near zero."
 	"microdot"	"microdot"	"What you came here to deliver"	"There'll be time enough for that later. If Fowler ever turns up. Where is she, anyway?"
 	
-Since the player may not know what all the help options are, we might as well let him get an overview, as well.
+Since the player may not know what all the help options are, we might as well let them get an overview, as well.
 
 	{**}Understand "help" as summoning help.  Summoning help is an action applying to nothing.
 
@@ -39,4 +39,4 @@ Since the player may not know what all the help options are, we might as well le
 		repeat through the Table of Standard Help: 
 			say "  [title entry]: [summary entry][line break]".
 	
-	Test me with "help / help about microdot / help cucumber / help california roll".
+	Test me with "help / help about microdot / help cucumber / help california roll".

resources/Documentation/Examples/ModernConveniences.txt

@@ -134,7 +134,7 @@ or create an
 
 	Instead of examining the stove in the Industrial Kitchen: ...
 	
-sort of rule for those objects he wanted to describe specially; or he might use a when play begins rule to initialize a few things:
+sort of rule for those objects they wanted to describe specially; or they might use a when play begins rule to initialize a few things:
 
 	When play begins:
 		let N be a random stove in the Industrial Kitchen;

resources/Documentation/Examples/Morning.txt

@@ -2,7 +2,7 @@
 (FIND command; One of Those Mornings)
 A FIND command that allows the player to find a lost object anywhere
 
-Suppose that, contrary to the usual rules of interactive fiction, we want to allow the player to discover the locations of things he hasn't actually seen yet:
+Suppose that, contrary to the usual rules of interactive fiction, we want to allow the player to discover the locations of things they haven't actually seen yet:
 
 	{*}"One of Those Mornings"
 
@@ -43,4 +43,4 @@ If we want to have the key found in different places when the game is replayed:
 	
 	At 1:08 AM: say "The security guard arrives to find you fumbling about with keys. Curses."; end the story.
 	
-	Test me with "find pearl / find teakettle / get teakettle / find teakettle / find key".
+	Test me with "find pearl / find teakettle / get teakettle / find teakettle / find key".

resources/Documentation/Examples/Muppets.txt

@@ -6,7 +6,7 @@ Inform has built-in commands for other people, and sometimes we may want to adju
 
 	Kermit the Frog looks through his possessions.
 	
-we'd like someone taking inventory to report what he's got, thus:
+we'd like someone taking inventory to report what they have, thus:
 
 	Kermit the Frog says, "I seem to be carrying a microphone and wearing a hat and a trenchcoat."
 
@@ -26,4 +26,4 @@ To do this, we could replace the built-in report rule with a different one.
 
 	Kermit the Frog is a man in Grand Central Station. "Kermit the Frog stands nearby, enjoying being green." Kermit is wearing a hat and a trenchcoat. He is carrying a microphone.
 	
-	Test me with "inventory / kermit, inventory".
+	Test me with "inventory / kermit, inventory".

resources/Documentation/Examples/Names.txt

@@ -2,7 +2,7 @@
 (Port Royal: 4. Character names--Random characters seen through a window)
 A cell window through which the player can see people who were in Port Royal in the current year of game-time.
 
-Our protagonist is imprisoned in Port Royal, waiting out his years, and sometimes through the window of his cell he is able to see someone. 
+Our protagonist is imprisoned in Port Royal, waiting out their years, and sometimes through the window of the cell they are able to see someone. 
 
 We are, however, obsessive about historical accuracy, so we provide a table of people who really lived in the city, together with the year in which their existence is attested. We want these people to appear in the description only in the year when they are known to have been present. (After all, mortality was high in Port Royal and new people were constantly arriving, so someone's presence one year is no guarantee of their continued existence the next.)
 

resources/Documentation/Examples/Nudge.txt

@@ -2,7 +2,7 @@
 (HELP command is recommended if the player seems lost; Y ask Y?)
 Noticing when the player seems to be at a loss, and recommending the use of hints.
 
-Suppose we'd like to watch for signs that the player is floundering, and if we see them, recommend that he try the hints. There are probably more sophisticated diagnostics, but as a first cut, let's assume that a player who repeatedly reviews descriptions of objects he's already seen, looks around the room, and takes inventory, is at a loss for more productive activities. So then...
+Suppose we'd like to watch for signs that the player is floundering, and if we see such signs, recommend that they try the hints. There are probably more sophisticated diagnostics, but as a first cut, let's assume that a player who repeatedly reviews descriptions of objects they've already seen, looks around the room, and takes inventory, is at a loss for more productive activities. So then...
 
 	{*}"Y ask Y?"
 	
@@ -13,7 +13,7 @@ Suppose we'd like to watch for signs that the player is floundering, and if we s
 	After acting confused for the sixth turn:
 		say "(If you are feeling lost, try typing HELP for suggestions.)"
 
-And now we write a scenario which will, alas, rather encourage even a deft and clueful player to play as though he were hopelessly confused:
+And now we write a scenario which will, alas, rather encourage even a deft and clueful player to play as though they were hopelessly confused:
 
 	{**}The story headline is "or: Bad Author, No Biscuit".
 	
@@ -42,4 +42,4 @@ And finally a little dollop of perversity from a later chapter:
 		if player consents, say "[line break]You were getting close to a breakthrough, you know.[line break]";
 		otherwise stop the action.
 	
-	Understand "help" as a mistake ("You're doing fine! Just keep at what you're doing now.").
+	Understand "help" as a mistake ("You're doing fine! Just keep at what you're doing now.").

resources/Documentation/Examples/Odin.txt

@@ -2,7 +2,7 @@
 (You see nothing special... message replaced; Odin)
 Replacing "You see nothing special..." with a different default message for looking at something nondescript.
 
-In recent years there has been a strong trend towards providing unique descriptions for all implemented objects. Often this is a good idea, but there are also contexts in which we may want to discourage the player from looking too closely at some things and concentrate his attention on just a few interesting ones.
+In recent years there has been a strong trend towards providing unique descriptions for all implemented objects. Often this is a good idea, but there are also contexts in which we may want to discourage the player from looking too closely at some things and concentrate their attention on just a few interesting ones.
 
 The trick here is that leaving items completely undescribed leads to rather dull exchanges like this:
 
@@ -27,4 +27,4 @@ Because the description is attached to a whole kind ("thing"), it is really a bl
 	
 	{**}The infant is a man in the basket. The description of the infant is "So strong and fat that you wonder whether one of your fellow gods is acquainted with the mistress of the house-- but it's no concern of yours, of course."
 	
-	Test me with "x table / x chair / x infant".
+	Test me with "x table / x chair / x infant".

resources/Documentation/Examples/Oyster.txt

@@ -2,7 +2,7 @@
 (INVENTORY handling of properties made more flexible; Oyster Wide Shut)
 Replacing Inform's default printing of properties such as "(closed)", "(open and providing light)", etc., with our own, more flexible variation.
 
-As we've seen in earlier examples such as "Equipment List", it is possible to vary the way Inform creates inventory listings in general (to create lists that look more like paragraphs of prose, lists divided between what the player is wearing and what he isn't, and so on). We can also use activities to alter the printing of specific objects' names and contents, as with the "omit contents in listing" feature after printing the name of something.
+As we've seen in earlier examples such as "Equipment List", it is possible to vary the way Inform creates inventory listings in general (to create lists that look more like paragraphs of prose, lists divided between what the player is wearing and what they aren't, and so on). We can also use activities to alter the printing of specific objects' names and contents, as with the "omit contents in listing" feature after printing the name of something.
 
 We may find, however, that we would like a great deal more control over Inform's printing of inventory details, not just as a special effect for a few items, but throughout the game.
 
@@ -69,14 +69,14 @@ Now we're free to meddle. Let's give the player a bunch of possessions that will
 	
 	The player carries an oyster. The oyster contains a pearl. The oyster is openable.
 
-Now suppose that we don't want the oyster to say "closed" when it's closed. Instead, we'd like it to say "clamped shut". As this is the only property the oyster will ever have, we can simply override his whole property-aggregation rulebook:
+Now suppose that we don't want the oyster to say "closed" when it's closed. Instead, we'd like it to say "clamped shut". As this is the only property the oyster will ever have, we can simply override its whole property-aggregation rulebook:
 
 	{**}A property-aggregation rule for the oyster:
 		if the oyster is closed:
 			say " (clamped shut)";
 		rule succeeds.
 
-That's fine for the oyster because "clamped shut" is the only property he'll ever have. What if we'd like instead just to revise the way the sack (and only the sack) gets described as providing light?
+That's fine for the oyster because "clamped shut" is the only property it'll ever have. What if we'd like instead just to revise the way the sack (and only the sack) gets described as providing light?
 
 	{**}The sacklight rule is listed after the mention lit objects rule in the property-aggregation rules.
 
@@ -87,7 +87,7 @@ That's fine for the oyster because "clamped shut" is the only property he'll eve
 
 Now the flashlight (and any other regular light sources we might add to the game) will be described as "providing light", but the sack will only be said to be gently glowing -- a bit more appropriate for its rather fainter gleam.
 
-We might also wish to add a systematic feature across the board to include a new property in the inventory list? Let's say the player can enchant his possessions, and enchanted possessions should thereafter be listed accordingly:
+We might also wish to add a systematic feature across the board to include a new property in the inventory list? Let's say the player can enchant their possessions, and enchanted possessions should thereafter be listed accordingly:
 
 	{**}A thing can be magical or non-magical. A thing is usually non-magical. 
 

resources/Documentation/Examples/Paddington.txt

@@ -2,7 +2,7 @@
 (CUT [something] WITH [something] command--Soft objects able to be cut open; Paddington)
 A CUT [something] WITH [something] command which acts differently on different types of objects.
 
-Suppose we intend a game in which the player needs to cut things open on a regular basis. We'll want to check whether he has the proper tools handy, and deal graciously with commands such as CUT [something] when no tool is specified. So:
+Suppose we intend a game in which the player needs to cut things open on a regular basis. We'll want to check whether they have the proper tools handy, and deal graciously with commands such as CUT [something] when no tool is specified. So:
 
 	{*}"Paddington"
 
@@ -70,4 +70,4 @@ Here is a final nicety to get rid of the "which is closed" statement on our clos
 	{**}After printing the name of a closed unopenable container:
 		omit contents in listing.
 	
-	Test me with "cut quilt with bear / cut quilt with switchblade / examine quilt / cut bear with switchblade / again / examine bear / cut head with switchblade / get diamonds / mourn loss of innocence".
+	Test me with "cut quilt with bear / cut quilt with switchblade / examine quilt / cut bear with switchblade / again / examine bear / cut head with switchblade / get diamonds / mourn loss of innocence".

resources/Documentation/Examples/Pedro.txt

@@ -2,7 +2,7 @@
 (Command prompt changing to reflect state of combat; Don Pedro's Revenge)
 Combat scenario in which the player's footing and position changes from move to move, and the command prompt also changes to reflect that.
 
-Suppose our game features a detailed simulated combat between the player character and his opponent. He might have several weapons available, and several types of attack available; and at any given time he might be perched up in the rigging of his ship, standing on the open deck, or boxed in between some barrels. His options will vary depending on his position, and obviously it would detract from the pacing to make the player keep LOOKing in the middle of combat in order to remind himself where he is. Instead, we'll roll this information into the command prompt:
+Suppose our game features a detailed simulated combat between the player character and an opponent. The player character might have several weapons available, and several types of attack available; and at any given time they might be perched up in the rigging of his ship, standing on the open deck, or boxed in between some barrels. Their options will vary depending on their position, and obviously it would detract from the pacing to make them keep LOOKing in the middle of combat for a reminder of where they are. Instead, we'll roll this information into the command prompt:
 
 	{*}"Don Pedro's Revenge"
 	
@@ -59,4 +59,4 @@ Suppose our game features a detailed simulated combat between the player charact
 		
 	Test me with "advance / jump / advance / retreat / jump / retreat / retreat / advance".
 		
-Of course, this won't be much fun until we also provide the player with a few weapons, some more fighting maneuvers, and, most of all, a Don Pedro to defeat.
+Of course, this won't be much fun until we also provide the player with a few weapons, some more fighting maneuvers, and, most of all, a Don Pedro to defeat.

resources/Documentation/Examples/Photomap.txt

@@ -1,8 +1,8 @@
 * Adjacent rooms and routes through the map
-(Rooms player is forced to visit in order--Map rearranged as player wanders so he finds rooms in order; All Roads Lead to Mars)
+(Rooms player is forced to visit in order--Map rearranged as player wanders so they find rooms in order; All Roads Lead to Mars)
 Layout where the player is allowed to wander any direction he likes, and the map will arrange itself in order so that he finds the correct "next" location.
 
-Suppose we want to allow the player to wander freely in any direction, but ourselves maintain control over the order in which he encounters the rooms. This sort of effect emphasizes the order of the story-telling over any kind of rigorous simulation of space; on multiple play-throughs, the player might not find all the same rooms in the same locations.
+Suppose we want to allow the player to wander freely in any direction, but ourselves maintain control over the order in which they encounter the rooms. This sort of effect emphasizes the order of the story-telling over any kind of rigorous simulation of space; on multiple play-throughs, the player might not find all the same rooms in the same locations.
 
 	{*}"All Roads Lead to Mars"
 
@@ -21,4 +21,4 @@ Suppose we want to allow the player to wander freely in any direction, but ourse
 	
 	Test me with "n / s / e / e".
 	
-If we wanted still to be able to find routes between places, we could define a relationship of connection between rooms, which we would add to as we went along.
+If we wanted still to be able to find routes between places, we could define a relationship of connection between rooms, which we would add to as we went along.

resources/Documentation/Examples/Pine1.txt

@@ -2,7 +2,7 @@
 (Pine: 1. Waking the Princess--Sleeping person who can be woken in various ways)
 Pine: Using a scene to watch for the solution of a puzzle, however arrived-at by the player.
 
-Because scene rules are checked every turn, they can be useful for designing puzzles which have multiple solutions. Instead of deciding the puzzle is "solved" when the player does a certain action, we set up a scene that checks to see whether the player has achieved a certain outcome -- however he accomplished it.
+Because scene rules are checked every turn, they can be useful for designing puzzles which have multiple solutions. Instead of deciding the puzzle is "solved" when the player does a certain action, we set up a scene that checks to see whether the player has achieved a certain outcome -- however they accomplished it.
 
 For instance, in this scenario, we're waiting for Sleeping Beauty to wake up, and it doesn't much matter how...
 
@@ -39,4 +39,4 @@ For instance, in this scenario, we're waiting for Sleeping Beauty to wake up, an
 
 	The player carries a jug of water. Understand "pour [something] on [something]" or "splash [something] at/on [something]" as throwing it at.
 	
-	Test me with "x beauty / wake beauty / pour water on beauty".
+	Test me with "x beauty / wake beauty / pour water on beauty".

resources/Documentation/Examples/Pine2.txt

@@ -87,4 +87,4 @@ After we've generated any spontaneous conversation, we return her to her regular
 	
 	Test me with "x beauty / wake beauty / pour water on beauty / ask beauty about sleep / z / ask beauty about marriage".
 
-Now we have a scenario in which the player can ask her some questions out of order if he really wants to, but the scene will not end until the basic conversation topics have been exhausted. If we wanted to add some other chit-chat, not as part of the main conversation strand, but by way of optional enrichment, we might make a second conversation table and record alternative outcomes in it.
+Now we have a scenario in which the player can ask her some questions out of order if they really want to, but the scene will not end until the basic conversation topics have been exhausted. If we wanted to add some other chit-chat, not as part of the main conversation strand, but by way of optional enrichment, we might make a second conversation table and record alternative outcomes in it.

resources/Documentation/Examples/Pine3.txt

@@ -93,7 +93,7 @@ So far we haven't much of a chance to affect matters and make them better. Suppo
 
 	A fact is a kind of thing. The family circumstances is a fact. A fact can be known or unknown. A fact can be current or past.
 
-Once known, a fact remains known permanently -- this could be useful if we wanted to make some rules about how Beauty acts when she knows different information. By contrast, a fact is only "current" if it is the last thing discussed. Since a player can mention a fact over and over, he can make it "current" again and again, and thus reactivate the flashback.
+Once known, a fact remains known permanently -- this could be useful if we wanted to make some rules about how Beauty acts when she knows different information. By contrast, a fact is only "current" if it is the last thing discussed. Since a player can mention a fact over and over, they can make it "current" again and again, and thus reactivate the flashback.
 
 	{**}Table of Flashback Material
 	topic	reply
@@ -164,4 +164,4 @@ And the following is the same as in the Space Patrol example as well: we need a
 		
 	Test me with "x beauty / wake beauty / pour water on beauty / ask beauty about sleep / tell beauty about poverty / smell pigs / x mother / x letter / kiss mother / ask beauty about marriage / z / z".
 		
-Because we haven't changed the endings of the "Marriage Proposal" scene, there is still only one way for this scenario to work out; but at least now the player has the opportunity to alter Beauty's attitude a bit (or not) before the game is done.
+Because we haven't changed the endings of the "Marriage Proposal" scene, there is still only one way for this scenario to work out; but at least now the player has the opportunity to alter Beauty's attitude a bit (or not) before the game is done.

resources/Documentation/Examples/PizzaPrince.txt

@@ -1,10 +1,10 @@
 * Implicitly taking something
 (Near-infinite supply of pizza; Pizza Prince)
-Providing a pizza buffet from which the player can take as many pieces as he wants.
+Providing a pizza buffet from which the player can take as many pieces as they want.
 
-Suppose we want the player to have a pizza buffet from which he can take a number of slices. But we don't want to actually put the slices there in front of him, because "you can see 17 slices of pizza here" is not the descriptive effect we want, and because we want to pretend, at least, that the pizza supply is nearly infinite. In fact, we're going to replenish the supply by allowing eaten slices to return to the buffet table (safer in IF than in real life).
+Suppose we want the player to have a pizza buffet from which they can take a number of slices. But we don't want to actually put the slices there in front of them, because "you can see 17 slices of pizza here" is not the descriptive effect we want, and because we want to pretend, at least, that the pizza supply is nearly infinite. In fact, we're going to replenish the supply by allowing eaten slices to return to the buffet table (safer in IF than in real life).
 
-To do this, we create one object to stand in for the pizza supply, but whenever the player tries to take it, we give him a different "pizza slice" object instead. Thus:
+To do this, we create one object to stand in for the pizza supply, but whenever the player tries to take it, we give them a different "pizza slice" object instead. Thus:
 
 	{*}"Pizza Prince"
 	
@@ -21,11 +21,11 @@ Now we introduce our actual pizza slices, which are retained in a container out
 
 	{**}A pizza slice is a kind of thing. 10 pizza slices are in Pizza Limbo. A pizza slice is always edible. [After a fashion, anyway.]
 
-In this example we've set that supply to be artificially small, to make it easier to test what happens when the player reaches the limit; but we could provide many more slices to start with in Pizza Limbo, and the aim in practice would be to pick a number high enough (such as 50 or 100) that the average player will get bored of TAKE PIZZA long before he reaches the limit. 
+In this example we've set that supply to be artificially small, to make it easier to test what happens when the player reaches the limit; but we could provide many more slices to start with in Pizza Limbo, and the aim in practice would be to pick a number high enough (such as 50 or 100) that the average player will get bored of TAKE PIZZA long before they reach the limit. 
 
 The main thing to be aware of is that objects consume memory in the game file, so creating a large number of pizza slices might bulk the game out. This is more of a concern if we're compiling for the Z-machine than if we're compiling for Glulx.
 
-Whenever the player tries to take the selection, we want him to wind up holding an individual slice instead; but of course we need to check and make sure that he hasn't exhausted the pizza slice supply. 
+Whenever the player tries to take the selection, we want them to wind up holding an individual slice instead; but of course we need to check and make sure that they haven't exhausted the pizza slice supply. 
 
 	{**}Instead of taking the pizza selection:
 		let chosen slice be a random pizza slice in Pizza Limbo;
@@ -60,4 +60,4 @@ For tidiness, we should probably also return the consumed pizza slices to Pizza
 		move the noun to Pizza Limbo;
 		continue the action. 
 	
-	Test me with "i / get pizza / g / i / get pizza / drop pizza / look / get pizza / g / look / eat pizza / g / g / g / g / get pizza / g / g / g / g / g / g / g / g / g / g / g / g / i / eat pizza / take pizza / g".
+	Test me with "i / get pizza / g / i / get pizza / drop pizza / look / get pizza / g / look / eat pizza / g / g / g / g / get pizza / g / g / g / g / g / g / g / g / g / g / g / g / i / eat pizza / take pizza / g".

resources/Documentation/Examples/Planks.txt

@@ -1,6 +1,6 @@
 ** Going by, going through, going with
 (Plank bridge breaks on being crossed when the player is carrying something; One Short Plank)
-A plank bridge which breaks if the player is carrying something when he goes across it. Pushing anything over the bridge is forbidden outright.
+A plank bridge which breaks if the player is carrying something when they cross it. Pushing anything over the bridge is forbidden outright.
 
 	{*}"One Short Plank"
 
@@ -23,4 +23,4 @@ But indeed, why stop there?
 	Before going through the plank with something:
 		say "Surely you jest." instead.
 		
-	Test me with "w / e / w / push ball e / e / get feather / w".
+	Test me with "w / e / w / push ball e / e / get feather / w".

resources/Documentation/Examples/Potato.txt

@@ -2,7 +2,7 @@
 (Disambiguating based on properties; Masochism Deli)
 Multiple potatoes, with rules to make the player drop the hot potato first and pick it up last.
 
-Here the player has several potatoes; we would like to make him more likely to drop the hot one, and more likely to pick up the cold one, all else being equal. At the same time, we want to phrase our rules so that they don't make the player try to take something he's already holding, or drop something he isn't. 
+Here the player has several potatoes; we would like to make them more likely to drop the hot one, and more likely to pick up the cold one, all else being equal. At the same time, we want to phrase our rules so that they don't make the player try to take something they're already holding, or drop something they're not.
 
 So:
 
@@ -27,4 +27,4 @@ So:
 		
 	When play begins: now a random potato is hot.
 
-	Test me with "inventory / drop potato / g / g / get potato / g / i / get potato".
+	Test me with "inventory / drop potato / g / g / get potato / g / i / get potato".

resources/Documentation/Examples/Prague.txt

@@ -1,8 +1,8 @@
 * More general linkages
-(Scenes which change as the player explores his inventory--Hurrying the player on a specific task; The Prague Job)
-Scenes used to provide pacing while the player goes through his possessions.
+(Scenes which change as the player explores their inventory--Hurrying the player on a specific task; The Prague Job)
+Scenes used to provide pacing while the player goes through their possessions.
 
-Suppose we want to remind the player that he doesn't have all the time in the world, by starting to nag him when he's nearly, but not entirely, done going over his inventory in preparation for a job.
+Suppose we want to remind the player that they don't have all the time in the world, by starting to nag them when they're nearly, but not entirely, done going over their inventory in preparation for a job.
 
 	{*}"The Prague Job"
 
@@ -34,4 +34,4 @@ Suppose we want to remind the player that he doesn't have all the time in the wo
 
 	Mission is a scene. Mission begins when the player is in the Long Hallway. When Mission begins: end the story saying "The game is afoot"
 
-	Test me with "i / x lockpick / out / x bomb / out / x hook / x gloves / out".
+	Test me with "i / x lockpick / out / x bomb / out / x hook / x gloves / out".

resources/Documentation/Examples/Proposal.txt

@@ -1,8 +1,8 @@
 ** Conditions and questions
 (Asking the player a Yes/No question; Proposal)
-Asking the player a yes/no question which he must answer, and another which he may answer or not as he chooses.
+Asking the player a yes/no question which they must answer, and another which they may answer or not as they choose.
 
-Suppose we want to ask the player a question where he might say yes or no in response. There are two possible forms of this: the modal question where the player must pick one to proceed, and the non-modal question where he might also type other verbs.
+Suppose we want to ask the player a question where they might say yes or no in response. There are two possible forms of this: the modal question where the player must pick one to proceed, and the non-modal question where they might also type other verbs.
 
 	{*}"Proposal"
 
@@ -77,4 +77,4 @@ And since the player might SAY YES TO SPRUCE, we had better reroute the relevant
 	Test me with "z / z / z / yes".
 
 	Test more with "z / z / z / no".
- 
+ 

resources/Documentation/Examples/PuffOfOrangeSmoke.txt

@@ -40,7 +40,7 @@ The trick is, though, that >MOVE LYDIA will only be understood if there is somet
 
 	{**}The worldview is a privately-named backdrop. It is everywhere. The spirit-world is a privately-named transparent closed unopenable container. It is part of the worldview.
 
-	Definition: a person is dead if he is in the spirit-world.
+	Definition: a person is dead if they are in the spirit-world.
 
 It's also possible that the player will type something like >X LYDIA when Lydia's corpse is not in view, so we should have an appropriate answer to that as well:
 
@@ -61,4 +61,4 @@ And finally a trick borrowed from the chapter on understanding, so that we can r
 
 	{**}Understand "corpse" as a body when the item described is not part of a person.
 
-	Test me with "x body / x lydia's body / touch lydia's body / x corpse / kill lydia / look / x lydia's body / x lydia's corpse / x corpse / x lydia / touch lydia / lydia, hello / n / x lydia / touch lydia / lydia, hello". 
+	Test me with "x body / x lydia's body / touch lydia's body / x corpse / kill lydia / look / x lydia's body / x lydia's corpse / x corpse / x lydia / touch lydia / lydia, hello / n / x lydia / touch lydia / lydia, hello". 

resources/Documentation/Examples/QuizShow.txt

@@ -27,7 +27,7 @@ Because of the "...when" part of this line, random text is only treated as an an
 			say "Wrong!"; 
 		now answer mode is false. 
 
-This next rule allows a player to do something other than answer the question, but then makes him wait for another question before answering.
+This next rule allows a player to do something other than answer the question, but then makes them wait for another question before answering.
 
 	{**}Before doing anything other than guessing: 
 		if answer mode is true:
@@ -53,4 +53,4 @@ This next rule allows a player to do something other than answer the question, b
 
 	Test me with "1845 / z / z / 1787 / 1792 / z / 1845 / g".
 	
-Note that the situation will become a little more complicated if we have two or more identical topics in our trivia list; in that case, we would need to loop through the Table of Dates of Statehood explicitly, and only mark the player wrong if none of the lines were found to match. (See the chapter on Tables for many more ways to manipulate table behavior.)
+Note that the situation will become a little more complicated if we have two or more identical topics in our trivia list; in that case, we would need to loop through the Table of Dates of Statehood explicitly, and only mark the player wrong if none of the lines were found to match. (See the chapter on Tables for many more ways to manipulate table behavior.)

resources/Documentation/Examples/RegionBoundary.txt

@@ -2,7 +2,7 @@
 (Regions, traveling from--Message on leaving a region; Veronica)
 An effect that occurs only when the player leaves a region entirely.
 
-Suppose that we want to have something happen when the player leaves a region we've defined. "Instead of going from (the region)..." will not suffice for this, because this rule will be invoked every time the player successfully leaves a room within the region, whether or not he is going to a room that is also in the same region.
+Suppose that we want to have something happen when the player leaves a region we've defined. "Instead of going from (the region)..." will not suffice for this, because this rule will be invoked every time the player successfully leaves a room within the region, whether or not they are going to a room that is also in the same region.
 
 Instead we need a rule that is a bit more specific, like this:
 
@@ -21,4 +21,4 @@ Instead we need a rule that is a bit more specific, like this:
 	Instead of going from Neptune to a room which is not in Neptune:
 		say "It's a bad time to leave Neptune."
 
-	Test me with "s / w / e".
+	Test me with "s / w / e".

resources/Documentation/Examples/Robo.txt

@@ -1,10 +1,10 @@
 * Building lists
 (Robo: 1. Robot that stores only one program at a time--Robot who records, then replays, the player's actions)
-A robot which watches and records the player's actions, then tries to repeat them back in the same order when he is switched into play-back mode.
+A robot which watches and records the player's actions, then tries to repeat them back in the same order when it is switched into play-back mode.
 
 	{*}"Robo"
 	
-	The Experimentation Chamber is a room. Robo is a man in the Experimentation Chamber. "Robo, your prototype tin companion, stands awkwardly beside you. In the middle of his chest is a red enamel button[if the red button is switched on], currently depressed[otherwise], currently un-depressed[end if]."
+	The Experimentation Chamber is a room. Robo is a person in the Experimentation Chamber. "Robo, your prototype tin companion, stands awkwardly beside you. In the middle of its chest is a red enamel button[if the red button is switched on], currently depressed[otherwise], currently un-depressed[end if]."
 
 	The red button is a device. It is part of Robo. Instead of pushing the red button: if the red button is switched off, try switching on the red button; otherwise try switching off the red button.
 
@@ -22,7 +22,7 @@ A robot which watches and records the player's actions, then tries to repeat the
 		now the actor is Robo;
 		add the current action to the current instruction set;
 		now the actor is the player;
-		say "Robo watches you [the current action][one of], his yellow eyes lamp-like and observant[or]. In his metal head, gears whirr[or], his brushed-copper handlebar moustaches twitching[or] impassively[at random].";
+		say "Robo watches you [the current action][one of], its yellow eyes lamp-like and observant[or]. In its metal head, gears whirr[or], its brushed-copper handlebar moustaches twitching[or] impassively[at random].";
 		continue the action.
 	
 	Every turn when Robo is not watching:
@@ -37,12 +37,12 @@ A robot which watches and records the player's actions, then tries to repeat the
 	The red block and the blue cylinder are things in the Experimentation Chamber. The counter is a supporter in the Experimentation Chamber. The counter is scenery.
 
 	Report Robo examining Robo:
-		say "Robo examines each of his hands in turn, then each of his legs (bending over mostly double in the middle to do this)." instead.
+		say "Robo examines each of its hands in turn, then each of his legs (bending over mostly double in the middle to do this)." instead.
 	
 	Report Robo examining the player:
-		say "Robo stares at you, unblinkingly, for several seconds together[if a random chance of 1 in 7 succeeds]. His left moustache-bar twitches infinitesimally upward[end if]." instead.	
+		say "Robo stares at you, unblinkingly, for several seconds together[if a random chance of 1 in 7 succeeds]. Its left moustache-bar twitches infinitesimally upward[end if]." instead.	
 	
 	Report Robo taking the cylinder:
-		say "[one of][Robo] needs several attempts to get his metal fingers around [the cylinder] -- they are not designed for grasping small objects elegantly. But at last he succeeds[or]Once again, Robo struggles a bit before picking up [the cylinder][stopping]." instead.
+		say "[one of][Robo] needs several attempts to get its metal fingers around [the cylinder] -- they are not designed for grasping small objects elegantly. But at last it succeeds[or]Once again, Robo struggles a bit before picking up [the cylinder][stopping]." instead.
 	
-	Test me with "z / take cylinder / take block / put cylinder on counter / put block on counter / x robo / x me / get block / drop block / press red button / z / z / z / z / z / z / z / z / z / z".
+	Test me with "z / take cylinder / take block / put cylinder on counter / put block on counter / x robo / x me / get block / drop block / press red button / z / z / z / z / z / z / z / z / z / z".

resources/Documentation/Examples/Robo2.txt

@@ -1,6 +1,6 @@
 *** Accessing entries in a list
 (Robo: 2. Robot able to store and perform fifteen named scripts--Robot who tracks up to fifteen separate command scripts)
-A robot which watches and records the player's actions, then tries to repeat them back in the same order when he is switched into play-back mode.
+A robot which watches and records the player's actions, then tries to repeat them back in the same order when it is switched into play-back mode.
 
 We have seen how we can make a robot that watches the player, then plays back the same actions again. A slightly more adventurous implementation would be to let the player create a whole series of named scripts which the robot will run on command.
 
@@ -21,7 +21,7 @@ To do this, we'll need each program to have a command that sets it off (stored a
 
 	The current instruction name is some text that varies. The current instruction set is a list of stored actions that varies.
 
-Now, we want to let Robo learn new programs; for this purpose, we'll emulate the code from our previous implementation, so that Robo watches what the player does and stores those actions in his script:
+Now, we want to let Robo learn new programs; for this purpose, we'll emulate the code from our previous implementation, so that Robo watches what the player does and stores those actions in its script:
 
 	{**}Section 2 - Learning New Programs
 	
@@ -45,10 +45,10 @@ Now, we want to let Robo learn new programs; for this purpose, we'll emulate the
 		now the actor is Robo;
 		add the current action to the current instruction set;
 		now the actor is the player;
-		say "Robo watches you [the current action][one of], his yellow eyes lamp-like and observant[or]. In his metal head, gears whirr[or], his brushed-copper handlebar moustaches twitching[or] impassively[at random].";
+		say "Robo watches you [the current action][one of], its yellow eyes lamp-like and observant[or]. In its metal head, gears whirr[or], its brushed-copper handlebar moustaches twitching[or] impassively[at random].";
 		continue the action. 
 
-Of course, we also need to be able to switch learning mode off, and store any script learned this way. We'll also use the same STOP command to make Robo terminate a program he's in the middle of running.
+Of course, we also need to be able to switch learning mode off, and store any script learned this way. We'll also use the same STOP command to make Robo terminate a program it's in the middle of running.
 
 	{**}Section 3 - Returning to Standby Mode
 
@@ -75,7 +75,7 @@ Of course, we also need to be able to switch learning mode off, and store any sc
 	Report Robo stopping:
 		say "Robo is now standing by."
 
-Next, we need to be able to play these programs back again. We'll give Robo a "current program" to store which program he's currently working on, and a number called "stage" which will record where he is in the script. Our previous implementation simply had Robo erase entries from his script list as he performed them, but this time we would like Robo to be able to remember and rerun the same scripts over and over, so we need something a little more subtle.
+Next, we need to be able to play these programs back again. We'll give Robo a "current program" to store which program it's currently working on, and a number called "stage" which will record where it is in the script. Our previous implementation simply had Robo erase entries from its script list as it performed them, but this time we would like Robo to be able to remember and rerun the same scripts over and over, so we need something a little more subtle.
 
 	{**}Section 4 - Running Learned Programs
 
@@ -106,7 +106,7 @@ Next, we need to be able to play these programs back again. We'll give Robo a "c
 		try the next step;
 		increment the stage of Robo;
 		if the stage of Robo is greater than the maximum:
-			say "Robo's program ends, and he reverts to stand-by mode.";
+			say "Robo's program ends, and it reverts to stand-by mode.";
 			now Robo is standing by;
 			now the stage of Robo is 1.
 	
@@ -166,13 +166,13 @@ Now we use pretty much the same set-up as before to test Robo's abilities:
 	The red block and the blue cylinder are things in the Experimentation Chamber. The counter is a supporter in the Experimentation Chamber. The counter is scenery.
 
 	Report Robo examining Robo:
-		say "Robo examines each of his hands in turn, then each of his legs (bending over mostly double in the middle to do this)." instead.
+		say "Robo examines each of its hands in turn, then each of its legs (bending over mostly double in the middle to do this)." instead.
 
 	Report Robo examining the player:
-		say "Robo stares at you, unblinkingly, for several seconds together[if a random chance of 1 in 7 succeeds]. His left moustache-bar twitches infinitesimally upward[end if]." instead.
+		say "Robo stares at you, unblinkingly, for several seconds together[if a random chance of 1 in 7 succeeds]. Its left moustache-bar twitches infinitesimally upward[end if]." instead.
 
 	Report Robo taking the cylinder:
-		say "[one of][Robo] needs several attempts to get his metal fingers around [the cylinder] -- they are not designed for grasping small objects elegantly. But at last he succeeds[or]Once again, Robo struggles a bit before picking up [the cylinder][stopping]." instead.
+		say "[one of][Robo] needs several attempts to get its metal fingers around [the cylinder] -- they are not designed for grasping small objects elegantly. But at last it succeeds[or]Once again, Robo struggles a bit before picking up [the cylinder][stopping]." instead.
 
 	Test me with "test chocolate / test vanilla".
 
@@ -195,4 +195,4 @@ We could also have written this so that Robo learns new scripts by accepting the
 		say "'CHECK: [current action] added to script,' says Robo." instead.
 	
 	Unsuccessful attempt by Robo doing something when Robo is watching:
-		say "He does not actually perform the action."
+		say "He does not actually perform the action."

resources/Documentation/Examples/Rope.txt

@@ -198,7 +198,7 @@ Another part of the fun of a rope is that you can drag things from another room:
 
 	Definition: a thing is secondary if it is not the noun.  Definition: a thing is pullable if it is not the noun and it is not the player.
 
-A player who is tied to things should also have some restrictions on his ability to move.
+A player who is tied to things should also have some restrictions on their ability to move.
 
 	{**}Before going a direction (called the way) when the player has something (called the link) which is stuck to something anchored (called the anchor):
 		let the next room be the home of the anchor;
@@ -227,7 +227,7 @@ A player who is tied to things should also have some restrictions on his ability
 			otherwise:
 				say "Your attachments prevent you going any way but [best route from the location to the next room]." instead.
 
-Sometimes, if the player is tied to a movable object, the moved object will move with him.
+Sometimes, if the player is tied to a movable object, the moved object will move with them.
 
 	{**}After going somewhere when the player has something (called the link) which is stuck to something draggable:
 		if the player is not stuck to the link:

resources/Documentation/Examples/Rubies.txt

@@ -1,6 +1,6 @@
 *** Writing and reading tables to external files
 (Scoreboard preserved between games; Rubies)
-A scoreboard that keeps track of the ten highest-scoring players from one playthrough to the next, adding the player's name if he has done well enough.
+A scoreboard that keeps track of the ten highest-scoring players from one playthrough to the next, adding the player's name if they have done well enough.
 
 The trick here is that we need a table with text in order to keep track of the players' names.
 
@@ -97,4 +97,4 @@ And now we introduce a scenario that allows different players to come up with di
 
 	Instead of waiting, end the story finally.
 	
-	Test me with "get ruby / z".
+	Test me with "get ruby / z".

resources/Documentation/Examples/SecondOldest.txt

@@ -4,7 +4,7 @@ Adapting the going action so that something special can happen when going from a
 
 Text in this example is drawn from Will Crowther's original 1976 FORTRAN implementation of ADVENTURE, the founding work of the genre, whose source code was rediscovered by Dennis G. Jerz in 2007. Note the capitals: the program ran on an early computer without lower case lettering. They look a little mimsy now, but picture them glowing green on an old-style cathode ray tube monitor in a darkened room late at night.
 
-The problem alluded to is that the player is forbidden to walk between two dark rooms, so that he must always have light to see by from at least one end of any movement. Writing source text to achieve this is tricky to get right in every case, because the determination of light is hard to do. Here we interleave the necessary rules into the existing "going" action, using a new action variable to record the number of ends which are dark as experienced by the player, which might be 0, 1 or 2:
+The problem alluded to is that the player is forbidden to walk between two dark rooms, so that they must always have light to see by from at least one end of any movement. Writing source text to achieve this is tricky to get right in every case, because the determination of light is hard to do. Here we interleave the necessary rules into the existing "going" action, using a new action variable to record the number of ends which are dark as experienced by the player, which might be 0, 1 or 2:
 
 	{*}"THE SECOND OLDEST PROBLEM"
 	

resources/Documentation/Examples/SlogarsRevenge.txt

@@ -2,7 +2,7 @@
 (LOCK and UNLOCK with altered carrying requirements; Slogar's Revenge)
 Creating an amulet of tumblers that can be used to lock and unlock things even when it is worn, overriding the usual requirement that keys be carried.
 
-Under most circumstances, locking and unlocking require the player to be carrying the key he uses to unlock something. This makes sense -- unless the key is on a keychain, or on a chain around his neck, for instance. So here we explore one way to circumstantially override the carrying requirements, while still making sure that the player cannot unlock the door if the unlocking tool is nowhere in sight. 
+Under most circumstances, locking and unlocking require the player to be carrying the key they use to unlock something. This makes sense -- unless the key is on a keychain, or on a chain around their neck, for instance. So here we explore one way to circumstantially override the carrying requirements, while still making sure that the player cannot unlock the door if the unlocking tool is nowhere in sight. 
 
 In essence, we are rewriting the carrying requirements rule with a different one of our own devising, and swapping it in only at those moments when it is correct to do so.
 
@@ -36,4 +36,4 @@ We can now replace the usual behavior of the carrying requirements rule (to chec
 
 	Test me with "unlock disturbing door with amulet / open door / west / remove amulet / close door / lock disturbing door with amulet / drop amulet / unlock disturbing door with amulet".
 	
-For a more systematic handling of the keychain problem (and a number of other refinements to the behavior of doors), see the Locksmith extension included with Inform.
+For a more systematic handling of the keychain problem (and a number of other refinements to the behavior of doors), see the Locksmith extension included with Inform.

resources/Documentation/Examples/Slouching.txt

@@ -4,7 +4,7 @@ A system of postures allowing the player and other characters to sit, stand, or
 
 Suppose we want to let the player explicitly sit, stand, or lie down on different enterable objects. (Normally Inform treats all these actions as entering, but there may be cases where we want to distinguish between the player sitting on a chair and the player standing on it.)
 
-Our implementation gives each kind of enterable a range of allowed postures, and one preferred posture. If the player enters the supporter or container without specifying a posture (as in ENTER CHAIR), he will be put in the preferred posture. If he explicitly says, e.g., STAND ON CHAIR, he will be put in the standing position as long as standing is a posture that suits the chair.
+Our implementation gives each kind of enterable a range of allowed postures, and one preferred posture. If the player enters the supporter or container without specifying a posture (as in ENTER CHAIR), they will be put in the preferred posture. If they explicitly say, e.g., STAND ON CHAIR, they will be put in the standing position as long as standing is a posture that suits the chair.
 
 	{*} "Slouching"
 

resources/Documentation/Examples/Solitude.txt

@@ -36,52 +36,52 @@ The rationale for asking the question this way, and not another, is that novices
 	
 	The novice suggestion rules is a rulebook.
 
-	A novice suggestion rule (this is the suggestion that he look rule):
+	A novice suggestion rule (this is the suggestion that they look rule):
 		if not looking and not going, say "  [bold type]look[roman type]".
 
-	A novice suggestion rule (this is the suggestion that he check inventory rule): 
+	A novice suggestion rule (this is the suggestion that they check inventory rule): 
 		if the player carries something and we are not taking inventory, say "  [bold type]inventory[roman type] (I)".
 
-	A novice suggestion rule (this is the suggestion that he put things on rule):
+	A novice suggestion rule (this is the suggestion that they put things on rule):
 		if the player carries something and a free-standing supporter is relevant, say "  [bold type]put[roman type] something [bold type]on[roman type] [the list of relevant supporters]".
 
-	A novice suggestion rule (this is the suggestion that he take things rule): 
+	A novice suggestion rule (this is the suggestion that they take things rule): 
 		if a gettable thing is relevant, say "  [bold type]take[roman type] [the list of gettable relevant things]".
 	
-	A novice suggestion rule (this is the suggestion that he examine things rule):
+	A novice suggestion rule (this is the suggestion that they examine things rule):
 		if an unexamined thing is relevant, say "  [bold type]examine[roman type] (X) [the list of unexamined relevant things]".
 
-	A novice suggestion rule (this is the suggestion that he enter things rule):
+	A novice suggestion rule (this is the suggestion that they enter things rule):
 		if a relevant thing is worth entering, say "  [bold type]enter[roman type] [the list of worth entering relevant things], or [bold type]get out[roman type]".
 
-	A novice suggestion rule (this is the suggestion that he open things rule):
+	A novice suggestion rule (this is the suggestion that they open things rule):
 		if an unlocked openable thing is relevant, say "  [bold type]open[roman type] or [bold type]close[roman type] [the list of unlocked openable relevant things]".
 
-	A novice suggestion rule (this is the suggestion that he lock things rule):
+	A novice suggestion rule (this is the suggestion that they lock things rule):
 		if a closed lockable thing is relevant, say "  [bold type]lock[roman type] or [bold type]unlock[roman type] [the list of closed lockable relevant things]".
 	
-	A novice suggestion rule (this is the suggestion that he eat things rule):
+	A novice suggestion rule (this is the suggestion that they eat things rule):
 		if the player carries an edible relevant thing, say "  [bold type]eat[roman type] [the list of edible relevant things carried by the player]".
 
-	A novice suggestion rule (this is the suggestion that he wear things rule):
+	A novice suggestion rule (this is the suggestion that they wear things rule):
 		if the player carries a wearable relevant thing, say "  [bold type]wear[roman type] [the list of wearable relevant things carried by the player]".
 
-	A novice suggestion rule (this is the suggestion that he turn things on rule):
+	A novice suggestion rule (this is the suggestion that they turn things on rule):
 		if a device is relevant, say "  [bold type]turn on[roman type] or [bold type]turn off[roman type] [the list of relevant devices]".
 
-	A novice suggestion rule (this is the suggestion that he go places rule):
+	A novice suggestion rule (this is the suggestion that they go places rule):
 		if a room is adjacent, say "  [bold type]go[roman type][exit list][if in darkness] or try other directions in the dark[otherwise]".
 
-	A novice suggestion rule (this is the suggestion that he enter doors rule):
+	A novice suggestion rule (this is the suggestion that they enter doors rule):
 		if an open door is relevant, say "  [bold type]go through[roman type] [the list of relevant open doors]".
 	
-	A novice suggestion rule (this is the suggestion that he interact with people rule):
+	A novice suggestion rule (this is the suggestion that they interact with people rule):
 		if another person is relevant, say "  [bold type]kiss[roman type] or [bold type]wake[roman type] [the list of relevant other people][if the player carries something], or [bold type]give[roman type] things [bold type]to[roman type] someone[end if]".
 	
-	A novice suggestion rule (this is the suggestion that he ask for help rule):
+	A novice suggestion rule (this is the suggestion that they ask for help rule):
 		say "  [bold type]help[roman type] to see a more complete set of instructions".
 		
-	A novice suggestion rule (this is the suggestion that he turn off help rule):
+	A novice suggestion rule (this is the suggestion that they turn off help rule):
 		say "  [bold type]novice mode off[roman type] to turn off this guidance".
 
 	Last novice suggestion rule:

resources/Documentation/Examples/SwigmoreU.txt

@@ -2,7 +2,7 @@
 (DROP modified to distinguish between large and small enterable supporters--Stool, from which dropped objects fall to the floor; Swigmore U.)
 Adding a new kind of supporter called a perch, where everything dropped lands on the floor.
 
-Inform's default assumption is that if a player on an enterable object drops something, the dropped article winds up beside him on the same supporter or in the same container. This makes lots of sense for a dais, say, or a king-sized bed. It's a little less sensible if the enterable supporter in question is a bar stool or the like. So suppose we want to add a new kind of supporter called a perch, where everything dropped lands on the floor.
+Inform's default assumption is that if a player on an enterable object drops something, the dropped article winds up beside them on the same supporter or in the same container. This makes lots of sense for a dais, say, or a king-sized bed. It's a little less sensible if the enterable supporter in question is a bar stool or the like. So suppose we want to add a new kind of supporter called a perch, where everything dropped lands on the floor.
 
 There are actually several ways of implementing this, but one of them is to reach right into the drop action and replace the "standard dropping rule" with a different one of our own invention -- like this:
 

resources/Documentation/Examples/TakeCoffin.txt

@@ -2,7 +2,7 @@
 (Check rules modified for taking something we're inside--Automatically leaving an object before trying to take it; Get Axe)
 Changing the check rules to try automatically leaving a container before attempting to take it. (And arranging things so that other people will do likewise.)
 
-We could now re-write the check rules so that any time someone (the player or someone else) tries to pick up a container which he is in, he will first get out:
+We could now re-write the check rules so that any time someone (the player or someone else) tries to pick up a container which they're in, they will first get out:
 
 	{*}"GET AXE"
 	
@@ -17,4 +17,4 @@ We could now re-write the check rules so that any time someone (the player or so
 	Persuasion rule for asking Raskolnikov to try doing something: 
 		persuasion succeeds.
 	
-	Test me with "raskolnikov, get coffin".
+	Test me with "raskolnikov, get coffin".

resources/Documentation/Examples/Tamed.txt

@@ -4,7 +4,7 @@ Examples of a container and a supporter that can be entered, as well as nested r
 
 Within a room, we might have containers and supporters that a player can enter. A chair, stool, table, dais, or pedestal would be an enterable supporter (anything we would describe a person as being "on"); a cage, hammock, or booth would be an enterable container (because we would describe the person as being "inside"). 
 
-When the player is in or on something, he is able to see the rest of the contents of the room, but a note such as "(in the hammock)" or "(on the poster bed)" is added to the room title when he looks around.
+When the player is in or on something, they are able to see the rest of the contents of the room, but a note such as "(in the hammock)" or "(on the poster bed)" is added to the room title when they look around.
 
 Here is an example to show off the possibilities:
 
@@ -40,8 +40,8 @@ Now we create our other location:
 
 	{**}Inside from the Center Ring is the Starry Vastness. 
 
-...which handles the case of the player typing >IN. (We will not assume by default that he wants to get into the cage with the lion, this being obviously perilous.) But we also want to make sure that the player who types >ENTER BOOTH winds up in the same place, so we should add:
+...which handles the case of the player typing >IN. (We will not assume by default that they want to get into the cage with the lion, this being obviously perilous.) But we also want to make sure that the player who types >ENTER BOOTH winds up in the same place, so we should add:
 	
 	{**}Instead of entering the magician's booth: try going inside.
 	
-	Test me with "get in cage / open cage / get in cage / z / close cage / out / open cage / get on pedestal / get off / look / enter booth / out".
+	Test me with "get in cage / open cage / get in cage / z / close cage / out / open cage / get on pedestal / get off / look / enter booth / out".

resources/Documentation/Examples/Telephone.txt

@@ -101,7 +101,7 @@ And finally we want to make sure that calling random other numbers produces a se
 	After deciding the scope of the player while the player reaches someone:
 		place the other party of the player in scope, but not its contents.
 
-A note about this scope addition: the player can refer to the other party whenever he has the other person on the phone. He can't, however, see or refer to anything that person might be holding or wearing, thanks to the "but not its contents" option.
+A note about this scope addition: the player can refer to the other party whenever they have the other person on the phone. They can't, however, see or refer to anything that person might be holding or wearing, thanks to the "but not its contents" option.
 
 Furthermore, the player can't actually do anything to that person that requires touching. That's because of the reaching inside rules, which govern whether the player can reach through intervening barriers such as rooms. (See the Advanced Actions chapter for more about changing reachability.) There are two things we might want to be careful about, though. 
 
@@ -159,7 +159,7 @@ This portion supplies a simple method of conversation; but we could substitute s
 
 	Before going a direction in the Guard House, say "And leave your post? The boss would have you flayed. No kidding." instead.
 
-In a game where the player could walk around, we would of course want to add a before rule so that he automatically hung up any phone he was using before leaving the room.
+In a game where the player could walk around, we would of course want to add a before rule so that they automatically hung up any phone they were using before leaving the room.
 
 	{**}The Main Office is a room. The boss is a known woman in the Main Office. A telephone called the red telephone is in the Main Office. Understand "2802" as the red telephone.
 

resources/Documentation/Examples/Tenses.txt

@@ -48,6 +48,6 @@ The past ("if the box was...") and past perfect ("if the box had been...") are e
 
 This is in many respects similar to a rule beginning "After taking the mysterious box for the first time...", but it is superior in most circumstances, for two reasons. 
 
-First, it will respond correctly even if the player has somehow carried the box before without taking it explicitly: for instance, if another character gave him the box, if the box were moved into his inventory as a result of another action, or if the player carried the box at the start of play. Inform begins its reckoning of time when the game begins, so if the box is defined as being open at the outset, "if the box has been open" will always be true.
+First, it will respond correctly even if the player has somehow carried the box before without taking it explicitly: for instance, if another character gave them the box, if the box were moved into their inventory as a result of another action, or if the player carried the box at the start of play. Inform begins its reckoning of time when the game begins, so if the box is defined as being open at the outset, "if the box has been open" will always be true.
 
-Second, "after taking... for the first time" fires only the first time the player attempts to take something. If the player tried to take the box, failed, and then tried again later, the "for the first time..." rule would not fire; our "if the box has not been carried..." rule would.
+Second, "after taking... for the first time" fires only the first time the player attempts to take something. If the player tried to take the box, failed, and then tried again later, the "for the first time..." rule would not fire; our "if the box has not been carried..." rule would.

resources/Documentation/Examples/Throwing.txt

@@ -10,7 +10,7 @@ Suppose we want to expand the function of the existing THROW SOMETHING AT comman
 		check	an actor throwing something at	futile to throw things at inanimate objects rule
 		check	an actor throwing something at	block throwing at rule
 		
-Some of those still look useful. We want to leave the "implicitly remove thrown clothing" rule, for instance -- no fair having the player throw a hat that's on his head. On the other hand, the "futile to throw things at inanimate objects rule" is going to have to go, because that would prevent us from ever being able to complete the throwing command. So let's get rid of that:
+Some of those still look useful. We want to leave the "implicitly remove thrown clothing" rule, for instance -- no fair having the player throw a hat that's on their head. On the other hand, the "futile to throw things at inanimate objects rule" is going to have to go, because that would prevent us from ever being able to complete the throwing command. So let's get rid of that:
 
 	{*}"Kyoto"
 	
@@ -18,7 +18,7 @@ Some of those still look useful. We want to leave the "implicitly remove thrown
 	
 	The futile to throw things at inanimate objects rule is not listed in the check throwing it at rules.
 	
-That "block throwing at" rule also looks sinister: any "block..." rule in the standard actions library is there to print a message telling the player he can't do what he's asked to do.
+That "block throwing at" rule also looks sinister: any "block..." rule in the standard actions library is there to print a message telling the player they can't do what they've asked to do.
 
 But it's not enough to ignore it, the way we did the "futile" rule. Since we are only expanding the command to affect inanimate objects, let's replace the "block throwing at" rule with a different one which will only prevent the player throwing things at people:
 	
@@ -122,4 +122,4 @@ Now for an actual scenario with which to test this:
 
 	Test one with "open screen / throw netsuke at screen / n / get netsuke / close screen / get scroll / throw scroll at screen / throw netsuke at scroll / get netsuke / throw netsuke at shamisen / drop netsuke".
 	
-	Test two with "throw shamisen at netsuke / get all / throw netsuke at screen / get netsuke / throw netsuke at door / s / get netsuke".
+	Test two with "throw shamisen at netsuke / get all / throw netsuke at screen / get netsuke / throw netsuke at door / s / get netsuke".

resources/Documentation/Examples/TicketPlease.txt

@@ -73,7 +73,7 @@ Our choice of understand rules guarantees that "five dollar" will be understood
 	Instead of examining a for sale thing (this is the describe things by price rule):
 		say "[The noun] costs [the price of the noun], payable to [the owner of the noun]."
 	
-The cashbox is a theoretical construct, not something the player will ever encounter in the course of the game. It contains all the money that is available for non-player characters to use in making change. If we wanted, we could give each character his own stash of change, but this would increase the likelihood that any given person would run out of cash to make change with. (And in this example there is only one vendor anyway.)
+The cashbox is a theoretical construct, not something the player will ever encounter in the course of the game. It contains all the money that is available for non-player characters to use in making change. If we wanted, we could give each character their own stash of change, but this would increase the likelihood that any given person would run out of cash to make change with. (And in this example there is only one vendor anyway.)
 
 	{**}The cashbox is a container. The cashbox contains 10 pennies. The cashbox contains 10 nickels.  The cashbox contains 10 dimes.  The cashbox contains 10 quarters.  The cashbox contains 10 dollar bills.  The cashbox contains 10 five-dollar bills.
 
@@ -121,7 +121,7 @@ The cashbox is a theoretical construct, not something the player will ever encou
 		if the player owns the noun,
 			say "Your transaction is now complete, leaving you with [the player's cash]."
 
-We've skipped over defining what makes a denomination the best for a given transaction, so we'd better do that now. Our goal is to avoid ever having the player gratuitously overpay -- he should always offer the smallest amount of money that will meet the price of what he's buying.
+We've skipped over defining what makes a denomination the best for a given transaction, so we'd better do that now. Our goal is to avoid ever having the player gratuitously overpay -- they should always offer the smallest amount of money that will meet the price of what they're buying.
 
 We also assume that all money "enclosed by the buyer" -- that is, somewhere in the buyer's possession -- is available for use. This might not be true in a game where the player could pick up, say, a sealed lucite container with a ten-dollar bill inside; in that case we would have to define our terms more rigorously, perhaps by requiring that the bills be both enclosed and touchable by the buyer. The touchability check adds an extra layer of calculation, however, and since it is not necessary in this example (and probably not in most other cases either), we'll leave it out:
 
@@ -223,4 +223,4 @@ After all that, we should probably give the player a chance to win, as well:
 
 	Test more with "buy times / put all but five-dollar bill in machine / press button / buy gum / buy cards / i / put dollar in machine / g / put quarter in machine / i / d".
 
-In fairness to the Metropolitan Transit Authority, we should admit that most of the ticketing machines in the real New York subway are better than this, and will accept, say, a debit card. But that would be so much less exciting to implement.
+In fairness to the Metropolitan Transit Authority, we should admit that most of the ticketing machines in the real New York subway are better than this, and will accept, say, a debit card. But that would be so much less exciting to implement.

resources/Documentation/Examples/Tilt1.txt

@@ -94,7 +94,7 @@ This next bit is an optional borrowing from the Activities chapter: we want to p
 	
 	{**}Rule for printing room description details of something: do nothing instead. 
 	
-Finally, we want the player to use "draw" and "discard" to manipulate his hand of cards:
+Finally, we want the player to use "draw" and "discard" to manipulate their hand of cards:
 	
 	{**}Section 3 - Drawing and Discarding Actions
 

resources/Documentation/Examples/Timeless.txt

@@ -2,7 +2,7 @@
 (Instant EXAMINE and LOOK; Timeless)
 A set of actions which do not take any game time at all.
 
-In a game with tight timing, it is sometimes friendliest to the player to let him LOOK and EXAMINE as much as necessary without being penalized.
+In a game with tight timing, it is sometimes friendliest to the player to let them LOOK and EXAMINE as much as necessary without being penalized.
 
 	{*}"Timeless"
 	
@@ -45,4 +45,4 @@ Now the scenario for testing:
 		say "After a breathless climb, you emerge at last onto the open clifftop.";
 		end the story finally.
 	
-	Test me with "x me / x stone / x pitons / climb pitons".
+	Test me with "x me / x stone / x pitons / climb pitons".

resources/Documentation/Examples/Tower.txt

@@ -2,7 +2,7 @@
 (Windows in high places; A Haughty Spirit)
 Windows overlooking lower spaces which will prevent the player from climbing through if the lower space is too far below.
 
-Suppose we have a game in which the player can climb through windows which overlook rooms below. We want him to be allowed to climb out windows to reach a room on the same level or at most one level lower than the one he's on; otherwise, he should get a refusal, saying that he would break his neck.
+Suppose we have a game in which the player can climb through windows which overlook rooms below. We want them to be allowed to climb out windows to reach a room on the same level or at most one level lower than the one they're on; otherwise, they should get a refusal, saying that they would break their neck.
 
 To figure out the height distance between the start room and the destination room, we might have a repeat loop look at all the directions one has to follow along the "best route" path between the two rooms, and record any ups and downs; then subtract the number of "up" steps from the number of "down" steps, and report what remains.
 
@@ -53,4 +53,4 @@ Here we must anticipate a little from the chapter on Relations, and provide ours
 	
 	Test me with "jump through window / open window / jump through window / d / x narrow window / open window / climb through window / e / up / down".
 
-We could then add rules to allow the player to look through windows and see things in the rooms below, but that would require more material from later chapters. 
+We could then add rules to allow the player to look through windows and see things in the rooms below, but that would require more material from later chapters. 

resources/Documentation/Examples/Train.txt

@@ -58,7 +58,7 @@ And now our schedule for the train -- somewhat truncated, admittedly, since the
 		if the player is in the train or the player is in the station of the train, say "The train pulls out of [the station of the Train] and continues east through the darkness towards Spokane.";
 		now the station of the Train is the Train.
 	 
-Playing this out would of course require near inhuman patience. Let's set things up so that the player at least doesn't have to wait too long for his first departure:
+Playing this out would of course require near inhuman patience. Let's set things up so that the player at least doesn't have to wait too long for the first departure:
 
 	{**}The time of day is 4:43 PM.
 	
@@ -69,4 +69,4 @@ Playing this out would of course require near inhuman patience. Let's set things
 		
 	Test me with "out / in / z/ z / z / out / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / out / in / out / z / z".
 
-	Test more with "out / z/ z / z  / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z".
+	Test more with "out / z/ z / z  / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z / z".

resources/Documentation/Examples/Unblinking.txt

@@ -2,9 +2,9 @@
 (Light-filled rooms as a route through a space; Unblinking)
 Finding a best route through light-filled rooms only, leaving aside any that might be dark.
 
-Suppose we're simulating a situation where the player needs to travel through lit areas only, but we want to give him some hints about which way might be safe. Here we'll find our best route through light-filled rooms.
+Suppose we're simulating a situation where the player needs to travel through lit areas only, but we want to give them some hints about which way might be safe. Here we'll find our best route through light-filled rooms.
 
-The slightly tricky part is that it's not necessarily easy to tell whether a room has a lamp in it. We may say "if the Crypt is lighted", but that only tells us whether it has been declared to be inherently lighted or dark, not whether it happens to contain a light source that the player would be able to see if he went in.
+The slightly tricky part is that it's not necessarily easy to tell whether a room has a lamp in it. We may say "if the Crypt is lighted", but that only tells us whether it has been declared to be inherently lighted or dark, not whether it happens to contain a light source that the player would be able to see if they went in.
 
 The easiest way to get around this is to create an object -- the light-meter; place it in the target location; and check whether it "can see" a lit object. This preserves all the usual rules about open and closed containers, transparency, etc.
 
@@ -46,4 +46,4 @@ That done, we're free to use our best-route phrases to choose a particular route
 
 	Test me with "up / drop candle / down / up / take the candle / open sarcophagus / put candle in sarcophagus / down / up / close sarcophagus / d".
 	
-An important word of caution: this method would give false negatives if there were a backdrop lightsource, such as the moon, providing light to the Upward Path. This is because backdrops are actually moved around the map by Inform during play, following the player around. So if the moon backdrop is in the Crash Site with the player, it will not be in the Upward Path as well -- even if it's scheduled to move there as soon as the player does.
+An important word of caution: this method would give false negatives if there were a backdrop lightsource, such as the moon, providing light to the Upward Path. This is because backdrops are actually moved around the map by Inform during play, following the player around. So if the moon backdrop is in the Crash Site with the player, it will not be in the Upward Path as well -- even if it's scheduled to move there as soon as the player does.

resources/Documentation/Examples/VIP.txt

@@ -1,6 +1,6 @@
 ** Going from, going to
 (Region off-limits to a player without VIP pass; A&E)
-Using regions to block access to an entire area when the player does not carry a pass, regardless of which entrance he uses.
+Using regions to block access to an entire area when the player does not carry a pass, regardless of which entrance they use.
 
 Rules about going to regions make it easy to exclude the player from a large portion of the map, even if there are many connecting paths to the region. For instance, in this story it would be annoying to have to write a rule about all four exits by which the player could reach the film set area:
 
@@ -18,4 +18,4 @@ Rules about going to regions make it easy to exclude the player from a large por
 		say "Success! At last you are inside the set of 'Prouder and More Prejudiced'. Next step: locating Mr Firth.";
 		end the story finally.
 
-	Test me with "e / n / e / get pass / e".
+	Test me with "e / n / e / get pass / e".

resources/Documentation/Examples/VanHelsing.txt

@@ -1,10 +1,10 @@
 ** The location of something
 (Person who follows the player; Van Helsing)
-A character who approaches the player, then follows him from room to room.
+A character who approaches the player, then follows them from room to room.
 
 Suppose we want to write a character who tries to be in the same room as the player. We will do this by testing every turn whether the character's location and the player's location are the same; if the answer is no, the character will look for a path to the player's location, then try to move along that path. (We will learn more about finding paths and giving characters instructions later.)
 
-The result will be that if the player ever moves to another location, the character will automatically pursue him.
+The result will be that if the player ever moves to another location, the character will automatically pursue them.
 
 	{*}"Van Helsing"
 

resources/Documentation/Examples/Verbosity.txt

@@ -34,4 +34,4 @@ Moreover, we can ourselves check what the state of the descriptions is, with
 	if set to unabbreviated room descriptions: ...
 	if set to abbreviated room descriptions: ...
 
-Finally, it is possible to exercise more precise control over what the player sees on his first and subsequent visits to a room; see the next example for details.
+Finally, it is possible to exercise more precise control over what the player sees on their first and subsequent visits to a room; see the next example for details.

resources/Documentation/Examples/Verbosity2.txt

@@ -2,7 +2,7 @@
 (Verbosity: 2. Full-length descriptions mandatory--Full-length descriptions mandatory)
 Making rooms give full descriptions each time we enter, even if we have visited before, and disallowing player use of BRIEF and SUPERBRIEF.
 
-Suppose that we want the player always to see full room descriptions, even if he tries to reset the defaults -- perhaps because there is vital information there which he will miss if he turns off full-length room descriptions.
+Suppose that we want the player always to see full room descriptions, even if they try to reset the defaults -- perhaps because there is vital information there which they will miss if they turn off full-length room descriptions.
 
 To do this, we might want to remove the standard behavior of the three actions associated with BRIEF, SUPERBRIEF, and VERBOSE, replacing them with explanatory messages about how the game behaves. We cannot use Instead to override these actions, because Instead rules do not apply to actions out of world. Instead, we will want to remove and replace the carry out rules. 
 
@@ -45,4 +45,4 @@ Let's remove all three of the carry out rules and substitute our own:
 
 	The Men's Restroom is west of the Research Wing. "Well, yes, you really shouldn't be in here. But the nearest women's room is on the other side of the building, and at this hour you have the labs mostly to yourself. All the same, you try not to read any of the things scrawled over the urinals which might have been intended in confidence."
 
-	Test me with "west / east / brief / w / e / superbrief / w / e / verbose".
+	Test me with "west / east / brief / w / e / superbrief / w / e / verbose".

resources/Documentation/Examples/WainwrightActs.txt

@@ -30,7 +30,7 @@ And this allows us to write rules that have characters interacting with doors ev
 	
 	Liminality relates a door (called X) to a room (called Y) when the front side of X is Y or the back side of X is Y. The verb to be a threshold of means the liminality relation.
 
-	Definition: a person is other if he is not the player.
+	Definition: a person is other if they are not the player.
 
 	Every turn:
 		repeat with indiscreet one running through other people:
@@ -38,4 +38,4 @@ And this allows us to write rules that have characters interacting with doors ev
 				if the port is a threshold of the location and the indiscreet one is not in the location:
 					say "Through [the port], you overhear [the indiscreet one] discussing [one of]his hopes for your imminent resignation[or]your wife's infidelity[or]your financially straitened circumstances[or]ways to avoid attending your birthday party[or]your halitosis[as decreasingly likely outcomes]."
 
-	Test me with "z / z / z / w / z / e / close door / z".
+	Test me with "z / z / z / w / z / e / close door / z".

resources/Documentation/Examples/WaitMore.txt

@@ -21,7 +21,7 @@ The one nuance here is that after our wait command occurs, the turn sequence rul
 	{**}Report waiting more:
 		say "It is now [time of day + 1 minute]."
 
-And if we want to ensure that the player doesn't (accidentally or intentionally) put the interpreter through a really long loop, we could put an upper limit on his patience:
+And if we want to ensure that the player doesn't (accidentally or intentionally) put the interpreter through a really long loop, we could put an upper limit on their patience:
 
 	{**}Check waiting more:
 		if the time understood is greater than one hour, say "You really haven't got that kind of patience." instead.
@@ -32,4 +32,4 @@ And if we want to ensure that the player doesn't (accidentally or intentionally)
 
 	At 9:45 AM: say "At [the time of day in words], secretary glances at you and gives a reassuring smile."
 
-	Test me with "ask secretary about appointment / wait five minutes / g / g / wait 61 minutes / wait for half an hour / wait for a quarter of an hour / wait for an hour".
+	Test me with "ask secretary about appointment / wait five minutes / g / g / wait 61 minutes / wait for half an hour / wait for a quarter of an hour / wait for an hour".

resources/Documentation/Examples/WaitingSuite.txt

@@ -1,10 +1,10 @@
 ** Creating a scene
 (Scene that ends as soon as the player has embarrassed himself--Triggering a new scene when the player does any of several things; Entrapment)
-A scene in which the player is allowed to explore as much as he likes, but another character strolls in as soon as he has gotten himself into an awkward or embarrassing situation.
+A scene in which the player is allowed to explore as much as they like, but another character strolls in as soon as they have gotten into an awkward or embarrassing situation.
 
 The power of scenes lies in their ability to watch for general conditions and move the narrative along whenever these are fulfilled. Instead of waiting for the player to do one specific thing, the game waits for the world to be in a certain condition, before moving to the next stage of the plot.
 
-For instance, suppose we have a story in which the player has been captured for doing something inappropriate at court and is brought in to await a meeting with a palace official. We want to give the player a few minutes to stew, and we want the scene to end with him doing something mildly peculiar or embarrassing, and the official catching him in the act. So we tempt him into trying any of a number of different kooky activities, and just wait until he falls into the trap...
+For instance, suppose we have a story in which the player has been captured for doing something inappropriate at court and is brought in to await a meeting with a palace official. We want to give the player a few minutes to stew, and we want the scene to end with them doing something mildly peculiar or embarrassing, and the official catching them in the act. So we tempt them into trying any of a number of different kooky activities, and just wait until they fall into the trap...
 
 	{*}"Entrapment"
 
@@ -69,4 +69,4 @@ For instance, suppose we have a story in which the player has been captured for
 	
 ...and this scene might lead to another, and so on.
 
-The purpose of an open-ended scene like this might be puzzly or narrative: we might be waiting for the player to get a puzzle solved, or we might be waiting for him to fulfil some plot condition that must be met before we can go on. 
+The purpose of an open-ended scene like this might be puzzly or narrative: we might be waiting for the player to get a puzzle solved, or we might be waiting for them to fulfil some plot condition that must be met before we can go on. 

resources/Documentation/Examples/WaningMoon.txt

@@ -1,6 +1,6 @@
 *** Printing the description of a dark room
 (Four Stars: 1. Dark room which relies on other senses when light is off--Dark room which relies on other senses when light is off) 
-An elaboration of the idea that when light is absent, the player should be given a description of what he can smell and hear, instead.
+An elaboration of the idea that when light is absent, the player should be given a description of what they can smell and hear, instead.
 
 	{*}"Four Stars"
 
@@ -103,4 +103,4 @@ An elaboration of the idea that when light is absent, the player should be given
 	When play begins:   
 		say "You have at last escaped from the airport and gotten through customs; survived an unnerving taxi ride over icy highways; stared down the impertinent concierge; endured the bellhop's catalog of features in your room; and achieved, finally, a moment of peace. Time for a good night's slumber!"
 	
-	Test me with "x dreamcatcher / switch lamp off / look / sleep / eat chocolate / sleep / get plant / examine plant / open suitcase / put plant in suitcase / close suitcase / sleep / look / examine bose / switch bose off / sleep".
+	Test me with "x dreamcatcher / switch lamp off / look / sleep / eat chocolate / sleep / get plant / examine plant / open suitcase / put plant in suitcase / close suitcase / sleep / look / examine bose / switch bose off / sleep".

resources/Documentation/Examples/Waterskin2.txt

@@ -46,7 +46,7 @@ A campfire added to the camp site, which can be lit using tinder.
 		now the cloth is glowing;
 		say "You strike the flint against the steel and throw sparks onto the patch of cloth; they make tiny circles of orange there, which will only prosper if blown into flame."	
 
-Realistically, we ought to attach a randomization to this so that each step of the fire-starting has a good chance of failure. But because our player may not be as patient as someone who actually needs a fire started, we allow him to succeed the first time in every case.
+Realistically, we ought to attach a randomization to this so that each step of the fire-starting has a good chance of failure. But because our player may not be as patient as someone who actually needs a fire started, we allow them to succeed the first time in every case.
 
 	{**}Ignition is a kind of value. The ignitions are whole, fading, glowing, flaming. A thing has an ignition.
 	
@@ -84,4 +84,4 @@ Realistically, we ought to attach a randomization to this so that each step of t
 			say "You succeed in lighting yourself a proper campfire.";
 			now the printed name of Campsite is "By The Campfire".
 		
-	Test me with "i / drink water / i / drink water / i / wear steel / get flint / get cloth / drop cloth / get tinder / hit flint / blow on cloth / burn tinder / burn kindling / look".
+	Test me with "i / drink water / i / drink water / i / wear steel / get flint / get cloth / drop cloth / get tinder / hit flint / blow on cloth / burn tinder / burn kindling / look".

resources/Documentation/Examples/Wight.txt

@@ -1,12 +1,12 @@
 *** Defining new assertion verbs
 (Hints leading the player through physical puzzles; The Unexamined Life)
-An adaptive hint system that tracks what the player needs to have seen or to possess in order to solve a given puzzle, and doles out suggestions accordingly. Handles changes in the game state with remarkable flexibility, and allows the player to decide how explicit a nudge he wants at any given moment.
+An adaptive hint system that tracks what the player needs to have seen or to possess in order to solve a given puzzle, and doles out suggestions accordingly. Handles changes in the game state with remarkable flexibility, and allows the player to decide how explicit a nudge they want at any given moment.
 
 Hint systems in IF come in a variety of flavors: some are a static, prewritten set of guidelines (which might exist in a menu or outside the game entirely); others are built in as part of the program, and attempt to adapt to the situation the player currently faces. Adaptive hints have the advantage that they are less likely to reveal information for which the player is not ready, and the disadvantage that they are more work for the author.
 
-The exercise here is to write an adaptive hint system that will both respond in agile ways to the state of the world model and require a minimum of authorial fussing. We also want the player to be able to ask for a hint about any object he encounters in the game world: this will let him be specific and avoid accidentally receiving hints about the wrong puzzles.
+The exercise here is to write an adaptive hint system that will both respond in agile ways to the state of the world model and require a minimum of authorial fussing. We also want the player to be able to ask for a hint about any object they encounter in the game world: this will let them be specific and avoid accidentally receiving hints about the wrong puzzles.
 
-Our baseline assumption is that a player may find a puzzle unsolvable for one of two reasons: he either hasn't seen the relevant clue, or he hasn't got the relevant equipment. If these are true, then he should be given hints about how to find this information, and then once he has it, more specific hints about the puzzle itself -- ending, as a last resort, with the exact command(s) he will need to use in order to bring about the solution.
+Our baseline assumption is that a player may find a puzzle unsolvable for one of two reasons: they either haven't seen the relevant clue, or they haven't got the relevant equipment. If these are true, then they should be given hints about how to find this information, and then once they have it, more specific hints about the puzzle itself -- ending, as a last resort, with the exact command(s) they will need to use in order to bring about the solution.
 
 In practice, there are other possibilities, but this will do for an example. 
 
@@ -30,7 +30,7 @@ We begin by defining our relations:
 
 	Hinting about is an action applying to one visible thing. Understand "hint about [any thing]" as hinting about. 
 
-This allows us to create the most absolutely generic sort of hint -- boring, perhaps, but in practice the player often just needs a nudge about what part of the game world he should be examining for a solution:
+This allows us to create the most absolutely generic sort of hint -- boring, perhaps, but in practice the player often just needs a nudge about what part of the game world they should be examining for a solution:
 
 	{**}Carry out hinting about:
 		if something explains the noun, say "You might want to review [the list of things which explain the noun]. ";
@@ -39,7 +39,7 @@ This allows us to create the most absolutely generic sort of hint -- boring, per
 		otherwise:
 			say "Sorry, I can't advise you further on that.".
 
-These things cover hinting about objects that are themselves puzzles. But what if the player asks for hints about a tool or piece of information because he doesn't know how to apply it yet? We might want to give some guidance there, as well.
+These things cover hinting about objects that are themselves puzzles. But what if the player asks for hints about a tool or piece of information because they don't know how to apply it yet? We might want to give some guidance there, as well.
 	
 	{**}Carry out hinting about something which explains something (called target):
 		if target is unseen, say "[The noun] might prove useful information, sooner or later." instead;
@@ -161,7 +161,7 @@ Now we can add specific hints to replace the generic ones:
 	{**}Carry out hinting about the tomb:
 		say "The lids are heavy, but you can open them when you carry the pry bar."
 		
-The rest of the hint system ensures that the player will not see this final suggestion until he has the pry bar, since the tomb "requires" the pry bar. Having the hint there doesn't excuse us from providing some alternate wording in case the player solves this not-very-difficult conundrum on his own, though:
+The rest of the hint system ensures that the player will not see this final suggestion until they have the pry bar, since the tomb "requires" the pry bar. Having the hint there doesn't excuse us from providing some alternate wording in case the player solves this not-very-difficult conundrum on his own, though:
 
 	{**}Understand "pry [something] with [something preferably held]" as unlocking it with. Understand the commands "lever" or "prise" as "pry".
 

resources/Documentation/Examples/WomensStudies.txt

@@ -4,7 +4,7 @@ Implementing liquids that can be mixed, and the components automatically recogni
 
 Our previous experiments into liquid have not dealt with the possibility of mixing components, but that is because for most games, tracking the details of mixture is overkill. 
 
-But let's suppose that this time we do want to have mixed liquids; moreover, we want a way to describe the mixtures to the player inventively, so that if he hits specific combinations those combinations are recognized: calling the result a martini, say, rather than just "a mixture of vodka and vermouth".
+But let's suppose that this time we do want to have mixed liquids; moreover, we want a way to describe the mixtures to the player inventively, so that if they hit specific combinations those combinations are recognized: calling the result a martini, say, rather than just "a mixture of vodka and vermouth".
 
 The implementation that follows relies on a fairly simple idea from linear algebra. Any given liquid can be expressed as a vector in N-space, where N is the number of available ingredients and the length of the vector depends on how much of each ingredient is used; then we find the recipe that best describes the liquid by taking the dot product of our liquid vector with a bunch of sample vectors and selecting the one with the largest result.
 
@@ -284,4 +284,4 @@ Here we cheat on our arithmetic. The following chart just provides values corres
  
 	The bottle is a fluid container carried by the player. The cacao volume of the bottle is 10.0 fl oz.
 
-	Test me with "i / pour flask in jigger / pour jigger in glass / pour bottle in jigger / pour jigger in glass / pour bottle in jigger / pour jigger in glass / pour decanter in jigger / pour jigger in glass / drink glass / g / g / x glass / pour flask in glass".
+	Test me with "i / pour flask in jigger / pour jigger in glass / pour bottle in jigger / pour jigger in glass / pour bottle in jigger / pour jigger in glass / pour decanter in jigger / pour jigger in glass / drink glass / g / g / x glass / pour flask in glass".

resources/Documentation/Examples/Xot.txt

@@ -2,7 +2,7 @@
 (Player's erroneous command recorded for later; Xot)
 Storing an invalid command to be repeated as text later in the game.
 
-In Hitchhiker's Guide to the Galaxy, any erroneous command the player types can return to haunt him later in the game. We could do the same, if we liked, by storing the player's command whenever we print a parser error.
+In Hitchhiker's Guide to the Galaxy, any erroneous command the player types can return to haunt them later in the game. We could do the same, if we liked, by storing the player's command whenever we print a parser error.
 
 	{*} "Xot"
 	
@@ -16,4 +16,4 @@ In Hitchhiker's Guide to the Galaxy, any erroneous command the player types can
 	Every turn when a random chance of 1 in 2 succeeds:
 		say "Over the loudspeaker comes some distorted nonsense. If you listen carefully, it sounds as though some fool is saying '[last error], [last error], [last error]!'"
 		
-	Test me with "wiggle / z / z / z / z / z / z".
+	Test me with "wiggle / z / z / z / z / z / z".

resources/Documentation/Examples/Xylan.txt

@@ -44,4 +44,4 @@ And finally, we could try adding instructions explicitly:
 	
 ...though of course in fact these other commands won't be available until we define them, too. 
 
-This last approach, defining all the extra commands up front, is especially useful if these commands are very technical or unusual; if they are needed early in the game, before you've a chance to educate the player; or if they are not suggested by any in-game objects. A player who encounters a tool with an obvious use, such as a hairbrush, will likely think of trying to BRUSH things with it. It's harder to rely on his guessing actions that are both outside the range of usual commands and unrelated to any of the visible props, however.
+This last approach, defining all the extra commands up front, is especially useful if these commands are very technical or unusual; if they are needed early in the game, before you've a chance to educate the player; or if they are not suggested by any in-game objects. A player who encounters a tool with an obvious use, such as a hairbrush, will likely think of trying to BRUSH things with it. It's harder to rely on them guessing actions that are both outside the range of usual commands and unrelated to any of the visible props, however.

resources/Documentation/Examples/YolkofGold.txt

@@ -1,8 +1,8 @@
 ** Counting while comparing
 (Drawers where thing is always in the last opened; Yolk of Gold)
-Set of drawers where the item the player seeks is always in the last drawer he opens, regardless of the order of opening.
+Set of drawers where the item the player seeks is always in the last drawer they open, regardless of the order of opening.
 
-Suppose that for dramatic effect we would like the player to find the thing he is looking for always in the last drawer he opens...
+Suppose that for dramatic effect we would like the player to find the thing they are looking for always in the last drawer they open...
 
 	{*}"Yolk of Gold"
 
@@ -81,4 +81,4 @@ Perhaps, just for fun, we have all the other scenery draw the player's attention
 	
 	The strange dress is a wearable thing in the glass case. The description is "Not the sort of dress that anyone wears now: such elaboration would be ludicrous.  It drips gold -- gilt lace, ruffles of trimmed gold, shimmering golden tracery -- dulled here and there by the sinister black of faceted jet."	
 
-	Test me with "d / x case / x dress / x carpet / look under carpet / look under desk / x desk / open top drawer / close top drawer / look under desk / open bottom drawer / close bottom drawer / open middle drawer / get thing / look under carpet / look under desk / up".
+	Test me with "d / x case / x dress / x carpet / look under carpet / look under desk / x desk / open top drawer / close top drawer / look under desk / open bottom drawer / close bottom drawer / open middle drawer / get thing / look under carpet / look under desk / up".

resources/Documentation/Examples/Zed.txt

@@ -2,7 +2,7 @@
 (Travel requiring a vehicle; Peugeot)
 A journey from one room to another that requires the player to be on a vehicle.
 
-Let's say that our protagonist is about to flee . Obviously, he can't make the journey on foot; he needs transportation.
+Let's say that our protagonist is about to flee . Obviously, they can't make the journey on foot; they need transportation.
 
 	{*}"Peugeot"
 	
@@ -23,4 +23,4 @@ And now we borrow from the Actions chapter to prevent travel without the proper
 		say "You begin pedalling determinedly.";
 		continue the action.
 	
-	Test me with "e / get on ten-speed bike / e".
+	Test me with "e / get on ten-speed bike / e".

resources/Documentation/Examples/Zodiac.txt

@@ -15,7 +15,7 @@ Notice that the following two scenarios do not have the same effect:
 		
 	Test me with "x me / x killer / touch killer / smell mace".
 	
-...will prevent the player from doing anything else to the killer, but allow him free range of action with other objects. By contrast, the following will prevent him doing anything other than examining to any item:
+...will prevent the player from doing anything else to the killer, but allow them free range of action with other objects. By contrast, the following will prevent them doing anything other than examining to any item:
 	
 	{*}"Zodiac"
 	
@@ -43,4 +43,4 @@ The most strict statement would be
 
 	Test me with "x me / x killer / touch killer / smell mace".
 	
-Because we left "something" out, now the pattern does not have to match an activity with an object; it will match any activity at all. Singing too will be deemed too risky in the presence of our sinister foe. But we do need to make an exception for "look", or else we won't get even the room description.
+Because we left "something" out, now the pattern does not have to match an activity with an object; it will match any activity at all. Singing too will be deemed too risky in the presence of our sinister foe. But we do need to make an exception for "look", or else we won't get even the room description.

resources/Documentation/Examples/Zorn.txt

@@ -1,6 +1,6 @@
 *** Printing a refusal to act in the dark
 (Light levels variable depending on the number of candles the player has lit; Zorn of Zorna)
-Light levels vary depending on the number of candles the player has lit, and this determines whether or not he is able to examine detailed objects successfully.
+Light levels vary depending on the number of candles the player has lit, and this determines whether or not they are able to examine detailed objects successfully.
 
 	{*}"Zorn of Zorna"
 
@@ -63,4 +63,4 @@ Light levels vary depending on the number of candles the player has lit, and thi
 	
 	North of the Hallway is Freedom. Instead of going to Freedom: say "You make it out into the cool night air at last!"; end the story finally.
 	
-	Test me with "examine placard / get placard / n / listen / n / s / examine candle-stand / push candle-stand east / examine novel / get unlit candle / light it / light unlit candle / examine placard / push candle-stand west / e / examine novel / w / n / n".
+	Test me with "examine placard / get placard / n / listen / n / s / examine candle-stand / push candle-stand east / examine novel / get unlit candle / light it / light unlit candle / examine placard / push candle-stand west / e / examine novel / w / n / n".