Fwd: Terminology

[Alon Zakai]

[ Sent this using the wrong email account
before - I presume it will bounce. If not,
sorry for double post ]

I think it might be useful to agree on a common
terminology for various things. It would be best
if that terminology could make as few assumptions
as possible about the underlying technology.

For example, I find myself almost using the
terms 'simulator' and 'grid' when talking about
the Intensity Engine, even though the servers
there are not in fact acting as simulators,
and even though the concept of a 'grid' is
meaningless there.

Here are some concepts I think should have
good names. Perhaps such names already
exist and just need to be pointed out to me.

1. 'Simulator' - need a more generic term for
a server that is 'in charge' of running a small
area; simulation/physics is just one part
of that. This is basically what a 'game server'
is in Quake etc. (which doesn't do simulation
in the SL sense, but still is in charge of
a single game). Name ideas: Server (too
general), server instance (a la Amazon EC2),
area server, etc.

2. Set of connected servers of type #1 - a
'grid' in SL, yet these could be separate
rooms, or not in a grid orientation. But
avatars can move between them in some
manner. Name ideas: World, universe,
realm, etc.

3. #2, plus some sort of user account
system, asset metadata, etc. - a
complete package (possibly one of many
in a federated setup). Name ideas:
universe, domain, realm, etc.

Best,
  Alon Zakai / kripken

[Ryan McDougall]

I agree, and this is something I'd like to contribute to, borrowing
terminology from a bunch of different sources.

Ewan, any possibility of having a common wiki up?

Cheers,

[Tommi Laukkanen]

You can also add pages to the google group and put the content there.

-tommi

[daniel miller]

new terms:

1. 'Simulator' - need a more generic term for
a server that is 'in charge' of running a small
area; simulation/physics is just one part
of that. This is basically what a 'game server'
is in Quake etc. (which doesn't do simulation
in the SL sense, but still is in charge of
a single game). Name ideas: Server (too
general), server instance (a la Amazon EC2),
area server, etc.

At Sirikata, we call this the space; a more generic term might be 'space server',  The idea being, it deals with a coordinate system, keeping track of the location and orientation of objects, proximity queries, and so on.  Full-core physical simulation is one possible extension.

Note that this is of course distinct from a content server.

2. Set of connected servers of type #1 - a
'grid' in SL, yet these could be separate
rooms, or not in a grid orientation. But
avatars can move between them in some
manner. Name ideas: World, universe,
realm, etc.

 

Federation?  That might confuse since the term can be used to apply to federated services in other areas.

Realm works for me.

3. #2, plus some sort of user account
system, asset metadata, etc. - a
complete package (possibly one of many
in a federated setup). Name ideas:
universe, domain, realm, etc.

World?

[Hurliman, John]

Cable Beach has its own set of definitions (which can change before the draft is completed) at <http://code.google.com/p/cablebeach/wiki/CableBeachCore1_0>. Feel free to cherry pick terms or make suggestions.

John

[daniel miller]

I have to say, I would love to get rid of the "simulation" terminology.  It is terribly confusing to anyone who is interested in "real" simulation, ie realistic robotics, scientific visualization of proteins etc.

What is really meant in SL "sim" terminology is the server that is responsible for a patch of virtual space.  Newer architectures won't necessarily map to that -- they may not use a grid system to divide up virtual space; you could easily have multiple servers "simulating" the same coordinates cooperatively.

I like Sirikata's use of "space", though even this term might be stretched at some point.

[Ewen Cheslack-Postava]

Ok, I've set up a wiki at http://www.kyoryoku.org/wiki/ . Just the
bare bones setup as I don't have time for more than that at the
moment. You need to register to edit (just for spam avoidance).

-Ewen

[Hurliman, John]

Cable Beach is using simulation in the correct sense of the word. Since the protocol doesn't deal with any spatial representations or state melding there is no built-in concept of virtual space. The more generic term of "simulation" is used to cover everything from protein folding to a virtual beachfront. It would probably be more accurate to say you aren't connecting to the protein folding simulation itself, but rather a state melding interface. I wanted to avoid having to define too many terms that were outside of the CB scope though.

