VRML mudding
aim...@digital.net
the techology matures. I know VRML is the bleeding
edge of technology right now. I was hoping for
whatever information I can get.
Thanx
Travis S Casey
Please note: all this is AFAIK, since I've only read one
book on VRML, and haven't been reading up on any new developments.
Someone please correct me if I'm wrong. :-)
Right now, VRML does not have any mechanism for user feedback;
that is, while users can move around in your virtual world,
they can't affect objects in it in any way. This renders it
rather unsuitable for muds, at least, used by itself.
When/if VRML has a user feedback mechanism or mechanisms added,
it may become useful for building muds. Right now, you might
be able to create a psuedo-VRML mud by using VRML for output
and some other means (like a traditional telnet session) for
input.
Alternatively, you could try Java. I've seen 3D demos in
Java that users can interact with, so I would imagine that
something along the lines of a Java mud would be possible,
though I don't really know anything about programming in
Java (yet).
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ FAQ maintainer for rec.games.design
|,4- ) )-,_..;\ ( `'-' (904) 644-4290; Room 101C Carothers
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
aim...@digital.net
demos in
> Java that users can interact with, so I would
imagine that
> something along the lines of a Java mud would be
possible,
> though I don't really know anything about
programming in
> Java (yet).
I am not too sure what Java is (forgive me) , I could
use some clarification. Also, I am considering
attempting to make a roomless text engine, with the
results of the MU* 'look' command being a
description derived from a 3d database (not the same
kind as used for a rendering engine, but they could be
made to run in parallel). Are there any 'connectivity'
engines that would handle juggling all the users and
leaving me free to work on the content?
Stephen Masterman
And if there is a GNU (or other free) compiler for it?
Thanks
stephen f white
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
[someone else asked]
>> I am interested in opening a VRML MU* game when
>> the techology matures. I know VRML is the bleeding
>> edge of technology right now. I was hoping for
>> whatever information I can get.
> Right now, VRML does not have any mechanism for user feedback;
> that is, while users can move around in your virtual world,
> they can't affect objects in it in any way. This renders it
> rather unsuitable for muds, at least, used by itself.
VRML doesn't, but VRML+ does. see
<URL:http://www.worlds.net/products/vrmlplus/index.html>
it's still being spec'ed, but it might be a better starting point.
> Alternatively, you could try Java. I've seen 3D demos in
> Java that users can interact with, so I would imagine that
> something along the lines of a Java mud would be possible,
> though I don't really know anything about programming in
> Java (yet).
java is another possible approach, but you'll still need to write
the server and run it on a separate machine. also, java's performance
may not be up to the task yet. for 3D libraries and integration with
VRML, "iced java" <URL:http://www.dnx.com/chris/about-icedjava.html>
may be of interest.
-=- sfw
--
stephen f. white
s...@io.org
http://csclub.uwaterloo.ca/u/sfwhite
tools to make tools to make tools to make tools to make tools to ...
Edward Goff
like to look into this my self.
thanks
aim...@digital.net wrote:
: I am interested in opening a VRML MU* game when
: the techology matures. I know VRML is the bleeding
: edge of technology right now. I was hoping for
: whatever information I can get.
: Thanx
Edward Goff
java control so that would be something to lookinto for those of us
who want more from our MUDS and MOO's ect.. than just text :)
Thanks
Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
: > I am interested in opening a VRML MU* game when
: >the techology matures. I know VRML is the bleeding
: >edge of technology right now. I was hoping for
: >whatever information I can get.
: Please note: all this is AFAIK, since I've only read one
: book on VRML, and haven't been reading up on any new developments.
: Someone please correct me if I'm wrong. :-)
: Right now, VRML does not have any mechanism for user feedback;
: that is, while users can move around in your virtual world,
: they can't affect objects in it in any way. This renders it
: rather unsuitable for muds, at least, used by itself.
: When/if VRML has a user feedback mechanism or mechanisms added,
: it may become useful for building muds. Right now, you might
: be able to create a psuedo-VRML mud by using VRML for output
: and some other means (like a traditional telnet session) for
: input.
: Alternatively, you could try Java. I've seen 3D demos in
: Java that users can interact with, so I would imagine that
: something along the lines of a Java mud would be possible,
: though I don't really know anything about programming in
: Java (yet).
: --
Dave Bacher
> I am interested in opening a VRML MU* game when
>the techology matures. I know VRML is the bleeding
>edge of technology right now. I was hoping for
>whatever information I can get.
>Thanx
I don't think this would be possible yet. The main problems are space,
bandwidth, and computer speed.
The space problem is self evident -- a VRML file plus a text description
(you'd need both, since VRML can't handle smell, taste, temperature,
etc.) take up alot of space compared to just the straight ascii text.
The bandwidth problem is what causes lag. You've got xxk of data
waiting for player x. You've also got xxk of data being stored for x
other users. In addition, you've got to do some amount of computation
to determine the xxk of data that is supposed to be sent, and which
players are supposed to receive it. When too much time is spent
computing the data, or sending it, that has to come from somewhere. The
connection between the host and InterNet is a slowpoint in the link,
even with a T1, and this link would be severely stressed.
The computer speed issue has to be addressed also. You've got some
players who are on SGI OpenGL 3d Terminals, and flying along at several
million polygons a second, then you've got the moron who has Win95
installed on a 386 with a Trident VGA card, and is ploding around at 5
polygons a second. You have to keep both of these users relatively in
sync (pretty easy), and you've got to keep the display on both systems
as accurate as possible.
I do not believe VRML is appropriate for this. Like HTML, it has the
potential to cause bandwidth problems if you attempt to use it this way.
Ideally, you want a tightly compressed binary format designed
specifically for MU*'s. This format would be designed to store alot of
the repetetive data on the users side. This would include sector maps,
etc.
This would probably reduce the throughput to the point that it would be
possible to do a 3d MU*. The next logical step would be sending
'objects' for actors to the clients, and then sending movement commands.
If done correctly, this would also reduce throughput requirements.
Also, a distributed environment would help, also. For combat MU*'s,
there would be the potential for cheating in a fully distributed
environment (a peer-to-peer setup), and that would have to be addressed,
but a distributed environment would /greatly/ increase the available
bandwidth, and significantly reduce LAG. LAG also would be a larger
issue, since due to network delays player A may miss player B on his
screen, but make contact on somebody elses.
The biggest problems (from a user standpoint) with 3d games, via
internet, right now are:
Warping
Pausing
Network Delay
Warping is caused when computer A is out of sync with computer B. When
a Syncronize command comes across, computer B's vehicle will warp on
computer A's screen, and probably vice-versa.
Pausing is caused by lost/delayed packets. The enemy will pause, and
just hover there, making a tempting target. Alternatively, pausing may
be handled by the computer moving the target in a straight line (the
computer assumes no modifications to course have been made), and will
apply all the movements made since the last good packet, resulting in
warping when a sync packet is recieved.
Network delay manifests itself as a delay between when the opponent does
something and when everyone else sees it (lag). Unlike current lag,
though, it is not possible to evaluate one's own lag (since you cannot
see yourself). It is possible to use this to your advantage (common
trick in flightsims/descent is to fly forward for 10 secs, then turn on
your tale and blast the enemy to bits, as they wonder how you could
possibly be hitting them when you're flying away from them).
Unfortunately, Warping, Pausing, and Network Delay are items that will
never go away. Period. No matter how fast InterNet becomes, these
problems will occur. They occur in every game performed on InterNet
(ever take an action, only to find out it wasn't posible because the
network didn't get the action to the server quickly enough?):
-> :slaps xxxx across the face.
xxxx walks through the timewarp door to the east, and vanishes in a
flash of light.
yyyy slaps xxxx across the face.
That's the best example I can come up with -- certainly attacks, blocks,
etc. would fall in this category also. A 3d MU* could be considerably
worsem especially since it might take more work to handle the command.
Dave
---===---
dba...@dnaco.net
http://www.dnaco.net/~dbacher [Under Construction]
Frank Crowell
: Speaking of Java, does anyone know what a good book about Java is?
: And if there is a GNU (or other free) compiler for it?
: Thanks
There are at least three books on the market right now dealing with Java
programming. Also http://java.sun.com/ has some documentation and of
course everything you need to get started for some systems. There is
also an implementation for Linux (requires a fairly new Linux).
Frank
--
___________________________________________________
Frank Crowell fra...@maddog.com
maddog's studio http://www.maddog.com/
Dark Cat
> Where can I get info on java? I've heard netscape 2.b2 is out and has
> java control so that would be something to lookinto for those of us
> who want more from our MUDS and MOO's ect.. than just text :)
>
>
> Thanks
>
> eg...@vespucci.iquest.com
Try http:\\java.sun.com\ or something similar.
Dark Cat
> Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
> : > I am interested in opening a VRML MU* game when
> : >the techology matures. I know VRML is the bleeding
> : >edge of technology right now. I was hoping for
> : >whatever information I can get.
>
Frank Crowell
: On 30 Nov 1995, Edward Goff wrote:
: > Where can I get info on java? I've heard netscape 2.b2 is out and has
: > java control so that would be something to lookinto for those of us
: > who want more from our MUDS and MOO's ect.. than just text :)
: >
: >
: > Thanks
: >
: > eg...@vespucci.iquest.com
: Try http:\\java.sun.com\ or something similar.
Also if you want to build servers, clients, or whatnots (especially whatnots),
you may want to join the mail list for this at majo...@eecs.com
with this in the body of the mail:
subscribe java-mud
Frank
Glenn Crocker
In article <49l0eo$g...@polo.iquest.com> eg...@iquest.com (Edward Goff) writes:
From: eg...@iquest.com (Edward Goff)
Newsgroups: rec.games.mud.admin
Date: 30 Nov 1995 19:25:12 GMT
Organization: interQuest Online Services -- Huntsville, AL
Where can I get info on java? I've heard netscape 2.b2 is out and has
java control so that would be something to lookinto for those of us
who want more from our MUDS and MOO's ect.. than just text :)
Check out Pueblo: http://www.chaco.com/pueblo It's a mud client with
support for text muds, ANSI, HTML, 2d graphics, sound (MIDI, WAV), and
VRML. It currently runs on Windows 95 and NT. The next release will
also run on Windows 3.1. Its VRML support is so good, NetManage (the
Chameleon folks) asked us to pull it out and make them a standalone
VRML viewer based on it. Its HTML is so good, another company has
asked us to do the same thing.
--
Glenn Crocker gl...@chaco.com Light bar not for occupant protection
VP Engineering Do not touch the len
Chaco Communications Do not taunt happy fun {ball,Chet}
Zombie
>
> aim...@digital.net wrote:
>
> > I am interested in opening a VRML MU* game when
> >the techology matures. I know VRML is the bleeding
> >edge of technology right now. I was hoping for
> >whatever information I can get.
> >Thanx
>
> I don't think this would be possible yet. The main problems are space,
> bandwidth, and computer speed.
>> Deleted Stuff <<
>
> xxxx walks through the timewarp door to the east, and vanishes in a
> flash of light.
>
> yyyy slaps xxxx across the face.
>
> That's the best example I can come up with -- certainly attacks, blocks,
> etc. would fall in this category also. A 3d MU* could be considerably
> worsem especially since it might take more work to handle the command.
>
> Dave
> ---===---
> dba...@dnaco.net
> http://www.dnaco.net/~dbacher [Under Construction]
If you want to look at the current status of this type of game, then try checking out
http://www.worlds.net/alphaworld/
At lot of the problems Dave has mentioned are present. Some of the easier problems have been solved...eg: The
client comes with generic background sounds.
It's pretty cool, though.
Seeya,
Pete
morgen
: : And if there is a GNU (or other free) compiler for it?
: : Thanks
: There are at least three books on the market right now dealing with Java
: programming. Also http://java.sun.com/ has some documentation and of
: course everything you need to get started for some systems. There is
: also an implementation for Linux (requires a fairly new Linux).
You can get the Java Development Kit at java.sun.com.
Thye have the compiler (javac) for WindozeNT and Solaris.
There is a java compiler for Linux too.
Glenn Crocker
In article <49lp43$h...@sisko.dnaco.net> dba...@dnaco.net (Dave Bacher) writes:
From: dba...@dnaco.net (Dave Bacher)
Newsgroups: rec.games.mud.admin
Date: Fri, 01 Dec 1995 02:30:42 GMT
Organization: The Dayton Network Access Company (DNACo)
Reply-To: dba...@dnaco.net
aim...@digital.net wrote:
> I am interested in opening a VRML MU* game when
>the techology matures. I know VRML is the bleeding
>edge of technology right now. I was hoping for
>whatever information I can get.
>Thanx
I don't think this would be possible yet. The main problems are space,
bandwidth, and computer speed.
The space problem is self evident -- a VRML file plus a text description
(you'd need both, since VRML can't handle smell, taste, temperature,
etc.) take up alot of space compared to just the straight ascii text.
I don't see the problem, here. If I walk into a room, watching my
modem lights, I see them blink, then they're idle. If I were
downloading a VRML file with that spare bandwidth, I wouldn't mind.
MUDs are not currently bandwidth-intensive in the least (except for
the server, but that's not the main problem, it's all those 14.4k
modems. As long as they're happy, assume the server can have a T1
or somesuch).
The bandwidth problem is what causes lag. You've got xxk of data
waiting for player x. You've also got xxk of data being stored for x
other users. In addition, you've got to do some amount of computation
to determine the xxk of data that is supposed to be sent, and which
players are supposed to receive it. When too much time is spent
computing the data, or sending it, that has to come from somewhere. The
connection between the host and InterNet is a slowpoint in the link,
even with a T1, and this link would be severely stressed.
On what data do you base this? I guess I'd just like to see you do
the math instead of waving your hands around. I'll start:
I'm going to use an example which has been implemented. In this room,
we have 2 VRML files (it really should be 3, but this is how it is
today):
filename size compressed size (zip)
---------------------------------------
board.wrl 12815 2238
queenbig.wrl 21572 4322
monotex.jpg 13127 (13127)
woodtile.jpg 17311 (17311)
wood1.jpg 3851 (3851)
marble.jpg 5132 (5132)
---------------------------------------
Total 73808 45981
(The scene is a simple room with textures on the walls, a
wood-textured table, 2 chairs, a marble-textured chessboard, and 8
Chess "queens". The queens are LODed, which means that there are
several (5 or so) versions of them, and you see different versions
based on how far away you are, so you can get a simpler version when
you're too far away to see lots of detail anyways.)
Let's assume that folks get about 1k/sec with their 14.4k modems. I
usually get 1.6k, but there's HTTP overhead, etc. so I'm willing to
estimate pessimistically. Now, when I walk in the room, I get a text
description and start downloading board.wrl. It has the references to
the other files, so I can't start them yet. 2.2 seconds later, I can
start drawing the scene with no textures and no queens on the
chessboard. I start downloading the rest of the files, and 44 seconds
later, I have the whole thing. As each of them is completed, it can
be displayed in the scene, so we get a kind of iterative improvement
of the graphics. The queens appear on the chess board, the marble
texture of the board appears, the wood on the chairs and table is
displayed, the wood tile on the floor appears, and the wall texture
appears. If I'm here to play N-queens, the 3d interactive game in
this particular room, I'm probably going to stay longer than 44
seconds, so I figure this is small enough.
Now, if I walk into another room and it refers to one of these
textures, or the queens, they're cached, so they'd be displayed
immediately, and if I walked back into this room, I'd see the whole
thing immediately. Depending on the mud and player type, you're
either going to have lots of repeating things (trees in forests, wall
textures in tunnels), or a bunch of people sitting in rooms chatting.
Some players are explorers, and those folks will probably have to do a
lot of downloading. In the mud where this room appears, users have
usually seen all these textures already, so they'd only have to
download the 2 VRML files, for a total of 2238+4322=6560 bytes, or
about 6 and a half seconds total.
To make that downloading go smoother, we could use prefetching. The
idea is that when I'm sitting in a room, the server looks at the
probability that I'll go through each of the exits, and tells my
client software, "There's an 80% chance you're going north next". The
client can start the download for that room if the link is idle so
when I go north (just like 80% of the people who go through here), I
get the graphics immediately.
I'm willing to assume that people move about every 10 seconds, since
most mud rooms take me that long to read. Sure, sometimes I blur
through rooms that are just on my way somewhere, but I'm not wanting
to see them anyways. Based on this, I'd say that any room under about
10k bytes is probably okay for a user on a 14.4k modem, and based on
my experience with VRML, 10k is enough for a reasonable room.
All of this is implemented and shipping, free, in Pueblo:
http://www.chaco.com/pueblo
The computer speed issue has to be addressed also. You've got some
players who are on SGI OpenGL 3d Terminals, and flying along at several
million polygons a second, then you've got the moron who has Win95
installed on a 386 with a Trident VGA card, and is ploding around at 5
polygons a second. You have to keep both of these users relatively in
sync (pretty easy), and you've got to keep the display on both systems
as accurate as possible.
That's certainly a potential problem. You just have to decide what
you can safely assume your user base has. People who are writing
games for PCs today assume you have a Pentium 75, for high-end 3d
stuff. (Actually, I know of 2 3d games being designed for P90s, but
those won't ship until March or so.)
I do not believe VRML is appropriate for this. Like HTML, it has the
potential to cause bandwidth problems if you attempt to use it this way.
Ideally, you want a tightly compressed binary format designed
specifically for MU*'s. This format would be designed to store alot of
the repetetive data on the users side. This would include sector maps,
etc.
Oh, yes, let's reinvent the wheel! It's no use at all leveraging off
of the 3d modelling packages which can output VRML. Nahhhh. Besides,
I'm sure we mudders could come up with a much better 3d format than a
bunch of inexperienced SGI employees and their buddies on the 'net. ;-)
I've been using TrueSpace and Fountain to generate VRML, and I'm very
impressed. It's worth being compatible with these great tools.
This would probably reduce the throughput to the point that it would be
possible to do a 3d MU*. The next logical step would be sending
'objects' for actors to the clients, and then sending movement commands.
If done correctly, this would also reduce throughput requirements.
Compressing the VRML does most of what you're wanting, really. You're
right about the need to be clever about motion, but that's a fairly
well-understood problem. Just ask the netrek folks.
-glenn
--
Glenn Crocker gl...@chaco.com Light bar not for occupant protection
VP Engineering Do not touch the len
Chaco Communications Do not taunt happy fun {ball,Chet}
http://www.chaco.com/ Check out Pueblo, a 3d mud client
David Bennett
> The space problem is self evident -- a VRML file plus a text description
> (you'd need both, since VRML can't handle smell, taste, temperature,
> etc.) take up alot of space compared to just the straight ascii text.
>I don't see the problem, here. If I walk into a room, watching my
>modem lights, I see them blink, then they're idle. If I were
>downloading a VRML file with that spare bandwidth, I wouldn't mind.
>MUDs are not currently bandwidth-intensive in the least (except for
>the server, but that's not the main problem, it's all those 14.4k
>modems. As long as they're happy, assume the server can have a T1
>or somesuch).
Its all the links inbetween. Even a T1 link is not infinite. However,
I think it is fairly safe to assume that either the mud or the player
will not be connected to a T1 link. You could quite easily asume
there are going to far lower bandwidth thingys in the middle. This
will just cause even more lag. Just look how much damage to the speed
of the net www clients have made...
>I'm going to use an example which has been implemented. In this room,
>we have 2 VRML files (it really should be 3, but this is how it is
>today):
> filename size compressed size (zip)
> ---------------------------------------
> board.wrl 12815 2238
> queenbig.wrl 21572 4322
> monotex.jpg 13127 (13127)
> woodtile.jpg 17311 (17311)
> wood1.jpg 3851 (3851)
> marble.jpg 5132 (5132)
> ---------------------------------------
> Total 73808 45981
>(The scene is a simple room with textures on the walls, a
>wood-textured table, 2 chairs, a marble-textured chessboard, and 8
>Chess "queens". The queens are LODed, which means that there are
>several (5 or so) versions of them, and you see different versions
>based on how far away you are, so you can get a simpler version when
>you're too far away to see lots of detail anyways.)
Ummm. 45k, say 40 players online. 45*40 to enter a room? How
often do people enter rooms on muds?
1.8meg for all the players to enter your room.
>Compressing the VRML does most of what you're wanting, really. You're
>right about the need to be clever about motion, but that's a fairly
>well-understood problem. Just ask the netrek folks.
VRML is probably the best current solution to a 3d mud or whatever.
I can forsee the death of the internet :)
Bing,
David.