[MUD-Dev] Virtual machine design

[Felix A. Croes]

Ben Greear <greear at cyberhighway.net> wrote:

> "Felix A. Croes" wrote:
>
>[...]
> > Lacking in power: may be true for some languages, but not necessarily
> > for all of them.  Some are powerful enough that you cannot just write
> > muds in them, but any sort of internet server.
>
> Yep, but once you reach this stage, I think the benefits of a more
> standard language (c/c++/java/whatever) outweigh a proprietary language
> that you write.  That doesn't mean that you couldn't write a perfectly good
> language for this sort of thing, but more that the effort you put into
> it may not be justified, compared to what you can do with an already
> written language/compiler/profiler.

It depends on how much importance you assign to the respective
benefits.  If the benefit of code that cannot crash your
server outweighs the advantages of C and C++, then C and C++
won't do.  If the benefit of multiple inheritance outweighs the
advantages of Java, then Java won't do.

It is of course possible to appropriate an existing language,
including compiler and profiler, for your mud server.

Suppose that, instead of developing your mud server from scratch,
you take one of the already existing ones and write your mud in
the server programming language.  Now your whole efford to gain
the advantages offered by this language is reduced to learning it --
a few hours, assuming that the language is sufficiently like
programming languages that you already know.  Right?


>[...]
> >  - Programmers cannot crash the mud.  Nothing as silly as dereferencing
> >    a NULL pointer is possible.
>
> So your internal language has no pointers?  I guess you could just
> crash the individual 'programlets' instead of your entire server
> if desired.  (By crash I mean abort abruptly, as the programmer
> probably did not want it to happen.)

What if a programlet in C++ decides to trash data at a random memory
location?


> >  - Any change can be made without taking the mud down, and takes effect
> >    immediately.  If necessary, it can also be instantly undone.  A well-
> >    run mud doesn't have to reboot.  This is particularly interesting
> >    for commercial muds, where downtime means loss of revenue and/or
> >    customer dissatisfaction.
>
> I wonder if commercial muds would do *any* development on production
> servers.  If your language is powerful enough to affect the game play,
> then it's definately powerful enough to affect it negatively!

Not development, upgrading.  And yes, commercial muds do this all
the time.

During the time that I played UO, the mud (and simultaneously, the
client) were upgraded several times.  At least one of these changes
was later rolled back when it turned out that the effect was not
quite as desired.  This was around the time that the new reputation
system was introduced.  All of the changes involved server reboots.


> It would be much safer to have multiple copies of the servers, one to
> develop on, and the other to host normal players on.

UO indeed has a separate development/test site.  Sometimes, a problem
will remain unnoticed until the code is run on a real mud :)


> >  - The mud can be made enormously complex without affecting the
> >    complexity and reliability of the basic server, which can in fact
> >    be smaller and simpler than what would be needed for even a
> >    medium-sized mud without internal programming language.
>
> This implies an enormously complex set of internal programs, which I
> would imagine would be just as hard to maintain as the normal server
> code, perhaps more-so because you also have compilers to deal with, and
> a non-standard language that your programmers must become proficient at.

It would be very much easier, considering that the code is written
in a high-level language.  Additionally, only the actual server
code could contain bugs that seriously affect the stability of the
mud, i.e. that cause the mud to crash or would require a reboot to
fix.

Regards,
Felix Croes


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