I don't think the SL use of simulation is incorrect, it's just one of an infinite number of simulations you could do. The "space" terminology seems like a more narrow definition that accurately describes what Sirikata and SL both do, but I don't think it captures enough to be a universal term for all virtual world application.

[Ewen Cheslack-Postava]

The terminology rat hole is a deep and messy one... you captured our
intention though, which was that spaces would refer to a fairly narrow
set of scenarios you're describing: 3D "physical" worlds. Honestly,
almost all the terms used for most platforms are too generic to be
useful (Sirikata's included). This all boils down to convention +
understanding how any given implementation or architecture maps onto
that convention. So personally I'm indifferent to the particular
terminology used on this list so long as it is well specified.

-Ewen

[Ryan McDougall]

I don't think its really important precisely what names are chose, or
even that the naming is 1-1, only that we have a way of understanding
what each is talking about when describing ideas to each other.

Cheers,

[Alon Zakai]

>
> I don't think the SL use of simulation is incorrect, it's just one of an infinite number of simulations you could do. The "space" terminology seems like a more narrow definition that accurately describes what Sirikata and SL both do, but I don't think it captures enough to be a universal term for all virtual world application.
>

I think 'space' is a much better term for general (non-SL)
use, as it implies what the server is 'in charge' of (an
area, a space) rather than what it does in that space
(simulate or something else). However, I fully agree
with the point that 'space' isn't universal for all virtual
worlds. For example, in something like Quake or
the Intensity Engine, the servers do manage a 'space',
but what they are really in charge of is an *activity*.
An activity has a space, but also a ruleset, etc. Also,
two activities can share the same space (duplicates
of it, i.e., multiple instantiation of the same activity).

Still, there is something very similar between what
an SL simulator and a Quake server do, despite the
differences. They both serve as the manager for
an interaction between a set of avatars that
experience a shared 'world'. I can't help but feel
that a good term for this exists, but it eludes me.

[Hurliman, John]

For the purposes of this list, what about the "state melding" term? The point of all virtual worlds is a shared real-time simulation of *something*. The shared and real-time parts are the most important, because it implies a technology that takes inputs, manages state for multiple objects/actors, and broadcasts the shared state back to viewers.

Every system is going to differ on what inputs are allowed, whether a single unified state or many sharded states are managed, the consistency model of the state(s), and how and what state is broadcast to whom. But state melding is still a commonality there. With the scale of most worlds, the state melding is probably happening across many processes and servers and maybe p2p nodes, but any entity participating in the process could be called a "state melding server" or "state melding node". Or we could fudge and use the simulator term to mean the same thing. As long as we collectively understand what is being discussed it's a non issue.

John

>-----Original Message-----
>From: kyor...@googlegroups.com [mailto:kyor...@googlegroups.com] On
>Behalf Of Alon Zakai
>Sent: Friday, June 19, 2009 10:40 PM
>To: kyor...@googlegroups.com
>Subject: [kyoryoku] Re: Fwd: Terminology
>
>
>>

[Tommi Laukkanen]

Here is the MXP domain model as explained at Bubble Cloud wiki:

http://www.bubblecloud.org/wiki/-/wiki/Main/Domain%20Model

It may offer some new terms which are associative and not too tightly
bound to specific implementations or architecture.

Respectfully,
Tommi
http://www.bubblecloud.org/

[daniel miller]

. I can't help but feel
that a good term for this exists, but it eludes me.

I agree.  Perhaps John is right that 'simulator' is the best description, but for some reason it feels wrong to me.  Maybe that's because I use the term in a more narrow sense in my work.

Terminology and jargon are interesting subjects.  Choosing your terms wisely is important, though presumably some terms will end up looking silly years down the road, and that isn't necessarily fatal.  It's sort of like naming variables and methods -- it's always wrong, but there are levels of wrongness.

Here's an example of why I'm not sold on 'simulator' as the right term.  I have a model of a p2p virtual world, where the central server does basically what a skype server does -- facilitate interconnections between nodes.  It would do no actual simulation, that all happens by nodes communicating and agreeing on how they react to things like collision.

In this model, the central server is basically just a switchboard.  It might answer queries, such as "give me a list of all objects within 10 meters", but it doesn't do any simulation.  What do you call this service?

[Alon Zakai]

>
> Here's an example of why I'm not sold on 'simulator' as the right term.  I
> have a model of a p2p virtual world, where the central server does basically
> what a skype server does -- facilitate interconnections between nodes.  It
> would do no actual simulation, that all happens by nodes communicating and
> agreeing on how they react to things like collision.
>
> In this model, the central server is basically just a switchboard.  It might
> answer queries, such as "give me a list of all objects within 10 meters",
> but it doesn't do any simulation.  What do you call this service?
>

Hmm, actually that is also fairly close to the Intensity Engine
architecture (but also allowing for 'virtual' clients on the
server - bots - which are run there). Indeed, 'simulation'
seems the wrong term here.

[Alon Zakai]

On Sat, Jun 20, 2009 at 9:18 AM, Hurliman, John <john.h...@intel.com> wrote:

For the purposes of this list, what about the "state melding" term? The point of all virtual worlds is a shared real-time simulation of *something*. The shared and real-time parts are the most important, because it implies a technology that takes inputs, manages state for multiple objects/actors, and broadcasts the shared state back to viewers.

This is a good direction, I think - 'meld', 'mix', 'merge', or
maybe 'synchronize' - something in that area seems
very appropriate.

[daniel miller]

Hmm, actually that is also fairly close to the Intensity Engine
architecture (but also allowing for 'virtual' clients on the
server - bots - which are run there). Indeed, 'simulation'
seems the wrong term here.

One obvious thing to note -- we're talking about services here, not machines.  In the case you mention, I would say you're running a 'space' service (or 'sim' in typical parlance) and a 'client', or what we at Sirikata call an 'object host' on the same machine.

I'd almost rather go with SL's 'sim' than simulator, because it's not really a word.

[Ryan McDougall]

Hope I'm not being obtuse, but I wonder why we can't have both

"Simulator": computation designed to compute the outcome of a system
according to a ruleset, such as provided by newtonian mechanics
"State Relay": network server designed to relay a dynamic system's
state to observing parties?

Cheers,

[Alon Zakai]

On Sun, Jun 21, 2009 at 9:08 AM, Ryan McDougall<semp...@gmail.com> wrote:
>
> Hope I'm not being obtuse, but I wonder why we can't have both
>
> "Simulator": computation designed to compute the outcome of a system
> according to a ruleset, such as provided by newtonian mechanics
> "State Relay": network server designed to relay a dynamic system's
> state to observing parties?
>

Both terms are useful, but something seems
'off' when using just these terms to describe a
Quake server or Intensity Engine server
(or a Sirikata space service?).

On the one hand, they do more than just relay
state, they are 'in charge' of it in some sense. But
on the other hand, in such architectures the clients
can do as much 'simulation' as the server (yet
this isn't 100% P2P as, again, the server is 'in
charge' of the overall shared experience - only it
can add new entities, and the state information
on it is authoritative in some sense).

I guess to use your two terms here, both clients
and server might be called 'simulators', while the
server would also be called a 'state relay'. But
this might confuse people used to considering
'simulator' in the SL sense.

[Ryan McDougall]

I have gone ahead and aggregated a bunch of terms here:
http://www.kyoryoku.org/wiki/index.php?title=Shared_Terminology

Please take some time to go through and fix things up to your liking.
If your word is missing, add it. If you'd like to make a change in
definition, make it, and bring it up on the mailling list.

Cheers,

[Alon Zakai]

I'm not sure what the purpose of the wiki page is. For
example, it contains SL-specific terms, without
qualifying them as such - is that intentional, or
just because it's a work in progress? (If the latter, I
would be happy to help.) Also, it contains very
specific terms like 'Seed Capability', which seems
to imply the list is specific to those using Cable Beach.

How about a high-level page with terminology comparisons
between systems, and several lower-level pages that are
system-specific?

Best,
Alon Zakai / kripken

[Ryan McDougall]

Sounds good. As I said, I just globbed everything together without
much thought. Figured if it annoyed someone they'd go in and fix it.
:)

Cheers,

[Alon Zakai]

Ok, made some changes. I'll try to do more later.

Best,
Alon Zakai / kripken