By the way, I didn't intend for these to be prioritized in any particular
way, I just wrote them down as they occurred to my addled brain. But I
guess the ones on the top were the ones I think most about so in some kind
of unconscious way they did get prioritized.
At 02:13 PM 02/01/2000 -0800, Jeff Sonstein wrote:
>take all that I say with a grain of salt
>for the following is just IMHO thinking-aloud time ;^}
>
>> * solving the signal bottleneck so that the server may support 50 or more
>> users at a time
>
>I totally agree with this issue as #1 priority for VNet
>I have some "ideas"
>and I need to finish building a test-bot client
>[1-n logons generating transformations and chat-text]
>and then put in a buncha printlns to gather real data
cool :-) call a break-the-server party sometime when ready. :-)
>> * database(s)
>
>I agree with this as #2
>but see below for details
>as I think it is about more complexity than
>"shared object states, behaviors, and ownership"
Yeah. I am not too knowledgeable on databases and how they would be used
here. I just understand enough to know that it would enable a whole range
of things. Of course the current system already has a database -- it just
needs to more capabilities.
>> * artificial life and bots
>
>there is a way to do this right now...
>build a specialized client that runs
>an avatar as the "visible/audible front-end"
>for what the simulation is doing
>[artificial life growing and changing
> robot lurching about muttering]
>and run an instance of the little bugger as a VNet client ;^}
Yes. Though a full avatar's capabilities are not necessary for say, a
growing tree -- it doesn't need to get info about all the other avatars in
the world, beyond perhaps that goat avatar that is happily munching on its
leaves, but it doesn't see, and it doesn't chat. (Unless we are talking
about Triffids :)
As you say, a bot might be best represented by an avatar run from some kind
of special client, logged in as a user. I wonder if there is a simpler way
to do general-purpose bots.
>> * in-world editing (another use of the database)
>
>I think this hints at a larger discussion like the dbms issue...
>see below
Yeah. This is a biggie... but VERY important.
>> * voice
>
>do you mean audio-chat??
>text-to-speech??
A strange combination of both. More on this shortly.
>> * avatar animation support with behaviors separated from avatars
>
>hmmmm
>this sounds like h-anim stuff to me
>or am I missing something?
Yes. Basically H-ANIM stuff, but they seem to have trouble separating their
behaviors from the models... they may have solved that now... I am not
sure. I think it is essential that behaviors are re-usable. And I think
scriptable (human-readable) behaviors would make bots, A-Life, and VR
fiction much easier too.
>> * being able to return to the world where you left it, if you desire
>>
>> * teleportation using clickable or bumpable objects.
>
>see dbms etc discussion below
>
>aha
>at last the "dbms and etc discussion" ;^}
:-)
>so what do we mean by "* distributed server"??
>different parts of a wrl can exist on separate machines
>already
>but the VNet server doesn't really understand the concept of a "world"
>it just knows about clients and messages to shuffle around between them
>
>my current phantasy runs as follows:
>
>there is a dbms server with a database on it
>within which there is a stable-character-oriented database table
> [maybe "Player Characters"]
> with username and default-avatar and password and such
>and maybe also a "Non-Player Characters" table
> but that's another story
>and also a current-transform-oriented table
> [maybe "Character States"]
> with username and last-transform-state and such
> for each wrl the db knows of and which the username has been in
>and also known-VNet-servers table
> [maybe "Known Servers"]
> with IP and password and so on
>and each real VNet server controls one wrl ("room"??)
>and a group of VNet servers uses the same dbms server and db and tables
>and users are teleported (logged out of and onto cooperating VNet servers}
>somehow
>[waves mirrors
> starts smoke-generator]
This sounds like a really neat way to have a shared world, which
generalised, fits with the worlds-in-a-universe point. The way you are
talking of it, it sounds like a database separated from the VNet servers.
This sounds right to me and the way to cross over from server to server.
Would the database be split into pieces -- each server having a piece? And
all together this would make up one big, scaleable database? That way there
is no center, and if one machine goes down or is unreachable the whole
thing doesn't go down with it.
This would have another nice side-effect: if someone puts a new VNet world
up on the net then when someone teleports to it from another VNet world
(using an explicit URL), the new server's address gets linked to all the
old servers' addresses on each server in the VNet ring. So everybody else
in all the other VNet worlds now can visit the new world without needing an
IP address.
[excuse my rambling on -- just running with the idea here]
>I'd like to get a discussion going on about
>what a DB should look like
>which allows VNet servers
>each controlling one "room"
>to cooperate in this sort of framework
>and to facilitate stable characters
Cool. :-)
I am not gonna be much use here but will take part in any way I can.
Cheers,
- Miriam
-----------------------------------------------------------------
http://werple.net.au/~miriam/
Virtual Reality Association (VRA)
Melbourne, Australia
http://www.vr.org.au/
