On Wed, Oct 28, 2009 at 3:39 PM, arkowitz <[email protected]> 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 <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
