Replies: 4 comments 1 reply
-
I think Lua would be a good choice. It's light weight and pretty easy to pick up in my opinion. It already has some traction within the mud community as well, with Mudlet being a popular client that supports Lua scripting. |
Beta Was this translation helpful? Give feedback.
-
The first pass is complete. For now I'm sticking with the javascript option, not because it's particularly superior language wise (although I do think a lot of people are familiar with javascript), but because the features and methodology I can use to expose methods and invoke scripts is currently preferrable to the lua ones I tried. I have a number of scripts written currently in the rooms folder, ending in Hopefully I will eventually find a better way to organize these scripts, although if not too plentiful they don't crowd the rooms folders TOO much.... |
Beta Was this translation helpful? Give feedback.
-
Scripting support is in place for mobs, along with a series of basic documentation in the /scripting folder readme I may still make changes to the room scripting to do what I'm doing on the mob scripting, essentially having a "details" object with properties depending on what invoked it. Room scripts only trigger on users currently, but I'll probably have them trigger on mobs too.... maybe.... |
Beta Was this translation helpful? Give feedback.
-
Script support is in for Items, Rooms, Mobs, Buffs, Spells. This may be expanded in the future, but closing this for now. |
Beta Was this translation helpful? Give feedback.
-
Some sort of embedded scripting language should be implemented, and since javascript had some questionable performance compiling on a small ARM processor, I'm gonna toy with LUA as an option.
Currently I'm thinking of an event driven model, where I define a series of events to be associated with rooms, items, whatever, and if a script has a trigger function defined it will invoke it.
So for example a room may have:
commands can equally have special triggers:
These can probably be defined on any scriptable objects, and call on a hierarchy with either a function or return type to abort processing the next trigger handler.
I think this would address a most cases which will be event/trigger based scripting, but there is probably room to expand it to more general usage, such as defining entirely new commands in a script.
What is and isn't scriptable will really need to be figured out and defined.
Some interfaces will need to be defined to give access to certain data and functions.
Beta Was this translation helpful? Give feedback.
All reactions