Inform 7: Possible future improvements II ----------------------------------------- Emily Short and Graham Nelson April 2009 This second discussion paper follows up the first, published in January 2007, which went through suggestions for changes and gave our view on their merits. In the two years since then, the proposals which were accepted or considered worth studying have pretty well all been acted on, and it is time to go through the process again with a fresh slate of proposals. As before, this has been accumulated from many people over many months, and as before the purpose is both to give our response to these suggestions and to invite others to comment. Sometimes we are fairly sure that we want to say "yes" or "no", but in other cases we would like more evidence and opinions before deciding. We have loosely categorised the proposals, but the order in which they appear under each heading is not meant to imply anything. Contents USER INTERFACE RULES AND RULEBOOKS ADAPTIVE TEXT ACTIONS OUT OF WORLD WORLD MODEL PROGRAMMING TEMPLATE NAMES PARSING OUTPUT FILTERING GLK/GLULX DEBUGGING DOCUMENTATION CHANGES MULTIMEDIA CHANGES EXTENSIONS MAPPING PUBLISHING USER INTERFACE (UI.1) -- Sound support. The core I7 code supports the use of sound effects in Glulx (we intentionally don't support Z-machine sound), and Inform allows compilation of story files that play back sound in suitably-equipped interpreters. The functionality described in the manuals all works, and sound effects are properly indexed. But the three user interface applications differ with each other on the extent to which they can play back sound effects in the Game panel: (a) On Mac OS X, sounds are not played back; messages are printed instead. While we would like to address this, issues with Apple's CoreAudio and licensing problems with APIs present frustrating challenges. (b) On Gnome for Linux, nothing happens; but it's expected that sound playback will be easier to add. (c) On Windows, sounds are played back normally, and there's no issue. So our ideal is to provide this across the board, but it's not as simple as it looks, and this will take a little more time. (UI.2) -- A search function that would allow the user to search the document pane currently visible for a given keyword - for instance, the Actions pane of the Index. This is already present on Mac OS X and Windows, and in development for Linux. (UI.3) -- Make control over font choice and colors consistently available across the platforms. All three platforms offer some choice of font, but they handle style and colour options differently, with Windows offering the least choice for now (being confined to the current system font, though at a choice of sizes). The source panel is currently being rewritten on Windows, so that we can eventually have elastic tab stops there (a feature newly added to OS X and Linux Inform); the new Windows source panel will be more configurable. (UI.4) -- A contextual menu item, and hotkeys, for commenting out selected code all at once, by inserting "[" and "]" around the selected text. This is particularly important in that restyling large chunks of text - as placing the first [ will do near the start of code - is extremely computationally expensive in the interface applications. We accept this proposal. It's already being experimented with on OS X and Linux, and is once again planned for the new Windows source panel implementation. (UI.5) -- A contextual menu item and keyboard shortcuts for indenting or unindenting selected code all at once. We accept this proposal, too. It is already working in the current OS X and Linux Inform builds, and is once again planned for the new Windows source panel implementation. (UI.6) -- Work to make sure that I7 projects are compatible with version control software. Currently it is difficult to use subversion with Inform 7 on some systems as reported here: http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/6ca6c0232ae7aa54?tvc=2&q=inform+subversion We have to be honest that this is not a big priority, because there's so much else to do, but we will make efforts. We have now standardised the source text line ending marker on "\n" (0x0A) across all platforms, which some people have requested for VCS-related reasons. (UI.7) -- A way to bookmark one's place in the Source text panel so that one can quickly jump back to it. We propose to allow the user to set bookmarks in the source, with shortcuts to jump back to the most-recently set; the bookmarks would also be visible in the contents view of the source, and could be deleted again. We accept this proposal in principle, and work is under way, but it's quite a large feature to add and will take a little time. (UI.8) -- A method for having the interface entirely in other language (menus, messages, panels). This hasn't been a priority so far because it wouldn't make the rest of the application conform to another language. Different operating systems have different idioms for localization, and given that the interface contains relatively little text, changing only slowly, it's probably better to do this platform by platform. Some progress has already been made on this for Linux. (UI.9) -- A shortcut or setting to turn on/off wrap lines in the editor, especially for cases where there are broad tables to view. In principle, this is fine, but we don't want the editor to become too visually complicated with controls to set. We are skeptical about the practicality of this. The new elastic tabs do help somewhat with tables, though they aren't the whole answer. (UI.10) -- To provide a Notes panel, as a sort of jotter attached to each project where authors could keep working ideas, to-do lists and so on. On Mac OS X, this already exists, in a limited form, in the Inspector window, though the Inspector doesn't exist on Windows and looks a little out of place on Gnome. There are people who very much like Notes options - "useful in the extreme" - but they leave a lot of other people cold. On the whole, we think that this is a slippery slope: people use a wide variety of tools to design IF, including text editors, spreadsheet programs, and diagramming programs. Since it is obviously impossible for the Inform interface to replicate all of those different functions, it probably makes more sense not to offer a half-hearted solution. There is, of course, nothing to stop authors from keeping associated files in the Materials directory attached to their project, and indeed that is part of the idea of Materials (and one reason why it is open-access rather than being concealed inside the project bundle on Mac OS X). (UI.11) -- Add memory usage statistics when compiling. It is proposed that we offer a compilation message of the form: The 25181-word source text has successfully been translated into a world with 7 rooms and 72 things, occupying 56% of Z-machine readable memory. This would be difficult to accomplish because the I7 report page is built before the I6 compiler (which produces this kind of information) is run. While it would in theory be conceivable to implement this, it would be a considerable bother to do. (It may be that a debugging command like, say, MEMORY could be written which would display this information in play.) (UI.12) -- For a command-click in the contents pane to take the user to the selected portion of the source, but without restricting the view only to that one area. We accept this proposal. (On Windows, it amounts to the same thing as an ordinary click at present - Windows does not yet implement restricted views, though it's hoped to add this in future.) RULES AND RULEBOOKS (R.1) -- Passive and thus more object-oriented-sounding phrasings for action rules, for instance: Check the cat being rubbed: .... Report the cat being rubbed: .... On consideration, we think this is likely to produce more confusion than enlightenment; these rulebooks really are about actions, not about objects, and we doubt whether it would be helpful in the long run to try to disguise that fact from authors. (R.2) -- Expansion of the rules model to allow rules to act on multiple, typed parameters, as in: Reaction rule for a powder (called reagent A) with a powder (called reagent B): ... To combine (reagent A - a powder) with (reagent B - a powder): consider the reaction rules with reagent A as the first component and reagent B as the second component. (The original proposal is laid out in more detail at http://groups.google.com/group/rec.arts.int-fiction/msg/964587315d0702b4). It is undeniable that the main "decision mechanisms" provided by Inform - phrases, properties, rulebooks, actions - nearly meet at the edges, and that as their capabilities increase they overlap. Here we are looking at the border-line between phrases and rulebooks. The introduction of rulebook variables in 2007 moved these closer together, because it meant that the collective rules of a rulebook could share "local variables" like those of the definition of a phrase. This new proposal would move the two concepts closer together still: it would allow a rulebook to have a general kind (K1, K2, ..., Kn) --> K - assuming that we are also allowed to make the outcome of a rulebook a value of any general kind. At present, only a phrase can behave like that. We don't regard overlaps as necessarily a bad idea. Without going entirely in the Perl direction of "there are many ways to do something", we can still benefit from providing what seem natural facilities to the user. It might seem cleaner - better, in traditional computer science aesthetics - to have just one construct (the rulebook, probably) and build all else from that - actions, phrases, properties, even variables - but that would be a burden to the user, taking us away from natural language, and would also be less efficient to run. We think a simpler and less disruptive approach might be to allow the user to say that the definition of any phrase is a rulebook. For instance, the following prototype: To react (reagent A - a powder) with (reagent B - a powder) - this is the reaction rulebook. would create a rulebook, which would be initially empty; so that react potassium permanganate with sodium; would do nothing. (Well, okay, you don't see powdered sodium very much, except when it's a chloride.) Phrase definitions such as: To reach (reagent A - a powder) with (reagent B - sodium): say "Bang!" would then add rules to the rulebook, sorted according to specificity as usual. At present, when there are multiple definitions for the same phrase, the most specific one which matches is the only one which is applied. But for such a rulebook-defined phrase, multiple definitions could apply in sequence. "Reagent A" and "Reagent B", rather than being local variables, would be rulebook variables. This probably needs further thinking about. We still need consensus on what the syntax should best look like; this is a question for further study. ADAPTIVE TEXT (AT.1) -- For the functionality of Emily Short's Plurality extension to be normalized and built into the main body of Inform, and also to provide an assortment of text substitutions. This we plan to do. (AT.2) -- Another text variation: something like [then at random] that printed things in the specified order the first time through and then was random. This can be implemented as follows: To say then at random -- ending say_one_of with marker I7_SOO_TAR: (- {-close-brace} -). To say then purely at random -- ending say_one_of with marker I7_SOO_TPAR: (- {-close-brace} -). To say then in random order -- ending say_one_of with marker I7_SOO_TSHU: (- {-close-brace} -). Include (- [ I7_SOO_TAR oldval count; if (oldval DROP NOSE the response is (misleadingly) "You haven't got that." It would be better to have an additional check rule in the appropriate verbs (drop, insert, put, give, throw at) which offered a more sensible reply. We agree. (WM.8) -- For rules such as Instead of Narcissus kissing: ... to fire whether or not the player is Narcissus, so that rules made for multiple-PC games will act consistently. We feel that this doesn't necessarily make things easier, but merely shifts the burden of programming a multiple-PC scenario to a new place: now the author would have to write rules such as Instead of Narcissus kissing: if the player is Narcissus: [stuff]; otherwise: [other stuff] Instead of Echo kissing: if the player is Echo: [stuff]; otherwise: [other stuff] as opposed to Instead of Narcissus kissing: [stuff] Instead of Echo kissing: [stuff] Instead of kissing: if the player is Narcissus: [stuff]; if the player is Echo: [other stuff]; We are inclined to leave the existing structure alone, for the sake of stability. (WM.9) -- Optimize static relations. It may be possible to optimize searches and loops using relations that are declared to remain static from compile time onward. This we believe would be useful; we've seen cases where it would substantially improve performance. (WM.10) -- Add more implicit actions to the standard world model, such as getting up from a supporter before attempting to move, opening a door before passing through, and so on. While these are all easily customized in Inform, some of these customizations are so common that they perhaps deserve to become the default. We are wary of making adjustments that would cause disruption for previous projects, but we are tentatively open to this. We would need more discussion about exactly which implicit actions should be added. PROGRAMMING (Pr.1) -- The ability to declare a column of a table to have a default (non-null) value unless the author overrides this; as in Table of Drugs drug cost a drug a price (usually $1.99) We accept this proposal. (Pr.2) -- A better way to refer to a single item with a given specification, in a situation where it's known that it must be the only one. At present "a random..." is sometimes used for this, so for instance: try inserting the item into a random pocket that is part of the garment; Here the author knows that the garment has exactly one pocket, and is really trying to say "the pocket which is a part of this particular garment" - no actual randomness is really involved, and the source text is therefore misleading to read. Various alternatives are proposed. At the moment, the one we like best is to use articles more naturally here, so that try inserting the item into the pocket that is part of the clothing. ...would assert that there is only one such pocket, and throw a run-time problem message if that proves to be false. This would be quite difficult for us to implement; we're interested in investigating it in the long term but make no promises. (Pr.3a) -- That there should be named constants. This is problematic because it becomes difficult to distinguish a named constant from a literal value. (Pr.3b) -- That there should be a way to apply numbers to global variables with "usually" (as in "the time of day is usually 5 PM"). This has in fact already been implemented for a future version of Inform. (Pr.4) -- That there should be some way for an extension author to declare the existence of objects while allowing the author to control how many instances of the object should exist. For instance: A string is a kind of thing. String-count many strings are in the string repository. Or perhaps String-count instances of string are in the string repository. Or The string-count is a number constant. The string-count is usually 10. In practice, though, there is nothing to stop an author from adding more instances of an object (simply by writing an additional line such as "10 strings are in the string-repository); or, indeed, from replacing the relevant section of the extension, if need be. So we are unconvinced that there is a strong need for this feature, and it would complicate the syntax of the language. (Note that the ability to declare that a variable "usually" has a given value was added in build 5Z71.) (Pr.5) -- Representation of all strings of text within the game as objects, with the ability then to place them in kinds, discover whether a given string had yet been printed, etc. This is simply not possible. (Pr.6) -- Better and more syntax to refer to kinds, and variables that range over kinds. Some proposed syntax: The current monster class is a kind that varies. now the current monster class is the kind of the attacker; now the current monster class is a random kind of monster; if the current monster class is a kind of monster: ... if the current monster class is a direct kind of monster: ... repeat with current monster class running through kinds of monster: ... now the second monster class is the parent kind of the current monster class; This would allow us to determine whether two objects have the same kind, to traverse at least the object branch of the kinds tree, and so on. We may consider some variation on this, not necessarily in the syntax above. It would be considerable effort to set up, but may be worthwhile. (Pr.7) -- Manipulation of objects based on the heading in which they occurred, as in All rooms in Section - first floor (living area) are in the Ark Quarters. or If the player is in a room in Section - first floor (living area) then... This might be possible to do, but in initial discussions there is no consensus that this would be a good idea. Barring more persuasive argument, we are inclined to leave the current behavior alone. (Pr.8) -- "namespaces", or some other way to help prevent ambiguities. We listed this in the previous consultation document: the idea was to perhaps create some concept of namespace, which would in particular help prevent names in one extension from interfering with names in another. Since then, there have been some changes to the way that Inform resolves its ambiguities, and it may be that this is no longer felt to be as necessary; we have heard fewer complaints about namespace clashes recently. So we're curious. Is this still a pressing concern? We would prefer to avoid complicating the language more than necessary, but at the same time want it to be as practically useful as possible. (Pr.8a) -- a heading could contain when or while clauses that would affect when all the enclosed rules and phrases should apply, as in Section 1 - Sam at the Piano (when Sam is on the Piano Bench) This would be a nightmare to implement. What if the author puts assertions into this section? How would restrictive headings nest? We feel this would introduce far more problems than it would resolve. (Pr.9) -- Ability to write Instead of doing something involving the baseball: ... as shorthand to catch both the case where the baseball is the noun and the one where it is the second noun; and perhaps also Instead of doing something indirectly to the baseball: ... to catch only the one where it is the second noun. We agree. (Pr.10) -- A new kind of value, an array, that allows multi-dimensional indexing (not a table, because the array would have to allow the same type to be used in all columns). We consider this a perfectly reasonable request, but would like to flesh out the syntax a bit. (Pr.11) -- Some sort of special form to shorten the wordy "To decide which number is..." construct: for instance "To compute..." We oppose this on the grounds that it's a special syntax which does not increase the range of possibilities and which would lead to confusion, especially since "compute" is ambiguous about what the data being computed is. (Pr.12) -- The inclusion of "or", as in the Inform 6 code if (a == 2 or 4 or 6) ... if (leader ~= bill or martin or fred) ... Which might be syntactically rendered in I7 as, say: if a is either 2 or 4 or 6... if the leader is neither Bill nor Martin nor Fred... This should work with all verbs, so that we could have, e.g. if the player is carrying either a knife or a sword... A variant with positive "and" conjunctions would also be welcome: if the player is carrying both the flint and the steel and the firewood... And if it worked on the left hand side too, then all the better: if either the dragon or the troll is on the bridge... We would have to watch out for over-complicated, ambiguous sentences though: if the player is carrying either a knife or a sword which is made of either steel or bronze or a spear or a halberd... And allowing these constructs on both sides would be difficult: if both the large door and the small door are either open or broken... We agree that this would be nice, but the implementation problems make us want to hide under the bed. (The word "or" is already used for selection between actions, and the ambiguities pile up.) We'll keep this under review. (Pr.13) -- Since we now can both continue and amend tables, it seems natural to also be able to replace them completely. The columns would still have to be the same, but the previous contents would be discarded. For instance, to replace the final question options, one must currently write Section 1 - My custom final question options (in place of Section SR2/12 - Final question options in Standard Rules by Graham Nelson) Table of Final Question Options [etc] Here, it would clearly be less work to write: Table of Final Question Options (replaced) [etc] We accept this proposal. (Pr.14) -- The ability to make collective statements about regions, as in The flooring object of a room in the outdoors is usually the ground. We will investigate whether this is possible. (Pr.15) -- For snippets of zero length to be allowed. The snippet value which would be stored at run-time as the number 100 -- begins at word 1, contains 0 words -- can be useful in splicing snippets together, but currently this is disallowed out of hand at the I7 level. We accept this proposal. (Pr.16) -- Syntax such as decrement the bar of foo; where "bar" is a named value. Along the same lines, to have decrement N; mean "decrement N by 1" by default. We accept. (Pr.17) -- To be able to empty a list simply by saying now L is empty; rather than having to truncate a list to 0 entries. This we intend to do. (Pr.18) -- To allow definitions such as Definition: the orange is citrus. including no condition at all. This seems reasonable. TEMPLATE (Te.1) -- For "deadflag" to be handled with the throw/catch opcodes that both the Z-machine and glulx have. Death needs to be handled at too many levels of the call stack for this to be a good idea, we think. NAMES (Na.1) -- A Use option that would force the author always to type the full name of every object, rather than having the compiler guess what object was intended by allowing subset names (e.g., accepting "car" to refer to "car keys"). We are not hostile to this suggestion, but are not sure how much desire there is for it. If at least three different people would like to see it, we will go ahead and implement it. (Na.2) -- To have the compiler allow abbreviations where they're unambiguous but choose the shortest match otherwise. For instance, if we have: The car key is a thing. And somewhere else: The car is a thing. Then could the compiler be made to assume that, since there's an identifier called 'car', 'car' by itself always refers to the car and never to the car key (although 'car' could otherwise be taken as a reference to the 'car key' if 'car' had not been defined as a separate identifier). This is a good idea but very difficult to implement; we will see whether it turns out to be possible. There are also possible hazards. At present, ambiguous names are resolved partly by seeing what names are closer in the source text; this is useful in resolving ambiguities between extensions and the main source. We are concerned that implementing this feature might introduce errors which the current implementation resolves correctly. (Na.3) -- that the final word in an object's name is by default read as the primary noun. A match is considered stronger if it contains the primary noun. This would take care of a lot of the common cases, like "red car" (primary noun "car") versus "car key" (primary noun "key"). The problem with this is that the final word isn't always the primary noun, as in "key to the office". We thinks this is a case where the good that might be done in the majority of cases would be outweighed by the great confusion that would be caused in the minority. PARSING (Pa.1) -- A way to remove something from scope explicitly. The basic design of the Inform parser is such that adding and removing from scope are not at all symmetrical. Placing something in scope does not add it to some slate of items to be considered later, but causes it to be tried for parsing then and there; so once something is placed in scope, it is too late to remove it. (This design was meant to save time and memory in the Z-machine.) So this is not an easy change and we see no strong case to make it. However, the case which we think people need it for - to handle situations where an object needs to be in some sense present (i.e., able to be found by the player) but not in scope - can be handled by other methods quite well. So we think the best approach would be to add more documentation hints on this, hyperlinked from the section on adding things to scope. (Pa.2) -- A way to order understand lines explicitly, as in: Understand "[a beat]" as discussing (this is the understand discussing rule). The understand discussing rule is listed first in the understand rules. We will not adopt this exact syntax (there is no "understand rules" rulebook, so the syntax would be misleading), but we are interested in offering the author some way to manually override Inform's assumptions about the order of understand lines. We would be interested in suggested syntax. (Pa.3) -- A way to restart the command sequence That is, a way to abandon the current action(s) and begin command processing all over again with a new input. The activity "after reading a player's command" is already capable of modifying the command text, but that happens before the command is converted into an action, and well before action processing starts. So at present, something like this is impossible: Instead of taking a candle, reparse the player's command as "get lamp". For instance, in an extension to deal with new player input, you might have determined that a player has used a recognized noun and a recognized verb, but in the wrong order; you could make adjustments and try reparsing the command to see if that makes sense. This is always likely to be tricky, and the user of such a feature would need to keep in mind that earlier rules might already have changed the model world, or printed text; so the current action would not be magically undone, but only abandoned part-way. However, we agree to explore this suggestion; it might further be possible to give the player multiple commands to perform, using a full stop between commands (but not a slash as found in test commands). (Pa.4) -- Ability to set an action to be "out of world" at some point during action processing, rather than strictly as a function of the type of action in question. For example, "ask ghost about wilbur" before we've met Wilbur prints a parser error and no passage of time, but the same command behaves as normal later in the game. We are unwilling to do this because "out of world"-ness affects more than just the passage of time - see the account of action processing vs. specific action processing in the annotated Standard Rules - and this would confuse things conceptually. It would make more sense for authors interested in this effect to modify the rules governing the time sequence, so that it checked a flag and did not advance time if an action had been prevented by a logical refusal to act rather than by a failed attempt. (Pa.5) -- The option to remove OOPS mistake-handling from the parser's behavior, with a line such as Use no oops command. (And/or one might want to be able to assign a different word this function, for ease of foreign language translation.) We agree to this idea. (Pa.5a) As a variation: couldn't oops be handled as a regular out-of-world action? It would construct the corrected command and then trigger a reparse. The "again" command is similar. If these were regular actions, then the suggestions here would be unnecessary. Again and oops are intrinsic to the parser in ways that are simply not equivalent with actions (and anyway there are good implementation reasons why they are the way they are). This is an elegant suggestion but it would mean reimplementing the parser for no very great gain. (Pa.6) -- The option to turn off or tweak the behavior of noun-guessing (where the parser makes an assumption about what the player means because the player has omitted to name an object). The behavior is often singularly inappropriate when there are only a few objects in scope, leading to exchanges such as >DRINK (the statue of Ponce de Leon) There's nothing here to drink. "Does the player mean" rules helps provide guidance in the situation where the parser is choosing between multiple items of which some are more valid; but there is currently no way to say "if there's nothing of type X available, don't even bother to guess." We think possibly the thing here is to call the Does the player mean rules even when there is only a single object available, and then also to allow the author to say that some objects can never be selected automatically (see Pa.10). Much of this behavior is already provided by Jon Ingold's extension "Disambiguation Control"; nonetheless we feel that it might be useful to consider incorporating some of these features into Inform proper. (Pa.6a) -- to give the player some controls over whether nouns are guessed or not, through some sort of mode while playing, just as players can choose between verbose and brief. On the whole, we think the author is in a better position to decide when the game should make guesses and when it shouldn't. (Pa.7) -- More control over library verbs. For instance (a) allow the author to revise the definitions of actions already defined, such as to make "looking" an action out of world; or (b) remove an action entirely from your game, without having to track down all its synonyms. This would enable the author to escape from assumptions made in some extension - most obviously the Standard Rules. We are concerned that strong versions of (a) would lead to serious ambiguities. For instance, suppose the Standard Rules say Opening is an action applying to one thing. (as they do), and the author redefines this as applying to two things. What is then the status of sentences like Understand "open [thing]" as opening. or of conditions like "if opening the marble door"? Confusion at least, and I6 errors at worst, will result if we forgive constructions valid in the old specification but not the new. While there are properties of actions which it is less problematic to alter (the accessibility, for instance), so that weaker versions of (a) might be possible, we are unconvinced. We think a better approach might be to allow (b), so this is written up next. (Pa.8) -- A way to make Inform forget about an *action* (and all its grammar) rather than about a *command*. Currently if we want to forget an action with lots of synonyms, we have to do things like Understand the command "hit" as something new. Understand the command "kill" as something new. Understand the command "attack" as something new. ...which is annoying, requires going through the indices to find all the words accepted for an action, and always leaves the author with the apprehension that maybe he hasn't caught all of them. And it's even worse if we want to redefine, say, *only* "get off...", but not "get": since we have to first forget "get" as a command, then *rewrite* the line that tells Inform to understand get as taking. This we agree to. (Pa.9) -- A way to make certain literal commands stand in for actions. To quote the suggester: Often a situation arises where I want to understand a form of player input that doesn't match an existing grammar line, but I don't want to have to define a whole new verb just to recognize that one command. You can kludge around this like so: Understand "turn stereo down" as a mistake ("[trystereoadjusting]"). To say trystereoadjusting: try setting the stereo to 2. ...but what's really needed is a companion to "Understand as a mistake," that allows for understanding commands which actually do produce actions in the game world. Understand "turn stereo down" as a command (setting the stereo to 2). [Silently substituting missing information needed.] Understand "bare hands" as a command (attacking the dragon) when dragon is visible. [Assuming the noun.] Understand "set [an appliance] to [a number]" as a command (switching on the the noun) when location is Kitchen. [Discarding the number in the process as unnecessary.] Understand "shout [some text] at [someone]" as a command (shouting). [Where shouting has been defined as applying to nothing.] We agree with this suggestion, although we will probably alter the proposed syntax since properly speaking it is understood as an action, not as a command. (It's already a command.) (Pa.10) -- Ability to refer to the list of things which is currently being disambiguated. This might involve canceling disambiguation entirely because items should be considered equivalent; removing specific items from the disambiguation list, while continuing to consider others; and the ability to add or subtract from the "likeliness score" of an item, rather than having one Does the player mean rule control its likeliness completely. Rule for disambiguating when every object under consideration is destroyed: say "It no longer matters which is which.". Rule for disambiguating when an object under consideration (called candidate) is inactive: remove candidate from disambiguation list. In a modified way, we might take this on. We propose to add a "completely impossible" option to the does the player mean rules, which would effectively allow the author to bar certain things from appearing at all in the disambiguation list; we might also offer the opportunity to view the list-to-be-disambiguated and modify it at some point before the "does the player mean" rulebook takes effect. This wouldn't provide all the things the suggester asked for as Inform features, but would offer enough of a hook (we think) that interested authors could cook up variants of the "likeliness score" approach themselves, if desired. We might also add an "unobvious" option. Unlocking the key to the Star Chamber with the Pommel of the Magic Sword may actually work, but constitute a puzzle you don't want the parser to solve for the player with: Unlock star chamber door (with the pommel of the magic sword) The door flies open! So we might want to have a "completely impossible" result that removes an object both from parser guesses and disambiguation lists and an "unobvious" result that removes an object from parser guesses only. We think that it might be useful (again) to have a look at Jon Ingold's "Disambiguation Questions" extension, and see whether some or all of its features should be adapted for the main language. (Pa.11) -- Ability to run a command as a test, to see whether it has interesting results, without actually making anything happen in the model world or printing any output to the player. For instance: if we are pushing and the player's command would produce standard output, try touching noun instead. ["would produce standard output" == results in a library message being printed.] To decide whether the player's command results in death: process the player's command; if deadflag is 1, let decision be yes; otherwise let decision be no; roll back last action; decide decision. Something like this ability is already provided in an extension (Hypothetical Questions by Jesse McGrew). We feel that it may be too esoteric to warrant inclusion in the main language. (Pa.12) -- A way to handle "all" and "all [xxx]" differently, so that "deciding whether all includes" would work differently depending on whether the player had typed TAKE ALL or TAKE ALL BOOKS. We are not opposed in principle, but would need more specific suggestions about what authors want to be able to do, and in what syntax. The implementation may also be tricky, depending on what exactly authors want to do. We will see. (Pa.13) -- A way to make verb infinitives longer than a single word, thus tacitly allowing adverbs to be soaked up into them ("to run down", say, rather than "to run"). We could allow this, and it seems in principle fair enough, but it would a little bit of a nuisance to implement. (This is left over from the original consultation document, but something we would still like to accomplish.) (Pa.14) -- The ability to define a null token in a list of alternatives in Understand grammar, to match the existing ability to make a word optional in a phrase definition. For example, Understand "google for/-- [text] in/on [library computer]" as consulting it about (with nouns reversed). which could match "GOOGLE FOO ON COMPUTER" or "GOOGLE FOR FOO ON COMPUTER". While there are other ways to achieve this effect, by defining new grammar tokens, allowing "--" would be quicker and more legible. We agree. (Pa.15) -- More flexibility in how the parser copes with object names given the instruction to "Understand the foo property as describing a bar", where foo contains an enumerated kind of value. At present this only allows the property to be given at the beginning of the object name, like an English adjective. This is fine for colours and temperatures, but fails in some other cases, for example a "can of cola" or "glass of lemonade" where cola and lemonade are elements of a "flavour" kind of value. One approach is to make flavor a kind of thing instead, and use a relation to parse the name: "can of [something related by flavoring]". However, this way we lose the other effect of the understand-property-as-describing syntax, which is distinguishing identical objects. Cans filled with different flavors will be collapsed into a single inventory listing, and the parser will arbitrarily choose one rather than disambiguating, even though they can be distinguished by typing. The proposer suggested four possible improvements in this area: (1) Allow the understood property value to appear anywhere in the object name, not just at the beginning. (2) Add an activity, or some other mechanism, for customizing the way objects are distinguished. Running an activity for every call to Identical() could be a performance problem, but it might be enough simply to add a way to tell Inform that members of kind K are distinguished by properties P and Q, even when those properties can't or shouldn't be parsed as part of the object name. (3) Allow the "[something related by X]" syntax to work with relations between objects and values, not just between objects. (4) Allow the understand-property-as-describing syntax to work with object properties, not just values. (3) and (4) seem entirely reasonable. With (2), the performance problems are indeed horrible in general, but the issue here seems to be to distinguish objects related to different things, and it may just be that Inform needs to compile cleverer "parse_name" routines. (1) is something we are very reluctant to do, again for run-time speed reasons, but also because it would make object name parsing much more ambiguous and complicated. To sum up, we accept the general point that something needs to be done here, and will experiment. (Pa.16) The ability to use objects and kinds with qualifications, E.G: A vase is a kind of thing. A vase can be broken. Understand "shards" as a broken vase. This is already possible, since one can rephrase it as: Understand "shards" as a vase when the item described is broken. ...but it would be better if Inform could do this automatically. We will see whether this is reasonable to implement. (Pa.17) The ability to understand something as a varying thing or value, E.G: The appointed time is a time which varies. Understand "appointment" as the appointed time. This seems doable, because the time token just returns the parsed time. It could return a computed value just as well as a constant one. It's more complicated with objects, but it could be done. The following: The suspect is a person which varies. Understand "suspect" as the suspect. ...could be internally rephrased as: Understand "suspect" as a person when the item described is the suspect. Again, we need to consider whether this can be implemented. (Pa.18) -- Support for [room] as a grammar token matching rooms that are in scope. At the moment we have to use [any room] - potentially qualified with an adjective, be it built-in or supplied by a definition - [any adjacent room] or [any oniony room] for example. Seeing as we can add rooms to scope explicitly, [room] is currently an omission. We agree. (Pa.19) -- Add "[any things]" token, to refer to multiple objects anywhere in the game; it should be possible to raise scope limits on this. We agree, though it will be up to the authors to cope with the results if the player then tries to use ALL with such a command. (Pa.20) -- To provide an easy way whereby one can easily turn off the response to obscenities entirely. (A use option like "Use bashful innocence", perhaps.) We will look into it. OUTPUT FILTERING (OF.1) -- The ability to adjust the final output before it's printed to the screen. For instance - An output processing rule: replace the regular expression "\n\n\n" in output with "\n\n". An output processing rule: repeat with wd running through words in output: if there is a name entry of wd in Table of Conversation Topics, replace wd in output with "[bold type][wd][roman type]". ...etc. This is essentially impossible with the Z-machine; under Glulx it is conceivable but probably difficult. As with many advanced Glulx options, we suspect that the best course is for interested Glulx programmers to mock up an extension. (OF.2) -- Ability to redefine a new line. In the words of the suggester: "I can't re-define this new_line to sometimes forego the line break. I would appreciate it if instead Inform appended a macro or function call or something that I could override, especially for certain rulebooks. If efficiency is a concern, then perhaps a Use option that enabled this alternate behaviour?" The template is designed to allow access for this kind of hacking; it should be possible to make such an adjustment at that level. (OF.3) -- Different handling of apostrophes. For some languages like French, Italian, maybe Spanish as well, it may be useful to be able to disable the replacement of apostrophe by " and replace quote by something else ([quote] or ["], etc). We will investigate how plausible this is. GLK/GLULX (Gl.1) Authors have repeatedly asked for more control over the styles used in the game. At a minimum, some way for arbitrary colour changes to be allowed - this is the one area where Glk/Glulx is behind the Z-Machine. Glk and Glulx are independent standards, and not part of the Inform project; they're available to anyone who needs an IF virtual machine. We would certainly support this change to their specification, speaking ourselves as users for once. We believe that Andrew Plotkin, who leads these projects, may be sympathetic. DEBUGGING (D.1) -- A TABLE testing command that would list the contents of a given table in full. We accept this suggestion. (D.2) -- The ability to get a complete list of unique words used in the game after compilation. This is not easy, and we are not convinced that it belongs in I7. (For instance, given that some words printed are not printed whole but are composited from smaller strings, there would be no way to guarantee that those words were include properly.) To get a roughly similar effect, it should be possible to add something to the template setting the compilation switch for I6 that dumps the game text. (D.3) -- Exportable walkthroughs/test me. In the words of the suggester: "I don't use much the skein or transcript concept, but I find the "test me" command very useful. I'd like to be able to keep it after the release of the game, or convert the command into a "walkthrough" option, which could either display the whole solution, only a part of it, or replay the game automatically (useful for testing a game with different interpreters). At the moment I must export all the "test me" commands, clean up the code, and use it with the replay command." We will consider whether this is possible. (D.4) -- To be able to compile a z-machine game within the IDE but devoid of the testing commands, to allow full-sized z-code games to take full advantage of the skein (etc). This would be in addition to the Use memory economy command, intended for games very close to the z-code limits. We are sympathetic to this and will investigate. (D.5) -- The ability to use a strict setting so that the compiler will catch unnamed rules (as for extensions which ought to name all of their rules for the convenience of subsequent authors). We accept this suggestion, though we think it should be something that can be set per extension (like "authorial modesty"). (D.6) -- For the annotation * to be added back to Inform (this is a feature of the Inform 6 6/11 library) so that people can note comments in transcripts without the game interpreting their remarks as commands. We're considering whether its presence or absence annoys the greater number of people. (D.7) -- For RULES ALL to list even the rules that are implemented in Inform 6. This is a bit of a performance challenge, and could produce very, very verbose output, but we will look into it. DOCUMENTATION CHANGES We would especially welcome general comments and feedback on the documentation, and not only on the issues mentioned below. (Doc.1) -- There has, historically, been a fair amount of concern about the way actions are documented. In particular, some users have not been convinced by the guidance on when to use before/instead/after rules in preference to check/carry out/report rules. The designer's intention was that the check/carry out/report rules would be the way to lay out a general-purpose action in its normal operation, while before/instead/after rules would be the way to provide quirky behaviour in particular situations. On this basis, an IF source text would be likely to contain many before/instead/after rules - they would be the easiest way to design interesting rooms, items and people, and new Inform authors should learn about them first. Some users have not followed this advice, and some have outright disagreed with it. One reason may be that before build 5T18 very large rulebooks ran slowly, so that people felt that stacking up large quantities of "instead" rules (for instance) would result in a story file which played slowly. This problem has been fixed, and profiling suggests that there's now no issue. But perhaps it's just that the documentation doesn't explain the ideas well, or convincingly. We hope also that the actions documentation has been improved by the addition of sections to the Recipe Book which offer more detail on how to design new actions or modify old ones. We are curious whether this adequately addresses concerns about action documentation, or whether there is still more that we should do (and, if so, what). At the same time, we are conscious that Inform itself remains a work in progress and that the documentation is necessarily also a work in progress; and that many of Inform's users are in the odd position of having read many drafts (or parts of many drafts) before. (Doc.2) -- Indexing of the documentation. This continues to be something that should wait until the project is relatively stable and the documentation itself in a fairly finished form. (We may revise Writing with Inform fairly substantially yet, which makes indexing it now a less appealing prospect.) As a related note, though: we are already adding a greater number of links from the indices into the documentation; build 5Z71 also incorporates many direct links to documentation from problem messages. (Doc.3) -- More emphasis in the documentation on the usefulness of the indices, since many authors have found them to be more useful than Writing With Inform suggests they would be. (Doc.4) -- For there to be a cleaner way to view the Standard Rules from within the user interface. This is something we plan to work on. MULTIMEDIA CHANGES (MM.1) -- Extensive sound library for I7 allowing the use of more complex features such as multiple channels and crossfades. This is currently in progress as an extension, "Damusix", by a Spanish team. We continue to think that it is best for this kind of feature to exist through extensions rather than as part of the core library, but we are very pleased to see the work that has been done and wish the best to Eliuk Blau and others working on the project. (MM.2) -- For someone other than Emily to be responsible for maintaining the Glulx utility extensions Glulx Entry Points and Glulx Text Effects. Volunteers would be very welcome. (MM.3) -- Support for MOD sound files. The Spanish community makes extensive use of these in multimedia; on the other hand, there are some implementation challenges to do with providing appropriate cross-platform interpretation. EXTENSIONS (EX.1) -- A means to include extensions on a project-by-project basis, e.g. in a subfolder of the project directory; alternatively to override the standard extensions directory of a project. We have for a long time resisted this because the extension search path is already complicated, because it raises awkward questions about whether these extensions would appear in the in-app documentation, and because it's a feature which almost invites abuse. Experienced programmers new to Inform often start out by trying to bend it into a more familiar C-like shape, when it would be better to start without preconceptions. They may seize on locally installed extensions as a way to dice up a source text into modules file by file, a standard computing practice, but not an Inform one. Those remain good arguments, but they lose out to a growing need: to be able to archive the source text of an Inform project for modification years later. Public extensions gradually change, or are withdrawn in favour of replacements, and "Fancy Vehicles by Joseph Smith" may mean something quite different in 2015. So, with a slight sigh, we now accept this suggestion. (EX.2) -- A heading in an extension could be declared as "for internal use only". Things defined under such a heading would only be visible inside the extension in question. We are curious whether this would be useful enough to be worth the effort. MAPPING (Map.1) -- A way to flag some rooms as not mappable - so that, for instance, the game would produce a map of all the street rooms but none of the interior locations. This should be possible; we will look into it. (Map.2) -- A way to force a location to appear on a given level, as in "Index map with Cheapside on Level 1". We will investigate this, too. PUBLISHING Historically, the website publishing option has been hobbled by the unattractiveness of the Standard template, and by the limitations of the release process. The rewritten cBlorb tool inside build 5Z71 goes quite some way to improving matters. But two suggestions remain on the table for future consideration: (Pub.1) -- For one or more templates to be offered which hook into the resources of online web interpreters such as Parchment, so that the author could export a webpage that would allow online play of his game, with minimal setup on the author's part. This last feature is somewhat dependent on the development of suitable interpreters (and ideally one for Glulx as well), but we strongly feel that it is important to support browser-based play of IF. (Pub. 2) -- For some inclusion of licensing information in the I7 bibliographic data, which would be printed in the banner and also automatically be added to IFDB. Currently the banner-printing of such information is pretty easy to arrange and is further supported by the Extended Banner extension by Stephen Granade. Any arrangements concerning metadata would have to be taken up with the Treaty of Babel contributors and IFDB maintenance. This may be worth discussing. (The design document ends here.)