[MUD-Dev] Client Technology

Ola Fosheim Grøstad <o.f.grostad@notam.uio Ola Fosheim Grøstad <o.f.grostad@notam.uio
Sat May 6 23:18:38 CEST 2000


Jon Morrow wrote:
> Currently, I am deciding which programming language would support a GUI
> based client most effectively.  Portability is obviously a consideration,
> while so is development time.  For these reasons, I am pondering the
> potential of Java.  Massive calculations will not need to be made, but I am
> a little concerned about what I have seen in its speed with graphical
> components.  Low-interaction video and audio must be supported, along with
> the regular graphical controls like text boxes.

A Java applet is probably your best bet, if you can waste the time
needed to work out the quirks between different implementations or
settle on one initially. I have only rudimentary experience with Java,
but in my experience the library internals used in various browsers
seems to vary in unpredictable ways. This will lead to crashes or
defects if you try to get something up to speed, doing things in AFAIK
legal, but unusual ways. Hard to debug, not fun. I would personally
/prefer/ to develop using Java, I just don't see enough stability yet,
and I don't want to learn the quirks. As far as I am concerned it is a
client-side failure. I want to code, not debug. This goes for just about
anything that has to do with browsers, even HTML/CSS... :-(((

I am currently considering C++, qt and CommonC++, which is available for
unix (for free) and MSWindows and might possibly be available for other
platforms later. It seems easy enough for prototyping.  If you want
serious audio then I know of no usable portable alternatives.  Audio has
much stricter real-time requirements than video, so I think you are
better off by implementing the audiodriver separately for each platform
(unless you just want to play soundfiles, in which case you can just
call an external play program/library.). C++ is probably the most
open-ended path. If people are going to install something on their
harddrive then you may as well distribute a smooth optimized
executable...

Basically, I think the main issues are:  What language/toolkit is spoken
fluently in your team, is that language up to the task, how easy will
the result be to install. Don't hire someone that has never written code
in C++ to write a client in that language. Don't hire someone who does
not know the java libraries/quirks to write applets...

Maybe it would be better if several developers co-operated on a GPLed
C++ framework. I am certainly open for such suggestions!

Btw, does anyone know if it is possible to write a tcp/udp client in
shockwave?
--
Ola  -  http://www.notam.uio.no/~olagr/



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list