[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=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
>=20
>         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.

>         Do you actually get much on paper?  I find I get a bit then dec=
ide
> 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 mana=
ge
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 c=
an
easily determine or sketch out when I code. I make a lot of sketches of w=
hat
is going to be presented to the user though, which I find very helpful. A=
nd
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 whi=
ch
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 a=
dd
overhead to implementation and API.  Meaning, there is less room for maki=
ng
assumptions which costs.  The client and the client/server split is what =
I
find most disturbing in this low-level simulationist approach. Although i=
t
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 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.

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

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

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?

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.

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



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