initial commit

resources/Documentation/Examples/(Recipes).txt

@@ -96,7 +96,7 @@ Appraisal == OMIT
 	Maze with randomized room links
 	Carousel Room from which exits lead to random locations
 	Exits added to a room
-	Map rearranged as player wanders so he finds rooms in order
+	Map rearranged as player wanders so they findxo rooms in order
 	Compass directions renamed
 	A hexagonal map grid for movement
 	
@@ -203,7 +203,7 @@ Appraisal == OMIT
 	*TRAITS DETERMINED BY THE PLAYER
 	Name of player character selected at start of play
 	Asking the player to choose a gender
-	Allowing the player to describe his character before starting play
+	Allowing the player to describe the main character before starting play
 
 	*CHARACTERIZATION
 	Another, distinct from the player
@@ -421,7 +421,7 @@ Appraisal == OMIT
 	Escape action for non-player characters only
 	Reporting rules for other characters' behavior
 	Person who opens a container before trying to get something from it
-	Person who pursues his own goals each turn
+	Person who pursues their own goals each turn
 	
 	*SOCIAL GROUPS
 	People who interact with each other each turn

resources/Documentation/Examples/Abolition.txt

@@ -153,7 +153,7 @@ Note that the above unsetting is not equivalent to "now the noun does not impres
 		now every person fancies the noun.
 	
 	Report flattering:
