Ok so I finally got the whole project compiled and running and managed to telnet on my localhost and was able to create a new character.  Upon doing so I found the game is a lot futher along than I thought.  That is good!  However many of the commands are not complete or only work halfway.  My biggest one is take all.  It should take everything you can grab in the room.  However it looks for an all object and not finding it says you can't find it.  I would be glad to fix this but I'm not sure where to start in the code.  If someone could point me in the right direction I would appreciate it.

Justin

However, what 'all' means is context-sensitive.  For instance 'get all from bag' means 'all' should be replaced with all items which are contained in the container object identified with the keyword 'bag' whereas 'get all' would be referring to all items in the same room as the player.  There are other ways an 'all' keyword might come up, such as 'read all unread' or whatnot with in-game message boards or email systems.

Parameters are also always passed to the command as strings in order to keep the command system clean/generic.  We can certainly utilize common/shared code for something meaning, say, 'give me a List[Item] of player-accessible things that this list of args is referring to'.  (I believe this is already done with a single-Item version?)  The Get command's local Item reference could be replaced with List[Item], and reuse the List[Item] even when a single Item is identified, so that only one set of code (the foreach iteration) has to be written.  IMO it makes most sense for argument pattern recognition to generally be implemented in the command, with liberal usage of reuseable helper methods for common interpretations of common keywords/patterns.

Perhaps some more powerful means of interpreting sentences typed from users could be employed;  some kind of crazy tokenization scheme would be one such idea.  On top of everything else, a generic system would have to take into consideration all kinds of permissions things rather than letting behaviors be determined completely dynamically;  IE if we supported "examine joe's helmet" to get the description of a helmet item upon joe's paperdoll, then typing "get joe's helmet" would have to be blocked due to the command's specific context, whereas "get helmet from chest" (where chest is an open container in the current room) is OK.  As is, by requiring the command to define the behavior of an explicit pattern, such behavior is generally "opt in" rather than "opt out", meaning a MUD admin is less likely to find out that "clever" players are (as per this example) stealing from others in such a way.

Posted By Karak on 23 Dec 2009 11:23 PM

Parameters are also always passed to the command as strings in order to keep the command system clean/generic.  We can certainly utilize common/shared code for something meaning, say, 'give me a List[Item] of player-accessible things that this list of args is referring to'.  (I believe this is already done with a single-Item version?)  The Get command's local Item reference could be replaced with List[Item], and reuse the List[Item] even when a single Item is identified, so that only one set of code (the foreach iteration) has to be written.  IMO it makes most sense for argument pattern recognition to generally be implemented in the command, with liberal usage of reuseable helper methods for common interpretations of common keywords/patterns.

After some more thought on this I had this thought as well.  If you move the check to where the Get action is executed you end up with parsing every command to check what kind of parameter(s) are being passed to it, etc.  It keeps the object model and code cleaner to deal with it in the action class itself.  A simple List would solve the problem.  However I think other code would have to be changed to deal with the possibility of getting more than 1 item.