[MUD-Dev] Graphical MUDs

[Cynbe ru Taren]

Michael Hohensee <michael at sparta.mainstream.net> notes:

| Has to do with client
| renderers, and stuff like that.  I'd be interested to find out if anyone
| else has done any thinking on the subject, and if so, whether I've
| missed anything.

My thinking so far has been that graphics muds have
all the problems of text muds, plus lots more (such
as serious performance and synchronization issues,
which can largely be ignored in the text setting):
 I'm kind of hoping to hold off on graphics stuff
until a decent solution to text muds can be found :)

As far as graphics specifically:  I won't claim to
be an expert, but I -did- spend a decade employed
doing GL graphics on SGI boxes, plus I've been
writing a mudserver for the last five years, so
I've had a little time to think about all this. :)
  I think you clearly want GL/ActiveX level graphics
for interactive stuff for the forseeable future, but
that it would be nice to have the option of running
off stills using POVray or (better) Renderman.  (Note
that BMRT makes Renderman available free on Linux,
even if source is unfortunately not available.)
  I think one clearly wants to plump for procedurally
generated world geometry rather than the currently
popular static polygon databases, more or less for
the reasons you suggest.
  A procedural world definition also makes it
significantly easier to output either GL-level
polygon definitions or Renderman-level surfaces,
so as to support both nice interactive worlds
and nice stills.

As a practical matter, I think you should look at
the emerging 3D binding for Java: 
 http://java.miningco.com/
has a pointer to the 0.98 spec and an unofficial
implementation.  IMHO, the ubiquity of Java-enabled
browsers and the gigabucks of development money
going into Java make it a tide you want to swim
with rather than against.  At least, unless you have
a few gigabucks to throw at your alternative client
design... :)

 Cynbe