On Wed, Oct 28, 2009 at 8:06 PM, arkowitz <[email protected]> wrote:
>
> An MXP platform need in no way be "continuous". A user's avatar - in
> terms of where it is, how it behaves, what it looks like - can and
> should be completely at the discretion of that user. Continuous
> "regions", a single physics engine for everything - these are not
> requirements or even suggestions of MXP. MXP was designed to support
> many different environments.
>
I meant 'continuous' in a different sense. Perhaps I was not clear.
A concrete example: Second Life uses the same movement/position update
message format in all its regions. In that sense it is continuous. Whereas
in a *non*-continuous platform, that is not necessarily the case, and each
area would define its own movement/position update message (and even have
different ones for different entity types), which would then let some
regions look like SL, while others behave like Quake.
The bottom line in my definitions is this: In a 'continuous' architecture,
all the regions behave in one way - be it SL, or Quake, or something else.
That is still quite flexible, just as you said (users can change their
avatars, etc.). But in a 'non-continuous' architecture, one region can
behave like SL, another like Quake, and another otherwise, while at the same
time all are accessible with a single client. That was a requirement for us
during our planning stage, and it is what led to our current architecture
and implementation.
>
> You say that what is important is what language you have, what API...
> and that, to me, is exactly the point of trying to define a ubiquitous
> protocol. Software written in multiple languages, using multiple
> API's, should be able to interoperate. We are a long way from that in
> the virtual world space, due to the tendency to create protocols based
> on how a particular API is envisioned or developed, and due to the
> tendency of folks to start with the API and the language and then add
> the protocol.
>
We are talking about different things.
To compare to the web: MXP is a parallel for HTTP, while the Syntensity API
is a parallel for JavaScript (the core language + the standard web browser
stuff). To continue the analogy, having just MXP is like a web browser
without JavaScript - it can only show HTML ('one type' of virtual world, in
the analogy). That is why I said that the language + API was more
interesting to me: The language + API is what allows a 'non-continuous'
architecture to run both SL-like and Quake-like worlds with the same client,
which is what I am interested in.
Note that we are open to using MXP in our platform, alongside our API,
assuming it at some point supports our necessary features - and that is why
I talked at length with the MXP devs. We already have something working in
the place that MXP would fill, but it would be nice to use something more
standard.
> A huge assumption I am hoping to dissolve with MXP is this notion of a
> virtual world "server". MXP has no server other than a lightweight
> communication hub which switches updates based on physical and
> awareness bounds. This is important. Building scripting, physics,
> etc. into the server creates a monolithic environment. Any script,
> whether run on some sort of server-scripting-host or on the client, is
> a participant in the MXP scheme. A server is really a collection of
> components which provide services to users (participants). It is
> important to talk about the components, breaking the assumption of a
> monolithic server.
>
>
No argument about that.
- kripken
> Many fine efforts will continue to go nowhere as long as devs are
> forging ahead without a proper and deep discussion of architecture.
> Issues and principles such as we are getting to in this conversation,
> in a roundabout way, should be discussed prior to running down the
> primrose path with code.
>
> Arkowitz
>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/realxtend
http://www.realxtend.org
-~----------~----~----~----~------~----~------~--~---
