If your goal is to enhance your Perl programming skills, I recommend you set modest goals, particularly for your command parser. What are you finding difficult about recognizing when a command is entered? It seems like you should have a main loop that looks like this:

while (<STDIN>) {
  # Command is in $_
  chomp;
  handle_command($_);
}
[download]

In addition to TADS, I recommend you check out the Inform language and the introduction to Inform on that website, which also tells you a lot about how the Infocom adventures were implemented and how the grammar works.

In most cases, the feature set available through Inform will be total overkill for you, as you want to simply split up an (english) sentence into words and act upon the words. If you want to simplify and assume that all sentences are in the imperative form, then the first word will always be the action and the rest of the sentence (if any) will be objects belonging to that action. A different, also simplicistic approach would be stupid pattern matching where you specify (regular expression) patterns that get applied to the sentence entered to describe what you want:

my %action = (
  qr/^give (.*)(?:\s+(to) (.+)))$/ => \&give_to,
  qr/^go (.*)$/ => \&go_to,
  qr/^take (\w+)$/ => \&take_item,
);

while (<>) {
  my $matched;
  for my $pattern (keys %action) {
    if (/$pattern/) {
      $action{$pattern}->();
      $matched++;
      last;
    };
  };
  print "I didn't understand what you meant by '$_'.\n";
};
[download]

Of course, that will only get you so far, as the concepts of reference to the last sentence/object (look at banana. eat it.) and error correction (go nwrth. oops north.) won't be caught by this scheme, but for a simple start giving you quick results, this is a viable way.

As for combining it with an object, you should first define the commands and the grammar you would accept, then perhaps parse the commands with something akin to Parse::RecDescent - or something simpler if your grammar is simple enough.

Personaly, for an adventure of any sophistication, I don't think hashes are going to be sophisticated enough - to simulate actions on objects you should use, well, objects...

My suggestion would be to take input, chomp it, then split it on spaces, taking the first as the potential action, then any remaining values as the object, if necessary. Then, you just need to have some structure that has the results of that action, or return a message that says that action could not be performed on the object. Just tossing some code together might look something like this (untested):

while (($alive) and ($playing)) {
    $input = <STDIN>;
    chomp($input);
    my @part = split(/\s+/, $input, 2);
    if (defined($actions{$part[0]})) {
        &handle_action(\@part, \$playing, \$alive);
    } else {
        print "Huh?\n";
    }
}
[download]

The handle_action routine would then have more logic regarding how to handle individual actions.

Hope that helps, at least give you an idea to start from.

As for mapping what you parse from the commandline into your data structures, I found it very useful to write callbacks and associate them with commands. So, the "examine" command would have a function associated with it that would be called whenever the "examine" command was entered. This is sometimes known as a dispatch table. Although I worked primarily with the command, there is no reason why you cannot extend that idea to a function that will, given the name of something, return back a list of objects that map to that something. You could even have that function constrain based on various criteria, such as what the player can see, what the player has in inventory, etc.

I have a node here regarding the testing of this game. The "Adventure" link links to the a PDF written by Donald Knuth dissecting the original Adventure game. It's a C translation of the original game in Fortran, but it has a number of good ideas.