Something dawned on me while reading through the documentation in Inform 7, and the comments from random people when a person asked how they could add a multiple-choice system to the game. Some comments were helpful, and some were more about trashing Inform 7. Like the old language COBOL, Inform 7 tries to use natural language for the code, as opposed to what, in speech, would be pretty hard to say.
 
In both COBOL and Inform 7, the code looks a bit like a disjointed list of plain-language statements, which for those of us who have trouble interpreting more "codey" programming languages must look like a revelation. I've had enough experience, though, that I'm prepared to learn what a function does even if it's just a bunch of punctuation, because I know that with a little practice I'll remember what things mean and be able to translate things into precise speech that the software will understand. I'm not as excited by seeing such things, and sometimes I wind up being a bit confused because I'm not quite sure if the use of the word in this language is the same I might mean in English.  I guess a bit more practice would narrow the gap, as with any language.
 
What dawned on me, though, was how similar the complaints some were making against Inform 7 (by way of COBOL) were with the problem of parser commands themselves.  Inform, and text adventure software in general, is largely about creating a platform that will interpret sensible input from the user, written in grammatical sentences, and turn those into commands that affect the game world. There is a lot of extra text that goes into a grammatical sentence, and putting things in expected order, using synonyms, similar constructions, all of that, may produce an error. A lot of effort may be put in by the user and the effort may still be rewarded with a sarcastic screen message saying you did it wrong.  Just like natural language programming, a lot more energy is put into a blob of text that may or may not do what you want to.
 
This has a whimsical quality, in that it's almost like you're communicating directly with a computerized offspring of the creator's mind, but without an insane amount of coding on the part of the creator, you will often reach a point where you will reach the limits of the engine, and it will look a lot less interesting.
 
I found that what I want is something a lot more precise, something with few options, limiting interpretation errors, but many ways and places those options could be applied. That can be done in Inform 7, and in text adventures in general, but it's a bit strange actually trying to get people to talk about these things within the communities that continue to support the hobby (and it makes me feel like I stumbled into the wrong support group, "no, I actually don't have a problem with alcohol at all. Sorry, I'll just show myself out. Thanks for the donuts."). It's almost like text adventures are expected to parrot earlier models, and I get an echo of Zork in a lot of the projects that even come out today. Some of them, I think, approach literature, but those are necessarily limited and straightforward, telling a story that the user has a small part in, and their part changes how the story is perceived. 
 
What I think limits text adventure is not the graphics themselves, but the very specific way a text adventure is expected to behave, with rooms, objects, cardinal directions, turn-based interaction, and grammatical language interpretation. 
 
I've talked about Storytron before, and in many ways I'm rather fond of it, but I get the sinking feeling that its quirks may turn me back toward Inform or maybe TADS to muddle through trying to make the interface simpler and more standardized. Storytron actually does what I want in a lot of ways: you are given a paragraph based on the situation you're in, and you pick words in the command sentence that bring you to a precise result. You could have something say "You've defeated the minotaur! Now what do you want to do?" and it would give you a list of possibilities that the programmer would preset based on the relationship of user to all the objects, places, and especially people, in the area. If something prevented you from looting an object, it wouldn't be part of the list, but other stuff would be listed. You just pick what you want to do from the command list and move on to the next command, creating a string with no false components.
 
My big issues, though, with Storytron are pretty simple: you have to be online to compile, and sometimes the player seems locked into a series of commands. I really, really am not fond of compiling online, since what programming I would do will probably be offline, away from distractions. There were times in the sample game in Storytron where I wondered why it picked the particular result it did, since I wanted a different result than it suggested.
 
Storytron also, like text adventure engines, makes peculiar assumptions about the environment a programmer wants to design. In text adventures you have segmented rooms, even if a room can be an endless prairie, while Storytron has things called stages, and they are separated by the time it takes to move between them. I'm warming to Storytron's assumption, but if I wanted to, say, recreate the map from one of the Might and Magic games, but instead of having the player move in squares, you could just sorta move in any direction to any point in the map, and run into landscapes and obstacles based on that. Neither seems to fit that very well, at least on the surface.
 
And that's for a fixed map, but what if I wanted to seed a new map from scratch every time the player started a new game? I feel like both systems assume solidity there that I don't ultimately intend.
 
For the graphically oriented what I'm suggesting probably sounds like a nightmare in such formats, but I'm not really worried if everyone isn't into this sort of game. In a way, I'm not fond of being so limited either, but I know that I could probably write a game presented in this way that it would take a team of helpers or years of study for me to do otherwise (and still, by the time I was done, graphics would have probably taken a step up and I would be back to being behind the curve again). All I want is a logical system that helps me make the environment I want, rather than to topple the mighty gaming gods.
 
There are a few other, more graphically oriented, engines I've run across. One that is geared toward adventure games of the point-and-click variety that also seems pretty easy to use, but I'm not sure my interest lies there, since perfecting the graphics seems like a distraction for me rather than the core of what I'm trying to accomplish. I once imagined using that system to try to make something, but I'm not so in love with rough conceptual design that seeing a big white placeholder rectangle marked "1" standing in for the character sounded all that neat to me.
 
Probably the closest I ever got to a full text adventure was when I was in my teens, using BASIC and LOGO, the slow children of programming languages that may not even be talked about anymore. They were more like choose-your-own-adventure books than I'd probably be comfortable with in a computer game today, since I'd like the computer to be a bit more busy behind the scenes than just printing out pre-programmed results.
 
I've just downloaded TADS, and a multiple-choice module for Inform 7. I'll also take another look at that point and click engine, but a lot of this stuff seems hell bent on recreating experiences that people have already had with slight variations. You have to make assumptions, though, when writing these sorts of construction engines for users who aren't already good at coding, so it may be a while before I find something that fits my level of ability. In the meantime, I'll be practicing.
 
Anyone here ever  try to make a game? How did it turn out?
 
Edit: Found a strangely prescient and fun criticism of the problems with adventure games back in the antediluvian year of 1989, written by Maniac Mansion designer Ron Gilbert, summoner of Deathspank. If anyone calls me a loot whore, I'll remind them of Rule 5.