This extension emulates the emphasized keyword system for streamlining common IF input, as seen in "Blue Lacuna." Nouns, directions, and topics are highlighted and can be typed without verbs to examine, move, or discuss, respectively. (Topics are implemented only in skeletal form to allow for integration with any conversation system; Keywords for Conversation by Matt Wigdahl, for instance, will integrate it with Eric Eve's Conversation Package extensions.) A full system for letting the player select his own preferred color scheme and keeping games backwards-compatible for players on screen readers or with no color support is also included. The extension is compatible with either z-code or Glulx.

A warning: Inform authors using color have poor options on either platform. In z-code games, colors can be freely adjusted, but are limited to a palette of eight neon shades, only a few of which will be readable on any given backdrop. Glulx users can select from a palette of sixteen million colors, but can only make two of these available at a time, and these cannot be changed during play. On z-code, all eight colors are made available to the user and can be adjusted by player or author at any time; on Glulx, the two defaults are blue and green, and only authors can customize this. On both platforms, bold, italics, and fixed-width are offered as alternatives to colored keywords.

Section 1: Basic Usage

Keyword Interface allows an emphasis style to be set for one of four possible categories. Each of these can be enabled or disabled independently by the author or player. By default, they are set as follows:

Object keyword highlighting is initially true.
Direction keyword highlighting is initially true.
Topic keyword highlighting is initially false.
Parser highlighting is initially false.

These can be enabled or disabled at any time during play through a "now" statement, or globally by making a more definitive assertion:

Object keyword highlighting is false.

If keywords are a crucial component of your game, you can add the following:

Keywords required is true.

This will bring up a message before your game begins ensuring that players can see the keyword highlighting, and giving them an option to adjust styles. Alternatively, you can advertize the KEYWORD verb to players, which brings up the same menu, or show some stock explanatory text, customized to which keywords are enabled, by using the following phrase, perhaps in the carry out rule for an "about" command:

carry out the showing the keyword introduction text activity

Section 2: Objects

When object keyword highlighting is set to true, the extension will automatically emphasize non-scenery objects listed by the parser. Objects in descriptive text may be manually emphasized by wrapping them in and substitutions.

The Office is a room. "Only a bare [o]bulb[x] illuminates this dim office, empty except for a solitary desk.". A desk and a bare bulb are scenery in the office. On the desk is a telephone book and the lamp.

This produces output like the following (where emphasis is marked with asterisks):

The Office
Only a bare *bulb* illuminates this dim office, empty except for a solitary desk.

On the desk are a telephone *book* and a *lamp*.

If you want scenery items to be automatically emphasized, you can manually set them as keyworded, or include a line like the following (which would add emphasis to "desk" in the final line above):

When play begins: now every scenery thing is keyworded.

The emphasized word will be the final word of the object's printed name. To change this, you can use the object's "keyword" text property, which should be one of the other words in the printed name. You can also define an object as "keywordless," in which case it will never be automatically emphasized.

A book of memories with keyword "book" is in the Office. Some scattered cigarettes are a keywordless thing in the Office.

Produces:

"You can also see a *book* of memories and some scattered cigarettes here."

Automatic emphasis normally occurs when looking, opening or taking inventory. If you want to disable one of these you can use code like the following:

The Keyword Interface highlight objects when looking rule is not listed in any rulebook.

Conversely, if you want object highlighting during other times, you can use code like this:

Rule for printing the name of a thing (called item) while asking which do you mean:
     carry out the object keywording activity with item.

Section 3: Directions

When direction keyword highlighting is set to true and cardinal directions are wrapped in brackets in room descriptions, these will be emphasized as they are printed.

"Gloomy passages depart to the [south] and [east]."

Compassless navigation as seen in Blue Lacuna can be implemented by adding a directional keyword as a synonym for the intended direction, limiting this to the specific room in which that keyword is valid, and wrapping the relevant word in "d" and "x" tags in the descriptive text.

"Gloomy passages depart down a dusty set of [d]stairs[x] and through a wide [d]passage[x]." Understand "stairs" as south when location is Gloomy Tunnel. Understand "passage" as east when location is Gloomy Tunnel.

An "exits" verb is included with Keyword Interface to assist blind users or those without color interpreters (who in the above example would have no way of knowing which words correspond to movement). EXITS lists all of the cardinal exits from the current location. If your game uses compassless navigation, you may want to extend this verb to print your keywords instead (see the "Gnome's Holiday" example below for one way to do this).

Section 4: Topics

Since there are so many different conversation systems, support for highlighting conversation topics is only vestigial. It's turned on when "topic keyword highlighting" is set to true and you can invoke it with the "[t]topic[x]" wrapper, but everything else will have to be done by hand to match your own conversation system. Again, see "Gnome's Holiday" for a simple example of a keyword-based conversation system.

Section 5: Parser Messages

The extension can also style parser messages differently from normal game text. This may be useful to authors who wish to differentiate error messages ("I didn't understand the first part of that.") from in-game admonishments ("You wouldn't be caught dead wearing that.")

Parser error highlighting is disabled by default; you can turn it on with

Parser highlighting is true.

If your game defines new parser error messages or rewrites existing ones, you should wrap them in the "as the parser" and "as normal" say statements:

Understand "floop" as a mistake ("[as the parser]To cast a spell, you must cast it on something, like FLOOP THE MATTRESS.[as normal]").

Section 6: Control

To change the default color values at the start of play, authors can use syntax like:

The style of object-word is keyword-cyan.

The four modes are object-word, direction-word, topic-word, and parser-word. For Glulx games, possible styles are keyword-color1-style and keyword-color2-style; for z-code games, they are keyword-red, keyword-green, keyword-yellow, keyword-blue, keyword-magenta, keyword-cyan, keyword-white, and keyword-black. Both VMs provide the additional styles keyword-bold-style, keyword-italics-style, keyword-fixedwidth-style, and keyword-no-style.

To change the Glulx colors, you can adjust g-color1 and g-color2 by amending the Table of Common Color Values-- see the documentation for "Glulx Text Effects" by Emily Short for more information.

Table of Common Color Values (amended)

glulx color value	assigned number
g-color1	15645627

All messages the extension prints are customizable responses. Use the RESPONSES testing command to view them, then adjust with a line like the following:

The setup keyword emphasis rule response (B) is "This is what [o]objects[x] look like."

Section 7: Screen Reader Mode

By typing "screen reader" or selecting the appropriate option from the keyword customization menu, players can set the internal variable "screen reader mode" to true. Blind players and those without color interpreters can activate this mode. This might be useful to provide an alternative if your game contains other visual components such as a map, or uses color in puzzles.

The extension provides two verbs to assist color-challenged players: a "things" command which prints a list of nearby objects, and an "exits" command which summarizes the nearby directions. If you're using compassless navigation, you may want to customize the exits command to make use of your custom direction names. Additionally, if your game features conversation, strongly consider building a "topics" command to round out the set.

Section 8: Disambiguation

Inform's normal disambiguation assumes that every command begins with a verb, which means conflicts between keywords, and between keywords and verbs, are hard or impossible to control. The best solution is to make sure your object, direction, and topic keywords have no overlap.

*If an object and direction keyword* are in the same scope, the parser silently assumes the player means the direction keyword, and will print a seemingly useless "(the object)" clarification if the player manually examines that object instead.

*If a highlighted keyword matches a verb*, the verb will take precedence. For example, typing "set" to reference a chess set would instead produce the message "What do you want to set?" The best way to avoid this is to change the keyword and description of the object to avoid mentioning the verb word-- in this case "chessboard" might be a good substitute. You could also disable the verb if it's not one your story uses (see "Overriding existing commands" in the docs).

*Conversation systems should take precedence over objects* since this is what players will expect. See the example below for one implementation of this.

A	Example Sense of Direction A simple usage of the extension to print bold compass directions.

B	Example The Gnome's Holiday A full example of emphasized objects, compassless directions, and conversation topics.