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
> * 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"
> * 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 ;^}
> * in-world editing (another use of the database)
I think this hints at a larger discussion like the dbms issue...
see below
> * voice
do you mean audio-chat??
text-to-speech??
> * avatar animation support with behaviors separated from avatars
hmmmm
this sounds like h-anim stuff to me
or am I missing something?
> * 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]
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
jeffs
--
Jeff Sonstein, M.A. http://ariadne.iz.net/
http://ariadne.iz.net/~jeffs/jeffs.asc
==============================================
there are no bugs
there are just undocumented features
