> You could use Z-machine or TADS (and provide the file for downloading). I know some things would have to be changed a bit. Certainly the game would be harder than AGL if it is text-adventure game, which is not a problem. One thing I don't like about AGL is that everything that you can do is written on the screen, and also that you have to use the mouse to click on which one you want, and a few other things also. Real text-adventure game is better than AGL, in my opinion.

The term you're looking for is "parser games" or "command-line games." AGL games *are* "real text adventure games." They are adventure games, and they are based on text. Hence, text adventure games.

If the command-line variety is more to your taste, that's fine. There's no arguing what you enjoy more. But I would enthusiastically argue against any statement that the form itself is inherently superior. I have a whole laundry list of complaints about the command-line form, starting foremost with how frustrating it can be just to get a command-line parser to understand what you want to do. In AGL, there is a distinct separation between the story/world and the interface to it. Puzzles are NEVER about how to work the interface -- they're always about what you should be doing in the world itself. (Your post about how command-line games can provide hints like how the commands start with specific letters is interesting to me, but only as a curiosity. The puzzles of a "pure" adventure game should reside firmly in the world itself, not in the interface to it. Then again, you could still do this kind of thing in AGL if you really wanted to.)

You disagree with the previous paragraph, and that's fine. Like I said, what you enjoy more is inarguable, and I'm only stating my own reasons for why I enjoy AGL more. Instead of pressing that point, I want to get around to why porting the AGL games to command-line interfaces would mostly be a waste of time.

The thing is, command-line games and menu-driven games differ by more than the interface. The interface has a role in DEFINING the types of puzzles you will encounter in the game.

In the AGL games, the individual steps may all be apparent, but the *coordination* of those steps is NOT. An awful lot of the puzzles in the AGL games are about coordinating different movements. So, ok, you have a "throw a rock at the upstairs window" option. Maybe you try it. But it doesn't do anything unless you do it at the exact moment that a guard on patrol walks by a certain point, at which point he's distracted by the noise. And then you must IMMEDIATELY pick the "go around to the other side of the building" option, or you'll miss your opportunity to take advantage of the guard's distraction and slip into the back door unseen.

This is common in AGL games and if anything is a lot simpler than many. If you think AGL games are easy just because they present all the options to you, you obviously haven't played through very many AGL games, and definitely not the harder ones. (I second Matsi, elsewhere in this thread -- there is no way I believe you've played much of Escape From St. Mary's. It's HARD and requires a whole lot of thought.) The point is, these puzzles were designed with the fact IN MIND that each individual action WOULD be visible to the player. Hide those behind a command-line, and the entire nature of the puzzle changes.

Similarly, command-line game puzzles are often irrevocably dependent on the fact that the player will NOT know what individual steps are available, and the puzzle becomes to figure out what the player may do in that area.

In other words, what puzzles work in one format may not necessarily work in the other. Some puzzles are untranslatable, period. Most can, admittedly, but the best AGL puzzles would not make very good puzzles in a command-line format, because they simply weren't designed for it.

So I echo a lot of Counterpoint's thoughts in my answer to you:

Can the AGL games be ported? Yes -- but with many gameplay compromises.

Can the AGL games be ported easily? No -- you'd have to rewrite the game from scratch in a different programming language.

Is it worth anybody's time to port them? No -- there are MILLIONS of command-line games already out there, or at least enough that you'd never be able to play them all in your lifetime. So why waste time making a command-line game out of something that wouldn't make a good one in the first place?