I don't remember any of the infocom games that weren't text only. I always hated text based interfaces.

If you're looking for modern take on the classic sierra and lucas arts age adventure games I recommend taking a look at the the Telltale games.

Hmm... I don't think that I've encountered one with that degree of complexity, no.

I think that the closest that I recall was the interface used by Gabriel Knight 3: clicking on an object brought up a small menu of icons representing the available actions for that object, and specific to that object. While some were common--such as "examine"--there were also actions that appeared only a few times. For example, when clicking on a tray of food, one might be given icons for "examine", "eat" and "smell"; a book might have "examine", "take", "read" and "dust for fingerprints" (it was an investigative mystery). The actions available could also be context-sensitive, such as a dumb-waiter door offering "open" when closed and "close" when open. (I think that there were cases in which more options were available, but alas seem to be blanking on an actual example.)

While lacking the explorative element of text-parsers--you don't get to guess what verbs are available--it at least lacks the blindness of such parsers--you don't have to guess which verbs are available--and does at least allow for a variety of context-sensitive actions.

[edit] I've been ninja'd on the "verb-menu" idea, it seems; one thing perhaps worth noting is that I've been involved in an argument over whether radial menus were a good idea for such a menu; I think that in the end I conceded that radial menus probably wouldn't work well outside of first-person cases, in which the object sits at and the menu appears in the centre of the screen.

I think part of the problem, as they say, is that a picture is worth a thousand words. In the old text-only adventure games the descriptions could be very rich but it was also very clear what the nouns were. In an image-based adventure game, literally every distinct thing on the screen is a potential noun, and that obscures which nouns are actually viable or interesting, which kind of gave rise to the sweep technique where you revert to sweeping the entire screen with the cursor when you're stuck on a puzzle. I don't know if its reasonable to implement a natural-language-like interface in an image-based adventure game, but there's certainly room for innovation.

If you want an example games with somewhat different takes on the genre interface, check out the more recent installations of Broken Sword from The Adventure Company, or Shadowgate 64 for a (admittedly, probably poor) example of a fully-3D, first-person adventure game.

Other than the Myst series, Sanitarium is the best graphical adventure game I ever played. The Longest Journey is very good too. But if you're looking for a linguistic interface in modern adventure games you're not going to find one - there was pretty widespread agreement that they were sucky and immersion-breaking. The closest you will find is a dialogue system like that in The Longest Journey or that in the Persona series (not adventure games).

Some thoughts... (and a description of the Infocom interface for younger readers)

I've been thinking about this for a couple of days and I think the key thing that you would have to do to make a graphical game like this would be get rid of all the guessing. In a graphical game what can be done needs to be explicit.

When you strip away the hype of natural language processing, the Infocom interface was basically the following:

1. Nouns were marked by the game. (You enter a room once and get the elaborate description, you then start getting the abbreviated description which was a list of the nouns in the room, some of which you could take and some of which were fixed to the room, but all could serve as objects in commands while in the room)
2. There was a list of common verbs that you knew you could use: get, move, pull, push, insert, give, tie, untie, open, close, cut, destroy, burn and a few more. This list was augmented by a few unknown verbs that were game dependent.
3. The verbs in 2. could take direct objects as well as indirect objects where applicable. Indirect objects could be entered either as proper indirect objects or via a prepositional phrase e.g. "Give the Chistmas tree monster the coconut" or "Give the coconut to the Christmas tree monster" respectively.
4. Prepositional phrases worked for modifying some objects if, I think, the object exposed a property for a slot associated with the preposition -- I'm guessing this is how it worked internally anyway; for example in The Hitchhiker's Guide to Galaxy pretty much the whole solution to the Babel Fish puzzle involved prepositional phrases and the object model they induced "Hang dressing gown on hook (so the "hook" has an "on" slot). Cover grating with towel (the grating also has an "on" slot which <cover> <with> knows to map to). Place satchel near door. Place junk mail on satchel.
5. There were places in which you could issue commands in the same form to other agents e.g. "Robot, give the coconut to the Christmas tree monster"

On 1. and 2, I would definitely consider any guessing of words required to be a negative thing. It was mitigated by the fact that after you played a few of these games you pretty much knew which verbs you could expect and relying on the need for a magical verb to solve a puzzle was considered bad form (although it happened. the life raft in Zork I was like this: you had to guess that a pile of plastic was "inflate"-able)

so 1. you could do in graphics in some way. 2. you could also do by way of limiting the list to very few and having some kind of uniform mechanism for engaging one of them -- something that isn't a menu though, I find the menus I've seen ugly, but also more that just an "action" button. Don't know exactly how I will do it but this seems solvable.

It's 3. and 4. where there really seems to be room for innovation. I think that there would need to be a visual language for the slots bound to objects that I am assuming exist invisibly to the user in infocom games. In infocom games you had to guess what you could do to and with an object. In the interface I am envisioning I think you would need to make what you can do to an object explicite via some mechanism.

(and 5. couldn't be done without text ... although in a 3rd person game essentially your avatar is just a special object you are interacting with that follows the commands you are entering in some way so in theory you could have more than one)

might be missing something here, but SCUMM had commands with multiple object "slots" as well -- give always had two slots,

I'm talking slots bound to objects not slots in commands.

Generally I think that it is a mistake to try to re-ify a text command with a GUI. This is what SCUMM did and it is not what I am after. It is what sunandshadow says is "immersion-breaking and sucky" above. And anyway If you wanted to do this the best idea would be a speech-to-text interface which given the small vocabularies of these games could be perfect without training with today's technology. Failing that you could just have some kind of menu system that is basically an onscreen keyboard optimized for this kind of game. But this isn't what I want.

I want a pure GUI that is as rich as the infocom text UI. Ultimately what I think is interesting about infocom games was the object model rather than the pseudo-NLP. The object model allowed semi-emergent behavior: you want to put the letter opener on top of the clock? okay, it is on top of the clock -- because the clock knows it can have stuff on it. You want to put the elephant on the clock? No, the clock says it can't have something that big on it.

This object model, or soemthing like it, would need to be translated into some kind of visual language...