A Modest Proposal
I just picked that title out of humor. I don’t endorse cannibalism.
Anyway, I declare 7/15/2005 to be the Day of Sigma. Here’s my proposal for a script architecture:
Well, the first thing with a script architecture is knowing what scripts are allowed. Here’s what I have so far:
- A use/brandish capability for special items
- Events for items, rooms, and denizens (character enters room, item dropped on floor… the works)
- Tasks (as in, things that are run like daemons on intervals)
- Handlers (as in, things that are run to respond to commands)
Handlers come last. The question is: can use/brandish be an event. Yes. Yes it can.
So, we’re basically dealing with
- Events
- Tasks
- Handlers
Of course, events are really methods (meaning, they take a self or this pointer as their first argument). That chicken has already been fried. We’re passing long int’s as pointers and the API functions will accept them, dereference them on the C side, then do whatever is necessary.
Tasks are just sentinel functions. Probably the easiest, probably the least useful on the short term. I could see using tasks to implement a weather module. I actually considered consolidating all tasks to Lua and writing the denizen locomotion function in Lua, but I discarded that notion based upon complexity and inefficiency.
Handlers really don’t matter for now. The architecture is there (I already have an abstract base Handler class that CxxHandler inherits). LuaHandler just needs to be written and set up. I’m not going to care about this one.
So… It looks like Lua is best at reading a file as input, then throwing all that code into a “function” on the stack. I put function in quotes because this data doesn’t have any metadata like what variables are taken as parameters and what is returned. This is all kind of loose, VB-style not Option Explicit stuff.
So you load up the code onto the stack, then follow it with what variables you need to give it. Because I’ve taken a month to think about all this, I have this all nice and tidy. I’m actually going to push the function chunk to a table called user, which will contain the code and a function “name” defined within xml as follows:<event type=“use” binding=“heal” />
Then, in your extension or script or whatever-I-end-up-calling-it section of server.map:<script file=“heal.lua” />
Sigma can intuit that heal.lua contains the code for the heal binding. When the function is called, a copy of the chunk is pushed from the user table to the top of the main stack, then the proper parameters are pushed. Then the function is called.
Ba da bing.