[vworld-tech] Verb/action handling

Bruce Mitchener bruce at cubik.org
Sun Jan 25 23:19:57 PST 2004


Brian Hook wrote:
>>What is your world model?  
> 
> Can you be more specific?

Just being 'room-based' doesn't mean a whole lot.  Are rooms regular in 
size/shape? Are they in Euclidian space?  Are there higher level 
organizational systems (these rooms are the inn, these buildings are 
this street, these streets make up a district, or other organizational 
structures) or does a room exist independently in and of itself?

Depending on this, the way in which you handle events may or may not be 
appropriate to do at a room level or may require the use of mixin 
classes, something datadriven, or something else altogether. (For 
example, if you have something in a bar room, but that 'room' is 
actually 2 rooms underneath everything, how will you go about having 
each have the same responses and share data? Or will you end up making 
each space within the world a single space? Or will you use a higher 
level organizational structure for attaching the code to that level of 
things?)

>>While you say rooms, are things going to
>>happen that cross room boundaries?  
> 
> Yes.

So you'll need some way to determine the context, type, strength, etc of 
an event/action and how to go about propagating it through the 
surrounding environment.  You'll also need to determine how much CPU 
power you'll willing to let this take up, how much extra memory for 
rooms that have to be in memory rather than potentially swapped out to 
disk, whether or not you want it to take closed/open doors/windows/etc 
into account, and whether or not you want to use a technique like beam 
tracing for determining the propagation paths for an action.

>>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.

Well, everyone wants that.  But designing and planning for 10k players 
in a single world is somewhat different from designing and planning for 
200 players.  The hard cap is going to be based on how computationally 
expensive things are, how much interactivity there is in the world, how 
far you propagate events, to what degree you're engaging in strict 
simulation, etc.

>>What is the scope of a single room?
> 
> As in?

Is a room a single contiguous space? Or do multiple rooms make up a 
single space? What is 'a single space' anyway (a 20x20 chunk of street? 
a street block?, part of a bar room or the whole bar room?)

>>How much ability do you need to modify the world for scripters/GM
>>staff?
> 
> A lot.

Then you should really look at something like what my post to MUD-Dev 
described for what we do in TEC.  It excels at this and is one of the 
nicest systems that I've seen around. (I didn't create it, I came on 
board after it was in place.)

If I recall correctly, you have some NextStep experience, so some of it 
may seem familiar.

>>Do you allow user programming at all?
> 
> No.

It is sometimes useful to class staff as users in answering this 
question depending on their level of skill, the amount/type of code that 
they write.  In TEC, we have several staffers that write code, but some 
of them write directly in ColdC (since we run Cold).  Others write in a 
higher level language that that that is fairly domain specific and 
contains a number of primitives related to managing interactions between 
players, NPCs, their environment and the passing of time.  Internally, 
we compile that domain specific language (DSL) down to ColdC which then 
gets executed as normal.  This lets us present smething fairly safe, 
something fairly powerful, yet limited to the staff for getting their 
jobs done.  A lot of it could also be used in another system for 
presenting some very basic world modification to users.

>>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).

I wouldn't trust all of the staff to always do the right thing. :/

They're people. You'll get bad people sometimes, or they'll have an 
error in judgement.  What does this mean?

    * It is always useful to have a security model and framework!
    * Auditability is important.

Both of these can complicate the process of adding actions to the game 
world depending on the extent to which you go with a security framework 
and an auditing system.

>>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.

I have a lot of comments about issues that I see with this, even as 
pseudocode, but perhaps another night for that.

Personally, I think that it is interesting to approach this whole topic 
at a different level such as Claude Shannon's _A Mathematical Theory of 
Communication_ or one based on semiotics.  But perhaps more about that 
some other day/week/month as well.

  - Bruce



More information about the vworld-tech mailing list