[MUD-Dev] Custom Server Roll Call?

[Marc Hernandez]

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

> Marc Hernandez wrote:
> > On Sun, 2 May 1999, Ola Fosheim [iso-8859-1] Gr=F8stad wrote:
> > > basic reason for this is that I realize that I want to make it access=
ible 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 mechani=
cs?
> > 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 lo=
w
> level. Basically the system wouldn't know the difference between a tree a=
nd
> 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 softw=
are
> 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 certainl=
y
> would have considered using Java for the client. With 1.2 caching and a l=
ot
> of other stuff seems to come for free. I am basically tired of reinventin=
g
> the wheel, something which is hard to avoid when doing a graphical MUD in
> c++/x11. Java sound support sucks though.

=09In 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.
=09Sound support for java got a bit better under 1.2 (or 2.0 as it is
now called.  Amazing it is not Java2000). =20

> > 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 implem=
ent
> core mechanics for xlib. Sounds nice! :-) X is arcane. :(

=09I 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 usin=
g
> > distribution can help relieve that (and IBM AS400's have very good
> > benchmarks on running java byte code due to some architectural reasons)=
=2E
>=20
> 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 mu=
ch
> 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?

=09You 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 on=
e
> 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 w=
ith
> downloads. Or you would have to use many servers as entry and communicati=
on
> points. What I want to do is to let people initially access the applet fr=
om
> a regular local web server and then connect to my remote server using udp=
=2E

=09Actually I plan on using Java applications for the client.  The
server is currently an application.  This has no security restrictions. =20
=09As 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. =20
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'. =20

Marc Hernandez
5 billion neurons can't be wrong.



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