Re: [MUD-Dev] Custom Server Roll Call?

[Marc Hernandez <marc#ias,jb.com>]

On Tue, 11 May 1999, Ola Fosheim [iso-8859-1] Grøstad wrote:

> Marc Hernandez wrote:
> > On Sun, 2 May 1999, Ola Fosheim [iso-8859-1] Grøstad wrote:
> > > basic reason for this is that I realize that I want to make it accessible to
> > > handicapped people, to blind people and others who cannot easily use many of
> > > the newer inherently graphical systems.  Which pretty much rules out the
> > > hardcore simulationist approach which I have been following so far.  So, I'm

> >         Hmm.  Why would accessability have a dependancy on game mechanics?
> > You still have objects and such to do stuff with I assume.

> Heh. Well, the trouble is that those objects would provide very inane
> descriptions. It has different kinds of particles, but they are fairly low
> level. Basically the system wouldn't know the difference between a tree and
> a bush, not to mention what a path is. It wouldn't be able to distinguish
> between stones, a fence or a monument like stonehenge... The very close
> relationship to spatial layout is another problem.

<whats on paper snipped>

> [bottom up approach has a] larger initial cost with this approach than
> with a top-down approach. In the
> top-down approach most concepts can be nearly empty, but with the bottom up,
> everything has to be in place: collision detection, physics,
> significant-change-detection, caching, rendering... Because of the larger
> amount of data, dynamics and spatial layout efficiency is an issue that I
> haven't been abel to convince myself to ignore.

> One of the bad decisions was, I think, to insist on only using FREE software
> for the project. I probably could have got a lot of slack with commercial
> rendering solutions, a real IDE etc. Had I started today, then I certainly
> would have considered using Java for the client. With 1.2 caching and a lot
> of other stuff seems to come for free. I am basically tired of reinventing
> the wheel, something which is hard to avoid when doing a graphical MUD in
> c++/x11. Java sound support sucks though.

	In my system I am using Java for the server.  The client currently
is just standard telnet (actually I did not fully support the telnet
protocol (ok not at all)) so it is an even lower level.  With the way my
plugin client support is adding a proper telnet client would be fairly
easy.
	Sound support for java got a bit better under 1.2 (or 2.0 as it is
now called.  Amazing it is not Java2000).  

> > anything.  It is currently 2500 lines, supports persistant objects and
> > users and allows talking.

> 2500 is just slightly more than I what I need to open a window and implement
> core mechanics for xlib. Sounds nice! :-) X is arcane. :(

	I just went over some X programming.  It is a bit tricky.  Much of
the stuff I did was under GTK or Motif.  Much easier.

> > [1] I think java makes an excellent server (and client) base.  I like
> > writing stuff in the language (I used to hate it).  Compiling other
> > languages to java byte code is not too difficult.  It is slow, but using
> > distribution can help relieve that (and IBM AS400's have very good
> > benchmarks on running java byte code due to some architectural reasons).
> 
> Do you use any particular development tools (Integrated Debugger Editor)?  I
> find both emacs/c++ and emacs/java to be rather annoying (haven't done much
> in java, only some graphics).  I enjoyed the free c++ editor xcoral for a
> while, except for the lack of undo, so I basically ended up using emacs
> anyway. What are the alternatives?

	You can get some pretty good emacs files for either c++ or java,
or write your own.  I currently use microsofts Dev Studio with Sun's javac
compiler.  The only thing it does not allow me to do is double click on
the error and go directly to it.  With a little hacking that could be done
but it is not too difficult.  I am moving to emacs soon, but I do not have
it setup yet.

> Another question.  What are the security restrictions on applets in Java
> 1.2?  Are you allowed to receive datagrams from other servers than the one
> you downloaded the applet from?  If not, then I really don't see how Java
> can be useful, because then there would be one server being bogged down with
> downloads. Or you would have to use many servers as entry and communication
> points. What I want to do is to let people initially access the applet from
> a regular local web server and then connect to my remote server using udp.

	Actually I plan on using Java applications for the client.  The
server is currently an application.  This has no security restrictions.  
	As far as the client is concerned, I had a friend that is a very
good java programmer and his experimentation showed that getting good
frame rates out of browsers is very difficult.  Additionally even if you
get one browser to work quickly, it tended to break another.  We came to
the conclusion that since:
The user has to download everything anyway.  Why not put it in one easy to
install zip?
With applications you have a smaller set of variables to deal with.  
Applications can easily do things applets cannot including connecting to
anywhere and writing to disk.
Sound is finally loadable off of disk.  Java sound support is not.  I do
not even know why they say they have an 'api'.  

Marc Hernandez
5 billion neurons can't be wrong.



_______________________________________________
MUD-Dev maillist  -  MUD-Dev#kanga,nu
http://www.kanga.nu/lists/listinfo/mud-dev