Yes, there is definitely interest in such an interface. For example, there’s Robin Johnson’s “Detectiveland”, which was very well received – it won the IF Comp 2016, in fact.
There’s also the development system “Quest”, which usually allows both point-and-click and typed input. For an example, see Bitter Karella’s “Poppet” from last year’s comp.
So, the interest exists, and I think there’s still room for experimentation and friendly competition concerning user interfaces and development systems.
[Edited to add: I had typed my post as a direct reply to fdisk’s first post, and only afterwards read tayruh’s most recent post. I did not intend to contradict tayruh concerning the possible interest in a new system, although it might read that way now. I think the general interest exists, as I wrote, but it can unfortunately sometimes be hard to raise interest for a specific new project. Maybe the best way to gain traction is by entering a showcase game in a huge competition.
So tayruh’s advice is very sound, that the most important reason should be your own enjoyment. Best of luck to you both! – end of edit]
For me, part of the appeal of free-form parser-based input is the feeling that I could potentially type anything, from the mundane
OPEN DRAWER to the abstract
REMEMBER VACATION or the unusual
DANCE THE TANGO or
PRAY, or even that one can (in principle) give the full range of parser commands to NPCs, as in:
CONSTABLE, ARREST THE SUSPECT or
FIDO, FETCH THE STICK.
Or consider the very satisfying feeling of coming across a reference book in a game and thinking of consulting it about some obscure name that came up way earlier:
CONSULT BURKE'S PEERAGE ABOUT VISCOUNT BLAKELEY (and then actually finding an entry).
Of course, it’s only an illusion of freedom, but in good games, it works fairly well and has a special kind of magic.
So, that would be a point in favour of adding typed input to your user interface.
As I said, there’s still room for experimentation in the UI area, because it would be great if there was a way to get the “best of both worlds”, so to speak: On the one hand, provide a wide range of possible inputs, and create and sustain that feeling of freedom that comes with parser-based input, and on the other hand get the strong points of point-and-click interfaces, which avoid the notorious “guess the verb” problems and are more accessible to players who are not used to the parser interface.
With regard to the implementation, it would be a lot of work, but it might also be a great opportunity to learn more about data structures and algorithms.
You would not necessarily need to solve the problem of general natural language processing (which, after all, is the domain of a whole field of studies, Computational Linguistics).
You could start relatively small and maybe only accept two-word commands like
TAKE COIN, where you always assume the first word to be a verb and the second word to be a noun.
You’d have a sort of world model in your code, so that you can check which objects are TAKEable by the player at the moment. The coin should be in the same room as the player, but it should not be in a locked chest. In an object-oriented programming language, you might implement this with an attribute or method “contains”, for example.
The parsing step would consist of making the connection between the player’s typed input and its meaning in the world model. Maybe you’d have a dictionary-like data structure (also known as “associative array” - anything with a key-based value lookup), where the keys are the verbs the player might type in, and the corresponding values have a reference to the action that’s supposed to happen in the world model.
So you’d look up the first word of the input. If it isn’t found (e.g.,
TRIANGULATE), you tell the player that this verb is not necessary in the game. If it is found (e.g.,
GET, which would map to the same action), you now know the intended action and proceed to check which world model object is meant by the second word of the input, and whether that object fulfils the conditions for the action (check whether both the player and the coin are contained by the same room, and so on). If all checks pass, transfer the coin to the player’s inventory.
(Of course, this is only an extremely rough sketch, and I don’t wish to understate the complexity. It’s a huge undertaking to write a good IF system, but it might be an instructive project and a lot of fun for you.)