MUD Design Digest V1 #55

[Chris Gray]

:Somehow, that syntax reminded me of my elementary school days and LOGO.
:Just a random thought.

Probably just the names. The closest "main-stream" language to what I
use is probably Algol68, which isn't mainstream any more, and never
really was in the U.S.

:Hmmm. What do you _really_ send across? Surely not those text messages?
:Also, is this restricted to tile/polygon whatever you were demonstrating
:there? I'm playing around with undefined command transmission, for my GURU
:project, and one of the things I've discovered is that matrix burst
:transmission works very, very well for 3-D skeletal systems. I use a
:translation algorithm, in the form of a primitive matrix, a covariance
:matrix, and a secondary contravariance matrix, which reduces the needed
:bandwidth by a healthy margin. I then use a mod to the matrix in question
:to define movement rates... pretty much, linear algebra and calculus, with
:the computer doing most of the nasty calculations in advance. The lookup
:tree for the algos is actually designed to table joint types, and I've
:listed all of the known hinges I can find. Of course, this does mean I am
:limited to existing texture maps, but colors and skeletals I can transmit
:without any roblem in client compatibility. (I use multiple client types.)

All communications between my server and the custom client is done with
binary messages. Each message has a short fixed header, which includes
a message type and a tail length. Then, many of the messages have extra
stuff in the tail. E.g. an "rq_text" message from server to client just
contains a bunch of text to format onto the text window. An "rq_effects"
message contains a binary effects stream. They consist of a bunch of
effects operations, which consist of a one-byte effect code followed by
whatever parameters that effect needs, all in binary.

This was the natural way to do things on the Amiga, where the OS is a
multitasking OS based on message passing. A local client messages directly
with the server. Users on serial ports have an "agent" program which
is a go-between for a reliable serial protocol <=> AmigaOS messages. For
Internet connections, there is a pair (one for text, one for full binary)
of agent programs that go-between TCP/IP and AmigaOS messages. The custom
client can do any of local direct connections, serial connections or
TCP/IP connections.

My effects can be classified somewhat like this:

    - lines, circles, rectangles, polygons, etc.
    - sound output, voice output
    - on-screen "mouse buttons" and "clickable areas"
    - tile graphics (client caches tiles)
    - bitmap graphics from on-client files

Nothing high-level like your descriptions ... yet!

You lost me completely with your various matrices! Could you rephrase
that so that a non-math person can follow it? 3D graphics is not something
I've gotten into yet.

:Heh. Well, GURU is, and was, well beyond the scope of my understandign
:from teh very start. I do my components, and others do theirs, and we all
:hope that the dfact that we all understand the desired outcome allows them
:to mesh. No way I'm gonna let these discussions alter that project. As for
:my text mud... well, yes, damnit, this group HAS increased the work on it,
:but at least I know in the end, I will have a superior product for
:release, and future mud programmers will not have their programming habits
:mauled by working on Russ Taylor's ROM code, hopefully. I dunno how that
:extends to other mud types... I've tried to broaden the base, but still,
:it does have the same flavor I started with... vaguely mercish.

Well, you may have to work in a somewhat black-box environment, but at
least you aren't doing everything by yourself! There is something to be
said for mutual feedback in a large project.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA