The inversion modifier presents some special difficulties with the inverse parser. Consider how it works:
As presented, this all makes perfect sense. However, let’s consider how the player would enter this command if he were Wile E. Coyote. The player is finished conversing with Floki and wishes to depart. First, he’d have to select the verb “go to see”. But that is not his intention: he doesn’t want to go anywhere, he wants to depart. He’ll get the opportunity to add the inversion modifier immediately after selecting the “go to” logogram, but he doesn’t know that when he’s making his decision. This situation begs for confusion. It is unacceptable. I see four solutions:
1. Bundle the logograms. The menu of available logograms shows both the “go to” logogram and the “go to” logogram with the inversion modifier attached to it. This solution is the clearest but it’s also visually clumsy and will likely consume too much screen space. The logograms are already big enough as is: at 4096 pixels in area, just ten of them would take up 40K pixels out of a total of one megapixel of total available screen space. Double-word logograms such as this would vastly increase the required screen real estate.
2. Replace inversion with already-inverted logograms. Create a special “depart from” verb for this situation. This sounds easy enough, but it raises new problems. Is it possible to use the inversion modifier on some words, but not on others? This would create a user interface clash; the user would never know what’s invertible. It would be necessary to create inverted forms for every word in the dictionary. Some of these would be very difficult; for example, if this next word means “failure”, what do we use to say “success”? A ship not sinking?
3. Use an internal modifier. Here are some possible versions of “success”:
Each of these solutions has a problem. Turning the word upside down won’t work with vertically symmetric words. Color inversion is not immediately obvious in its meaning, and a color-inverted image is harder to read. The red x implies negation, not inversion.
4. Make inversion a special-case additive. If the player holds down the shift-key, for example, while clicking on a word, that means the inversion of that word. We could also use left-click for standard, right-click for inversion. Or a special component of the word menu that indicates that the words are meant to be used in their inverted form. But these are user interface disasters waiting to happen: they represent invisible commands, a serious no-no.
I have some serious thinking to do.
May 5th:
I have decided that the inversion logogram cannot meet the requirements of an inverse parser. It requires the user to say the opposite of his intention before reversing that meaning, and such a sequence is counterintuitive. Each word must be expressed in a single logogram. I might be willing to make an exception for some attributes such as smart_stupid or fat_skinny, but I doubt that I’ll need such attributes.
The problem of showing inversion in a single logogram remains. I have examined the current dictionary and it appears that I won’t have too many problems with this, but there are a few knotty cases, such as the verb ‘obey’ and its inverse, ‘defy’:
Once again, none of the possibilities for ‘defy’ strike me as ideal. Vertical inversion is, I suppose, acceptable, but I’m fearful that one day I’ll run into a logogram that is vertically symmetric and therefore unsuitable for the use of vertical inversion to denote semantic inversion. The color inversion, again, is not apparent in its meaning. The middle finger is rather ugly; the thumbs down logogram is semantically broader in meaning than ‘defy’.
Nevertheless, I shall proceed, for the moment, with vertical inversion. I consider the question open to further consideration.