[vworld-tech] Ultimate MMO Platform (was OT:Dead?)

[Megan Fox]

> This is part of what I had in mind, the architecture of the logical
> representation of the world. How are things like trees and buses and bus
> drivers modelled? How do they interact? Are objects mainly lists of
> properties in a prototype system which are used by game systems (physics
> uses mass and volume properties, combat uses hitpoints and strength
> properties) or do objects have behaviours triggered by events
> poked at them
> by the platform (a mine and a ship collide, both are told about the
> collision event they have taken part in, the ship delegates the
> outcome to a
> standard behaviour, the mine overrides this behaviour and goes
> boom). Maybe
> you have both? These are the things that the replicated objects I was
> talking about before do. These logical behaviours just get on an do their
> thing, not worrying about the synchronisation happening at a lower level.
> What I vaguely have in mind is some kind of MUD like object model like
> LlambdaMOO at this level, with the network VR synchronisation stuff
> happening underneath.

Well, in my current Entity system, all data and function calling is
abstracted.  Function calls are done by name through the entity, which has a
registry of all functions exposed by all attached components.  All data
storage is on a central variable context, a generic data container that can
be added to or changed by any component.

As such, the AI component might just look for "CanDrive" in the variable
context when attempting to hop into a jaguar.  If it finds "CanDrive", then
it would put itself in the seat, expose the required
data/functions/whatever, and call "AIDrive".  "AIDrive" would be a function
served by whatever component was attached to the entity that knew how to
drive, and it would then handle the driving of the entity in the car given
the data exposed by the calling component.  When it finished, it might stand
the entity back up, then call "AIRoam" to reset the AI state back to another
controlling component.

This abstracts the AI code such that your "driver" component can be plugged
into almost anything.  Hell, so long as it had the required animations, a
newt could drive a car, if you wanted it to.  The rest works on the same
principle.


... I gather the way I'm doing things is very much like a MUD - at the very
least, bruce has been nudging my methods as far as script exposure and
entity messaging go towards the way a MUD might do it.  I don't see this as
a bad thing at all, as it should faciliate the system's use in other game
types (or an MMORPG, or a co-op game, etc).

> I don't think the right approach is to just try to model a world
> at the most
> detailed level possible, but to model the world in enough detail for the
> game it supports. There would be little use in modelling trees in the
> painful detail you describe if the game was a vietnam combat game
> where all
> that happened was the trees got flown over at high speed and then
> napalmed.

I disagree, but not in a way that is relevant right now.  Eventually, there
will be processing power to spare, and designers will be saying "what kind
of cool thing can we add that the kids want."  The answer?  Why trees that
explode, topple realistically, and burn, of course!  And houses too!  And
forts!  And... etc.  And for that, you need the entity properties and
functionalities I touched on - you need to know the object is wood (or
another burnable material), you need to know how to break the material up
when it gets hit with an RPG, and you need the leaves to contact with the
ground and bend away realistically.

So even if it isn't useful now, such technologies might eventually become
useful - and if your system just happens to support the data required
already, just needs lots of expansion, cool.

-Megan Fox