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

[Ola Fosheim Grøstad <olag#ifi,uio.no>]

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.

>         Do you actually get much on paper?  I find I get a bit then decide
> to go implement because I do not know how this or that will work.
> Probably just immaturity in designing multiuser servers.

Well, as I don't cooperate with anybody I don't go for any formal specs, but
use my own notation down to a level where I feel assured that I will manage
to implement it. Getting a lot down on paper wouldn't help me much and
changes would be difficult to make. There will be changes when I get down to
implementation anyway, so I don't feel like spec'ing out things which I can
easily determine or sketch out when I code. I make a lot of sketches of what
is going to be presented to the user though, which I find very helpful. And
write down lists of what is going in and what is going to be delayed to
future versions etc. For formal design, I like to keep it on a few sheets so
I won't hestitate to explore other design possibilities, but more
importantly the specs should function as a mental map for me.

Yeah, I implement, mostly things that can be separated out, or things which
will have serious impact on the overall design and which I am not sure if I
will manage to get right, or just plain stupid lust.  Although this gives me
a better feeling for the possibilities, it has proven to be wasteful as
there is a lot of uncertainty and I will go for generic solutions which add
overhead to implementation and API.  Meaning, there is less room for making
assumptions which costs.  The client and the client/server split is what I
find most disturbing in this low-level simulationist approach. Although it
is potentially rewarding when you first get it rolling, there seems to be 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.

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

> [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?

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.

The Palace provides applet access btw.
--
Ola Fosheim Groestad,Norway      http://www.stud.ifi.uio.no/~olag/



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