What would a blimp look like as it floats through this invisible matrix? Could you ensure it is artifact free? Could you fire your canon at it from a different room? Consider the possibility of a very large blimp (a bunch of participants might be wining and dining up there).
I don't believe you'll need something 'completely different' from TeaTime. You are clever. You will find workarounds, if you look for them. Consider, instead, the possibility of 'TeaTime + careful discipline'. If you can localize interactions, bound them to just a few cells in the matrix, you can keep synchronization costs to a reasonable level - but this will cost you expressiveness. Careful applications of idempotence and commutativity can save you a lot of efforts by supporting 'eventual consistency' and reducing the need for strict ordering of events within a time-slice - i.e. you can find disciplined ways to weaken the transactions necessary (and thus improve performance) - but this would require more careful expression of many algorithms. Motion of objects (non-characters) through cells will be a challenge to model, especially if they have dependencies (references) to other objects in the environment. Autonomous objects raise their own challenges (Grab your rifles, men, we're going after that mutant kangaroo. It's somewhere in this matrix.) What "federated worlds" really means: you have many *independent* developers linking their worlds together. At the Internet scale, this might mean * millions* of concurrent developers, the way we have billions of web-pages today. To ask a million developers to be 'disciplined' would be optimistic. Even asking them to be 'benign' would be ineffective. A million developers will have almost a million agendas. At large scales, discipline and security must be systematic, and on the path of least resistance. The win is commensurate with the challenge - rich content and relationships, secure business integration, augmented reality, and a cloud of not-entirely-trustworthy compute resources available for competitive prices with an e-purse (but not every computation needs trust). This is part of what I aim to achieve with RDP. So long as your world is built by yourself or a small group, you can achieve the discipline necessary to make TeaTime or a minor variation work at scale. You can even allow some user-generated content, if you carefully control its construction or at least limit damage. Regards, Dave On Tue, Aug 9, 2011 at 8:39 PM, Casey Ransberger <casey.obrie...@gmail.com>wrote: > Aha. This explains why various wonderful people warned me that what I > wanted to do would end up being expensive to implement. > > There's been some talk about "federated worlds" and this is I *think* part > of what I'm after. > > So let me ask you this: if I can find a way to cut down the time to load a > new room far enough to where users don't have to notice it very much, e.g. > by caching a lot of assets on disk, etc, find a way so that one can see into > the next room in a matrix of rooms, and then just make the portals invisible > and at compass boundaries between spaces, do you still think I'd need to rip > out TeaTime and replace it with something of a completely different design > in order to build a large, apparently (but not actually) continuous space? > > I realize that I'm probably pushing my luck:) but crowds are important for > large groups like everyone, so this just got twice as interesting! > > On Tue, Aug 9, 2011 at 5:37 PM, David Barbour <dmbarb...@gmail.com> wrote: > >> On Tue, Aug 9, 2011 at 3:40 PM, BGB <cr88...@gmail.com> wrote: >> >>> ideally, we should probably be working with higher-level "entities" >>> instead of lower-level geometry. >>> >> >> I agree with rendering high-level concepts rather than low-level >> geometries. >> >> But I favor a more logical model - i.e. rendering a set of logical >> "predicates". >> >> Either way, we have a set of records to render. But predicates can be >> computed dynamically, a result of composing queries and computing views. >> Predicates lack identity or state. This greatly affects how we manage the >> opposite direction: modeling user input. >> >> >>> possibly, ultimately all levels should be expressed, but what should be >>> fundamental, what should be expressed in each map, ... is potentially a >>> subject of debate. >>> >> >> I wouldn't want to build in any 'fundamental' features, except maybe >> strings and numbers. But we should expect a lot of de-facto standards - >> including forms, rooms, avatars, clothing, doors, buildings, landscapes, >> materials, some SVG equivalent, common image formats, video, et cetera - as >> a natural consequence of the development model. It would pay to make sure we >> have a lot of *good* standards from the very start, along with a flexible >> model (e.g. supporting declarative mixins might be nice). >> >> >>> >>> I am not familiar with the Teatime protocol. apparently Wikipedia doesn't >>> really know about it either... >>> >> >> Teatime was developed for Croquet. You can look it up on the VPRI site. >> But the short summary is: >> * Each computer has a redundant copy of the world. >> * New (or recovering) participant gets snapshot + set of recent messages. >> * User input is sent to every computer by distributed transaction. >> * Messages generated within the world run normally. >> * Logical discrete clock with millisecond precision; you can schedule >> incremental events for future. >> * Smooth interpolation of more cyclic animations without discrete events >> is achieved indirectly: renderer provides render-time. >> >> This works well for medium-sized worlds and medium numbers of >> participants. It scales further by connecting a lot of smaller worlds >> together (via 'portals'), which will have separate transaction queues. >> >> It is feasible to make it scale further yet using specialized protocols >> for handling 'crowds', e.g. if we were to model 10k participants viewing a >> stage, we could model most of the crowd as relatively static NPCs, and use >> some content-distribution techniques. But at this point we're already >> fighting the technology, and there are still security concerns, disruption >> tolerance concerns, and so on. >> >> Regards, >> >> Dave >> >> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > > -- > Casey Ransberger > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
