[MUD-Dev] Programming Languages and I/O Algorithms

[Sasha Hart]

[Ben Chambers]

> Which language is prefferred for mud design?  C/C++ provides speed
> but Java adds a lot of flexibility.

I assume you mainly mean server-side (it seems to me that more
concerns come into play client side), and I don't know what kind of
interface you are looking at.

Look into system resource use. My text game is in C because I plan
on using cheap hosting (for various reasons), because the complexity
of the job is not fantastically great, because I horde cycles for
various reasons.

If I had a nice reliable connection to just sit on, I would just
choose a language which was beautiful to me and which allowed me to
optimize bits in C and do everything in that. This is according to
taste, but I have really liked hammering out little proof of concept
and simulation apps in Python. If I were not greatly concerned with
performance, or if I really hated C (I actually rather like it), I
would use something like that.

Certainly if you get many replies to this I imagine many will argue
that C++ has everything you need. Personally I don't find it more
fun to write Java than C++, even though Java is (arguably) more
rational.

Note that some features like GC can be used as library bolt-ons and
so forth, if that is why you are looking at Java. Sometimes this
means notational sacrifice, though. :) That can be a big deal - this
is your working environment for at least a few hundred hours. If you
really want Java and you have the headroom to do it, why not do it?

> Furthermore how do most muds handle incoming commands in order to
> minimize lag?  I was thinking some sort of queue sorted by
> criticality of the type of event, but then you have to pre-process
> all the events and sort the queue which then creates lag in the
> process.  What are some common solutions?

I have found that text games deal with lag primarily by design
devices, not technical ones (e.g., client-side prediction). Slowing
down combat, making character semi-autonomous, etc. My favorite
solution has been to make gameplay pervasively predictive - more
like designing a machine to resist transient stresses, and repairing
and improving between stresses, than acutely reacting to one thing
or another. But there are many reasons not to be satisfied with that
and to attempt more technical solutions, among them that you need a
fairly bizarre game model to do it without being completely awkward.

About queues. The abuse of the approach doesn't make it the wrong
approach. Just because piecing through things ahead of time can take
a little overhead doesn't mean it won't save you a ton more later.
I finished making decisions about this stuff a while ago, but there
is a lot of information on the list archives and much more outside
them.

The personal reason I have not gotten into heavy queuing _as an
approach to lag_ is that it complicates the interface greatly, which
I have taken as a great problem highlighted by the fact I'm using
text. In one's own life, one does not typically deal with queuing
outside dealing with certain appliances. So to impose such a task on
a game which presents itself more or less as moving around in a
world is very artificial (to me anyway).

Sasha











_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev