In the interest of getting down my notes on my screwing around with Cold Genesis/ColdC, I thought I'd put up a quick page on the various methods I've used for the player .parse().
Regarding the login .parse(), I just use a switch() statement for that since the number of methods that are used there are always small. Even using a full list of commands like MOO does on it's login screen, I still feel that a switch() handles it just fine.
For the logged in .parse(), I've tried various ways of doing it and so far, I still have not come up with one I really like.
Method 1: switch()
At stated above, with a small number of commands and a simple user set up, I think using switch is
just fine. However, when your switch statement starts to reach 200 lines or whatever, it gets a bit
unwieldy. I have't done a performance comparison with switch vs. any other method but it is cumbersome
for me to go through a lot of case statements when looking for something specific. The handling of
different player classes also starts to make this messy; either all commands are in one giant switch()
with checking for different classes or you put a switch out there for each class duplicating some of
the commands in each or some other version equally as messy.
Method 2: command dictionaries
Actually, in all other methods I've toyed with, I've always used a command dictionary to reference
a command from the user into an actual method. I like this because it allows for the use of a command
that doesn't quite match the method definition. @shutdown, as an example; you cannot make a method with
the "@" symbol in the name. So my command dictionary might look similar to this:
#[["who",'cmd_who],["inv",'cmd_inventory],["@shutdown",'cmd_shutdown]]
The "@" symbol on commands, of course, can be used to differentiate game commands from normal play commands as in other tiny-like MUDs. This also shows the ability to use abbreviations for commands but pattern matching might also work just as well here.
So using a dictionary, there have been a few different ways I've played with...
Dictionary Method 1: dictionary defined on multiple objects
This involves your code having a player object in your core database for each class/level of player that you're
going to have: $player, $builder, $wizard or whatever. Each object has their own command dictionary
defined on it. You traverse the parent tree looking for a dictionary on each object and then see
if the user's command matches any of the keys in it. When you find one, you return the value, a symbol that
should already match a defined method and then you call that method with the arguments. Using this method as a
command parser allows you to have an object to define a certain class of player if necessary, allows for expansion
by just adding another class into the parent tree and allows for the isolation of commands to only that player class,
I.e. you have to be a descendant of $wizard in order to use the $wizard methods, yes?
Dictionary Method 2: dictionaries all on one object
Recently, I was playing around with just having one player object, $player, and using flags to define the player
classes. I did still have separate command dictionaries for each class and just hit each of the dictionaries in the
parser. This assumes that you already know what your classes are and have them defined in your parser. There might be
a better way of doing it this way but I like the method of using an object for each class better instead.
Dictionary Method 3: modified Method 1
While writing this, I just thought about using objects for each player class, having the command dicitonary on each
object and then, instead of traversing the parent tree, we define the class objects in a list somewhere and then just
traverse that list for objects to check for command dictionaries. More on this later.
I had thought that I had another method to add here but at the moment, I can't recall it. I'll have to look through my junk core DBs and see if there is still something there somewhere.
Enjoy!