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.
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. 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. 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 On Oct 28, 10:55 am, Kripken <kripkenste...@gmail.com> wrote: > On Wed, Oct 28, 2009 at 3:39 PM, arkowitz <arkow...@gmail.com> wrote: > > > Thank you for clarifying your earlier terms. If I am understanding > > correctly, when you say "Second Life like" you mean that the > > environment produced lacks guarantees that the situation in one client > > is identical to the situation in another client. > > > Our goals ARE different as you have said. The goal of MXP is to > > enable a metaverse which is the product of many "participants" and > > which scales by having cooperative "hubs" which are tracking the > > overlap of objects' physical bounds with their awareness bounds. I > > believe your goal is to be able to support a true gaming experience - > > possessing guarantees of identical behaviour across clients. > > That is related, but not exactly how I would put it. > > First, the only clients of interest to me are open-source clients running on > general purpose computers (like Second Life, reX, and Syntensity). No such > client can guarantee identical behavior (unlike, say, game consoles with > their specialized hardware+software). > > So the issue isn't "product of many participants" vs. "identical behavior > across clients". I would say that the issue is between "product of many > participants" vs. "allowing many different environments". > > To put it another way, Second Life is 'continuous', both physically, and in > that you have the same avatar everywhere, and that the 'rules' are much the > same everywhere (physics, scripts). An MMORPG like World of Warcraft is also > continuous in that sense. But it is also interesting to consider a > 'non-continuous' platform which allows very different areas. Some of those > areas could be continuous and Second Life-like, others could be Quake-like, > yet others 'scripted movement'-type, and so forth. > > > I think the relevant questions now are: > > > - CAN there be one protocol which supports both of these models > > Based on our existing implementation, which is in production, I would say > yes. > > Also, if one has a system that allows the "many different environments > model", then a "product of many participants" (i.e., SL-like) model can > simply be just one of the different environments made possible. That is, if > you have the flexible model, you by definition can have the inflexible one > inside it. > > > - SHOULD there be one protocol which supports both of these models > > (does it matter) > > That's a matter of opinion. I, for one, think it does matter, because I > believe the future of the 3D web is not just one kind of 3D world, but many. > > > > > > > [...] > > > On Wed, Oct 28, 2009 at 3:43 PM, arkowitz <arkow...@gmail.com> wrote: > > > I would like to add that MXP provides a framework for sending any kind > > of update about any kind of arbitrary attribute associated with an > > object. The fact that we kept the definition of object attributes out > > of the protocol does not mean it is not supported. It is a big part > > of what MXP does. An MXP hub essentially routes the updates to the > > participants who need them; but it doesn't care what the updates are. > > There is a content definition layer which defines all that. > > > It is possible that a "one true protocol" has to have this kind of > > flexibility and stay out of the business of defining what can be > > updated about a particular object. > > Of course, but that just makes the core protocol extremely thin. What then > does matter is the platform, which in this case must allow both client and > server-side scripting, because you want each area to be able to define its > own protocol, so you must be able to run different (and arbitrary) protocol > code in each area. > > In other words, what is important is what language you use to write the > protocol code, what API you have on top of that language, and so forth. Our > implementation uses JavaScript for protocol code and a custom API designed > specifically for this purpose. > > Of course the core protocol must still be suitable - it should allow > multiple channels, ordering schemes, reliable/unreliable options, and so > forth, following established standards and best practices (as mentioned in > the MXP discussion I linked to earlier). > > - kripken --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/realxtend http://www.realxtend.org -~----------~----~----~----~------~----~------~--~---
