X-Git-Url: https://jxself.org/git/?a=blobdiff_plain;f=chapters%2F04.rst;h=b01d7732d021218faeb9ddf0eb2f9d8f5193539b;hb=81deb40a92a715b3ef8037535806b01d4fe2f5fa;hp=e6af20c62fa362e770970516d8bf032681bd74f8;hpb=95b5702817b987123d71d432f81eeb0c7101b59c;p=ibg.git diff --git a/chapters/04.rst b/chapters/04.rst index e6af20c..b01d773 100644 --- a/chapters/04.rst +++ b/chapters/04.rst @@ -4,6 +4,8 @@ .. highlight:: inform +.. default-role:: samp + .. epigraph:: | |CENTER| *G was a gamester, who had but ill-luck;* @@ -68,12 +70,16 @@ but you can change it at any time. For example, we used the statement:: location = before_cottage; -to reset the value of the ``location`` variable to the +.. Generated by autoindex +.. index:: + pair: location; library variable + +to reset the value of the :var:`location` variable to the ``before_cottage`` object, and we wrote:: if (nest in branch) deadflag = 2; -to reset the value of the ``deadflag`` variable to 2. +to reset the value of the :var:`deadflag` variable to 2. Later, we'll talk about the :term:`local variable` (see :ref:`routines`) and about using object properties as variables (see :ref:`objects`). @@ -89,20 +95,16 @@ room is an object, each item that the player sees and touches is an object; indeed the player herself is also an object (one that's automatically defined by the library). -.. todo:: - - The set-off below needs to be tweaked or perhaps a custom lexer - created to get italics in the right places. +The general model of an :term:`object` definition looks like this: -The general model of an :term:`object` definition looks like this:: - - Object obj_id "external_name" parent_obj_id - with property value , - property value , - ... - property value , - has attribute attribute ... attribute - ; + | `Object {obj_id} "{external_name}" {parent_obj_id}` + | `with` + | `{property} {value},` + | `{property} {value},` + | `...` + | `{property} {value},` + | `has {attribute} {attribute} ... {attribute}` + | `;` The definition starts with the word ``Object`` and ends with a semicolon; in between are three major blocks of information: @@ -116,22 +118,22 @@ Object headers An object header comprises up to three items, all optional: -* An internal ``obj_id`` by which other objects refer to this object. It's +* An internal `{obj_id}` by which other objects refer to this object. It's a single word (though it can contain digits and underscores) of up to thirty-two characters, and it must be unique within the game. You can - omit the ``obj_id`` if this object isn't referred to by any other + omit the `{obj_id}` if this object isn't referred to by any other objects. For example: ``bird``, ``tree``, ``top_of_tree``. -* An ``external_name``, in double quotes, which is what the interpreter +* An `{external_name}`, in double quotes, which is what the interpreter uses when referring to the object. It can be one or more words, and need not be unique (for instance, you might have several ``"Somewhere in the desert"`` rooms). Although not mandatory, it's best to give *every* - object an ``external_name``. For example: ``"baby bird"``, ``"tall + object an `{external_name}`. For example: ``"baby bird"``, ``"tall sycamore tree"``, ``"At the top of the tree"``. -* The internal ``obj_id`` of another object which is the initial location +* The internal `{obj_id}` of another object which is the initial location of this object (its "parent" -- see the next section) at the start of the game. This is omitted from objects which have no initial parent; it's *always* omitted from a room. @@ -144,8 +146,8 @@ An object header comprises up to three items, all optional: ... The ``tree`` starts like this; the only real difference is that, because - the player character can't move a ``scenery`` object, it's always going - to be in the ``clearing``:: + the player character can't move a :attr:`scenery` object, it's always + going to be in the ``clearing``:: Object tree "tall sycamore tree" clearing ... @@ -184,20 +186,21 @@ Here are examples of the properties that we've come across so far:: By happy coincidence, those examples also demonstrate most of the different types of value which can be assigned to a property. The value associated -with the ``description`` property in this particular example is a string of -characters in double quotes; the value associated with this ``e_to`` -property is the internal identity of an object; the ``name`` property is a -bit unusual -- its value is a list of dictionary words, each in single -quotes; the ``each_turn`` property has a value which is an :term:`embedded -routine` (see :ref:`embedded-routines`). The only other type of value -which is commonly found is a simple number; for example:: +with the :prop:`description` property in this particular example is a +string of characters in double quotes; the value associated with this +:prop:`e_to` property is the internal identity of an object; the +:prop:`name` property is a bit unusual -- its value is a list of dictionary +words, each in single quotes; the :prop:`each_turn` property has a value +which is an :term:`embedded routine` (see :ref:`embedded-routines`). The +only other type of value which is commonly found is a simple number; for +example:: capacity 10, In all, the library defines around forty-eight standard properties -- like -``name`` and ``each_turn`` -- which you can associate with your objects; -there's a complete list in :ref:`object-props`. And in :doc:`08` we show -you how to invent your own property variables. +:prop:`name` and :prop:`each_turn` -- which you can associate with your +objects; there's a complete list in :ref:`object-props`. And in :doc:`08` +we show you how to invent your own property variables. Object attributes ----------------- @@ -413,7 +416,7 @@ which could equally have been defined thus:: Constant Headline "^A simple Inform example^by Roger Firth and Sonja Kesserich.^"; -and as the value of an object ``description`` property:: +and as the value of an object :prop:`description` property:: description "Too young to fly, the nestling tweets helplessly.", @@ -434,8 +437,12 @@ into individual words, which it then looks up in the dictionary. If it finds all the words, and they seem to represent a sensible course of action, that's what happens next. +.. Generated by autoindex +.. index:: + pair: name; library property + So far, we've seen dictionary words used as the values of an object -``name`` property:: +:prop:`name` property:: name 'bird^s' 'nest' 'twigs' 'moss', @@ -465,7 +472,7 @@ encountered only a few. We saw:: which is an example of an :term:`assignment` statement, so-called because the equals sign ``=`` assigns a new value (the internal ID of our -``before_cottage`` room) to a variable (the global variable ``location`` +``before_cottage`` room) to a variable (the global variable :var:`location` which is part of the library). Later we saw:: if (nest in branch) deadflag = 2; @@ -486,7 +493,11 @@ interpreter executes that statement: it performs an assignment:: deadflag = 2; -which changes the value of the library variable ``deadflag`` from its +.. Generated by autoindex +.. index:: + pair: deadflag; library variable + +which changes the value of the library variable :var:`deadflag` from its current value to 2. Incidentally, ``if`` statements are often written on two lines, with the "controlled" statement indented. This makes it easier to read, but doesn't change the way that it works::