[vworld-tech] Verb/action handling
Brian Hook
hook_l at pyrogon.com
Sun Jan 25 11:02:50 PST 2004
> What is your world model?
Can you be more specific?
> While you say rooms, are things going to
> happen that cross room boundaries?
Yes.
> What sort of scalability requirements do you have?
Ideally I want to be scalable to a very large degree, I'd hate to
implement something with a hard cap on users, rooms, mobs, etc.
> What is the scope of a single room?
As in?
> How much ability do you need to modify the world for scripters/GM
> staff?
A lot.
> Do you allow user programming at all?
No.
> Do you trust everyone that has access to writing code?
Yes (but bugs are bugs, so we're still going to have to solve the
out-of-control-script problem with Lua).
> Will someone doing extension work be actually writing code, filling
> out a set of rules, or what?
There are two parts to the editing process (at least, as I envision it
right now, but this is all fluid). The first is data definition, done
using standard DB tools.
So you make a new room, assign it basic properties like name,
description, exits, etc. It has no intrinsic special behaviour, but
then again, very few rooms do.
But, say you want to make a room with special case behaviour, I dunno,
like it heals everyone standing in it every 10 seconds. To do this,
I'm thinking that the database author sets the "OnTick" field to
"HealingRoom:OnTick".
At room load time, its OnTick function is redirected to
HealingRoom:OnTick (i.e. it's a function pointer).
Which means that someone, at some time, needs to write
HealingRoom:OnTick. The larger ramification is that it's a hybrid
data-driven/procedurally-driven system, and that's a kind of
uncomfortable place to be.
A purely procedural system is going to have a lot of overhead and
suffer from all the myriad problems that inheritance/sub-classing have
but a data driven system is going to have a lot of bloat and spaghetti
code.
Blah
Brian
More information about the vworld-tech
mailing list