[MUD-Dev] Graphical MUDs

[Michael Hohensee]

Cynbe ru Taren wrote:
> 
> 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 :)

Heh, well, the kind of thing I'm describing would
just fall into place, if a good client/server system
is built. :)
 
> 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,

Sorry, you've lost this poor little fledgling coder 
here, precisely what are GL/ActiveX level graphics? :)

> 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.
 
That's what I thought.  Another thing just hit me,
since light sources are just objects, you could have
the "sun" change position over time.  *that* would be 
a spiffy effect.  One that is probably unmatched even
in the single-player graphical games.  Because all of
their images are pre-rendered, it seems unlikely that
very many "duplicate" frames are going to be made to 
simulate some detailed night/day activity.  While it's
trivial for this rendering system.

That's what's so attractive about it to me, a chance to
make a game that is *better* in some ways than commercial
products. :)

> 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... :)

Hmm, yes, I thought about writing the client in Java, since
everyone's got it, but there is the problem of efficiency.
Java, being such a high-level language, is not going to have
the same efficiency of some well written and optimized C code.
Especially when the client that I'm envisioning will operate as
a parallel database to the server...

I had considered trying to write it for X windows, but then balked
when I discovered that Motif costs something like $150.  *sigh*
perhaps Java is the only solution...  Ack, gotta go and learn a 
new language. :( :)

--
Michael Hohensee	michael at sparta.mainstream.net
"If all the world's a stage, I want to operate the trap door."
                -- Paul Beatty
http://www.geocities.com/SiliconValley/Heights/9025/