I am dropping some thought around, well if you don't mind of course :)
I think the easiest to read/type would be the one i'm used to ;)
command target args
now there are 2 ways to analyse this. go for the command see if the player can run that command, then go for the target. Or go for the target first, and see whether the command can be applied to it.
In the target-then-command it has the advantage that you could trigger quest/activity scripts with it. like : rub lamp, bow statue, pull lever, ... smile lady, ...
if there is no target, then the room would be choosen as a target. look = look room. smile = smile room, that is smile to everyone.
Unfortunatly that becomes harder when no target is required but args are.
say Hello all. you don't want to write : say room hello all.
2 Layers
--------
I think the command system needs two layers. Command (means command names required target, possible args and so on) and Actions (the command code in itself).
Why ?
-----
2 command names could lead to the same code. look/examine, get/take/pick, to name a few.
Link scripts to the Actions (so I type look or examine, and it triggers the script anyway).
in world files :
<item>
<name>statue</name>
...
<on action="bow">script</on>
</item>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as two commands pointing to the same code, that is already possible.
The interpreter manager takes a string and an actor.
The string is broken into two segments, a command and an argument (the argument may be parsed later by more in-depth commands as necessary).
A command is matched by the command word and the availabilty as determined by the command itself in reference to the actor. If a command is found which matches under the various criteria, it is called, passing the actor and the argument string.
It has been considered that the commands, when being calles, should be made aware of how they were called (eg: the exact string of the command word), but it's still under speculation.
Also of great importance to note is that in the near future the InterpreterManager may be replaced with another class of a specific interface. This would allow you to plug in a parsing method more to your liking if necessary. If you're interested in developing an alternative InterpreterManager, that would be absolutely excellent.
Ideally there is only one class which will be un-replaceable, and that is the core jamud.Jamud class. All the managers, data instances, etc all the way down will eventually be replace-able.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am dropping some thought around, well if you don't mind of course :)
I think the easiest to read/type would be the one i'm used to ;)
command target args
now there are 2 ways to analyse this. go for the command see if the player can run that command, then go for the target. Or go for the target first, and see whether the command can be applied to it.
In the target-then-command it has the advantage that you could trigger quest/activity scripts with it. like : rub lamp, bow statue, pull lever, ... smile lady, ...
if there is no target, then the room would be choosen as a target. look = look room. smile = smile room, that is smile to everyone.
Unfortunatly that becomes harder when no target is required but args are.
say Hello all. you don't want to write : say room hello all.
2 Layers
--------
I think the command system needs two layers. Command (means command names required target, possible args and so on) and Actions (the command code in itself).
Why ?
-----
2 command names could lead to the same code. look/examine, get/take/pick, to name a few.
Link scripts to the Actions (so I type look or examine, and it triggers the script anyway).
in world files :
<item>
<name>statue</name>
...
<on action="bow">script</on>
</item>
As far as two commands pointing to the same code, that is already possible.
The interpreter manager takes a string and an actor.
The string is broken into two segments, a command and an argument (the argument may be parsed later by more in-depth commands as necessary).
A command is matched by the command word and the availabilty as determined by the command itself in reference to the actor. If a command is found which matches under the various criteria, it is called, passing the actor and the argument string.
It has been considered that the commands, when being calles, should be made aware of how they were called (eg: the exact string of the command word), but it's still under speculation.
Also of great importance to note is that in the near future the InterpreterManager may be replaced with another class of a specific interface. This would allow you to plug in a parsing method more to your liking if necessary. If you're interested in developing an alternative InterpreterManager, that would be absolutely excellent.
Ideally there is only one class which will be un-replaceable, and that is the core jamud.Jamud class. All the managers, data instances, etc all the way down will eventually be replace-able.