-		say "You draw down universal admiration for [the noun] by casting him or her in a flattering light."
+		say "You draw down universal admiration for [the noun] by casting them in a flattering light."
 
 
 	Understand "unflatter [someone]" as unflattering. [Okay, okay, but it's four am.] Unflattering is an action applying to one thing.

resources/Documentation/Examples/AlienInvasion-G.txt

@@ -2,7 +2,7 @@
 (Preferences file loaded on replaying; Alien Invasion Part 23)
 Keeping a preference file that could be loaded by any game in a series.
 
-Suppose that we have a series of games each of which allows the player to select a puzzle difficulty level. When the player plays a new game in the series, we want him to start out by default with the same difficulty level he faced earlier on, so we store this information in a small preferences file, as follows:
+Suppose that we have a series of games each of which allows the player to select a puzzle difficulty level. When the player plays a new game in the series, we want them to start out by default with the same difficulty level they faced earlier on, so we store this information in a small preferences file, as follows:
 
 	{*}"Alien Invasion Part 23"
 
@@ -34,4 +34,4 @@ Suppose that we have a series of games each of which allows the player to select
 
 Our preference file is restricted to a single option here for simplicity's sake, but we could keep track of more information -- whether the player preferred verbose or brief room descriptions, screen configurations, and so on.
 	
-If we were disposed to be somewhat crueler, we could use a similar method to make the player finish each episode of the series in order to "unlock" the next. All we would need to do is store a numerical password in our preferences file when the player finished a given level; the next level would check, say, the Table of Completed Levels for that password, and refuse to play unless the right number were present.
+If we were disposed to be somewhat crueler, we could use a similar method to make the player finish each episode of the series in order to "unlock" the next. All we would need to do is store a numerical password in our preferences file when the player finished a given level; the next level would check, say, the Table of Completed Levels for that password, and refuse to play unless the right number were present.

resources/Documentation/Examples/Alliances.txt

@@ -1,6 +1,6 @@
 * Defining new assertion verbs
 (Shifting alliances among people; Unthinkable Alliances)
-People are to be grouped into alliances. To kiss someone is to join his or her faction, which may make a grand alliance; to strike them is to give notice of quitting, and to become a lone wolf.
+People are to be grouped into alliances. To kiss someone is to join their faction, which may make a grand alliance; to strike them is to give notice of quitting, and to become a lone wolf.
 
 The following is best tested by experimentally kissing and/or attacking, and typing RELATIONS after every change to see the effect.
 
@@ -20,4 +20,4 @@ The following is best tested by experimentally kissing and/or attacking, and typ
 		say "Smack!";
 		now the player does not help the vilified one.
 	
-	Test me with "relations / kiss sophie / relations / hit ryan / relations".
+	Test me with "relations / kiss sophie / relations / hit ryan / relations".

resources/Documentation/Examples/Alpaca.txt

@@ -47,4 +47,4 @@ This example takes the ordering of grammar lines to its logical extreme, sorting
 	
 	Test me with "use gate / use blower / use nippers / use brush / use apple / remove sombrero / use sombrero".
 
-Whether we actually want a USE action is a subject of some theoretical debate in the IF community. On the one hand, it helps avoid guess-the-verb problems where the player cannot figure out what term to use in order to express a fairly simple idea. On the other, it encourages the player to think that all items have one and exactly one use, rather than getting him to consider the range of possibilities that arise from having a complex vocabulary.
+Whether we actually want a USE action is a subject of some theoretical debate in the IF community. On the one hand, it helps avoid guess-the-verb problems where the player cannot figure out what term to use in order to express a fairly simple idea. On the other, it encourages the player to think that all items have one and exactly one use, rather than getting them to consider the range of possibilities that arise from having a complex vocabulary.

resources/Documentation/Examples/AntSensitiveSunglasses.txt

@@ -2,7 +2,7 @@
 (Varying room description text; Ant-Sensitive Sunglasses)
 What are activities good for? Controlling output when we want the same action to be able to produce very flexible text depending on the state of the world -- in this case, making highly variable room description and object description text.
 
-Suppose we want to create an object -- or maybe even a series of objects -- that warp the player's perception of every room description and object around him. 
+Suppose we want to create an object -- or maybe even a series of objects -- that warp the player's perception of every room description and object around them. 
 
 We've already seen some ways to create variations in text. For instance, we could make a room description with if substitutions in it, like so:
 
@@ -90,7 +90,7 @@ Now we do the same thing to room descriptions.
 
 	The activity-based room description body text rule is listed instead of the room description body text rule in the carry out looking rules. 
 	
-Our replacement rule this time around is a little bit trickier just because the rule that we're replacing is a complicated one: describing a room already checks to see whether there's light to see by, whether the player has turned off room descriptions when he enters a room for the second time, and whether the player character is (say) inside a closed box he can't see out of. 
+Our replacement rule this time around is a little bit trickier just because the rule that we're replacing is a complicated one: describing a room already checks to see whether there's light to see by, whether the player has turned off room descriptions when entering a room for the second time, and whether the player character is (say) inside a closed box they can't see out of. 
 
 But all of those details are re-copied from the standard rules, and the important thing is that, at the end, we again carry out our activity.
 

resources/Documentation/Examples/Anteaters.txt

@@ -1,6 +1,6 @@
 ** Stored actions
 (Device to remember and play back actions; Anteaters)
-The player carries a gizmo that is able to record actions performed by the player, then force him to repeat them when the gizmo is dropped. This includes storing actions that apply to topics, as in "look up anteater colonies in the guide".
+The player carries a gizmo that is able to record actions performed by the player, then force them to repeat those actions when the gizmo is dropped. This includes storing actions that apply to topics, as in "look up anteater colonies in the guide".
 
 	{*} "Anteaters"
 	
@@ -32,4 +32,4 @@ The player carries a gizmo that is able to record actions performed by the playe
 		try the idea of the gizmo;
 		now the idea of the gizmo is waiting.
 
-	Test me with "get guide / look up spines in guide / x gizmo / get gizmo / i / x gizmo / drop gizmo / get gizmo / look up anteater colonies in guide / x gizmo / drop gizmo".
+	Test me with "get guide / look up spines in guide / x gizmo / get gizmo / i / x gizmo / drop gizmo / get gizmo / look up anteater colonies in guide / x gizmo / drop gizmo".

resources/Documentation/Examples/AppleCount.txt

@@ -18,7 +18,7 @@ or
 
 	>EAT PRISTINE APPLE
 	
-but if he types
+but if they type
 
 	>EAT APPLE
 	
@@ -61,4 +61,4 @@ Inform will also separate the bitten from the pristine apples in inventory listi
 		if every apple held by the source is bitten, say "bitten ";
 		if every apple held by the source is pristine, say "pristine ".
 		
-	Test me with "i / eat apple / i / eat apple / pristine / i / eat apple / pristine / i".
+	Test me with "i / eat apple / i / eat apple / pristine / i / eat apple / pristine / i".

resources/Documentation/Examples/Athens.txt

@@ -2,7 +2,7 @@
 (LOOK [direction] command; A View of Green Hills)
 A LOOK [direction] command which allows the player to see descriptions of the nearby landscape.
 
-Suppose a game in which the player is wandering an open landscape with long vistas, allowing him to LOOK in some direction, or even look at an adjacent location.
+Suppose a game in which the player is wandering an open landscape with long vistas, allowing them to LOOK in some direction, or even look at an adjacent location.
 
 	{*}"A View of Green Hills"
 
@@ -17,7 +17,7 @@ Suppose a game in which the player is wandering an open landscape with long vist
 		if the viewed item is not a room, say "You can't see anything promising that way." instead; 
 		try looking toward the viewed item.
 
-In rules about action handling, "noun" refers to the first object that the player has mentioned in his command, so if the player typed >LOOK WEST, "let the viewed item be the room noun from the location" would be processed as "let the viewed item be the room west from the location", and so on.
+In rules about action handling, "noun" refers to the first object that the player has mentioned in their command, so if the player typed >LOOK WEST, "let the viewed item be the room noun from the location" would be processed as "let the viewed item be the room west from the location", and so on.
 
 We can at need override the default behavior, if it is not going to be appropriate for the player to see the next room over. There is only sky above at any time, so...
 
@@ -36,4 +36,4 @@ This design allows us to create descriptions for rooms (as seen from the outside
 	{**}Instead of looking toward Athens: 
 		say "Even from here you can make out the silhouette of the Acropolis."
 
-	Test me with "look north / look south / look up / look east / east / look west".
+	Test me with "look north / look south / look up / look east / east / look west".

resources/Documentation/Examples/BaritoneBass.txt

@@ -1,5 +1,5 @@
 *** Understanding values
-(Allowing the player to describe his character before starting play; Baritone, Bass)
+(Allowing the player to describe the character before starting play; Baritone, Bass)
 Letting the player pick a gender (or perhaps other characteristics) before starting play.
 
 The "reading a command" activity is rather advanced; for the moment, what we need to understand is that we're intervening in commands at the start of play and insisting that the player's first instruction to the game consist of a choice of gender. After that point, the gender will be set and play will proceed as normal.
@@ -48,4 +48,4 @@ If we had a whole series of things to ask the player about, we might define a wh
 and use a "construction stage" variable to keep track of the current stage of character-construction, as in
 
 	After reading a command when the current construction stage is choosing a vocal range:
-		... 
+		... 

resources/Documentation/Examples/BaseWindow.txt

@@ -2,7 +2,7 @@
 (Basic window similar to a door; Escape)
 Window that can be climbed through or looked through.
 
-Suppose we want to offer the player a window he can climb through, instead of a boring ordinary door. Our window will be like a door in that it connects two rooms, appears in both places, and impedes movement when it is shut. But we also want to add that we can look through it and see what lies on the other side; and we further want to understand "climb through window" or "jump through window" as attempts to pass through it.
+Suppose we want to offer the player a window they can climb through, instead of a boring ordinary door. Our window will be like a door in that it connects two rooms, appears in both places, and impedes movement when it is shut. But we also want to add that we can look through it and see what lies on the other side; and we further want to understand "climb through window" or "jump through window" as attempts to pass through it.
 
 We'll start by defining a couple of rooms and making the window a door between them.
 

resources/Documentation/Examples/Batteries.txt

@@ -91,7 +91,7 @@ And to get rid of annoying messages like "Which would you like to close, the fla
 
 	The wind chimes are fixed in place in Thirtieth Street. "Carefully attached to the wall with a piece of duct tape and a hook is a light-weight set of wind chimes. Someone else has been here before you, it seems." The description is "Several of your friends use wind chimes as a sort of ghost alarm, since ghosts sometimes cause very localized movements of air when there is no natural breeze."
 	
-And this last bit, borrowed from the chapter on Understanding, adds some special instructions to help Inform decide when the player is likely to be referring to a compartment and when he's likely to be referring to the device itself.
+And this last bit, borrowed from the chapter on Understanding, adds some special instructions to help Inform decide when the player is likely to be referring to a compartment and when they're likely to be referring to the device itself.
 
 	{**}Does the player mean doing something other than searching to a battery compartment: it is unlikely. [We discourage Inform from choosing a compartment when the player uses just the name of a device or the word 'battery'.]
 	
@@ -113,4 +113,4 @@ We also need to deal with commands like PUT BATTERY IN FLASHLIGHT, where Inform
 
 	Test first with "i / open flashlight compartment / put battery in it / turn on flashlight / take d battery / open cassette compartment / turn on cassette / put battery in cassette compartment / turn on cassette / z / z / z / z".
 
-	Test second with "get d battery / put d battery in flashlight compartment / turn on flashlight / z / z / z / z / z / z / turn off flashlight / z / z / turn on flashlight / z".
+	Test second with "get d battery / put d battery in flashlight compartment / turn on flashlight / z / z / z / z / z / z / turn off flashlight / z / z / turn on flashlight / z".

resources/Documentation/Examples/Beachfront.txt

@@ -1,8 +1,8 @@
 * In the presence of, and when
 (SEARCHing for an item which moves into play--Evidence hidden until item is searched; Beachfront)
-An item that the player can't interact with until he has found it by searching the scenery.
+An item that the player can't interact with until they have found it by searching the scenery.
 
-Suppose we have our player, a detective, searching for evidence; we don't want him to be able to use this evidence until he has performed the action that reveals it, but after that it should be visible in the room when he looks.
+Suppose we have our player, a detective, searching for evidence; we don't want them to be able to use this evidence until they have performed the action that reveals it, but after that it should be visible in the room when they look.
 
 A simple way to do this is to start the object -- an envelope, in this scenario -- out of play, and only move it into the location when the player looks for it:
 
@@ -21,11 +21,11 @@ A simple way to do this is to start the object -- an envelope, in this scenario
 		say "You rifle through the piles of bills and notices; invitations to conventions; advertisements for high-end prescription drugs; pink carbon sheets bearing patients['] names and medical identification numbers in spidery, elderly handwriting. Almost at the bottom of the heap, you find what you were looking for: a creamy envelope with the address typed.";
 		move the envelope to the desk.
 	
-Here we've changed the property of the envelope to keep track of the fact that it has been found, so that if the player tries again, he won't find anything more. 
+Here we've changed the property of the envelope to keep track of the fact that it has been found, so that if the player tries again, they won't find anything more.
 	
 	{**}Instead of searching the desk:
 		say "Further investigation of the desk reveals nothing else suspicious."
 		
 Notice that we have two rules that apply to "searching the desk", but one of them has a more specific set of parameters ("when the envelope is lost"). This means that Inform will consult that rule first and use it if it applies; it will only carry out our plain vanilla "instead of searching the desk" rule when the more restricted rule is not relevant.
 	
-	{**}Test me with "x envelope / x desk / search desk / look / get envelope / x envelope".
+	{**}Test me with "x envelope / x desk / search desk / look / get envelope / x envelope".

resources/Documentation/Examples/Beer.txt

@@ -1,6 +1,6 @@
 ** Deciding the scope of something
 (Telescope allowing view of another room; Ginger Beer)
-A portable magic telescope which allows the player to view items in another room of his choice.
+A portable magic telescope which allows the player to view items in another room of their choice.
 
 Suppose we want to have a pair of linked lenses so that the player can look into one of them and see things which occur in room containing the other lense.
 

resources/Documentation/Examples/Below.txt

@@ -24,11 +24,11 @@ Speaking of the Index, the Actions tab contains a list of all the grammar that c
 
 The nuances of this will be explored in the chapter on Understanding. What is useful to know here is that we have taught Inform to understand that >FLIP LIGHT SWITCH means to turn it on when the switch is already off; if the switch is already on, FLIP SWITCH means to turn the switch off. Depending on the kind of device we are modeling (button? lever? dial?), we might want to write similar lines for commands such as PUSH, PRESS, PULL, TURN, and so on.
 
-Finally, we need to deal with a special case. In general, the player cannot interact with other things in a dark room because he can't see them, but if we adhered strictly to this it would be impossible for him to find the light switch to turn it back on. So we need something from the chapter on Activities to change this:
+Finally, we need to deal with a special case. In general, the player cannot interact with other things in a dark room because they can't see them, but if we adhered strictly to this it would be impossible for them to find the light switch to turn it back on. So we need something from the chapter on Activities to change this:
 
 	{**}After deciding the scope of the player when the location is the Terrifying Basement:
 		place the light switch in scope.
 	
 	Upstairs is above the Terrifying Basement.
 
-	Test me with "turn off light / look / flip light switch".
+	Test me with "turn off light / look / flip light switch".

resources/Documentation/Examples/BigSainsburys.txt

@@ -4,7 +4,7 @@ Making implicit takes add a minute to the clock, just as though the player had t
 
 Implicit takes are a convenience to players; in general, we would like to avoid asking players to type any more obvious commands than strictly necessary, while allowing the computer to guess as much as it safely can.
 
-Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish his objectives. In that case, the implicit take complicates matters, because it means that a player who types
+Occasionally, though, we have designed a timed puzzle in which the player has a limited number of moves in which to accomplish their objectives. In that case, the implicit take complicates matters, because it means that a player who types
 
 	>EAT GATEAU
 	(first taking the gateau...)
@@ -29,4 +29,4 @@ gets away with a spare move compared to the precise but naïf dupe who types
 	When play begins:
 		now the right hand status line is "[time of day]".
 	
-	Test me with "take crispy duck / eat crispy duck / eat steak pie".
+	Test me with "take crispy duck / eat crispy duck / eat steak pie".

resources/Documentation/Examples/Blakeney.txt

@@ -1,6 +1,6 @@
 *** Relations which express conditions
 (People introduced by relative; A Humble Wayside Flower)
-Relations track the relationships between one character and another. Whenever the player meets a relative of someone he already knows, he receives a brief introduction.
+Relations track the relationships between one character and another. Whenever the player meets a relative of someone they already know, they receive a brief introduction.
 
 First we define the relationships we choose to acknowledge:
 
@@ -43,4 +43,4 @@ For brevity, we will ignore the existence of mothers. It is a sad world.
 	
 	Test me with "out / west / east / west".
 
-Monsieur St Just never appears on the scene in this piece, but if we did put him somewhere the player could find him, he, too, would be properly introduced.
+Monsieur St Just never appears on the scene in this piece, but if we did put him somewhere the player could find him, he, too, would be properly introduced.

resources/Documentation/Examples/Bosch.txt

@@ -43,4 +43,4 @@ We could, if we wanted, make a table of stored actions all of which represent th
 	
 	Test me with "eat lily / w / full score / get leaf / full".
 	
-This system is tidy, but limited: we cannot give actions interesting names in the score list, like "seducing the pirate's daughter" or "collecting a valuable artifact". So it will not be ideal in all situations, but it has the virtue of being easy to extend, and of listing all of the player's successes in the order in which they occurred in his play-through.
+This system is tidy, but limited: we cannot give actions interesting names in the score list, like "seducing the pirate's daughter" or "collecting a valuable artifact". So it will not be ideal in all situations, but it has the virtue of being easy to extend, and of listing all of the player's successes in the order in which they occurred in their play-through.

resources/Documentation/Examples/BowlerHats.txt

@@ -15,7 +15,7 @@ Suppose we have a plot that features a number of scripted scenes, where we need
 	Instead of going somewhere during a restricted scene:	
 		say "Better to stay here for the moment and find out what is going to happen next."
 
-And now let's set up our restricted scene. In it, a clown is going to turn up wherever the player is (it doesn't matter where on the map he's gotten to at this point) and do a performance; the player will not be able to leave the area until the performance completes. We'll start with the setting:
+And now let's set up our restricted scene. In it, a clown is going to turn up wherever the player is (it doesn't matter where on the map they've gotten to at this point) and do a performance; the player will not be able to leave the area until the performance completes. We'll start with the setting:
 	
 	{**}Section 2 - The Stage and Props
 

resources/Documentation/Examples/Broughton.txt

@@ -19,7 +19,7 @@ Suppose that we have a core set of issues we want to be able to bring up with al
 		relate the current subject with the second noun;
 		now the current subject is the second noun.
 
-And if we wanted to offer the player some hints about angles he could pursue:
+And if we wanted to offer the player some hints about angles they could pursue:
 	
 	{**}Instead of thinking:
 		say "You contemplate [a list of things suggested by the current subject]."
@@ -79,4 +79,4 @@ Of course, we can override specific instances, if we want the character always t
 	
 	Test me with "think / ask lady about infidelity / show nasty letter to lady / show note to lady / think / ask lady about divorce / ask lady about love / ask lady about marriage / ask lady about divorce / ask lady about love / ask lady about penmanship".
 		
-We would have to be careful about this system, since we have applied a various-to-various relation to every single object in the game. In practice it would probably be wisest to restrict it a bit, with judicious definitions of kind and so on.
+We would have to be careful about this system, since we have applied a various-to-various relation to every single object in the game. In practice it would probably be wisest to restrict it a bit, with judicious definitions of kind and so on.

resources/Documentation/Examples/BumpingIntoWalls.txt

@@ -1,6 +1,6 @@
 *** Going from, going to
 (GOing an invalid direction produces a list of valid exits--Exits listed when the player tries a wrong direction; Bumping into Walls)
-Offering the player a list of valid directions if he tries to go in a direction that leads nowhere.
+Offering the player a list of valid directions if they try to go in a direction that leads nowhere.
 
 	{*}"Bumping into Walls"
 
@@ -24,4 +24,4 @@ There is no theoretical reason why we have to define "count of exits" here: we c
 
 	The church door is east of Eastern End and west of the Courtyard. The church door is a door.
 	
-	Test me with "u / n / n / e / n / s / u / open door / e / n".
+	Test me with "u / n / n / e / n / s / u / open door / e / n".

resources/Documentation/Examples/CHS.txt

@@ -1,6 +1,6 @@
 **** Printing the name of something
 (Hints leading the player through conversation; Chronic Hinting Syndrome)
-Using name-printing rules to keep track of whether the player knows about objects, and also to highlight things he might want to follow up.
+Using name-printing rules to keep track of whether the player knows about objects, and also to highlight things they might want to follow up.
 
 Suppose we have a conversation system in which it is important to keep track of which subjects the player has heard mentioned. If we're careful to mark subjects in brackets, we can use the "printing the name of" activity to record which things have been mentioned so far:
 
@@ -21,7 +21,7 @@ Suppose we have a conversation system in which it is important to keep track of
 	After printing the name of a subject (called idea):
 		now the player is aware of the idea.
 		
-Now suppose that as an added convenience for the player, we let him turn on a mode in which useful conversation topics are always automatically highlighted in the text, so he doesn't waste his time trying to follow up dead leads:
+Now suppose that as an added convenience for the player, we let them turn on a mode in which useful conversation topics are always automatically highlighted in the text, so they don't waste time trying to follow up dead leads:
 
 	{**}Setting is a kind of value. The settings are bright and dull. Understand "on" as bright. Understand "off" as dull.
 

resources/Documentation/Examples/Cabin11.txt

@@ -6,16 +6,16 @@ If we wanted, we could make the player's backpack infinitely capacious, so:
 
 	{*}The backpack is a player's holdall.
 	
-...And now whenever the player character is unable to hold everything, he will automatically stow some of his possessions therein.
+...And now whenever the player character is unable to hold everything, they will automatically stow some of their possessions therein.
 
-This is only useful if the player doesn't have infinite carrying capacity himself, so perhaps we also need
+This is only useful if the player doesn't have infinite carrying capacity, so perhaps we also need
 
 	{*}The carrying capacity of the player is 3.
 	
-Perhaps mercifully, items which are worn are not counted against the player's carrying capacity. We might want to let him take advantage of that, too:
+Perhaps mercifully, items which are worn are not counted against the player's carrying capacity. We might want to let them take advantage of that, too:
 
 	{*}The backpack is wearable.
 
 This capacity system makes a compromise between the realistic and the absurd: on the one hand, it acknowledges that people can't carry an infinite number of items in their hands, while at the same time providing a sack that can.
 
-Many games will have no use for object-juggling of this kind at all; others will want to be much more rigorous about questions of capacity and volume. Fortunately, it is easy to leave the whole business out by assigning no carrying capacity to anything. 
+Many games will have no use for object-juggling of this kind at all; others will want to be much more rigorous about questions of capacity and volume. Fortunately, it is easy to leave the whole business out by assigning no carrying capacity to anything. 

resources/Documentation/Examples/Cabin8.txt

@@ -6,8 +6,8 @@ We probably do not need a vehicle to ride around our boat, but there might be a
 
 	{*}The ice chest is a closed openable container in the Deck. "A very heavy ice chest sits on the ground." It is fixed in place and pushable between rooms. A quantity of ice is in the chest. The description is "Ready and waiting just in case there's any fish needing to be kept cool."
 	
-This anticipates a later chapter, but it would probably be a good idea to hint to the player, if he tries to take the ice chest, that there is another way to move it:
+This anticipates a later chapter, but it would probably be a good idea to hint to the player, if they try to take the ice chest, that there is another way to move it:
 
 	{**}Instead of taking the chest: say "It's too heavy to lift, but you might be able to push it, and just inch it over the frame of the door."
 
-Otherwise, attempts to pick it up will just reply with "That's fixed in place." 
+Otherwise, attempts to pick it up will just reply with "That's fixed in place." 

resources/Documentation/Examples/Carnivale.txt

@@ -27,7 +27,7 @@ As the descriptions make clear, the ferris wheel should be visible from everywhe
 
 as it normally would.
 
-Now, by default, if the player were to type TOUCH FERRIS WHEEL while in another room, he would get the response
+Now, by default, if the player were to type TOUCH FERRIS WHEEL while in another room, the story would respond
 
 	You can't reach into By the Wheel.
 	

resources/Documentation/Examples/Carousel.txt

@@ -2,7 +2,7 @@
 (Carousel Room from which exits lead to random locations; Zork II)
 A "Carousel Room", as in Zork II, where moving in any direction from the room leads (at random) to one of the eight rooms nearby.
 
-All we need to do is select the player's destination for him at random:
+All we need to do is select the player's destination at random:
 
 	{*}"Zork II"
 	
@@ -36,4 +36,4 @@ And then
 
 	Test me with "turn off machine / s / n / turn on machine / s".
 
-	When play begins, seed the random-number generator with 1234.
+	When play begins, seed the random-number generator with 1234.

resources/Documentation/Examples/Cash.txt

@@ -1,6 +1,6 @@
 * Arithmetic with units
 (BUY command and a system of money--Money system with simple tracking of player wealth; Frozen Assets)
-A treatment of money which keeps track of how much the player has on him, and a BUY command which lets him go shopping.
+A treatment of money which keeps track of how much the player has on them, and a BUY command which lets him go shopping.
 
 In our brave new world, everything will have a price, so we had better spell this out.
 
@@ -60,4 +60,4 @@ Now we just need something to buy.
 	
 	Test me with "inventory / examine syllabub / get syllabub / buy syllabub / drop it / get it / buy raspberry tart".
 
-Implementing caloric units for this scenario is left as an exercise for the reader.
+Implementing caloric units for this scenario is left as an exercise for the reader.

resources/Documentation/Examples/Celadon.txt

@@ -1,8 +1,8 @@
 * To carry, to wear, to have
 (DROP applies even to objects the player carries indirectly; Celadon)
-Using the enclosure relation to let the player drop things which he only indirectly carries.
+Using the enclosure relation to let the player drop things which they only indirectly carry.
 
-By default, Inform only lets the player drop those things which he is carrying -- that is, those directly in his possession. Things inside satchels or on portable trays have to be taken first.
+By default, Inform only lets the player drop those things which they are carrying -- that is, those directly in their possession. Things inside satchels or on portable trays have to be taken first.
 
 If we want to change this behavior, we might add a dropping rule that distinguishes between carrying and mere enclosure (introduced back in "The location of something" in the chapter on Things):
 
@@ -19,4 +19,4 @@ If we want to change this behavior, we might add a dropping rule that distinguis
 	Instead of taking the napkin:
 		say "It seems to be stuck to the tray, possibly by an underlying wad of gum."
 			
-	Test me with "i / drop teapot / i / look / drop teapot / drop napkin / i / drop tray".
+	Test me with "i / drop teapot / i / look / drop teapot / drop napkin / i / drop tray".

resources/Documentation/Examples/Cheese-makers.txt

@@ -4,7 +4,7 @@ Scenes used to control the way a character reacts to conversation and comments,
 
 As we have seen, there are a number of different ways of controlling conversation in interactive fiction, and the best choice of way will depend quite a lot on what kind of work we're writing. 
 
-One common model is to replace Inform's default ASK and TELL commands with a TALK TO command. This gives the player less control than he would otherwise have: instead of asking a character about any topic under the sun, he's restricted to seeing (or not seeing) a single sequence of text that the author has written in advance. On the other hand, such a system is harder for the player to break (since he can never ask about a topic that the author hasn't implemented), and easier for the author to tie into plot developments. If we give TALK TO different output at each scene, we get conversation that is always tied to the current state of the plot.
+One common model is to replace Inform's default ASK and TELL commands with a TALK TO command. This gives the player less control than they would otherwise have: instead of asking a character about any topic under the sun, they're restricted to seeing (or not seeing) a single sequence of text that the author has written in advance. On the other hand, such a system is harder for the player to break (since they can never ask about a topic that the author hasn't implemented), and easier for the author to tie into plot developments. If we give TALK TO different output at each scene, we get conversation that is always tied to the current state of the plot.
 
 This is a design approach that works best in a game with a large number of short, focused scenes. For other kinds of conversation system design, compare the other examples listed in the Recipe Book.
 

resources/Documentation/Examples/CipherRoom.txt

@@ -2,7 +2,7 @@
 (ASK someone ABOUT an object the same as SHOW--ASK made like SHOW when applied to objects; Nameless)
 ASKing someone about an object rather than about a topic.
 
-By default, ASK SOMEONE ABOUT... applies only to a text token. We might want also to offer the player the option of asking characters about pieces of physical evidence. This example implements an ASK PERSON ABOUT THING command that is mostly synonymous with SHOW, with the added nuance that the player can ask about things that are not currently visible, as long as he has encountered them at some time in the past.
+By default, ASK SOMEONE ABOUT... applies only to a text token. We might want also to offer the player the option of asking characters about pieces of physical evidence. This example implements an ASK PERSON ABOUT THING command that is mostly synonymous with SHOW, with the added nuance that the player can ask about things that are not currently visible, as long as they have encountered them at some time in the past.
 
 	{*}"Nameless"
 
@@ -18,7 +18,7 @@ Now we create our new action, "interrogating it about". We write the grammar lin
 
 	Understand "ask [someone] about [any known thing]" as interrogating it about. interrogating it about is an action applying to two visible things. 
 
-Now we replace and redirect the showing action. This gets rid of the requirement in the default library that the player be holding anything he shows to another character:
+Now we replace and redirect the showing action. This gets rid of the requirement in the default library that the player be holding anything they show to another character:
 
 	{**}Understand the commands "show" and "display" and "present" as something new. 
 

resources/Documentation/Examples/Cloves.txt

@@ -2,7 +2,7 @@
 (Adverbs used in commands; Cloves)
 Accepting adverbs anywhere in a command, registering what the player typed but then cutting them out before interpreting the command.
 
-It has sometimes been suggested that IF should allow for the player to use adverbs, so that doing something "carefully" will have a different effect from doing it "quickly". There are several inherent challenges here: it's a good idea to make very sure the player knows all his adverb options, and the list of possibilities should probably not be too long. 
+It has sometimes been suggested that IF should allow for the player to use adverbs, so that doing something "carefully" will have a different effect from doing it "quickly". There are several inherent challenges here: it's a good idea to make very sure the player knows all their adverb options, and the list of possibilities should probably not be too long. 
 
 Another trick is that adverbs complicate understanding commands, because they can occur anywhere: one might type >GO WEST CAREFULLY or >CAREFULLY GO WEST, and ideally the game should understand both. After reading a command is the best point to do this sort of thing, because we can find adverbs, interpret them, and remove them from the command stream. So:
 
@@ -56,4 +56,4 @@ Now we have, automatically, a value called manner understood to be used whenever
 
 The qualification about turn count is to prevent this before message from occurring when the player first looks around the room (automatically) at the start of play.
 
-Note that to test this example, one must type INSOUCIANTLY TEST ME, and not simply TEST ME: a poseur's work is never done.
+Note that to test this example, one must type INSOUCIANTLY TEST ME, and not simply TEST ME: a poseur's work is never done.

resources/Documentation/Examples/Compassless.txt

@@ -18,13 +18,13 @@ The original Adventure allowed the player to type the names of rooms in order to
 
 	Going by name is an action applying to one thing.
 	
-We should reject movement to the player's current location, or to anywhere he hasn't been and can't see:
+We should reject movement to the player's current location, or to anywhere they haven't been and can't see:
 
 	{**}Check going by name:
 		if the noun is the location, say "You're already in [the location]." instead;
 		if the noun is not adjacent and the noun is unvisited, say "That noun did not make sense in this context." instead.
 
-The assumption here is that the player does know the names of the rooms adjacent to his current location, even if he hasn't been there yet.
+The assumption here is that the player does know the names of the rooms adjacent to their current location, even if they haven't been there yet.
 
 Now for the travel itself. The simplest way to ensure that the usual movement rules will still apply is to convert GO BY NAME into a GO action, and here the best route comes to our aid:
 
@@ -35,7 +35,7 @@ Now for the travel itself. The simplest way to ensure that the usual movement ru
 		try going aim;
 		if the location is not the noun, say "You'll have to stop here."
 		
-This will allow the player to travel toward rooms he has already visited even if they are several moves away.
+This will allow the player to travel toward rooms they have already visited even if they are several moves away.
 
 Finally, so that the player can also use the names of doors as commands:
 
@@ -48,4 +48,4 @@ And in keeping with the original, we might add to our scenario a rule or two abo
 	Instead of going to the Plover Room from the Alcove when the player carries something which is not the plover egg:
 		say "Something you're carrying won't fit through the tunnel with you. You'd best take inventory and drop something."
 
-	Test me with "go to misty cavern / go to dark corridor / go to plover room / go to alcove / go to dark corridor / drop pyramid / go to dark corridor / g / go to alcove / g / go to misty cavern".
+	Test me with "go to misty cavern / go to dark corridor / go to plover room / go to alcove / go to dark corridor / drop pyramid / go to dark corridor / g / go to alcove / g / go to misty cavern".

resources/Documentation/Examples/Conversation.txt

@@ -2,7 +2,7 @@
 (Conversation system with recap of past exchanges; Farewell)
 People who respond to conversational gambits, summarize what they said before if asked again, and provide recap of conversation that is past.
 
-We begin with the idea that each person comes with his own table of things to say:
+We begin with the idea that each person comes with their own table of things to say:
 
 	{*}"Farewell"
 

resources/Documentation/Examples/Deadbolt.txt

@@ -1,16 +1,16 @@
 ** Locks and keys
-(Deadbolted door unlockable without a key on one side; Neighborhood Watch)
+(Deadbolted door unlockable without a key on one side; Neighbourhood Watch)
 A locked door that can be locked or unlocked without a key from one side, but not from the other.
 
 Suppose we want a locked door that can be opened with a key, but is also openable by hand without a key from one side only. We start by defining an ordinary lockable door and the key that controls it:
 
-	{*}"Neighborhood Watch"
+	{*}"Neighbourhood Watch"
 	
 	The shabby door is a door. It is outside from the Studio Apartment and inside from the Rickety Stairwell. The shabby door is locked.
 
 	The brass key is carried by the player. It unlocks the shabby door.
 	
-The next part is going to require that we modify the normal operation of the "lock" command. "Lock" ordinarily requires that the player supply two objects: a thing he wants to unlock, and the key he wants to use on it. The full command is LOCK DOOR WITH THE KEY, and Inform will not accept simply LOCK DOOR as locking. 
+The next part is going to require that we modify the normal operation of the "lock" command. "Lock" ordinarily requires that the player supply two objects: a thing they want to unlock, and the key they want to use on it. The full command is LOCK DOOR WITH THE KEY, and Inform will not accept simply LOCK DOOR as locking. 
 
 Therefore, we're going to need to create our own new variant on the lock verb (and the unlock verb, while we're at it). The full procedure for this is laid out in the chapters on Action and Understanding, but here is an example:
 
@@ -30,7 +30,7 @@ This check rule is performed before the keyless locking action succeeds. The fir
 
 The second thing is to check whether the player is outside but keyless, and, if so stop the action from being performed successfully. Here we print a failure message followed by the word "instead", which tells Inform that we've substituted some other outcome for the usual performance of the action.
 
-Now we're reasonably sure that the player is only locking keylessly in the case that he is inside the Studio. (We might have to do a more thorough check for this if there were more than two rooms, but as it is, the player can only be in the Stairwell or in the Studio, so if we have ruled out the Stairwell, we are safe.) So now we want to add what happens when locking-without-a-key command succeeds:
+Now we're reasonably sure that the player is only locking keylessly in the case that they are inside the Studio. (We might have to do a more thorough check for this if there were more than two rooms, but as it is, the player can only be in the Stairwell or in the Studio, so if we have ruled out the Stairwell, we are safe.) So now we want to add what happens when locking-without-a-key command succeeds:
 	
 	{**}Carry out locking keylessly:
 		now the noun is locked.
@@ -58,4 +58,4 @@ And now we have to do a similar set of things for unlocking:
 	
 	Test me with "unlock door / drop key / open door / out / close door / lock door / open door / in / get key / out / close door / lock door / unlock door".
 	
-Some (but not all) of this work is done for you if you like by the Locksmith extension. If you prefer, you can include that extension, then follow the documentation in order to implement the remainder of the scenario. Locksmith takes care of implementing the additional locking and unlocking actions, and provides some other conveniences.
+Some (but not all) of this work is done for you if you like by the Locksmith extension. If you prefer, you can include that extension, then follow the documentation in order to implement the remainder of the scenario. Locksmith takes care of implementing the additional locking and unlocking actions, and provides some other conveniences.

resources/Documentation/Examples/Dishes.txt

@@ -2,7 +2,7 @@
 (Refusing to understand "hot"--Infrared goggles affect what player can see and refer to; Hot Glass Looks Like Cold Glass)
 Responding to references to a property that the player isn't yet allowed to mention (or when not to use "understand as a mistake").
 
-Suppose we have a situation where the player is allowed to talk about the heat of an object only if he's properly equipped to detect it.
+Suppose we have a situation where the player is allowed to talk about the heat of an object only if they're properly equipped to detect it.
 
 	{*}"Hot Glass Looks Like Cold Glass"
 
@@ -28,7 +28,7 @@ Suppose we have a situation where the player is allowed to talk about the heat o
 
 	Before printing the plural name of a glass dish when the player wears the goggles: say "[heat] "
 	
-So far, so good. Now, what if the player tries to GET HOT DISH when the goggles are off? "You can't see any such thing." doesn't seem like quite the right response: he can see such a thing. He just doesn't know which it is.
+So far, so good. Now, what if the player tries to GET HOT DISH when the goggles are off? "You can't see any such thing." doesn't seem like quite the right response: they can see such a thing. They just don't know which it is.
 
 We could go on to write a mistake rule that would scold the player for trying "get [heat] [text]" when not wearing the goggles. The problem is that this would not cover any other phrasing of the command, nor would it account for all the many other things the player might try to do with an object specified by heat. 
 
@@ -49,4 +49,4 @@ What we really want is to catch all instances of the player using the property n
 	Instead of asking Claudia for something:
 		say "She clears her throat faintly and glances at [the second noun], as though to say that it's not hers to give." 
 	
-	Test me with "get all / drop all / look / wear goggles / look / ask claudia for cream / put cream in hot dish / put cream in cold dish / remove goggles / get hot dish".
+	Test me with "get all / drop all / look / wear goggles / look / ask claudia for cream / put cream in hot dish / put cream in cold dish / remove goggles / get hot dish".

resources/Documentation/Examples/Donut.txt

@@ -1,5 +1,5 @@
 **** Spontaneous actions by other people
-(Person who pursues his own goals each turn; Boston Cream)
+(Person who pursues their own goals each turn; Boston Cream)
 A fuller implementation of Ogg, giving him a motivation of his own and allowing him to react to the situation created by the player.
 
 	{*}"Boston Cream"

resources/Documentation/Examples/DownInOodville.txt

@@ -1,12 +1,12 @@
 ** Understanding kinds of value
 (Menu of numerical options; Down in Oodville)
-Offering the player a choice of numbered options at certain times, without otherwise interfering with his ability to give regular commands.
+Offering the player a choice of numbered options at certain times, without otherwise interfering with their ability to give regular commands.
 
 Now and then in IF there is a situation where we need to ask the player for a numbered choice rather than an ordinary action command. What's more, that numbered choice might change during the game, so we don't want to just hard-wire the meanings of "1", "2", and "3" whenever the player types them.
 
 A better trick is to keep a list or table (we'll use a table here because it involves slightly less overhead) recording what the player's numerical choices currently mean. Then every time the player selects a number, the table is consulted, and if the number corresponds to something, the player's choice is acted on.
 
-In our example, we'll have a transporter pad that can take the player to any room in the game that he's already visited. (Just for the sake of example, we'll start him off with a few pre-visited rooms.) 
+In our example, we'll have a transporter pad that can take the player to any room in the story that they've already visited. (Just for the sake of example, we'll start him off with a few pre-visited rooms.) 
 
 	{*}"Down in Oodville"
 	
@@ -83,4 +83,4 @@ In our example, we'll have a transporter pad that can take the player to any roo
 	
 	Test me with "get on pad / 0 / -1 / 8 / 2 / look / w / home / get on pad / get off pad / 3".
 
-If we wanted to replace the regular command structure entirely with numbered menus, or use menus to hold conversation options, we could: several Inform extensions provide these functions.
+If we wanted to replace the regular command structure entirely with numbered menus, or use menus to hold conversation options, we could: several Inform extensions provide these functions.

resources/Documentation/Examples/Elevator.txt

@@ -87,7 +87,7 @@ In charity, though, let us assume that the author has a legitimate reason for wa
 	
 	Test me with "press 3 / in / press button 3 / look / out / in / press 27 / out / s / in / n / in / press 15 / out / in / press 18 / out / s / in / n / in / press 4 button / out".
 		
-This will all work very well, unless the player has portable objects; in that case, anything he drops on the Generic Floor will be there every time he goes back -- whether it's masquerading as Floor 6 or Floor 23. There are there are two ways round this -- (i) the cheeky way. When we drop something, the unobtrusive yet ever-vigilant maids pick it up and take it down to the Foyer's lost property office; and (ii) the super-duper way, in which things are moved out of play but with their floor numbers remembered, so that the scenario can be reconstructed each time. (i) is probably in fact the more true-to-life, considering the hotel's boasts about its service, but we will demonstrate both methods.
+This will all work very well, unless the player has portable objects; in that case, anything they drop on the Generic Floor will be there every time they go back -- whether it's masquerading as Floor 6 or Floor 23. There are there are two ways round this -- (i) the cheeky way. When we drop something, the unobtrusive yet ever-vigilant maids pick it up and take it down to the Foyer's lost property office; and (ii) the super-duper way, in which things are moved out of play but with their floor numbers remembered, so that the scenario can be reconstructed each time. (i) is probably in fact the more true-to-life, considering the hotel's boasts about its service, but we will demonstrate both methods.
 
 Here is the version with vigilant maids:
 
@@ -100,7 +100,7 @@ Here is the version with vigilant maids:
 	
 	Test maids with "in / press 6 / out / drop all / in / out / in / press 23 / out / in / press 1 / out / s / get all".
 	
-Notice that we tie the maid service to the pressing of the lift button, so that if the player just goes into the lift and comes out again, the maids will not have had a chance to clear his possessions. 
+Notice that we tie the maid service to the pressing of the lift button, so that if the player just goes into the lift and comes out again, the maids will not have had a chance to clear the dropped items.
 
 Alternatively:
 
@@ -129,6 +129,6 @@ The "enclosed by" line clears even things left on, say, small un-portable side-t
 	
 	Test management with "get all from bag / in / press 22 / out / drop tickets / in / press 23 / out / drop gown / in / press 22 / out / get tickets / in / press 23 / out / get gown".
 	
-And now we have a situation in which the player's valuables are left untouched wherever in the hotel he happens to abandon them.
+And now we have a situation in which the player's valuables are left untouched wherever in the hotel they happen to abandon them.
 	
-Incidentally, this example was almost set in an entirely different location: the largest hotel in the world may some day be the Ryugyong Hotel in Pyongyang, North Korea, with its 105 floors -- but for some years construction halted at the creation of the building's huge concrete shell.
+Incidentally, this example was almost set in an entirely different location: the largest hotel in the world may some day be the Ryugyong Hotel in Pyongyang, North Korea, with its 105 floors -- but for some years construction halted at the creation of the building's huge concrete shell.

resources/Documentation/Examples/Examination.txt

@@ -1,8 +1,8 @@
 * After rules
 (TAKE prints a description; Morning After)
-When the player picks something up which he hasn't already examined, the object is described.
+When the player picks something up which they haven't already examined, the object is described.
 
-Suppose we want to make the player's life slightly easier by examining everything he picks up, if he hasn't already examined it.
+Suppose we want to make the player's life slightly easier by examining everything they pick up, if they haven't already examined it.
 
 	{*}"Morning After"
 
@@ -25,4 +25,4 @@ Carry out rules are explained in more detail in the chapter on advanced action h
 
 	The hangover cure is a thing in the Red Door Saloon. The description of the hangover cure is "Two yellow egg-yolks unbroken in a red-brown liquid. Yep."
 	
-	Test me with "x pistol / get all".
+	Test me with "x pistol / get all".

resources/Documentation/Examples/Exits.txt

@@ -10,7 +10,7 @@ It may sometimes be helpful to prompt the player with a list of exits printed up
 		now left hand status line is "Nearby: [if a room is adjacent][the list of adjacent rooms][end if][if a room is adjacent and a door is visible] and [end if][if a door is visible][the list of visible doors][end if]";
 		now right hand status line is "".
 	
-Of course, we may not want to tell the player what glories are to be found in locations he hasn't yet explored. 
+Of course, we may not want to tell the player what glories are to be found in locations they haven't yet explored. 
 
 	{**}Rule for printing the name of an unvisited room (called the target) while constructing the status line:
 		let aim be the best route from the location to the target;
@@ -51,4 +51,4 @@ Everywhere else, the names of directions will still be printed out in full in th
 	
 	Test me with "n / w / s".
 	
-Note that while this looks fine in some places, other locations exceed the limits of what the status-line can hold: if any given room is going to have a large number of exits, this kind of listing will almost certainly not fit. So apply cautiously. 
+Note that while this looks fine in some places, other locations exceed the limits of what the status-line can hold: if any given room is going to have a large number of exits, this kind of listing will almost certainly not fit. So apply cautiously. 

resources/Documentation/Examples/ExtraSupplies.txt

@@ -2,7 +2,7 @@
 (Faux-infinite supply of red pens; Extra Supplies)
 A supply of red pens from which the player can take another pen only if he doesn't already have one somewhere in the game world.
 
-Suppose we have a supply closet in our game from which the player is allowed to take red pens. To keep modeling simple, we only allow him to have one in play at a time, and we test this by seeing whether the red pen is "off-stage" before moving it to his possession.
+Suppose we have a supply closet in our game from which the player is allowed to take red pens. To keep modeling simple, we only allow them to have one in play at a time, and we test this by seeing whether the red pen is "off-stage" before moving it to their possession.
 
 This approach might seem no different from having a single red pen sitting in the closet, but it may be preferable, for two reasons. First, it's not very plausible for a supply closet to contain nothing but a single red pen (well, assuming a well-regulated supplier, anyway); and second, it gives the player a way to get a new red pen should the original be destroyed in a tragic handwriting accident.
 
@@ -25,4 +25,4 @@ This approach might seem no different from having a single red pen sitting in th
 		now the noun is nowhere;
 		say "A fiery blast consumes [the noun]!"
 		
-	Test me with "get pen / i / get pen / get supply / s / put pen in incinerator / n / get pen".
+	Test me with "get pen / i / get pen / get supply / s / put pen in incinerator / n / get pen".

resources/Documentation/Examples/FactsWereThese.txt

@@ -18,7 +18,7 @@ We start by creating the idea that everything in the game has a monetary value:
 
 	Understand "give [things preferably held] to [someone]" as multiply-giving it to. Understand "give [things] to [someone]" as multiply-giving it to.  Multiply-giving it to is an action applying to two things.
 	
-A subtlety here: we say "things preferably held" to prefer items that the player is holding (so if the player has two dollars in hand and a third lies on the ground, he will use just the two he has). 
+A subtlety here: we say "things preferably held" to prefer items that the player is holding (so if the player has two dollars in hand and a third lies on the ground, they will use just the two they have). 
 
 The second grammar line allows Inform to match things that aren't held if it can't make up the list from things that are. If all three dollars are on the ground, the player can pick them up before spending them.
 

resources/Documentation/Examples/FifthBody-G.txt

@@ -1,8 +1,8 @@
 ** Writing, reading and appending text to files
 (WRITE IN command that will open a free-text mode--Notebooks that can be written in as a separate command line; The Fifth Body)
-An expansion on the notebook, allowing the player somewhat more room in which to type his recorded remark.
+An expansion on the notebook, allowing the player somewhat more room in which to type their recorded remark.
 
-The implementation here is much like that of the previous example, except that we allow the player to write his notebook input as a separate command, leading to an exchange such as
+The implementation here is much like that of the previous example, except that we allow the player to write their notebook input as a separate command, leading to an exchange such as
 
 	>write in my notebook
 	You open your notebook and prepare to write in it.
@@ -63,7 +63,7 @@ The opening is much as before:
 
 Now what happens is that the player, having typed WRITE IN NOTEBOOK, will be faced with a ">>" prompt instead of the usual ">": a sign that the input mode has changed. 
 
-The next code is to react to reading a command. Whatever the player types at the >> prompt when the target jotter is set will now be recorded in the notebook, though with a character limit of about 60-100 characters depending on how much upper-case and punctuation he uses. (There are ways to lift the character length restriction as well, but they would take us into deeper waters.)
+The next code is to react to reading a command. Whatever the player types at the >> prompt when the target jotter is set will now be recorded in the notebook, though with a character limit of about 60-100 characters depending on how much upper-case and punctuation they use. (There are ways to lift the character length restriction as well, but they would take us into deeper waters.)
 	
 	{**}After reading a command when target jotter is a jotter:
 		now the command prompt is ">";

resources/Documentation/Examples/Finality.txt

@@ -2,7 +2,7 @@
 (UNDO not mentioned in the final question; Finality)
 Not mentioning UNDO in the final set of options.
 
-By default, Inform reminds the player that he has the option of typing UNDO after a story-ending action. This is generally good practice, especially for the sake of novice players who might not be aware of this possibility otherwise, and might be frustrated by a loss they could easily step back from.
+By default, Inform reminds the player that they have the option of typing UNDO after a story-ending action. This is generally good practice, especially for the sake of novice players who might not be aware of this possibility otherwise, and might be frustrated by a loss they could easily step back from.
 
 Just occasionally, though, we may decide that the player does not deserve any such notification:
 
@@ -24,4 +24,4 @@ And if we decided that we didn't want the player to be able to undo the command
 
 	{**}Use undo prevention.
 	
-	Test me with "jump".
+	Test me with "jump".

resources/Documentation/Examples/FineLaid.txt

@@ -2,7 +2,7 @@
 (Redirecting actions to new objects; Fine Laid)
 Making writing that can be separately examined from the paper on which it appears, but which directs all other actions to the paper.
 
-Sometimes it is useful to direct all -- or almost all -- actions from one object to another. For the sake of argument, say we have a sheet of paper with writing on it, and (because we're very meticulous) we want to let the player examine the writing and get a customized response, different from when he just examines the sheet of paper. But for all other purposes -- say, TAKE or TASTE -- we want the two objects to be treated as one.
+Sometimes it is useful to direct all -- or almost all -- actions from one object to another. For the sake of argument, say we have a sheet of paper with writing on it, and (because we're very meticulous) we want to let the player examine the writing and get a customized response, different from when they just examine the sheet of paper. But for all other purposes -- say, TAKE or TASTE -- we want the two objects to be treated as one.
 
 Here, we approach the problem by changing the noun and/or the second noun of the current action, then issuing a new command to "try the current action". Because we've changed the noun and second noun, the "current action" at this point is different from the one generated originally by the player's command.
 
@@ -21,4 +21,4 @@ Here, we approach the problem by changing the noun and/or the second noun of the
 		if the writing is the second noun, now the second noun is the sheet of paper;
 		try the current action instead.
 	
-	Test me with "examine sheet of paper / examine writing / get writing / taste writing". 
+	Test me with "examine sheet of paper / examine writing / get writing / taste writing". 

resources/Documentation/Examples/ForDemonstrationPurposes.txt

@@ -34,7 +34,7 @@ Thanks to Jesse McGrew for the initial design of this example.
 	
 	The learning by observation rule is listed after the report stage rule in the specific action-processing rules.
 	
-	Definition: a person is other if he is not the player.
+	Definition: a person is other if they are not the player.
 	
 	This is the learning by observation rule:
 		repeat with the viewer running through other people who can see the player:
@@ -49,4 +49,4 @@ Thanks to Jesse McGrew for the initial design of this example.
 	When play begins: 
 		now Clark is capable of taking inventory. 
 	
-	Test me with "Clark, inventory / Clark, x me / x me / Clark, x me".
+	Test me with "Clark, inventory / Clark, x me / x me / Clark, x me".

resources/Documentation/Examples/Former.txt

@@ -1,14 +1,14 @@
 *** Going from, going to
 (GO BACK command; Polarity)
-A "go back" command that keeps track of the direction from which the player came, and sends him back.
+A "go back" command that keeps track of the direction from which the player came, and sends them back.
 
-The main trick of this is always to record where the player has gone when he has just moved. 
+The main trick of this is always to record where the player has gone when they have just moved. 
 
 	{*}"Polarity"
 	
 	The former location is a room that varies.
 
-Here we record where the player has been before moving him; by calling this the "first carry out going rule", we make sure that this rule is followed during the going action before any other pieces of the movement occur. For more detail, see the chapters on advanced actions and on rules.
+Here we record where the player has been before moving them; by calling this the "first carry out going rule", we make sure that this rule is followed during the going action before any other pieces of the movement occur. For more detail, see the chapters on advanced actions and on rules.
 
 	{**}First carry out going rule:
 		now the former location is the location.
@@ -32,4 +32,4 @@ And to deal with the case where the player has not yet moved:
 
 	The church door is east of Eastern End and west of the Courtyard. The church door is a door.
 
-	Test me with "back / n / go back / e / open door / go through door / go back".
+	Test me with "back / n / go back / e / open door / go through door / go back".

resources/Documentation/Examples/FourthBody-G.txt

@@ -2,7 +2,7 @@
 (WRITE text IN command that will store text--Notebooks that can be written in; The Fourth Body)
 Notebooks in which the player can record assorted notes throughout play.
 
-Some mystery games supply the player with an in-game system for taking notes, in case he doesn't want to rely on scraps of paper next to the computer. One way of doing this is to write out all the player's notes and observations into a notebook file, whose contents can be retrieved during play (or, indeed, after it).
+Some mystery games supply the player with an in-game system for taking notes, in case they don't want to rely on scraps of paper next to the computer. One way of doing this is to write out all the player's notes and observations into a notebook file, whose contents can be retrieved during play (or, indeed, after it).
 
 We'll first invent a general system for writing text into notebooks, by creating a new kind called jotter. Each individual jotter will have its own disc file, and there will be basically three things which can be done with jotters: erasing, reading and writing.
 

resources/Documentation/Examples/FunWithParticiples.txt

@@ -2,7 +2,7 @@
 (Describing ongoing character behavior with participles; Fun with Participles)
 Creating dynamic room descriptions that contain sentences such as "Clark is here, wasting time" or "Clark is here, looking around" depending on Clark's idle activity.
 
-Mostly the Standard Rules use verbs adapted to finite forms ("he jumped", "we take the hammer", and so on). But Inform can also produce participles to describe actions that are ongoing: "he is carrying the fedora" or "taking the hammer..."
+Mostly the Standard Rules use verbs adapted to finite forms ("she jumped", "we take the hammer", and so on). But Inform can also produce participles to describe actions that are ongoing: "he is carrying the fedora" or "taking the hammer..."
 
 In this example, we give non-player characters actions to perform and then have Inform dynamically describe what they're doing when the player chooses to look. 
 

resources/Documentation/Examples/Fussy.txt

@@ -138,7 +138,7 @@ This example does include a number of features that we haven't met yet, particul
 	Instead of going to an adjacent room when the player is in the Dining Room:
 		say "'You're not leaving!?' whimpers the table at once."
 	
-Moreover, every time the player gets close to resolving this issue, his unhelpful companion Alison brings in something else inconvenient. We can use the counting of contented supporters to decide when the player is getting close to winning and it's time for her to bring something else...
+Moreover, every time the player gets close to resolving this issue, their unhelpful companion Alison brings in something else inconvenient. We can use the counting of contented supporters to decide when the player is getting close to winning and it's time for her to bring something else...
 
 	{**}Section 5 - Source of Further Complications
 
@@ -181,7 +181,7 @@ Moreover, every time the player gets close to resolving this issue, his unhelpfu
 			say "Just then the kettle boils in the kitchen. Whistling chirpily, Alison brings it in and sets it down smack on [the next victim], then goes back out.";
 			rule succeeds.	
 		
-And just so that the player knows where he stands at the end of each turn:
+And just so that the player knows where they stand at the end of each turn:
 	
 	{**}Section 6 - General Assessment 
 

resources/Documentation/Examples/Gender.txt

@@ -12,7 +12,7 @@ Suppose we would like to allow the player to choose a gender for the main charac
 		otherwise now the player is female; 
 		say paragraph break. 
 	
-Now a piece of Inform 6 code handles the unusual input. It's not necessary to understand this to use it, and the code should work for any question you'd like to ask the player. The first three words in quotation marks ('male', 'M', 'man'...) correspond to positive feedback; the later three words correspond to negative feedback. So "to decide whether men win" will be true if the player types one of the first three, and false if he types one of the last three.
+Now a piece of Inform 6 code handles the unusual input. It's not necessary to understand this to use it, and the code should work for any question you'd like to ask the player. The first three words in quotation marks ('male', 'M', 'man'...) correspond to positive feedback; the later three words correspond to negative feedback. So "to decide whether men win" will be true if the player types one of the first three, and false if they type one of the last three.
 
 	{**}To decide whether men win:
 		(- Question('male','M//','man','female','F//','woman') -)
@@ -38,4 +38,4 @@ Now a piece of Inform 6 code handles the unusual input. It's not necessary to un
 	Instead of examining the player when the player is male:
 		say "Congratulations, you are a boy!"
 	
-	The Room of Self-Knowledge is a room. "Mirrors cover every available wall-surface of this hexagonal chamber, allowing you to examine yourself from all angles."
+	The Room of Self-Knowledge is a room. "Mirrors cover every available wall-surface of this hexagonal chamber, allowing you to examine yourself from all angles."

resources/Documentation/Examples/Girls.txt

@@ -2,7 +2,7 @@
 (Randomized pedestrian passer-by; Uptown Girls)
 A stream of random pedestrians who go by the player.
 
-Suppose we have an urban space we want to populate with random passers-by. These should have a range of characteristics and not always be described in the same way; and once the player has noticed one, he should be able to look at her further, until another pedestrian crosses his path.
+Suppose we have an urban space we want to populate with random women. These should have a range of characteristics and not always be described in the same way; and once the player has noticed one, they should be able to look at the passer-by further, until another pedestrian crosses their path.
 
 	{*}"Uptown Girls"
 
@@ -78,4 +78,4 @@ If we also wanted each of those combinations to mean some more specifically-desc
 	blonde	medium-height	tidy	"A rounded, Marilyn-esque blonde."
 	blonde	short	tidy	 "Pin-precise in a blue-and-white striped suit and a boyish haircut."	
 	
-	Test me with "z / z / x passerby / z / z / x passerby".
+	Test me with "z / z / x passerby / z / z / x passerby".

resources/Documentation/Examples/Grapes.txt

@@ -2,7 +2,7 @@
 (Scope approaches compared; Peeled)
 Two different approaches to adjusting what the player can interact with, compared.
 
-Suppose we have a situation where the player is in darkness, but is allowed to feel and interact with (except for examining) any large objects. In that case, we write a scope rule that puts those large objects into scope all the time, and trust the "requires light" aspect of verbs like examining to prevent the player from doing any actions that he shouldn't:
+Suppose we have a situation where the player is in darkness, but is allowed to feel and interact with (except for examining) any large objects. In that case, we write a scope rule that puts those large objects into scope all the time, and trust the "requires light" aspect of verbs like examining to prevent the player from doing any actions that they shouldn't:
 
 	{*}"Peeled"
 	
@@ -39,4 +39,4 @@ Alternatively, suppose we have a situation in which the player can use one comma
 
 	Test me with "ask about catsuit / x catsuit".
 	
-All this said, there do arise certain complex situations when we want an activity-specific scoping.
+All this said, there do arise certain complex situations when we want an activity-specific scoping.

resources/Documentation/Examples/Grilling.txt

@@ -1,6 +1,6 @@
 * Instead rules
 (Supporter from which the player cannot take things; Grilling)
-A grill, from which the player is not allowed to take anything lest he burn himself.
+A grill, from which the player is not allowed to take anything lest they're burned.
 
 Descriptions of objects can be used in "Instead" rules: we can not only say "Instead of taking the steak", but also "Instead of taking something" or "Instead of taking something which is on the grill". 
 
@@ -19,4 +19,4 @@ That last rule is useful if, for example, we want to prevent the player from int
 	
 We could just as easily adapt this rule to affect a container: "Instead of taking something which is in the ice chest," for example. 
 
-Note also that in older versions of Inform, the pattern "get all from..." was treated differently from "get steak", and had to be accounted for separately. This is no longer the case; this instead of taking... rule will handle all the phrasings which the player might use to try to acquire this object.
+Note also that in older versions of Inform, the pattern "get all from..." was treated differently from "get steak", and had to be accounted for separately. This is no longer the case; this instead of taking... rule will handle all the phrasings which the player might use to try to acquire this object.

resources/Documentation/Examples/Harrison.txt

@@ -2,7 +2,7 @@
 (Smuggler carrying hidden items; Search and Seizure)
 A smuggler who has items, some of which are hidden.
 
-Suppose we want a character who carries hidden objects, but only while he is wearing his jacket. If we deprive him of this, his other possessions become known. Furthermore, if we ever search him, his possessions also become known, and can thereafter be mentioned by us.
+Suppose we want a character who carries hidden objects, but only while they are wearing their jacket. If we deprive them of this, their other possessions become known. Furthermore, if we ever search them, their possessions also become known, and can thereafter be mentioned by us.
 
 	{*}"Search and Seizure"
 
@@ -12,7 +12,7 @@ Suppose we want a character who carries hidden objects, but only while he is wea
 
 	A thing can be discovered or secret. A thing is usually secret.
 	
-Now, we want the character to be able to hide small things if he has some sort of concealing garment on. We also want to be able to see anything that the player has already found once, perhaps by using the >SEARCH PERSON command. So:
+Now, we want the character to be able to hide small things if they have some sort of concealing garment on. We also want to be able to see anything that the player has already found once, perhaps by using the >SEARCH PERSON command. So:
 
 	{**}Rule for deciding the concealed possessions of someone (called the suspect):
 		if the particular possession is discovered, no;

resources/Documentation/Examples/Hatless.txt

@@ -14,14 +14,14 @@ Suppose we want a game in which each scenario starts with the characters wearing
 	Rule for writing a paragraph about a hatless person (called the target):
 		say "[The target] mopes about, hatless."
 
-	A hat is a kind of thing. A hat is always wearable. Definition: a person is hatless if he is not the player and he does not wear a hat.
+	A hat is a kind of thing. A hat is always wearable. Definition: a person is hatless if they are not the player and they do not wear a hat.
 
 	The indigo bowler, the polka-dotted fedora, the pink beret, and the scarlet cloche are hats.	
 		
 	When play begins:
 		now every hat is worn by a random hatless person.
 	
-And we might hope that this would choose a new hatless person for each hat, but we would be wrong. It will instead choose one hatless person and put all the hats on him -- and everyone else has to go bare-headed. That's clearly no good. Let's try again:
+And we might hope that this would choose a new hatless person for each hat, but we would be wrong. It will instead choose one hatless person and put all the hats on that one person -- and everyone else has to go bare-headed. That's clearly no good. Let's try again:
 
 	{*}"Hatless 2"
 	
@@ -33,7 +33,7 @@ And we might hope that this would choose a new hatless person for each hat, but
 	Rule for writing a paragraph about a hatless person (called the target):
 		say "[The target] mopes about, hatless."
 
-	A hat is a kind of thing. A hat is always wearable. Definition: a person is hatless if he is not the player and he does not wear a hat.
+	A hat is a kind of thing. A hat is always wearable. Definition: a person is hatless if they are not the player and they do not wear a hat.
 
 	The indigo bowler, the polka-dotted fedora, the pink beret, and the scarlet cloche are hats.	
 
@@ -54,7 +54,7 @@ In this case, we do have to expand out our loop so that the game makes an explic
 	Rule for writing a paragraph about a hatless person (called the target):
 		say "[The target] mopes about, hatless."
 
-	A hat is a kind of thing. A hat is always wearable. Definition: a person is hatless if he is not the player and he does not wear a hat.
+	A hat is a kind of thing. A hat is always wearable. Definition: a person is hatless if they are not the player and they do not wear a hat.
 
 	The indigo bowler, the polka-dotted fedora, the pink beret, and the scarlet cloche are hats.	
 

resources/Documentation/Examples/Hover.txt

@@ -1,6 +1,6 @@
 *** Vehicles and pushable things
 (Description from inside a vehicle; Hover)
-Letting the player see a modified room description when he's viewing the place from inside a vehicle. 
+Letting the player see a modified room description when they're viewing the place from inside a vehicle. 
 
 Suppose we want the player to see a modified room description when he's viewing the place from inside a vehicle. There are several conceivable ways of doing this; the example here shows a rather advanced way, but is very flexible and will let us write all sorts of special cases.
 
@@ -37,4 +37,4 @@ In fact, as a special refinement, we could even say:
 	
 	Test me with "get in bubble / look / west / take all / look / get out / east".
 	
-And now anything that's beside us in the vehicle will be described during that first paragraph, rather than later on.
+And now anything that's beside us in the vehicle will be described during that first paragraph, rather than later on.

resources/Documentation/Examples/Hudsucker.txt

@@ -2,7 +2,7 @@
 (Letters described as a group; Hudsucker Industries)
 Letters which are described differently as a group, depending on whether the player has read none, some, or all of them, and on whether they are alike or unlike.
 
-In this scenario, the player starts with a bag full of unsorted letters. These can be polite or rude, but he won't know which until he has examined them. What's more, he is allowed to sort the letters, in which case a group of letters will be shown as (for instance) "two polite letters"; but a group of mixed letters, even if they have all been read, will be called "unsorted letters".
+In this scenario, the player starts with a bag full of unsorted letters. These can be polite or rude, but they won't know which until they have examined them. What's more, they are allowed to sort the letters, in which case a group of letters will be shown as (for instance) "two polite letters"; but a group of mixed letters, even if they have all been read, will be called "unsorted letters".
 
 Further, the player should be allowed to refer to sorted letters by tone, but not unsorted letters.
 
@@ -49,7 +49,7 @@ To do this, we'll need printing the name... and printing the plural name..., as
 
 	The plural of mailbox is mailboxes. A mailbox is a kind of container. The CEO box is a mailbox. The Hold box is a mailbox. The Trash box is a mailbox. Understand "mailbox" as a mailbox.
  
-Now, there's a good bit of interaction to streamline. We intend that the player will be taking letters from the satchel, reading them, and putting them (perhaps grouped) into boxes. Our interaction rules should assist in this process as much as possible. To start with, the player will be most likely to examine letters he hasn't read yet:
+Now, there's a good bit of interaction to streamline. We intend that the player will be taking letters from the satchel, reading them, and putting them (perhaps grouped) into boxes. Our interaction rules should assist in this process as much as possible. To start with, the player will be most likely to examine letters they haven't read yet:
 
 	{**}Does the player mean examining a letter (called the subject):
 		if we have examined the subject, it is very unlikely;
@@ -67,7 +67,7 @@ The rules about taking are more subtle: the player is more likely to want to tak
 		if the subject is in the satchel, it is very likely;
 		it is possible.
 
-And finally, we will assume by default that anything other than examining or taking is most likely to apply to a letter he's already identified:
+And finally, we will assume by default that anything other than examining or taking is most likely to apply to a letter they've already identified:
 	
 	{**}Does the player mean doing something other than examining or taking with a letter (called the subject):
 		if we have examined the subject, it is likely;
@@ -84,4 +84,4 @@ And we would also like to understand properties under the same circumstances as
 
 	Test me with "inventory / examine letter / get letter / i / put letter in ceo box / inventory / get letter / x letter / g / g / i / x letter / g / g / i / put letter in hold box / get letter / g / g / i".
 
-That last "repeat" is merely a device to shuffle the order of items in the satchel so that the player will not always encounter the letters in a neatly presorted order, despite our defining them that way. (Of course, that means that the test produced by TEST ME cannot be very exciting...)
+That last "repeat" is merely a device to shuffle the order of items in the satchel so that the player will not always encounter the letters in a neatly presorted order, despite our defining them that way. (Of course, that means that the test produced by TEST ME cannot be very exciting...)

resources/Documentation/Examples/IPA.txt

@@ -1,8 +1,8 @@
 ** The time of day
 (Shops open and close at specific hours; IPA)
-Shops which each have opening and closing hours, so that it is impossible to go in at the wrong times, and the player is kicked out if he overstays his welcome.
+Shops which each have opening and closing hours, so that it is impossible to go in at the wrong times, and the player is kicked out if they overstay their welcome.
 
-Suppose we wanted a game set in a living town, with locations opening and closing at different times of day, and business carrying on as usual. The point might be to force the player to plan his itinerary carefully to hit the right spots at the right times; or we might be writing a more contemplative piece, where part of the enjoyment came from just watching the characters wander around doing their daily business...
+Suppose we wanted a game set in a living town, with locations opening and closing at different times of day, and business carrying on as usual. The point might be to force the player to plan an itinerary carefully to hit the right spots at the right times; or we might be writing a more contemplative piece, where part of the enjoyment came from just watching the characters wander around doing their daily business...
 
 	{*}"IPA"
 
@@ -40,4 +40,4 @@ Suppose we wanted a game set in a living town, with locations opening and closin
 	
 	Noah's Bagels is a shop. It is north of the Parking Lot. The opening hour of Noah's Bagels is 6:00 AM. The closing hour of Noah's Bagels is 11:00 AM. "The selection has been somewhat picked over, leaving you with your choice of Pumpernickel, Asiago, or Everything."
 	
-	Test me with "e / e / n / z / s / e / z / e / z / z / e".
+	Test me with "e / e / n / z / s / e / z / e / z / z / e".

resources/Documentation/Examples/PuncakJaya.txt

@@ -39,4 +39,4 @@ Based on the "representation" relation, we now devise a conditional relation tha
  
 	Test me with "x kippax / up / x kippax / kiss kippax / kippax, hello".
 	
-Further complications of this example might require that the player meet a character before being able to refer to him or her.
+Further complications of this example might require that the player meet a character before being able to refer to them.

resources/Documentation/The Recipe Book.txt

@@ -272,7 +272,7 @@ Finally, the looking command lists visible non-scenery items that sit on scenery
 
 These paragraphs can be manipulated with the printing the locale description activity and the printing a locale paragraph about activity.
 
-Another common thing we may want to do is change the description of a room depending on whether we've been there before (as in <b>Slightly Wrong</b>) or on how often we've visited (as in <b>Infiltration</b>). <b>Night Sky</b>, meanwhile, changes the description of a room when we've examined another object, so that the player's awareness of his environment is affected by other things the character knows. 
+Another common thing we may want to do is change the description of a room depending on whether we've been there before (as in <b>Slightly Wrong</b>) or on how often we've visited (as in <b>Infiltration</b>). <b>Night Sky</b>, meanwhile, changes the description of a room when we've examined another object, so that a player's awareness of their environment is affected by other things the character knows. 
 
 (See Looking for ways to change the default length of room descriptions.)
 
@@ -385,7 +385,7 @@ Certain complications apply when characters other than the player have to see an
 
 (See Magic (Breaking the Laws of Physics) for a hat that lets the player walk through closed doors.)
 
-(See Modifying Existing Commands for ways to allow the player to unlock with a key he isn't currently holding.)
+(See Modifying Existing Commands for ways to allow the player to unlock with a key that isn't currently being carried.)
 
 [x] Windows
 
@@ -487,7 +487,7 @@ All else being equal, time passes at a rate of one minute per turn. But this nee
 
 <b>Timeless</b> makes certain actions instant, so that they don't count against the clock; this is sometimes useful in timed situations where the player needs to review the situation before going on with a tricky puzzle. <b>Endurance</b> systematically extends this idea to allow us to assign different durations to any action in the story. <b>The Big Sainsbury's</b> goes the opposite direction, and meticulously adds a minute to the clock for all implicit take actions, just so that the player isn't allowed to economize on moves.
 
-An alternative approach to time is not to tell the player specifically what hour of the day it is at all, but to move from one general time period to another as it becomes appropriate - when the player has solved enough puzzles, or worked his way through enough of the plot. To this end we might use scenes representing, say, Thursday afternoon and then Thursday evening; then our scene rules, rather than the clock, would determine when Thursday afternoon stopped and Thursday evening began:
+An alternative approach to time is not to tell the player specifically what hour of the day it is at all, but to move from one general time period to another as it becomes appropriate - when the player has solved enough puzzles, or worked their way through enough of the plot. To this end we might use scenes representing, say, Thursday afternoon and then Thursday evening; then our scene rules, rather than the clock, would determine when Thursday afternoon stopped and Thursday evening began:
 
 	Thursday afternoon is a scene. Thursday evening is a scene.
 	
@@ -512,11 +512,11 @@ Though this gives time a loose relation to the number of turns played, it feels
 ^^{story structure: scenes with scripted events}
 ^^{scenes: scripting story events in scenes}
 
-Sometimes we want to arrange a scene in which something goes on in the background (as though it were a movie playing) while the player goes about his business; or where a series of things has to happen before the player gets to the end.
+Sometimes we want to arrange a scene in which something goes on in the background (as though it were a movie playing) while the player goes about their business; or where a series of things has to happen before the player gets to the end.
 
 The simplest way to arrange background events for a scene is to write the sequence of events into a table and work our way through it, printing one line per turn, until the scene runs out. <b>Day One</b> does exactly this.
 
-At other times, we want a scene to last as long as it takes the <i>player</i> to do something. <b>Entrapment</b> lets the player poke around and explore as much as he likes, but ends as soon as he has accomplished the scene's goal - which, unfortunately for him, is to get into an embarrassing situation so that another character can walk in and make fun of him. <b>The Prague Job</b> has a scene that requires the player to do a more specific set of tasks, but nags him and hurries him along until he's done.
+At other times, we want a scene to last as long as it takes the <i>player</i> to do something. <b>Entrapment</b> lets the player poke around and explore as much as they like, but ends as soon as they have accomplished the scene's goal - which, unfortunately for them, is to get into an embarrassing situation so that another character can walk in and make fun of them. <b>The Prague Job</b> has a scene that requires the player to do a more specific set of tasks, but nags them and hurries them along until they're done.
 
 <b>Bowler Hats and Baby Geese</b> assumes that our story is going to be assembled with a number of scenes, some of which will need to prevent the player from leaving the location until the scene is complete: it thus defines a "restricted" property for scenes, so that all such elements of the plot will work in the same way.
 
@@ -543,7 +543,7 @@ Similarly, we can schedule things during play to happen at a specific time of da
 
 (See Scene Changes for more things that arrive at pre-determined times.)
 
-(See Ships, Trains and Elevators for a train that follows a schedule, carrying the player along if he is aboard.)
+(See Ships, Trains and Elevators for a train that follows a schedule, carrying the player along if they are aboard.)
 
 [x] Scene Changes
 
@@ -554,11 +554,11 @@ Similarly, we can schedule things during play to happen at a specific time of da
 ^^{rules: run at end of scene}
 ^^{rules: for scenes}
 
-In a plot that takes place over multiple locations or has several distinct scenes, we may want to move the player or change the scenery around him. <b>Age of Steam</b> brings a train on and off-stage as the plot requires. <b>Meteoric</b> similarly brings a meteor into view at a certain time of day, showing off several implementations depending on whether or not the player is supposed to be able to refer to the meteor after it has gone.
+In a plot that takes place over multiple locations or has several distinct scenes, we may want to move the player or change the scenery around them. <b>Age of Steam</b> brings a train on and off-stage as the plot requires. <b>Meteoric</b> similarly brings a meteor into view at a certain time of day, showing off several implementations depending on whether or not the player is supposed to be able to refer to the meteor after it has gone.
 
 <b>Entrevaux</b> constructs an organized system such that all scenes have their own lists of props and associated locations, and props are moved on and off automatically. Scene changes are also announced with a pause and a new title, such as "Chapter 2: Abduction".
 
-<b>Space Patrol - Stranded on Jupiter</b> inserts an interlude in which the player's possessions and clothes are switched for new ones and the player moved to a new location - and then put back where he started from.
+<b>Space Patrol - Stranded on Jupiter</b> inserts an interlude in which the player's possessions and clothes are switched for new ones and the player moved to a new location - and then put back where they started from.
 
 (See Flashbacks for more ways to move the player from one level of reality to another.)
 
@@ -582,7 +582,7 @@ The "pause the game" phrase in the same extension offers a more dramatic pause t
 
 Cut-scenes are easy to implement but should be used sparingly, since players often get impatient with long uninteractive passages. A slightly more deluxe implementation might insert an interactive scene that simply happens to be set in the past, before going on with another scene set "now"; and, indeed, some IF abandons the idea of "now" entirely, presenting pieces in a non-chronological order and letting the player work out how the sequence works together.
 
-The most challenging case to implement (though still not very hard) is the one where we remove the player from one scenario, let him play through a flashback with past possessions and clothing, and then restore him to the same situation he left, with all of the same possessions and clothing. <b>Pine 3</b> shows how to do this: the code to change the player's status is isolated at the end of the example, and might fruitfully be reused.  <b>Pine 4</b> expands on the same idea by adding another flashback scene, demonstrating one that can be visited repeatedly and one that can be seen only once.
+The most challenging case to implement (though still not very hard) is the one where we remove the player from one scenario, let them play through a flashback with past possessions and clothing, and then restore them to the same situation they left, with all of the same possessions and clothing. <b>Pine 3</b> shows how to do this: the code to change the player's status is isolated at the end of the example, and might fruitfully be reused.  <b>Pine 4</b> expands on the same idea by adding another flashback scene, demonstrating one that can be visited repeatedly and one that can be seen only once.
 
 (See Scene Changes for more uses of stripping and restoring the player.)
 
@@ -595,9 +595,9 @@ The most challenging case to implement (though still not very hard) is the one w
 ^^^{story structure <-- game structure <-- plot structure}
 ^^{story structure: dynamic plot management}
 
-A plot manager (sometimes called a drama manager) is a piece of the program whose job it is to plan out events so that, whatever the player does, the story advances and an interesting narrative results. The plot manager might, for instance, decide that the player has wandered around for too many scenes without making any progress, and might compensate by making something happen that gives him a new hint on his current problem. It might trigger characters to act when it thinks the story should be reaching a crisis point. It might introduce new complications when it determines that the player is running out of problems to solve.
+A plot manager (sometimes called a drama manager) is a piece of the program whose job it is to plan out events so that, whatever the player does, the story advances and an interesting narrative results. The plot manager might, for instance, decide that the player has wandered around for too many scenes without making any progress, and might compensate by making something happen that gives them a new hint on his current problem. It might trigger characters to act when it thinks the story should be reaching a crisis point. It might introduce new complications when it determines that the player is running out of problems to solve.
 
-This is a theoretically challenging field. Sophisticated plot management requires that the story make difficult guesses, such as whether the player is "stuck" and what the player is working on right now. The advantage of using such a system is that (done very well) it makes the story extremely responsive to the player's behavior, which means that he is a real agent in the unwinding of the plot. It also contributes to the replayability, since trying the story a second or third time will produce quite different outcomes. But it is procedurally difficult to design a good plot management system and it requires a huge amount of content, as well: in order for the plot manager to give the player hints, change the course of events to suit his focus, and so on, the story has to have available many, many more scenes than will ever occur in any single playing.
+This is a theoretically challenging field. Sophisticated plot management requires that the story make difficult guesses, such as whether the player is "stuck" and what the player is working on right now. The advantage of using such a system is that (done very well) it makes the story extremely responsive to the player's behavior, which means that they are a real agent in the unwinding of the plot. It also contributes to the replayability, since trying the story a second or third time will produce quite different outcomes. But it is procedurally difficult to design a good plot management system and it requires a huge amount of content, as well: in order for the plot manager to give the player hints, change the course of events to suit his focus, and so on, the story has to have available many, many more scenes than will ever occur in any single playing.
 
 <b>Fate Steps In</b> is only a <i>very</i> brief sketch in this direction, one in which the "fate" entity is trying to accomplish an end goal and, every turn, looks for ways to push the story towards that conclusion, whatever the player does.
 
@@ -616,7 +616,7 @@ By default, Inform gives the player character (and every other person) a simple
 
 Once we've done this, we may invite ambiguities if the player types LOOK AT FACE; it is this challenge that is addressed in <b>The Night Before</b>.
 
-<b>rBGH</b> gives the player a random height and then uses this to determine how the room should be described around him.
+<b>rBGH</b> gives the player a random height and then uses this to determine how the room should be described around them.
 
 <b>Slouching</b> lets the player (and other characters as well) take different sitting, standing, and lying down positions.
 
@@ -639,7 +639,7 @@ This is not the only way to go - as we'll see in the next section, there's also
 ^^{understand (words) as a mistake+assert+} ^^{understanding: mistakes}
 ^^{actions: understanding as mistakes}
 
-Much of the personality of the player character in IF emerges from what he can and cannot (or will and will not) do; part of the pleasure of playing a character arises from this opportunity for role-playing and role-exploration. Some characters are consciousless daredevils, willing to jump off cliffs, crawl through narrow gaps, and rob widows if the player commands it; others are repressed neurotics who barely dare to speak to other characters or touch anything that doesn't belong to them.
+Much of the personality of the player character in IF emerges from what they can and cannot (or will and will not) do; part of the pleasure of playing a character arises from this opportunity for role-playing and role-exploration. Some characters are consciousless daredevils, willing to jump off cliffs, crawl through narrow gaps, and rob widows if the player commands it; others are repressed neurotics who barely dare to speak to other characters or touch anything that doesn't belong to them.
 
 <b>Finishing School</b> and <b>Dearth and the Maiden</b> both treat the case of a character constrained by good manners and a sense of polite society: the former forbids only one action, while the latter condemns a whole range of them.
 
@@ -653,7 +653,7 @@ We can liven up the interactive aspect of characterization if we give the player
 
 	Understand "bite nails" as a mistake ("Your only nail remaining is the one on your left thumb, and you're saving it for the AP Calculus exam.").
 	
-(Of course, we would need to have hinted to the player that nail-biting is characteristic of his character.)
+(Of course, we would need to have hinted to the player that nail-biting is characteristic of the player character.)
 
 (See Clothing for more on dressing characters up.)
 
@@ -669,7 +669,7 @@ We can liven up the interactive aspect of characterization if we give the player
 
 In IF, as in all interactive storytelling, an essential problem is that the player does not begin the story knowing everything that the player character should, and so may implausibly bumble through situations that the player character should be quite comfortable in. If the player character has friends, an unusual job, a home or environment we're not familiar with, a secret past, these will all be a blank to the player. 
 
-Some games get around this by making the player character an amnesiac, or positioning him as a newcomer to a strange world in which his disorientation is explicable; but there are stories that cannot be told this way, and so we need other methods of getting the player to know what the player character already does.
+Some games get around this by making the player character an amnesiac, or positioning them as a newcomer to a strange world in which their disorientation is explicable; but there are stories that cannot be told this way, and so we need other methods of getting the player to know what the player character already does.
 
 Our first opportunity to inform the player about the player character is in the opening text of a story: 
 
@@ -682,7 +682,7 @@ We may also want to write descriptions of objects to give extra background infor
 	
 	The description of the newspaper is "A rolled-up newspaper[if unexamined], and thus a symbol of your newly-single state: Elise always had it open and the Local Metro section next to your plate by the time you got out of the shower[end if]."
 
-To expand on this, we could give the player a THINK ABOUT or REMEMBER command, with which he can call up information about people he meets or references he encounters in descriptions, so that he could (for instance) next type REMEMBER ELISE. <b>Merlin</b> demonstrates one way to implement a character with memory; <b>One of Those Mornings</b> puts a twist on this by letting the player FIND things which he knows his character possessed at some time before the story started.
+To expand on this, we could give the player a THINK ABOUT or REMEMBER command, with which they can call up information about people they meet or references they encounter in descriptions, so that they could (for instance) next type REMEMBER ELISE. <b>Merlin</b> demonstrates one way to implement a character with memory; <b>One of Those Mornings</b> puts a twist on this by letting the player FIND things which they know the player character possessed at some time before the story started.
 
 [x] Memory and Knowledge
 
@@ -713,7 +713,7 @@ or -- to have things remembered from the first moment they're mentioned in a roo
 
 The mental model need not always be accurate, of course. We might, for instance, have occasion to keep track of where the player character last saw something, even if the object has since been moved; or keep track of falsehoods the player character has been told in conversation; or make the player refer to a character as "the bearded man" until he is properly introduced. 
 
-Included with Inform is the extension Epistemology, by ^{@Eric Eve}, which provides one way of tracking this kind of information. Epistemology distinguishes between items that the player character has seen, because they're objects in a room the player has been to, and items that are familiar to the player for other reasons, such as a quest item he knows about but hasn't found yet, or an abstract conversation topic. Anything that is either seen or familiar is counted as "known".  
+Included with Inform is the extension Epistemology, by ^{@Eric Eve}, which provides one way of tracking this kind of information. Epistemology distinguishes between items that the player character has seen, because they're objects in a room the player has been to, and items that are familiar to the player for other reasons, such as a quest item they know about but haven't found yet, or an abstract conversation topic. Anything that is either seen or familiar is counted as "known".  
 
 Modeling what the player does and does not know is only half the job, of course: we also need that information to affect the behavior of the story in plausible ways.
 
@@ -741,11 +741,11 @@ If the player mentions an object that is not "in scope" -- say, a red hat left b
 
 This is not the only possible way for interactive fiction to handle such communication. Some games will respond differently to EXAMINE RED HAT and EXAMINE FURSZWIGGLE, saying in the first case something like "You can't see that now" and in the second "I don't know the word 'furszwiggle'." 
 
-The drawback of such behavior is that the player can make premature discoveries. If he hasn't found a sword yet, but thinks there may be a sword later in the story, he can type EXAMINE SWORD and see from the response whether his guess is correct. Nonetheless, there are people who prefer this alternative exactly because it does expose the limits of the story's understanding, preventing fruitless attempts to use a word that is not recognized at all. If it is desirable, there is an extension that will reproduce this behavior in Inform as well.
+The drawback of such behavior is that the player can make premature discoveries. If they haven't found a sword yet, but think there may be a sword later in the story, they can type EXAMINE SWORD and see from the response whether their guess is correct. Nonetheless, there are people who prefer this alternative exactly because it does expose the limits of the story's understanding, preventing fruitless attempts to use a word that is not recognized at all. If it is desirable, there is an extension that will reproduce this behavior in Inform as well.
 
 Using Inform's default behavior, however, scope is an ad-hoc way of keeping a list of things that are common knowledge between the story and the player. The player knows many things that the story might not (like what a cell phone is); the story knows a few things the player may not (like the fact that there is a sword in an as-yet unvisited room). Neither of those things can fruitfully enter into commands because they have no mutually agreed-upon referent.
 
-By default, Inform assumes that "scope" includes only those things that are currently visible by line of sight. This works pretty well for a wide range of situations, but there are still plenty of occasions when we want to admit that the story and the player share a knowledge of things not seen. GO TO THE KITCHEN might be a useful command even when the player can't currently view the kitchen. ASK FRED ABOUT THE FOOTPRINTS should perhaps work even when the footprints are far away in the garden. SMELL STINKY CHEESE might need to work even when the cheese is invisibly locked away in a porous container but is exuding a stench. In a dark room, the player can't see his own inventory, but he should still remember that he's carrying it and be able to mention it. And sometimes we might want the story to acknowledge that the player is referring to an object that he has seen somewhere, even if that thing is now out of sight.
+By default, Inform assumes that "scope" includes only those things that are currently visible by line of sight. This works pretty well for a wide range of situations, but there are still plenty of occasions when we want to admit that the story and the player share a knowledge of things not seen. GO TO THE KITCHEN might be a useful command even when the player can't currently view the kitchen. ASK FRED ABOUT THE FOOTPRINTS should perhaps work even when the footprints are far away in the garden. SMELL STINKY CHEESE might need to work even when the cheese is invisibly locked away in a porous container but is exuding a stench. In a dark room, the player can't see their own inventory, but they should still remember that they're carrying it and be able to mention it. And sometimes we might want the story to acknowledge that the player is referring to an object that they have seen somewhere, even if that thing is now out of sight.
 
 In practice, we have two ways to tinker with scope: we can change the scope for a specific command, using a token with any, as in 
 
@@ -762,7 +762,7 @@ Or we can add areas and items to scope for all commands, as in
 
 (See Helping and Hinting for objects tagged with a "seen" property when the player first encounters them.)
 
-(See Getting Acquainted for a character whose name is changed during the course of play as the player gets to know him better.)
+(See Getting Acquainted for a character whose name is changed during the course of play as the player gets to know them better.)
 
 (See Room Descriptions for more ways to change the description of a room depending on player experience.)
 
@@ -792,7 +792,7 @@ To do this at the most elementary level, we simply at some point
 
 	now the player is Janine;
 
-where Janine is a person we've already defined in the code. Now the player is in whatever location Janine inhabits, carries whatever Janine carries, and wears whatever Janine is wearing. <b>Terror of the Sierra Madre</b> shows off this effect, and also demonstrates how to make the command prompt remind the player which character he currently controls. Some games instead give this information in the status line or after the name of the location when looking, producing output like
+where Janine is a person we've already defined in the code. Now the player is in whatever location Janine inhabits, carries whatever Janine carries, and wears whatever Janine is wearing. <b>Terror of the Sierra Madre</b> shows off this effect, and also demonstrates how to make the command prompt remind the player which character they currently control. Some games instead give this information in the status line or after the name of the location when looking, producing output like
 
 	The Bottomless Acherousia (as Charon)
 
@@ -806,7 +806,7 @@ Of course, we'll need a good deal of other work to make Janine a distinct person
 	Instead of listening when the player is Janine: 
 		say "Your childhood accident left you unable to hear any but the loudest noises. Currently there is only silence."
 
-Janine may also have new, different perspective on her surroundings, expressed through the descriptions of the things she looks at; <b>Uncommon Ground</b> makes a "by viewpoint" token for text alternatives, allowing us to tag our descriptions to indicate which variations should be shown to which viewpoint characters. <b>The Crane's Leg 1</b> and <b>2</b> offer more elaborate and specialized ways of customizing the player character's observations to depend on how he relates (physically and in attitude) to the things around him.
+Janine may also have new, different perspective on her surroundings, expressed through the descriptions of the things she looks at; <b>Uncommon Ground</b> makes a "by viewpoint" token for text alternatives, allowing us to tag our descriptions to indicate which variations should be shown to which viewpoint characters. <b>The Crane's Leg 1</b> and <b>2</b> offer more elaborate and specialized ways of customizing the player character's observations to depend on how they relate (physically and in attitude) to the things around them.
 
 If we want to change the tense and person of narration from the conventional present second person, we may do this as well:
 
@@ -876,14 +876,14 @@ so that our FOLD command can change the object into its folded form. At other ti
 
 (Strictly, we might count a third kind of command: the kind that controls the story itself. The Advanced Actions chapter discusses how to add actions out of world, as these are called, but the difficult ones are already built into Inform - saving, restoring, restarting, undoing a turn, and so on. Mostly when we need to add new actions out of world, they will be help or hint systems of some kind. More about these can be found in the Helping and Hinting section of the Recipe Book, under Out of World Actions and Effects.)
 
-(3) Most commands that change the world require certain preconditions: the player needs to be holding the gun before he can fire it; the gun must be loaded with ammunition; if we're being especially detailed in our simulation, the safety must be off. 
+(3) Most commands that change the world require certain preconditions: the player needs to be holding the gun before it can be fired; the gun must be loaded with ammunition; if we're being especially detailed in our simulation, the safety must be off. 
 
 Often, there are also subtler details about how the command should interact with special items. For any new command we create, it's worth asking: should anything special happen if the player performs this action...
 
 	On himself?
 	On another living character?
-	On an object he (or another character) is carrying or wearing?
-	On an object he (or another character) is inside or on?
+	On an object they (or another character) are carrying or wearing?
+	On an object they (or another character) are inside or on?
 	On a door?
 	On an object that is impossible to move (defined as "scenery" or "fixed in place")?
 	On an intangible object (such as a beam of sunlight)?	
@@ -894,7 +894,7 @@ Often, there are also subtler details about how the command should interact with
 
 For instance, we might have written code so that if the gun is fired at anything but a person or a fragile object, the default response is "The bullet bounces harmlessly off [the second noun]." Our checklist would remind us to write special cases to prevent
 
-	SHOOT GUN AT MY SHOE (while he's wearing it)
+	SHOOT GUN AT MY SHOE (while they're wearing it)
 	SHOOT GUN AT ME
 	SHOOT GUN AT GUN
 
@@ -936,7 +936,7 @@ These variations are also covered in the Understanding chapter. If the action ne
 
 We may also need to modify reach or light levels (see Changing reachability and Changing visibility in the Advanced Actions chapter), or rely on the Deciding the scope of... activity. 
 
-As for guessing the player's intention when he isn't clear, we may want to consult the Does the player mean rules (to help Inform make guesses between multiple possible targets) and the activities Supplying a missing noun and Supplying a missing second noun (to help Inform guess an appropriate item when the player leaves something entirely out of his command). For instance, if the player typed SHOOT HENRY, it is the supplying a missing noun/second noun activity that would allow us to make Inform draw the obvious conclusion that he shoots Henry with the pistol in his hand. The Does the player mean rules are discussed in the chapter on Advanced Actions; the activities in the Activities chapter.
+As for guessing the player's intention when the command isn't clear, we may want to consult the Does the player mean rules (to help Inform make guesses between multiple possible targets) and the activities Supplying a missing noun and Supplying a missing second noun (to help Inform guess an appropriate item when the player leaves something entirely out of his command). For instance, if the player typed SHOOT HENRY, it is the supplying a missing noun/second noun activity that would allow us to make Inform draw the obvious conclusion that they shoot Henry with the pistol they are carrying. The Does the player mean rules are discussed in the chapter on Advanced Actions; the activities in the Activities chapter.
 
 Next we need to define our new action, as in
 
@@ -1041,7 +1041,7 @@ Changing the way an action works in all cases is usually better addressed by cha
 
 Similarly, we may delete, move, or replace rules that are already present (see the chapter on Rulebooks). This is handy if we decide that an action has restrictions that we dislike and want to abolish. If the restriction we need to change is part of the accessibility rules - those which check whether the player can take, see, and touch items - we may need to look at Changing reachability or Changing visibility in the Advanced Actions chapter (to revise what is allowed), at Deciding the scope of something in the Activities chapter (to influence what can be seen when). 
 
-If, for instance, the player character is a burly fellow who can lift any other character he likes:
+If, for instance, the player character is a burly fellow who can lift any other character they like:
 
 	The can't take other people rule is not listed in any rulebook.
 
@@ -1101,7 +1101,7 @@ Finally and most sweepingly, we can rip out whole passages of the Standard Rules
 
 Looking is quite a complicated command, since the production of a room description takes many steps. A detailed description of this process may be found in the Room Descriptions section.
 
-By convention, a player sees full descriptions of rooms he enters more than once, but may type BRIEF in order to see shorter descriptions, and SUPERBRIEF tells the story never to print room descriptions at all. VERBOSE restores the default behavior.
+By convention, a player sees full descriptions of rooms they enter more than once, but may type BRIEF in order to see shorter descriptions, and SUPERBRIEF tells the story never to print room descriptions at all. VERBOSE restores the default behavior.
 
 These conventions are not always appropriate, however, especially in works where experiencing a changing environment is essential. The use option 
 
@@ -1173,13 +1173,13 @@ Sometimes the way Inform by default lists properties such as "(closed)" or "(ope
 
 We may want to change the default refusal message when the player tries to pick up scenery: <b>Replanting</b> demonstrates this case simply.
 
-<b>Removal</b> modifies responses to successful TAKE commands, with the effect that when the player picks up an item, he gets a response such as "You take the book from the shelf."
+<b>Removal</b> modifies responses to successful TAKE commands, with the effect that when the player picks up an item, they get a response such as "You take the book from the shelf."
 
-<b>Croft</b> modifies the DROP command, so that objects dropped on specific surfaces get reported in a special way. <b>Celadon</b> allows the player to drop even objects he is carrying indirectly, for instance on a tray or in a sack.
+<b>Croft</b> modifies the DROP command, so that objects dropped on specific surfaces get reported in a special way. <b>Celadon</b> allows the player to drop even objects they are carrying indirectly, for instance on a tray or in a sack.
 
-<b>Morning After</b> introduces a simple rule that changes the behavior of the whole story: whenever the player takes an item he hasn't already looked at, he automatically examines it. This picks up the pace of exploration passages where the player is likely to be collecting a large number of objects.
+<b>Morning After</b> introduces a simple rule that changes the behavior of the whole story: whenever the player takes an item they haven't already looked at, they automatically examine it. This picks up the pace of exploration passages where the player is likely to be collecting a large number of objects.
 
-By default, when the player tries to put or insert an item that he isn't holding, Inform prints a refusal message; <b>Democratic Process</b> and <b>Sand</b> offer ways instead to have the player first pick up the relevant items. (The former applies to single items the player is trying to place; the latter expands coverage to work even if the player uses a command affecting multiple objects.)
+By default, when the player tries to put or insert an item that isn't carried, Inform prints a refusal message; <b>Democratic Process</b> and <b>Sand</b> offer ways instead to have the player first pick up the relevant items. (The former applies to single items the player is trying to place; the latter expands coverage to work even if the player uses a command affecting multiple objects.)
 
 Taking also happens as a result of other commands. Such takes can be made unnecessary by turning off the "carrying requirements rule" under particular circumstances, or presented differently using the implicitly taking activity.
 
@@ -1193,7 +1193,7 @@ Taking also happens as a result of other commands. Such takes can be made unnece
 ^^{looking+action+: as part of going}
 ^^{exiting+action+}
 
-Going is the most complex of actions after looking (or perhaps including looking): the success of every movement depends on the direction the player goes; the room he starts from; the room he intends to reach; whether there are any doors intervening (and, if so, whether these are closed or locked); whether he is traveling by vehicle; and whether he is pushing anything in front of him. When he gets there, the description he sees is itself generated by a looking command.
+Going is the most complex of actions after looking (or perhaps including looking): the success of every movement depends on the direction the player goes; the room they start from; the room they intend to reach; whether there are any doors intervening (and, if so, whether these are closed or locked); whether they are travelling by vehicle; and whether they are pushing anything in front of them. When they get there, the description they see is itself generated by a looking command.
 
 Pushing something in a direction is really a sort of going. The command >PUSH WHEELBARROW WEST first checks certain qualifying rules: by default, only things defined as pushable between rooms may be pushed, and they may be pushed only in horizontal directions (not UP or DOWN) -- though these rules can be overridden, as we see in <b>Zorb</b>. If the player's pushing attempt passes these criteria, the action is translated automatically into a going action, with all the usual checks about whether that direction leads anywhere, whether a door is in the way, and so on. The converted action afterward can be caught with such rules as
 
@@ -1222,11 +1222,11 @@ If these methods are not enough, the looking action has an action-specific varia
 	Check looking when the room-describing action is the going action:
 		say "You are temporarily too blinded to see." instead.
 
-Another category of examples treat how we handle the movement commands themselves. The eight compass directions, with UP and DOWN, IN and OUT, are used as standard in most interactive fiction, but they are not the only possible way of navigating, and strike many newcomers to the genre as counter-intuitive, since when strolling around in real life most of us rarely think about our travel in terms of compass orientation. <b>Misadventure</b> allows the player to GO TO a named room, instead, and calculates the best route to reach the destination; <b>Safari Guide</b> builds on this by letting the player make the whole trip in a single move, automatically opening any doors that stand in his way en route.
+Another category of examples treat how we handle the movement commands themselves. The eight compass directions, with UP and DOWN, IN and OUT, are used as standard in most interactive fiction, but they are not the only possible way of navigating, and strike many newcomers to the genre as counter-intuitive, since when strolling around in real life most of us rarely think about our travel in terms of compass orientation. <b>Misadventure</b> allows the player to GO TO a named room, instead, and calculates the best route to reach the destination; <b>Safari Guide</b> builds on this by letting the player make the whole trip in a single move, automatically opening any doors that stand in their way en route.
 
 In the same spirit of interpreting the player's intentions sensibly, <b>Provenance Unknown</b> modifies the pushing command so that if the player pushes the top object in a stack of objects towards a direction, Inform attempts to move the bottom item instead. This is convenient if, for instance, we have a heavy television on a movable cart and want PUSH TELEVISION WEST to work just as well as PUSH CART WEST. 
 
-We also sometimes want to respond sensibly to terse movement commands or ones that rely on some knowledge of where the player has already been. <b>Polarity</b> provides a GO BACK command, allowing the player to retreat in the direction from which he came, while <b>Minimal Movement</b> understands LEAVE, GO, and so on as OUT, in the absence of other information. <b>Owen's Law</b> takes this further, calculating from the best routes on a map how to make OUT mean "move towards the exit of this indoor room", and IN mean "proceed further into the interior". <b>Wonderland</b> assigns altitudes to all rooms and works out the local best meaning of UP and DOWN accordingly.
+We also sometimes want to respond sensibly to terse movement commands or ones that rely on some knowledge of where the player has already been. <b>Polarity</b> provides a GO BACK command, allowing the player to retreat in the direction from which they came, while <b>Minimal Movement</b> understands LEAVE, GO, and so on as OUT, in the absence of other information. <b>Owen's Law</b> takes this further, calculating from the best routes on a map how to make OUT mean "move towards the exit of this indoor room", and IN mean "proceed further into the interior". <b>Wonderland</b> assigns altitudes to all rooms and works out the local best meaning of UP and DOWN accordingly.
 
 (See Map for how to create other kinds of new direction.)
 
@@ -1241,9 +1241,9 @@ We also sometimes want to respond sensibly to terse movement commands or ones th
 ^^{entering+action+}
 ^^{exiting+action+ <-- standing}
 
-Under ordinary circumstances, Inform does not keep track of the player's posture, nor of his exact location in a room. <b>Lies</b> implements a room in which the player can lie in different positions on the floor, getting different views as a result.
+Under ordinary circumstances, Inform does not keep track of the player's posture, nor of their exact location in a room. <b>Lies</b> implements a room in which the player can lie in different positions on the floor, getting different views as a result.
 
-Our other examples are all modifications of the way Inform handles player movement to make better default guesses at what he wants to do: <b>Anchorite</b> adds a GET DOWN and DOWN command that work when the player is on a supporter, to accompany GET UP, GET OFF, and GET OUT (already understood). <b>Get Axe</b> makes the player get out of a portable container before attempting to lift it - a consideration that comes up relatively rarely, but that might pertain to inflatable rafts, beanbag chairs, and other lightweight but capacious pieces of furniture.
+Our other examples are all modifications of the way Inform handles player movement to make better default guesses at what they want to do: <b>Anchorite</b> adds a GET DOWN and DOWN command that work when the player is on a supporter, to accompany GET UP, GET OFF, and GET OUT (already understood). <b>Get Axe</b> makes the player get out of a portable container before attempting to lift it - a consideration that comes up relatively rarely, but that might pertain to inflatable rafts, beanbag chairs, and other lightweight but capacious pieces of furniture.
 
 (See Position Within Rooms for a box the player can push around the room and stand on in different locations.)
 
@@ -1257,9 +1257,9 @@ Our other examples are all modifications of the way Inform handles player moveme
 ^^{time: waiting intervals of time}
 ^^{sleeping+action+}
 
-The standard WAIT command makes time pass at the same rate that it would anyway - one minute per turn. In a story where events happen at specific times of day, though, we might want to give the player more control. <b>Nine AM Appointment</b> shows how to give the player a WAIT 10 MINUTES command, while <b>Delayed Gratification</b> lets him WAIT UNTIL a specific time of day.
+The standard WAIT command makes time pass at the same rate that it would anyway - one minute per turn. In a story where events happen at specific times of day, though, we might want to give the player more control. <b>Nine AM Appointment</b> shows how to give the player a WAIT 10 MINUTES command, while <b>Delayed Gratification</b> lets them WAIT UNTIL a specific time of day.
 
-Ordinarily, Inform also refuses to allow the player to SLEEP and WAKE UP: the commands exist, but have no effect. <b>Change of Basis</b> lets the player put himself into a sleep state in which he cannot do anything. A somewhat more interesting expansion on this idea would be to let the player sleep and have dreams; there are no examples specifically of dream states, but we might consult the examples on scenes about how to disrupt one environment and move the player to another, entirely new one.
+Ordinarily, Inform also refuses to allow the player to SLEEP and WAKE UP: the commands exist, but have no effect. <b>Change of Basis</b> lets the player enter a sleep state in which they cannot do anything. A somewhat more interesting expansion on this idea would be to let the player sleep and have dreams; there are no examples specifically of dream states, but we might consult the examples on scenes about how to disrupt one environment and move the player to another, entirely new one.
 
 (See Scene Changes for ways to move the player to a new environment such as a dream state.)
 
@@ -1313,7 +1313,7 @@ Sometimes we want Inform to apply a player's action to a different target than t
 
 We can also record a series of actions performed by the player or by another character.
 
-<b>Cactus Will Outlive Us All</b> demonstrates characters each of whom reacts to a very specific provocation; <b>I Didn't Come All The Way From Great Portland Street</b> implements a game show in which the player is not allowed ever to repeat an action he has already performed; and <b>Leopard-skin</b> implements a maze which the player can escape only by performing a specific sequence of actions.
+<b>Cactus Will Outlive Us All</b> demonstrates characters each of whom reacts to a very specific provocation; <b>I Didn't Come All The Way From Great Portland Street</b> implements a game show in which the player is not allowed ever to repeat an action they have already performed; and <b>Leopard-skin</b> implements a maze which the player can escape only by performing a specific sequence of actions.
 
 <b>Anteaters</b> provides a peculiar gizmo that can remember actions performed in its presence and force the player to reiterate them.
 
@@ -1450,7 +1450,7 @@ Talking about characters presents some special challenges. For one thing, some c
 
 The relation between the player and the other characters is not always static, however. Sometimes we want the player to learn a character's name part-way through play, and start referring to "the drunk pedestrian" as "Fernando". Similarly, the status of another character may change due to some twist of the plot. <b>Gopher-wood</b> shows how to change the name of a character mid-story, and <b>Peers</b> handles changing the character's rank.
 
-Alternatively, of course, the player character may already know some of the other characters when the story begins, even if the player does not. In that case, we may want to add a tag-line or so of identification to a character's name when he first appears in the story. <b>A Humble Wayside Flower</b> shows one way of doing this.
+Alternatively, of course, the player character may already know some of the other characters when the story begins, even if the player does not. In that case, we may want to add a tag-line or so of identification to a character's name when they first appear in the story. <b>A Humble Wayside Flower</b> shows one way of doing this.
 
 Another occasional challenge is dealing with such commands as EXAMINE DR. THISBY. The problem here is that Inform by default will understand the full stop after "Dr" to be the end of one command and the beginning of another, and will try to interpret "Thisby" as a verb. If we do have a story populated by such formally-addressed characters, we may turn to Punctuation Removal, which provides a phrase to remove the full stops in standard titles before attempting to interpret the command.
 
@@ -1482,11 +1482,11 @@ We might expand on this by providing a whole table of things for Mrs MacG. to cy
 	Every turn when the player can see Mrs MacGillicuddy:
 		say "Mrs. MacGillicuddy [one of]vacuums around the furniture[or]tries to remove gum from the underside of the desks[or]causes a racket by testing the smoke alarm[or]makes a pointed comment or two about them as sit by idly while someone works her fingers to the bone[as decreasingly likely outcomes]."
 
-This is no great innovation in characterization by itself, but it does at least remind the player that the character is alive and moving about, even when he isn't paying attention to her.
+This is no great innovation in characterization by itself, but it does at least remind the player that the character is alive and moving about, even when they aren't paying attention to her.
 
-<b>Annoyotron Jr</b> demonstrates a character who actively tries to get our attention, and whose routine of behavior changes just slightly if we show signs of having reacted to him.
+<b>Annoyotron Jr</b> demonstrates a character who actively tries to get our attention, and whose routine of behavior changes just slightly if we show signs of having reacted to them.
 
-<b>Lean and Hungry</b> implements a classic thief, a character who doesn't interact with the player much except to pick up valuable objects he finds left around the map. Later we will see rather more advanced ways to make characters act on their own goals and plans, but this kind of simple behavior is easily rigged as part of an every turn rule. 
+<b>Lean and Hungry</b> implements a classic thief, a character who doesn't interact with the player much except to pick up valuable objects they find left around the map. Later we will see rather more advanced ways to make characters act on their own goals and plans, but this kind of simple behavior is easily rigged as part of an every turn rule. 
 
 Finally, <b>Text Foosball</b> extends the every-turn-rule idea to create an opponent who joins us in a randomized game of table soccer.
 
@@ -1501,9 +1501,9 @@ For people, we are likely to need an assortment of additional techniques.
 ^^{characters (people): reacting to the player's actions}
 ^^{actions: reactions by other characters}
 
-As we observe characters, so they observe us. Those who seem to have no awareness of what the player is doing often come across more like waxworks than like people. <b>Zodiac</b> demonstrates a scenario where the watchful presence of a dangerous criminal keeps the player from doing what he otherwise might, while <b>Police State</b> expands on this idea with a policeman who reacts to entire types of behavior in his presence, regardless of whether the culprit is the player or a third party. <b>Noisemaking</b> has a crow who will fly away in response to any loud noises the player makes.
+As we observe characters, so they observe us. Those who seem to have no awareness of what the player is doing often come across more like waxworks than like people. <b>Zodiac</b> demonstrates a scenario where the watchful presence of a dangerous criminal keeps the player from doing what they otherwise might, while <b>Police State</b> expands on this idea with a policeman who reacts to entire types of behavior in his presence, regardless of whether the culprit is the player or a third party. <b>Noisemaking</b> has a crow who will fly away in response to any loud noises the player makes.
 
-And, of course, we definitely want to have characters react to being looked at or otherwise interfered with. <b>Search and Seizure</b> implements a smuggler who reacts when we try to confiscate his possessions. <b>Pine 1</b> gives us a sleeping princess who can be woken by a variety of methods. 
+And, of course, we definitely want to have characters react to being looked at or otherwise interfered with. <b>Search and Seizure</b> implements a smuggler who reacts when we try to confiscate their possessions. <b>Pine 1</b> gives us a sleeping princess who can be woken by a variety of methods. 
 
 We wrap up this section with two complete puzzle scenarios that demonstrate what can be achieved by giving characters reactions to the player's behavior. <b>A Day For Fresh Sushi</b> has a fish who watches the player's actions and comments on them, while the live furnishings in <b>Revenge of the Fussy Table</b> instead comment every turn on the current state of the world, until the player has successfully sorted out all their complaints.
 
@@ -1518,11 +1518,11 @@ If we'd like to change this, we can simply remove the default "block giving" rul
 
 	The block giving rule is not listed in the check giving it to rules.
 
-If we do this, giving items to characters will have the result of moving our possessions to the other person's inventory. Of course, without more customization, the player may not ever be able to persuade the other character to return his possessions. <b>Bribery</b> demonstrates a scenario in which a character will accept gifts if they are interesting to him, and respond with a changed attitude to the player.
+If we do this, giving items to characters will have the result of moving our possessions to the other person's inventory. Of course, without more customization, the player may not ever be able to persuade the other character to return their possessions. <b>Bribery</b> demonstrates a scenario in which a character will accept gifts that interest them, and respond with a changed attitude to the player.
 
 <b>Barter Barter</b> expands further on this by allowing other characters to trade things with one another.
 
-(See Modifying Existing Commands for ways to allow the player to give or show things that he isn't currently holding.)
+(See Modifying Existing Commands for ways to allow the player to give or show things that they aren't currently carrying.)
 
 (See Actions on Multiple Objects for an implementation of giving that allows the player to offer multiple objects at once, where their combined value determines whether they are accepted.)
 
@@ -1538,9 +1538,9 @@ If we do this, giving items to characters will have the result of moving our pos
 
 Not all characters are friendly, and there are times when we may want to include a fight sequence. There are a number of ways to approach this, depending on whether we want to offer the player a random outcome, a predetermined one, or a combat sequence that depends partly on strategy or on having the proper equipment.
 
-<b>Lanista 1</b> demonstrates randomized combat in the style of a role-playing game. The player has a partially random chance of doing any given amount of damage; both the player and his opponent have hit points, and whichever one runs out first dies. <b>Lanista 2</b> continues this idea, but includes weapons that affect the amount of of damage done. <b>Red Cross</b> by itself implements a command that we might use to find out how strong characters are at the moment.
+<b>Lanista 1</b> demonstrates randomized combat in the style of a role-playing game. The player has a partially random chance of doing any given amount of damage; both the player and their opponent have hit points, and whichever one runs out first dies. <b>Lanista 2</b> continues this idea, but includes weapons that affect the amount of of damage done. <b>Red Cross</b> by itself implements a command that we might use to find out how strong characters are at the moment.
 
-A word of warning about designing such sequences: a player who gets a roll he doesn't like always has the option of UNDOing a turn and re-rolling. This means that he can always win a random battle sooner or later; bad luck only means that it takes him longer (so he gets more bored and irritated as he plays through). It is possible to turn off UNDO implementation with
+A word of warning about designing such sequences: a player who gets a roll they don't like always has the option of UNDOing a turn and re-rolling. This means that they can always win a random battle sooner or later; bad luck only means that it takes them longer (so they get more bored and irritated as they play through). It is possible to turn off UNDO implementation with
 	
 	Use UNDO prevention.
 	
@@ -1561,7 +1561,7 @@ Traditionally, conversation is one of the most difficult things to program in in
 
 Conversation implementations often need to keep track of a lot of information: what else is going on in the model world, what the character knows, what plot phase we've reached, what mood the character is in, what else we've recently been talking about, whether we've said the same thing before (and how many times); and so on. Later in this chapter we will look at ways to model character knowledge and mood.
 
-Then, too, we have the problem of how the player communicates his conversational intentions to the story. Technology has not yet advanced to the point where a player can simply type in remarks in full natural English and have the character detect the significance, emotional tone, and subtext, if any: so we can't have RACHEL, THIS DESSERT TASTES LIKE FEET or WILL, LOOK! OUR SINISTER METAL FOES ARE APPROACHING! or BOSS, I WOULD BE DELIGHTED TO FILE ANOTHER TPB REPORT.
+Then, too, we have the problem of how the player communicates their conversational intentions to the story. Technology has not yet advanced to the point where a player can simply type in remarks in full natural English and have the character detect the significance, emotional tone, and subtext, if any: so we can't have RACHEL, THIS DESSERT TASTES LIKE FEET or WILL, LOOK! OUR SINISTER METAL FOES ARE APPROACHING! or BOSS, I WOULD BE DELIGHTED TO FILE ANOTHER TPB REPORT.
 
 The challenge is to create an interface that is both easy for the player to use and expressive enough to be interesting. We will look at some of the common solutions in "Saying Complicated Things".
 
@@ -1587,7 +1587,7 @@ There are times when even the commands ASK and TELL are overkill: sometimes the
 
 If we are frequently permitting the player to say things like LUCIUS, OLLIVANDER as shorthand for "talk to Lucius about Ollivander", then we may also want to allow LUCIUS, OLLIVANDER? This makes the player character seem a bit slow (or at least Laconic), but it is an effective interface in some cases. The trick is that the question mark at the end of the command may prevent Inform from recognizing the keyword; should that problem arise, we may want to use Punctuation Removal to erase question marks from the player's command before attempting to interpret it.
 
-Along the same lines, there are situations in conversation where similar commands do not correspond to the same actions within Inform; if we're careless about this, we may force the player to guess which vocabulary we want him to use, which is always vexing. Some cases to look out for:
+Along the same lines, there are situations in conversation where similar commands do not correspond to the same actions within Inform; if we're careless about this, we may force the player to guess which vocabulary we want them to use, which is always vexing. Some cases to look out for:
 
 Inform has actions for "saying yes" and "saying no". Sometimes this is useful, but sometimes we want YES and SAY YES TO FRED to do the same thing. <b>Sybil 2</b> shows how to roll these responses into one; <b>Proposal</b> expands on the idea to show more ways in which a player could reasonably answer a question put by another character. 
 
@@ -1597,7 +1597,7 @@ Finally, if we want to be able to ASK and TELL an inanimate object -- say, a com
 
 (See Remembering, Converting and Combining Actions for ways to redirect one conversation command to another conversation topic.)
 
-(See Varying What Is Read for a way of asking the player trivia questions that he can answer only on the next turn.)
+(See Varying What Is Read for a way of asking the player trivia questions that they can answer only on the next turn.)
 
 [x] Saying Complicated Things
 
@@ -1615,22 +1615,22 @@ or, sometimes,
 	1) "Jill, have you seen your no-good layabout brother Jack anywhere?"
 	2) "Look, Farmer Jill, I think a fox got into the chickens."
 
-The problem with ASK/TELL conversation is that it can feel undirected - if the player doesn't know which keywords to ask or tell about next, he gets stuck. It also doesn't always provide much sense of ongoing context or conversational flow, since the player can ask lots of unrelated questions and jump around a lot. What's more, sometimes the thing the player character asks isn't quite the question the player had in mind. If we type ASK JILL ABOUT JACK, Jill could wind up answering any of a number of questions - where Jack is, how old Jack is, whether Jack committed the recent murder, and so on. The player doesn't have much fine control over the conversation. Nonetheless, this is sometimes just what we want: <b>Farewell</b> implements a moderately sophisticated system along these lines, which keeps track of what the player has already said and allows him to review past conversation.
+The problem with ASK/TELL conversation is that it can feel undirected - if the player doesn't know which keywords to ask or tell about next, they get stuck. It also doesn't always provide much sense of ongoing context or conversational flow, since the player can ask lots of unrelated questions and jump around a lot. What's more, sometimes the thing the player character asks isn't quite the question the player had in mind. If we type ASK JILL ABOUT JACK, Jill could wind up answering any of a number of questions - where Jack is, how old Jack is, whether Jack committed the recent murder, and so on. The player doesn't have much fine control over the conversation. Nonetheless, this is sometimes just what we want: <b>Farewell</b> implements a moderately sophisticated system along these lines, which keeps track of what the player has already said and allows them to review past conversation.
 
-Menu-based conversation solves most of these problems: a branching tree of conversation choices maintains a consistent flow of discussion, it's hard for the player to run out of things to say, and the player always knows what his character is about to say. But there are compensating flaws. For one thing, a menu doesn't allow for many surprises. The player can see all the conversation the story has to offer by working methodically through all the menu branches. (This problem is sometimes referred to as the "lawnmower effect", since the process of seeing all the conversation is like the process of running a lawnmower over every inch of the lawn. It becomes a chore rather than an entertainment.) Menu systems can be long-winded to set up and therefore none are exemplified here, but several have been released as extensions for Inform.
+Menu-based conversation solves most of these problems: a branching tree of conversation choices maintains a consistent flow of discussion, it's hard for the player to run out of things to say, and the player always knows what their character is about to say. But there are compensating flaws. For one thing, a menu doesn't allow for many surprises. The player can see all the conversation the story has to offer by working methodically through all the menu branches. (This problem is sometimes referred to as the "lawnmower effect", since the process of seeing all the conversation is like the process of running a lawnmower over every inch of the lawn. It becomes a chore rather than an entertainment.) Menu systems can be long-winded to set up and therefore none are exemplified here, but several have been released as extensions for Inform.
 
-Since about 2001, more and more IF has used a sort of compromise method: the player is allowed to ask or tell about keywords, but he's sometimes given prompts about things to say that follow naturally on the conversation he was just having, as in
+Since about 2001, more and more IF has used a sort of compromise method: the player is allowed to ask or tell about keywords, but they're sometimes given prompts about things to say that follow naturally on the conversation they were just having, as in
 
 	You could ask where Jack is.
 
-Moreover, when he asks about a topic where many comments are possible, he'll be allowed to clarify, either using a menu or through a disambiguation question such as
+Moreover, when they ask about a topic where many comments are possible, they'll be allowed to clarify, either using a menu or through a disambiguation question such as
 
 	>ask Jill about Jack
 	Do you want to ask where Jack is, how old Jack is, or whether Jack committed the recent murder?
 	
 <b>Sweeney</b> implements one such hybrid type of conversation.
 	
-A third option is to take away almost all the player's expressiveness and give him just one command, TALK TO. The player can TALK TO characters whenever he wants, and the story will pick the most appropriate thing for him to talk about. This works best in works with few or simple puzzles and a fast-moving, constrained plot, where the player will keep having new things to talk about. <b>Cheese-makers</b> demonstrates this. 
+A third option is to take away almost all the player's expressiveness and give them just one command, TALK TO. The player can TALK TO characters whenever they want, and the story will pick the most appropriate thing for them to talk about. This works best in works with few or simple puzzles and a fast-moving, constrained plot, where the player will keep having new things to talk about. <b>Cheese-makers</b> demonstrates this. 
 
 Finally, a few extreme games try to fake natural language understanding by looking for keywords in the player's input, rather than an exact grammar. This is perilous, because it is all too easy for the story to completely misunderstand what the player meant to type. Nonetheless, for the sake of example, see <b>Complimentary Peanuts</b>, in which the incomprehension is partly excused by the fact that the player is talking to someone a bit hard of hearing.
 
@@ -1675,7 +1675,7 @@ Alternatively, we might have a list of salient facts that are important in our s
 
 	A fact is a kind of value. Some facts are defined by the Table of All Known Facts.
 
-	Knowledge relates various people to various facts. The verb to know (he knows, they know, he knew, it is known) implies the knowledge relation.
+	Knowledge relates various people to various facts. The verb to know (she knows, they know, he knew, it is known) implies the knowledge relation.
 
 	Table of All Known Facts 
 	fact   	summary   
@@ -1689,7 +1689,7 @@ Or again we might keep a whole database of information in a table: the character
 
 The possibilities of character reasoning are similarly broad, but <b>The Problem of Edith</b> introduces one kind: the character has a concept of how different conversation topics relate to one another, so that when she is asked about a new keyword, she picks a response that makes the question most relevant to the conversation already in progress.
 
-We end with a longer scenario, in which we track what the character knows about the player and the conversational state: in <b>Chronic Hinting Syndrome</b>, the main character guides conversation in the direction he intends it to go, with the player's sometimes-reluctant participation.
+We end with a longer scenario, in which we track what the character knows about the player and the conversational state: in <b>Chronic Hinting Syndrome</b>, the main character guides conversation in the direction they intend it to go, with the player's sometimes-reluctant participation.
 
 (See Obedient Characters for a character who needs to be taught how to perform actions before doing them.)
 
@@ -1703,7 +1703,7 @@ We end with a longer scenario, in which we track what the character knows about
 
 So far we've seen characters who will answer questions whenever the player feels like asking, and characters who will use some reasoning procedure to direct the conversation. There is a third option, often useful in IF with a fast-paced narrative: the character follows a conversational script, making sure to cover a series of points before the scene ends.
 
-There are more and less tedious ways to implement this kind of scene. The worst case is one in which the player is not allowed to interrupt or ask any questions; he must merely wait until the character runs out of things to say. This can be useful and plausible in very small doses - say, two or three turns - but if the character has more information than that to impart, we may want to make the scene more interactive.
+There are more and less tedious ways to implement this kind of scene. The worst case is one in which the player is not allowed to interrupt or ask any questions; they must merely wait until the character runs out of things to say. This can be useful and plausible in very small doses - say, two or three turns - but if the character has more information than that to impart, we may want to make the scene more interactive.
 
 <b>Pine 2</b> partly addresses this challenge: the character has a line of conversation that she wants to follow to its conclusion; we may ask questions along the way, but if we're silent, she'll take up the slack, and the scene won't end until she's done with what she has to say. 
 
@@ -1720,7 +1720,7 @@ Another kind of script is a series of actions for the character to perform. <b>R
 
 There are a number of ways we can make characters navigate our map. We might reasonably want them to approach and follow the player (as in <b>Van Helsing</b>); or to allow the player to follow characters who have left the room (as in <b>Actaeon</b>).
 
-Characters who are less interested in the player will more likely follow their own courses around the available geography, however. A character may move randomly from room to room, as demonstrated in <b>Mistress of Animals</b>; he may follow a path that we have specifically written in advance, as <b>Odyssey</b> shows; or, most elegantly, he may use the "best route" calculation to find the best possible way to a given target room, as seen in <b>Latris Theon</b>. 
+Characters who are less interested in the player will more likely follow their own courses around the available geography, however. A character may move randomly from room to room, as demonstrated in <b>Mistress of Animals</b>; they may follow a path that we have specifically written in advance, as <b>Odyssey</b> shows; or, most elegantly, the story may use the "best route" calculation to find the best possible way to a given target room, as seen in <b>Latris Theon</b>.
 
 This final method is arguably the neatest solution to character movement, allowing for characters to act in sophisticated ways; if we incorporate the Locksmith extension, other characters will even unlock and open doors that are in their way. The chief catch is that it should not be used too profligately with large numbers of characters, since on slow machines the processing power required to plan all their travel will make a noticeable difference to the running speed of the story.
 
@@ -1753,11 +1753,11 @@ Other characters can perform all the same activities that the player can; this d
 
 In <b>For Demonstration Purposes</b>, the character is only capable of a few actions at the outset, but can be taught new ones if the player performs them first.
 
-Often we want characters' obedience to be more selective. Just as the viewpoint character may be characterized in terms of what he will and will not do, so may others: <b>Generation X</b> demonstrates a character who will do what she's told, but who will comment unfavorably when the player asks for a nonsensical or repeated action, and who may eventually get fed up and leave.  
+Often we want characters' obedience to be more selective. Just as the viewpoint character may be characterized in terms of what they will and will not do, so may others: <b>Generation X</b> demonstrates a character who will do what they're told, but who will comment unfavorably when the player asks for a nonsensical or repeated action, and who may eventually get fed up and leave.
 
 Characters can be given moral objections to certain commands, as well: <b>Virtue</b> defines a few kinds of actions as bad, so that the character commanded will refuse to perform them. 
 
-<b>Under Contract</b>, more subtly, has the character object if the player's commands implicitly require any behavior he considers inappropriate: for instance, if the player commands him to put his pants in a container, he will work out that this requires the removal of the pants as a preliminary. If we want to implement a similar character, we may want to simply copy his unsuccessful attempt rule and the table of his retorts, then replace his banter with lines of our choosing.
+<b>Under Contract</b>, more subtly, has the character object if the player's commands implicitly require any behavior they consider inappropriate: for instance, if the player commands them to put their pants in a container, they will work out that this requires the removal of the pants as a preliminary. If we want to implement a similar character, we may want to simply copy the unsuccessful attempt rule and the table of retorts, then replace the banter with lines of our choosing.
 
 The little example <b>Latin Lessons</b> allows us to make characters clever about vague commands: we can, for instance, write rules so that CLARK, EAT will have Clark sensibly pick something edible, rather than having the parser ask what we want Clark to eat.
 
@@ -1773,7 +1773,7 @@ Goal-seeking characters are the most advanced IF life-form: they want to achieve
 
 A really advanced implementation of goal-seeking behavior is beyond the scope of our examples (though extensions exist that treat the problem more thoroughly). We can accomplish a surprising amount without heavy customization, though, if we keep in mind three points of technique:
 
-First: it helps to think abstractly and to create broadly-defined actions as a first step to more specific tasks. For instance, a character's goal might be to eat some dinner. He'd be equally satisfied with spaghetti carbonara or with braised lamb shanks, but he needs to figure out which is available. So we might have our every turn rule (or whatever we're using to activate the character) say something like
+First: it helps to think abstractly and to create broadly-defined actions as a first step to more specific tasks. For instance, a character's goal might be to eat some dinner. They'd be equally satisfied with spaghetti carbonara or with braised lamb shanks, but they need to figure out which is available. So we might have our every turn rule (or whatever we're using to activate the character) say something like
 
 	Every turn when Clark is hungry:
 		try Clark dining.
@@ -1796,7 +1796,7 @@ Third: goal-seeking characters notice when something is in the way of the action
 		try Clark unwrapping the candy;
 		if the candy is wrapped, stop the action.
 
-Here we've set things up so that if Clark tries to eat the wrapped candy, he'll be interrupted by this other command; and if his unwrapping-the-candy attempt fails, he won't go on and eat the thing. <b>IQ Test</b> demonstrates a character who shows this kind of planning intelligence.
+Here we've set things up so that if Clark tries to eat the wrapped candy, he'll be interrupted by this other command; and if his unwrapping-the-candy attempt fails, he won't go on to eat the thing. <b>IQ Test</b> demonstrates a character who shows this kind of planning intelligence.
 
 Because before-rules chain neatly, we can trigger whole plans of behavior if we have a sensible set, as in
 
@@ -1936,11 +1936,11 @@ Inform provides an either/or property called "edible" and an action, "eating", f
 
 For eating something not immediately to hand, see <b>Lollipop Guild</b>. <b>Delicious, Delicious Rocks</b>, conversely, adds a sanity check which prevents the player from automatically taking inedible things only to be told they can't be eaten.
 
-Inform does not normally simulate taste or digestion, but to provide foods with a range of flavours, see <b>Would you...?</b>; to make eating different foods affect the player differently, see <b>Stone</b>, or for the extreme case of poisoning foods, <b>Candy</b>. In <b>MRE</b>, hunger causes the player problems unless he regularly finds and eats food.
+Inform does not normally simulate taste or digestion, but to provide foods with a range of flavours, see <b>Would you...?</b>; to make eating different foods affect the player differently, see <b>Stone</b>, or for the extreme case of poisoning foods, <b>Candy</b>. In <b>MRE</b>, hunger causes the player problems unless they regularly find and eat food.
 
 (See Liquids for things to drink.)
 
-(See Dispensers and Supplies of Small Objects for a pizza buffet table from which the player may take all the slices he wants.)
+(See Dispensers and Supplies of Small Objects for a pizza buffet table from which the player may take all the slices they want.)
 
 [x] Bags, Bottles, Boxes and Safes
 
@@ -1992,7 +1992,7 @@ Finally, any action that destroys a container has to consider what to do with th
 
 (See Furniture for chests with lids that can support other objects.)
 
-(See Modifying Existing Commands for ways to allow the player to unlock with a key he isn't currently holding.)
+(See Modifying Existing Commands for ways to allow the player to unlock with a key that isn't currently being carried.)
 
 [x] Clothing
 
@@ -2086,7 +2086,7 @@ Signs, leaflets and encyclopaedias, being printed, have a wording which will nev
 
 	The computer display is on the desk. The description is "Giant green digits read: [the time of day]."
 
-This is easy because we know all the variations we want. But what if we want the player to write his own text, for instance, adding to a diary? This is trickier, because it means storing text as the player typed it, and replaying it later. (And suppose the player types reams and reams of text, not just a few words as we might have hoped?) <b>The Fourth Body</b> and <b>The Fifth Body</b> show how to use an external file - a multimedia trick requiring features only available if the project is set to the Glulx story file format - to handle even the most difficult cases.
+This is easy because we know all the variations we want. But what if we want the player to write their own text, for instance, adding to a diary? This is trickier, because it means storing text as the player typed it, and replaying it later. (And suppose the player types reams and reams of text, not just a few words as we might have hoped?) <b>The Fourth Body</b> and <b>The Fifth Body</b> show how to use an external file - a multimedia trick requiring features only available if the project is set to the Glulx story file format - to handle even the most difficult cases.
 
 Should we want a computer that responds to vocal commands, as in ASK COMPUTER ABOUT KLINGONS, the built-in extension Inanimate Listeners will allow the player to talk to inanimate objects as well as people.
 
@@ -2236,11 +2236,11 @@ The example with the best compromise between simulation quality and complexity i
 
 ^^{duplicates: taken from a dispenser}
 
-A slightly tricky situation arises in IF when we want to offer the player a simulation of a near-infinite supply of something: a napkin dispenser from which he can keep taking more napkins, or an infinite selection of pebbles on a beach, or something of that nature. 
+A slightly tricky situation arises in IF when we want to offer the player a simulation of a near-infinite supply of something: a napkin dispenser from which they can keep taking more napkins, or an infinite selection of pebbles on a beach, or something of that nature. 
 
 One approach is simply to limit the number of items the player is allowed to pick up at a time, while maintaining the fiction that there are more of these items in existence than the player is allowed to interact with. <b>Extra Supplies</b> demonstrates this.
 
-The task becomes harder if we do want to let the player have as many napkins as he wants. In some languages, it is possible to generate new objects on the fly after the story has begun (called "dynamic object creation"), and something like this is possible if we are compiling for Glulx. (See the Inform extensions site for examples.) Usually, though, it is less complicated and almost as effective simply to have a very large supply of existing objects, which are moved in and out of play as the player needs them. <b>Pizza Prince</b> demonstrates how to do this with slices of pizza.
+The task becomes harder if we do want to let the player have as many napkins as they want. In some languages, it is possible to generate new objects on the fly after the story has begun (called "dynamic object creation"), and something like this is possible if we are compiling for Glulx. (See the Inform extensions site for examples.) Usually, though, it is less complicated and almost as effective simply to have a very large supply of existing objects, which are moved in and out of play as the player needs them. <b>Pizza Prince</b> demonstrates how to do this with slices of pizza.
 
 (See Ropes for an example involving divisible pieces of string, which relies on similar techniques.)
 
@@ -2428,11 +2428,11 @@ There are many approaches, which differ on two main issues.
 
 First: do we spontaneously offer help to the player? The difficulty here is detecting the player's need: <b>Y ask Y?</b> tries to spot aimlessness, while <b>Solitude</b> has a novice mode where it is reasonable to assume that help is almost always needed. On the other hand, suppose we require that the initiative come from the player. Will a novice know to type HELP? <b>Query</b> shows how to redirect any attempt to ask a direct question into a HELP request. At the other end of the scale, wearily experienced players may type HELP all the time, out of habit, cheating themselves of the fun of frustration: if so, <b>Real Adventurers Need No Help</b> provides the nicotine patch against this addiction.
 
-Second: how do we decide what help is needed? Normally the player only types HELP, which is unspecific. The simplest approach offers a menu, diagnosing the player's problem by obliging him to make choices: see <b>Food Network Interactive</b>. Listing all the possible problems in the story may give away too much, though, since players may not have reached the puzzles in question yet; so some authors prefer to create menus that adapt to the current state of the story (commonly called "adaptive hints").
+Second: how do we decide what help is needed? Normally the player only types HELP, which is unspecific. The simplest approach offers a menu, diagnosing the player's problem by obliging them to make choices: see <b>Food Network Interactive</b>. Listing all the possible problems in the story may give away too much, though, since players may not have reached the puzzles in question yet; so some authors prefer to create menus that adapt to the current state of the story (commonly called "adaptive hints").
 
 Failing this, we can also try to parse commands like HELP ABOUT MICRODOT, as in <b>Ish.</b> <b>Trieste</b> takes a similar tack, except that instead of offering hints about puzzles, it offers help on story features (such as how to save), and lists all the available topics if the player types simply HELP. 
 
-Finally, and perhaps most stylishly, we can try to deduce what the player is stuck on from his immediate circumstances and from what is not yet solved: this needs a powerful adaptive hints system like the one in <b>The Unexamined Life</b>.
+Finally, and perhaps most stylishly, we can try to deduce what the player is stuck on from their immediate circumstances and from what is not yet solved: this needs a powerful adaptive hints system like the one in <b>The Unexamined Life</b>.
 
 (See Getting Started with Conversation for a way to redirect a player using the wrong conversation commands.)
 
@@ -2475,11 +2475,11 @@ We might also write our condition with "for the first time", like so:
 		increase the score by 5;
 		say "Boing! That was certainly entertaining."
 
-But we should be careful not to use "for the first time" in scoring situations where it's possible for the player to try the action but fail. Inform counts even unsuccessful attempts towards the number of times an action is understood to have occurred, so if the player tries to jump and fails, his "for the first time" will be used up and he will never receive the score points.
+But we should be careful not to use "for the first time" in scoring situations where it's possible for the player to try the action but fail. Inform counts even unsuccessful attempts towards the number of times an action is understood to have occurred, so if the player tries to jump and fails, their "for the first time" will be used up and they will never receive the score points.
 
 If there are many "treasure" items like the Picasso miniature, it is best to be systematic, as in <b>No Place Like Home</b>. <b>Bosch</b> takes another approach to the same idea, by creating a table of point-earning actions that the player will be rewarded for doing; the FULL SCORE command will then play these back.
 
-<b>Mutt's Adventure</b> demonstrates how we might add a scored room feature, such that the player earns a point when he first arrives at a special room.
+<b>Mutt's Adventure</b> demonstrates how we might add a scored room feature, such that the player earns a point when they first arrive at a special room.
 
 A single number does not really sum up a life, or even an afternoon, and <b>Goat-Cheese and Sage Chicken</b> and <b>Panache</b> offer more detailed citations. Works that are more story than story may prefer to offer a plot summary of the player's experience to date in lieu of more conventional scoring.
 
@@ -2522,7 +2522,7 @@ VERIFY examines checksums to make sure that the story file being run is intact a
 
 PRONOUNS announces to the player what the story is currently understanding as the antecedents of "him", "her", "it", and "them". This is often useful during testing, but sometimes also during play. 
 
-The following allow the player (when supported by his interpreter) to create a log of play:
+The following allow the player (when supported by the interpreter in use) to create a log of play:
 
 	Switching the story transcript on (TRANSCRIPT ON)
 	Switching the story transcript off (TRANSCRIPT OFF)
@@ -2568,7 +2568,7 @@ We can eliminate the asterisked headline entirely by removing the rule that prin
 
 	The print obituary headline rule is not listed in any rulebook.
 
-The next step is to print the player's score and, if applicable, the rank he achieved. By default a story doesn't feature scoring, but the following use option will incorporate it:
+The next step is to print the player's score and, if applicable, the rank they achieved. By default a story doesn't feature scoring, but the following use option will incorporate it:
 
 	Use scoring.
 
@@ -2596,7 +2596,7 @@ If we do leave the question in, the text is formed by the Table of Final Questio
 
 Because this is a table, we may alter the behavior by changing entries or continuing the table. <b>Finality</b> shows how we might take out the option to UNDO the last command, for instance.
 
-Using an ending phrase that includes "finally" tells Inform to include the options that are marked "only if victorious". One common use is to let the player read some special bit of additional text, perhaps describing easter eggs he might have missed in the story or presenting some authorial notes. <b>Xerxes</b> demonstrates a simple AMUSING command to read final information, while <b>Jamaica 1688</b> shows how to add completely new elements to the list of options.
+Using an ending phrase that includes "finally" tells Inform to include the options that are marked "only if victorious". One common use is to let the player read some special bit of additional text, perhaps describing easter eggs they might have missed in the story or presenting some authorial notes. <b>Xerxes</b> demonstrates a simple AMUSING command to read final information, while <b>Jamaica 1688</b> shows how to add completely new elements to the list of options.
 
 Old-school adventures expected their adventurers to die early and die often. <b>Labyrinth of Ghosts</b> shows how the residue of such past attempts can be preserved into subsequent attempts, using an external file. <b>Big Sky Country</b> shows how a player can be resurrected by, let us say, some beneficent god, so that a player can even die more than once in the same attempt.
 
@@ -2662,7 +2662,7 @@ The examples below offer miscellaneous alternatives, and are fairly self-descrip
 
 Inform normally expects a purely turn-based story: the player acts, the story responds and waits for the player to act again.
 
-Occasionally, however, we may want to offer a different mode of interaction, for instance with turns in which the player has limited time to come up with his next act. Likewise, we might want to have text that printed itself to the screen gradually, to represent dialogue with pauses, or the speed of a typewriter placing letters on a page.
+Occasionally, however, we may want to offer a different mode of interaction, for instance with turns in which the player has limited time to come up with the next action. Likewise, we might want to have text that printed itself to the screen gradually, to represent dialogue with pauses, or the speed of a typewriter placing letters on a page.
 
 It's best to be careful with these effects: overdone, they can be very annoying to players who prefer to read at a faster speed. Nonetheless, they do have their uses.
 
@@ -2682,7 +2682,7 @@ Inform does not have standard syntax to handle real-time delays and output, but
 
 Glulx is one of the two basic story file formats to which Inform can work. It is the more powerful of the two, and modern-day Inform uses it by default. At one time it was a less universally playable format, but today players rarely have any trouble getting it to work.
 
-Among its powers are the ability to display images, play back sound effects, and read and write external files to the disc. With care and a certain amount of fuss, this can even give a playing story file limited Internet connectivity, although it should be stressed that this can only be done if the player sets up his computer just right and runs an auxiliary program beside the story itself. That will mostly be too much to ask, if the player is playing offline, but when the story file is being run on an interpreter running at a server - so that the player simply sends commands to it and sees responses back on a web page - one could easily imagine setting up the server to provide these auxiliary programs, without any extra difficulty for the player.
+Among its powers are the ability to display images, play back sound effects, and read and write external files to the disc. With care and a certain amount of fuss, this can even give a playing story file limited Internet connectivity, although it should be stressed that this can only be done if the player sets up their computer just right and runs an auxiliary program beside the story itself. That will mostly be too much to ask, if the player is playing offline, but when the story file is being run on an interpreter running at a server - so that the player simply sends commands to it and sees responses back on a web page - one could easily imagine setting up the server to provide these auxiliary programs, without any extra difficulty for the player.
 
 Many of the more advanced multimedia abilities of Glulx are best unlocked using extensions available from the Inform website or the Public Library. As of this writing, extensions exist to help authors create complex multi-windowed displays (including per-location pictures, visual status bars, and even limited animations and gradually-revealed maps). 
 

resources/Documentation/Writing with Inform.txt

@@ -258,7 +258,7 @@ As these examples begin to show, Inform source imitates the conventions of print
 
 ^^{error messages: for source text} ^^{problem messages: for source text}
 
-The language used in the source reads as if it were English aimed at a human reader (and this is intentional: the designer, after all, is a human reader and needs to be able to understand his or her own source), but in reality Inform can only understand a very modest range of sentences and will complain if its limits are passed. Subtler problems arise if the source contains contradictions. For instance, the following "Problem" might be produced:
+The language used in the source reads as if it were English aimed at a human reader (and this is intentional: the designer, after all, is a human reader and needs to be able to understand their own source), but in reality Inform can only understand a very modest range of sentences and will complain if its limits are passed. Subtler problems arise if the source contains contradictions. For instance, the following "Problem" might be produced:
 
 	<b>Problem.</b> You wrote 'A starting pistol is in the cup' ///Reveal.png///, but in another sentence 'A Panama hat is on the cup' ///Reveal.png///: the trophy cup cannot both contain things and support things, which is what you're implying here. If you need both, the easiest way is to make it either a supporter with a container attached or vice versa. For instance: 'A desk is here. On the desk is a newspaper. An openable container called the drawer is part of the desk. In the drawer is a stapler.'
 
@@ -440,13 +440,13 @@ Newcomers will probably not need extensions for quite some while, but there is n
 
 Extensions are identified by name (say "Following People") and also by author (say "Mary Brown"). They need to be installed before they can be used, which means downloading them from the Internet. By far the easiest way to do this is to use the Public Library feature of Inform: then the application can do everything, letting us either choose individual extensions or download them en masse. But it's also possible to install extensions by hand.
 
-{OSX,^app:}When using Inform on Mac OS X, use the File menu item <b>Show Extensions Folder</b> to open the relevant folder in the Finder. Each author has a subfolder of this folder, and his or her extensions live inside it.
+{OSX,^app:}When using Inform on Mac OS X, use the File menu item <b>Show Extensions Folder</b> to open the relevant folder in the Finder. Each author has a subfolder of this folder, and their extensions live inside it.
 
 {Windows,^app:}When using Inform on Windows, this means storing them in the folder
 
 {Windows,^app:}	My Documents\Inform\Extensions
 
-{Windows,^app:}Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as:
+{Windows,^app:}Each author has a subfolder of this folder, and their extensions live inside it. Our example extension should therefore be placed as:
 
 {Windows,^app:}	My Documents\Inform\Extensions\Mary Brown\Following People.i7x
 
@@ -454,7 +454,7 @@ Extensions are identified by name (say "Following People") and also by author (s
 
 {Linux,^app:}	~/Inform/Extensions/
 
-{Linux,^app:}where "~" signifies your home folder. (This will have been created for you the first time you ran i7.)  Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as:
+{Linux,^app:}where "~" signifies your home folder. (This will have been created for you the first time you ran i7.)  Each author has a subfolder of this folder, and their extensions live inside it. Our example extension should therefore be placed as:
 
 {Linux,^app:}	~/Inform/Extensions/Mary Brown/Following People.i7x
 
@@ -462,7 +462,7 @@ Extensions are identified by name (say "Following People") and also by author (s
 
 {GNOME,^app:}	~/Inform/Extensions/
 
-{GNOME,^app:}where "~" signifies your home folder. (This will have been created for you the first time you ran i7.)  Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as:
+{GNOME,^app:}where "~" signifies your home folder. (This will have been created for you the first time you ran i7.)  Each author has a subfolder of this folder, and their extensions live inside it. Our example extension should therefore be placed as:
 
 {GNOME,^app:}	~/Inform/Extensions/Mary Brown/Following People.i7x
 
@@ -1148,7 +1148,7 @@ Rooms can be "dark" or "lighted", though they are lighted by default, and are li
 
 	The Sinister Cave is a dark room. "A profoundly disquieting rock formation, apparently sculptured by some demonic hand, this is not a cave in which to relax."
 
-When the player is in a dark room, he can still go in various directions, but he cannot see the room description or interact with any of the objects in the room, except those he is holding. This means that, unless we should change the Cave in some way during play, the text above ("A profoundly...") will only be read if the player succeeds in bringing light into the Cave, perhaps by bringing along the following:
+When the player is in a dark room, they can still go in various directions, but they cannot see the room description or interact with any of the objects in the room, except those they are holding. This means that, unless we should change the Cave in some way during play, the text above ("A profoundly...") will only be read if the player succeeds in bringing light into the Cave, perhaps by bringing along the following:
 
 	The flaming torch is in the Sandy Passage. "Stuck loosely into the sand is a flaming torch." The flaming torch is lit.
 
@@ -1336,7 +1336,7 @@ When the player has only limited carrying capacity, play is likely to be tiresom
 
 	In the Attic are a CD entitled No Smoke Without Fire, a 70s photograph of an American winning Wimbledon, a fraxinus branch, an urn holding your late great-aunt's remains, a convention badge from the American Society of Hypertension and a ghost story by M R James.
 
-This example story introduces a new kind of container, the "player's holdall". This is a kind of which most stories will contain at most one example, but in principle there can be any number. A player's holdall is a capacious bag into which the player automatically places surplus items whenever his or her hands are full: trying the above example story and getting the items one by one will give the general idea.
+This example story introduces a new kind of container, the "player's holdall". This is a kind of which most stories will contain at most one example, but in principle there can be any number. A player's holdall is a capacious bag into which the player automatically places surplus items whenever their hands are full: trying the above example story and getting the items one by one will give the general idea.
 
 Of course, if the carrying capacity of the player is never reached then there will never be any surplus items and a player's holdall will behave just like any other (portable, usually openable) container.
 
@@ -1543,7 +1543,7 @@ Some kinds are more general than others. For example, if we write:
 
 	Growler is an animal in the Savannah.
 
-then Growler is an "animal", which is a kind of "thing", which is a kind of "object". When we talk about "the" kind of Growler, we mean "animal", the most specific one, but actually he belongs to all of those kinds.
+then Growler is an "animal", which is a kind of "thing", which is a kind of "object". When we talk about "the" kind of Growler, we mean "animal", the most specific one, but actually Growler belongs to all of those kinds.
 
 As we see from this example, kinds have a whole hierarchy. Some are specialised versions of other kinds; some are not. Browsing the Kinds index shows that Inform builds its model world out of "objects". (That's really what objects are: "object" is a kind of value used to make the ingredients of the model world.) The objects fall into four fundamental kinds, "room", "thing", "direction" and "region", and "thing" is more subdivided still.
 
@@ -2165,7 +2165,7 @@ The standard naming scheme is often about right, but as usual Inform offers a wa
 then we will find the world full of, say, the Garden buggy, the Patio buggy and so on - instead of the Garden vehicle, the Patio vehicle and so on, which is what we would have had without the "called..." part. Similarly, we could write:
 
 	A person (called its fan) likes every colour.
-	Every person likes a colour (called his favourite colour).
+	Every person likes a colour (called their favourite colour).
 
 The former would produce new people with names like "Green's fan", whereas the latter would produce new colours with names like "Daphne's favourite colour".
 
@@ -2864,7 +2864,7 @@ but not
 
 	Łodz Churchyard is a room.
 
-Moreover, the player is not allowed to type these characters in commands during play: or rather, they will not be recognised if he does. They are for printing only.
+Moreover, the player is not allowed to type these characters in commands during play: or rather, the characters will not be recognised if the player does. They are for printing only.
 
 (d) <b>Characters which might work in quoted text, or might not</b>. The Arabic and Hebrew alphabets are fairly likely to be available; miscellaneous symbols are sometimes legible to the player, sometimes not. Other alphabets are chancier still. (If a work of IF depends on these being visible, it may be necessary to instruct players to use specific interpreters, or to provide a way for the player to test that all will be well.)
 
@@ -4062,7 +4062,7 @@ This may be a good place to mention a small restriction on the ways we can speci
 
 	The Dome is a room. The Hutch is north of the Dome. The rabbit is in the Hutch. Before going to the location of the rabbit, say "You pick up a scent!"
 
-because "the location of the rabbit" is a quantity which changes in play (the player can pick up the rabbit and take him to the Dome, for instance). However, we can get around this restriction by defining a suitable adjective, like so:
+because "the location of the rabbit" is a quantity which changes in play (the player can pick up the rabbit and take it to the Dome, for instance). However, we can get around this restriction by defining a suitable adjective, like so:
 
 	The Dome is a room. The Hutch is north of the Dome. The rabbit is in the Hutch. Definition: a room is rabbit-infested if it is the location of the rabbit. Before going to a rabbit-infested room, say "You pick up a scent!"
 
@@ -4106,7 +4106,7 @@ Finally, going is an action which can also happen while the player is pushing so
 
 	Instead of going from the Office with the trolley, say "But it looks perfectly placed here. Why push any further?"
 
-"Going" is not the only action which moves the player. Another is "exiting", an action which moves the player out of whatever he/she is currently in or on. This action is often caused by the player typing just OUT or GET DOWN, and there's no noun as such. But Inform allows the syntax "exiting from" to make it easier to write rules about the exiting of particular containers or supporters:
+"Going" is not the only action which moves the player. Another is "exiting", an action which moves the player out of whatever they are currently in or on. This action is often caused by the player typing just OUT or GET DOWN, and there's no noun as such. But Inform allows the syntax "exiting from" to make it easier to write rules about the exiting of particular containers or supporters:
 
 	After exiting from the Mini Cooper:
 		say "You painstakingly unpack your limbs from the tiny car."
@@ -4975,7 +4975,7 @@ The score and maximum score are just numbers that vary, so we can freely change
 ^^{scoring: ranking table}
 ^^{maximum score (— number)+glob+}
 
-Another tradition of interactive fiction is that the player has a current 'rank' according to how far his or her score has got. We can (but need not) choose to provide such rankings, and should do so by specifying a table like this:
+Another tradition of interactive fiction is that the player has a current 'rank' according to how far their score has got. We can (but need not) choose to provide such rankings, and should do so by specifying a table like this:
 
 	{*}Table 1 - Rankings
 	Score	Rank
@@ -5518,7 +5518,7 @@ Every scene has two rulebooks attached, one at each end, so to speak. These look
 		now the Flying Scotsman is nowhere;
 		if the player is in the Station, say "The Flying Scotsman inches away, with a squeal of released brakes, gathering speed invincibly until it disappears around the hill. All is abruptly still once more."
 
-Thus when the scene begins, our imaginary stage-hands wheel in a steam train; when it ends, they get rid of it again. Note that we know where the player will be at the start of the scene, but by the end he may have wandered off across the fields, so we must be careful not to report something he might not be in a position to see.
+Thus when the scene begins, our imaginary stage-hands wheel in a steam train; when it ends, they get rid of it again. Note that we know where the player will be at the start of the scene, but by the end they may have wandered off across the fields, so we must be careful not to report something they might not be in a position to see.
 
 When Train Stop begins, we printed some text, but we did this by hand. We didn't need to, because Inform automatically prints out the description of a scene (if it has one) when the scene begins. Scenes can have properties, just like objects, and in particular they have the "description" property. For example, we could write:
 
@@ -6687,7 +6687,7 @@ The following flow chart shows the natural course of events when Inform deals wi
 
 The coloured boxes on this chart represent "rulebooks", that is, collections of rules with a common purpose. The orange boxes for Before, Instead and After were covered in the Basic Actions chapter, but the blue boxes are new. The orange boxes are where we put rules to handle unusual situations, or unexpected events: special rules to cover the opening of a container which happens to be booby-trapped, or walking through a doorway into a room where a surprise party is about to be sprung.
 
-Blue boxes hold the mundane, everyday rules - the generic ways that particular actions behave. Every action provides these: "Check" rules, to see if it makes sense - for instance, to see that the player is not trying to take his or her own body, or a whole room, or something he or she already has; then "Carry out" rules, to actually do what the action is supposed to do - in the case of taking, to move an object into the player's possession; and finally "Report" rules, which tell the player what has happened - perhaps printing up "Taken."
+Blue boxes hold the mundane, everyday rules - the generic ways that particular actions behave. Every action provides these: "Check" rules, to see if it makes sense - for instance, to see that the player is not trying to take their own body, or a whole room, or something they already have; then "Carry out" rules, to actually do what the action is supposed to do - in the case of taking, to move an object into the player's possession; and finally "Report" rules, which tell the player what has happened - perhaps printing up "Taken."
 
 When we create a new action, we add a new column to the blue rows in this diagram. As we shall see, we can also put new rules into the existing blue boxes: for instance, if we wanted to increase physical realism by forbidding the player to carry more than a certain weight, we would want to add a new "check taking" rule, and this is entirely legal.
 
@@ -6797,7 +6797,7 @@ If we wish to write new successful actions for another character, we will need t
 ^^{ACTIONS+testcmd+} ^^{testing commands: >ACTIONS}
 ^^{Actions page of Index panel+ui+} ^^{user interface: Index panel: Actions page} ^^{Index panel+ui+: Actions page}
 
-Suppose, finally, that Will not only consents to try the action, but it also survives its passage through Before and Instead rules. What happens then? In principle, what happens to Will is exactly what would have happened to the player in his place. For instance:
+Suppose, finally, that Will not only consents to try the action, but it also survives its passage through Before and Instead rules. What happens then? In principle, what happens to Will is exactly what would have happened to the player in Will's place. For instance:
 
 	> will, go east
 	Will leaves to the east.
@@ -6838,7 +6838,7 @@ Finally, note that "unsuccessful attempt" rules apply only when the person in qu
 ^^{characters (people): acting spontaneously}
 ^^{unsuccessful attempt by+rb+: not used for spontaneous actions}
 
-The player's actions happen not only when he types a command, but can also happen spontaneously as a result of a "try" phrase.
+The player's actions happen not only when they type a command, but can also happen spontaneously as a result of a "try" phrase.
 
 	try going west
 	try asking Will to try going west
@@ -7464,7 +7464,7 @@ Sometimes we can choose our own answer to this question, and go either way. Supp
 
 The next question is: does the effect kick in after the hoped-for action has taken place, or not? In the case of the land mine, to answer that means deciding whether we think the detonator is sensitive to the slightest touch - in which case the explosion would happen at the first touch, and should be in an "Instead" rule - or whether one must actually pick up and disturb the mine - in which case an "After" should be used.
 
-That leaves us a choice of two rulebooks if the effect takes place when the merest impulse towards the action is felt: "Before" and "Instead". Which to use? In cases of doubt, choose "Instead". But if the effect is intended to absolutely suppress all such impulses - for instance, in a silent examination room there must be no talking - then "Before" might be more appropriate. We could imagine that someone about to say something first has a mental impulse to speak, then opens his mouth so that it becomes visible to others that some talking is about to go on, and finally utters words. Here are three possible responses:
+That leaves us a choice of two rulebooks if the effect takes place when the merest impulse towards the action is felt: "Before" and "Instead". Which to use? In cases of doubt, choose "Instead". But if the effect is intended to absolutely suppress all such impulses - for instance, in a silent examination room there must be no talking - then "Before" might be more appropriate. We could imagine that someone about to say something first has a mental impulse to speak, then opens their mouth so that it becomes visible to others that some talking is about to go on, and finally utters words. Here are three possible responses:
 
 	"You cannot contemplate breaking this smothering silence." (<i>Before</i>)
 	"The invigilator stares you down through her horn-rimmed glasses." (<i>Instead</i>)
@@ -7801,9 +7801,9 @@ Earlier versions of Inform needed to be told how to make other parts of the verb
 
 	The verb to sport means the wearing relation.
 
-is enough for Inform to understand "he sports", "they sport", "he sported", "it is sported", "he is sporting", "he had sported" and so on. It works with irregular verbs, too; it has a very comprehensive dictionary. But it's legal to spell out the conjugation if need be:
+is enough for Inform to understand "she sports", "they sport", "he sported", "it is sported", "she is sporting", "he had sported" and so on. It works with irregular verbs, too; it has a very comprehensive dictionary. But it's legal to spell out the conjugation if need be:
 
-	The verb to sport (he sports, they sport, he sported, it is sported) implies the knowledge relation.
+	The verb to sport (she sports, they sport, he sported, it is sported) implies the knowledge relation.
 
 Occasionally it's convenient to have the relation the other way around. For instance:
 
@@ -8694,7 +8694,7 @@ Adapts the given verb to the current story tense and story viewpoint, giving it
 {end}
 
 {defn phs_negatev}say "[negate (verb) from (narrative viewpoint)]"
-Adapts the given verb to the current story tense but the given viewpoint, giving it a negative sense. For example, "he [negate the verb provoke from the third person singular]" might produce "he does not provoke".
+Adapts the given verb to the current story tense but the given viewpoint, giving it a negative sense. For example, "she [negate the verb provoke from the third person singular]" might produce "she does not provoke".
 {end}
 
 {defn phs_negatet}say "[negate (verb) in (grammatical tense)]"
@@ -11246,7 +11246,7 @@ As this demonstrates, the either/or property "privately-named" makes Inform crea
 
 	The ungraspable concept is a privately-named thing in the Dining Room.
 
-then nothing the player can type will ever refer to it; though he will see it, and even be able to pick it up by typing TAKE ALL.
+then nothing the player can type will ever refer to it; though they will see it, and even be able to pick it up by typing TAKE ALL.
 
 The reverse property is "publicly-named", which all things and rooms are by default.
 
@@ -11379,7 +11379,7 @@ This phrase sets the multiple object list to the given value. The list is ordina
 ^^{testing commands: comments in transcripts from beta testers}
 ^^{comments: in transcripts from beta testers}
 
-When inspiration strikes the player, he can usually be relied upon to make a good-faith effort to communicate the new idea: he will guess the right command. If he guesses wrongly, the mistake is probably the author's, because a good author will try to anticipate all possible wordings and make all of them work.
+When inspiration strikes the player, they can usually be relied upon to make a good-faith effort to communicate the new idea: they will guess the right command. If they guess wrongly, the mistake is probably the author's, because a good author will try to anticipate all possible wordings and make all of them work.
 
 Nevertheless it is sometimes good practice to nudge the player towards the right wording - particularly if the player has the right idea but is not explicit enough: for instance, typing TALK TO JUDGE when we really want to know what is to be said (JUDGE, GUILTY); or if the player tries something like PLAY CHESS rather than MOVE PAWN TO KING 4. Similarly, if we make a casual reference such as "In your childhood days, you loved sliding in stocking feet across this hallway", a player might type SLIDE IN STOCKING FEET: a nice idea, and which deserves a nice response, even though it asks to do something beyond the scope of the story.
 
@@ -12092,7 +12092,7 @@ The " (providing light)" (note initial space) was added by this activity.
 
 	Before printing the announcement of darkness: now all of the gremlins are in the kitchen.
 
-(c) A special description for occasions when the player has climbed into a container and shut it (so that the darkness is the result of his own actions, rather than some external circumstance):
+(c) A special description for occasions when the player has climbed into a container and shut it (so that the darkness is the result of their own actions, rather than some external circumstance):
 
 	Rule for printing the announcement of darkness when closing a container which contains the player:
 		say "Congratulations: now you can't see a thing." instead.
@@ -12380,7 +12380,7 @@ Note that the object in question can be a room, as in this second example.
 
 (This must, however, also be a mirage, as at time of writing Mr Depp is alive and as well as can be expected following the reviews of "Charlie and the Chocolate Factory".) Note that "place the Ballroom in scope" doesn't just allow the player to talk about the dancers, the chamber musicians and so forth, also allows, say, "EXAMINE BALLROOM". To get one but not the other, use "place the contents of the Ballroom in scope" or "place the Ballroom in scope, but not its contents".
 
-(c) In darkness, the scope of someone is ordinarily restricted to his or her possessions (and body), but we can override that:
+(c) In darkness, the scope of someone is ordinarily restricted to their possessions (and body), but we can override that:
 
 	After deciding the scope of the player while in darkness: place the location in scope.
 
@@ -12575,7 +12575,7 @@ This converts the player's command to text, which is then manipulated by searchi
 
 No matter what rules are written for this activity, it is impossible to use it to allow the action to go ahead even without the item. The activity allows us to change how, or if, an implicit take will happen, but not to change the consequences of failure. (To do that, we would need to say that "The carrying requirements rule does nothing", but this kind of unstitching of the action machinery needs to be done with caution.)
 
-<b>3. Examples.</b> (a) Forbidding implicit takes for certain dangerous items. (This seems especially fair if taking such items might cause death: the player will not wish to be killed on the strength only of our guess as to what he might be intending to do.)
+<b>3. Examples.</b> (a) Forbidding implicit takes for certain dangerous items. (This seems especially fair if taking such items might cause death: the player will not wish to be killed on the strength only of our guess as to what they might be intending to do.)
 
 	Rule for implicitly taking the curare:
 		say "Ordinarily you'd pick up the curare in order to be able to do that, but this seems like a good moment for caution." instead.
@@ -13199,7 +13199,7 @@ To follow the working of this mechanism, we need to be able to predict the outco
 	stop the action; <i>means</i> "end this rule in failure"
 	... instead; <i>means</i> "end this rule in failure"
 
-("Success" and "failure" are technical terms here: they do not mean that the player has or hasn't got what he wanted.) This is why the rule:
+("Success" and "failure" are technical terms here: they do not mean that the player has or hasn't got what they wanted.) This is why the rule:
 
 	Before taking something: say "The sentry won't let you!" instead.
 
@@ -14914,7 +14914,7 @@ Queues typically form when two independent processes are at work, but going at d
 
 	The queue is a list of objects that varies.
 
-(Invariably people, in what follows, but we'll make it a "list of objects" to allow for other possibilities too.) Once we identify a "new customer", we can join him to the queue thus:
+(Invariably people, in what follows, but we'll make it a "list of objects" to allow for other possibilities too.) Once we identify a "new customer", we can join them to the queue thus:
 
 	add the new customer to the queue;
 
@@ -17249,7 +17249,7 @@ However, the Inform project does recognise some extensions as "public". Public e
 
 Writers who wish to make their extensions public on the Inform website should also be clear that by doing so, they are donating their work to the community on the basis of the broadest form of Creative Commons license: that is, they retain copyright and the right to be identified as the author (and as we shall see they are automatically credited in any work of IF which uses their extension), but are giving unlimited permission to use, circulate and republish their extensions in any form, even as part of commercial works (should that arise). To publish a public extension is a public-spirited act, done for only the reward of a modest acknowledgement.
 
-If the author of an extension has not made it public, or indicated in some other way that it is free to be used without the need for permission, then it would be both polite and prudent to check with the author before publishing something which incorporates his work.
+If the author of an extension has not made it public, or indicated in some other way that it is free to be used without the need for permission, then it would be both polite and prudent to check with the author before publishing something which incorporates their work.
 
 [x] The Standard Rules {SRULES}
 
@@ -17278,7 +17278,7 @@ If the file has already been included, then the sentence is simply ignored. This
 ^^{materials folder: project-specific extensions}
 ^^{inform7.com+web+}
 
-To recap: Inform builds projects from both the source text typed by the author and from Extensions; one of these, the Standard Rules, is always included; others are added as authors please. About 20 are "built-in" to Inform, meaning that they are stored inside the application and always available. Others must be "installed", and each Inform user will have a folder somewhere on his computer which contains these. Users typically obtain these from the Public Library feature in the Inform application, but can also download them directly from the extension writer's website and then use an Install Extension menu option in the application. Either way, the application then squirrels the file away, and it becomes available to any projects that that user may be working on.
+To recap: Inform builds projects from both the source text typed by the author and from Extensions; one of these, the Standard Rules, is always included; others are added as authors please. About 20 are "built-in" to Inform, meaning that they are stored inside the application and always available. Others must be "installed", and each Inform user will have a folder somewhere on their computer which contains these. Users typically obtain these from the Public Library feature in the Inform application, but can also download them directly from the extension writer's website and then use an Install Extension menu option in the application. Either way, the application then squirrels the file away, and it becomes available to any projects that that user may be working on.
 
 It is also possible to have extensions available to just one project. These must be stored in the Extensions subfolder of the project's ".materials" folder, but otherwise are arranged the same as installed extensions - there's an outer folder for each author's name, and extensions are named with a ".i7x" extension within. For example:
 
@@ -17297,7 +17297,7 @@ When Inform needs to find an extension, it looks here first, then in the install
 ^^{extensions: writing: author+biblio+}
 ^^{author+biblio+: of an extension}
 
-Extensions are identified by author and by name, so that a given author can produce his or her own range of extensions, and need only ensure that these are named differently from each other. If John Smith and Mary Brown each want to write an extension called "Following People", there is no conflict.
+Extensions are identified by author and by name, so that a given author can produce their own range of extensions, and need only ensure that these are named differently from each other. If John Smith and Mary Brown each want to write an extension called "Following People", there is no conflict.
 
 The name of an extension, and of an author, should be written in Sentence Capitalisation: that is, upper case for the first letter in each word. (Inform uses this to minimise problems on machines where filenames are read with case sensitivity.) It is permitted for author names to include upper-case letters within words, as with the "G" in "^{@Jesse McGrew}". In general it is best to avoid accented or unusual letters in titles and author names, but the standard ISO Latin-1 characters should be allowed - for instance,
 
@@ -17626,7 +17626,7 @@ Note that the paste button, denoted "*:", pastes in the text following it, but o
 
 Extensions often need to define new kinds or properties, which we want to make as helpful as possible for the user. In particular, we want them not to require additional work for the author just to obtain the effect which seems only natural.
 
-For example, consider Inform's built-in "locked" property. If a door is locked, then it cannot be opened, which seems fair enough. But if the player tries to unlock the door, he might then find the following response:
+For example, consider Inform's built-in "locked" property. If a door is locked, then it cannot be opened, which seems fair enough. But if the player tries to unlock the door, they might then find the following response:
 
 	That doesn't seem to be something you can unlock.