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
