Tim Bray's BlogBot: Site Personalities As 3D Bots

When we build a site, we build a personality. Ergo:

"If you’re naked in the snow, are you cold or warm?" - Tim Bray's Blogbot

That is not an avatar but the standard form. On the other hand, why use forms other than being soooo 90s. :-)

The one endlessly fascinating challenge in computing is still how to present that personality to its best advantage.

If your avatar subscribed to your feeds, what would it think about you?

Virtual worlds can be real-time maps of GPS-enabled real world objects. The services to those objects relate real-world database feeds as rendered by the real-time 3D engine. The standard real-time 3D embraces xmlHTTP for network services. D'oh.

You don't actually need a server-farm until you start doing MU. Yes? No?

Until that time, a feed-server can update the real-time model and the user can query over the domains of the feed server vocabularies. How much state do you really have to share to make a real-time 3D model enormously useful as a comparator?

3D is a real-time console, not a form, yet by the relationships of the real time model representation, a querying system nonetheless.

What are the inherent real-time 3D qualities unique to it that describe relationships among the named objects in a scene?

Querying the 3D scene is easy.

Using the 3D scene to construct a query is not difficult.

The question is what are the advantages over form-based querying?

One: faster human recognition of the objects presented with or without native language representation. Situation (say cultural, yadda) language specificity is increased by geo-location.

Using geo-located real world objects that send feeds, this is a no brainer. The identification of the real time object to the virtual representations when authenticated and authorized have the same relationships as a doppelganger. It knows what is in real-time space, so it queries the databases of that real-time objects and self-organizes by mapping its own relationships to the feeds.

Spatio/Temporal data for real time locations drives the frequency of the model selectors (not update but query by domain type; remember, this model is in motion) but the local models control the rest. The local model as in any auth/auth system can only query what is passed by subscription to the local device.

Otherwise, it is querying itself.

"If you’re naked in the snow, are you cold or warm?"

Say you are driving to work and bypass multiple city trucks parked on the highway and you want to know what event caused that. Open the GPS device and query. Same as any other GPS form except the person making the query does not have to speak a language as long as they click on a visual object seen in real time space. They don't have to type dip. Just click. Given authentication and authorization, the screen returns a situation update for that geo location in terms of scheduled objects and event types provided by feeds.

Subscription feeds should work fine. Take a system like the Planet9 RayGun and a virtual city, and plug-in. The question of scalability over feature set combinations makes me curious because that is the selector of the business sets that can be supported for collaborative scenes where collaboration is based on the combinations of feed services.

Avatar sophistication (botBuilding) is the really interesting part of virtual worlds.

Are avatars just humans? What about the other articulated objects? Aren't they all bots by botType? H-anim is a human bot standard for a specific language framework. Others in that framework? How generalizable to the body of practice for creating models for that application domain?

We do know enough to build self-organizing evolving bot systems. We don't know what
we want them for beyond entertainment and serious games. Or if they'll need us to
want them for very long. ;-)

len