[MUD-Dev] Virtual machine design

[Hans-Henrik Staerfeldt]

On Sat, 17 Apr 1999, Ben Greear wrote:

> "Felix A. Croes" wrote:
>=20
> >  - Programmers cannot crash the mud.  Nothing as silly as dereferenci=
ng
> >    a NULL pointer is possible.
>=20
> 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.)
>=20

>From experience; This is the very best feature of an internal language.
You can extend a rather advanced programming language for the players to
use, and extend the game with, but they will never be able to crash the
server, but the individual (simulated) threads of the user applications
(scripts if you will) will simply be discontinued, and a log will be
forwarded to the programmer of the conditions of the crash.=20

As for the complexity of the language; it would be easy to make a
'script template' in most any 'more complex' language that can be=20
followed without any problem by an inexperienced programmer, so they can
be show 'how it is done'. More complex extensions would ofcause require
some programming experinece. What have been done on the server i've been
working on is to make documentation and working examples of some standard=
=20
things, that the players can use as examples.

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

Yes, such inter-dependencies should be a focus in the language constructs
and the way the modules work. Then your development focus is now how the
game-items influence eachother, rather than if they are stable and cause
the game to crash.=20


Hans Henrik St=E6rfeldt   |    bombman at diku.dk    | work:  hhs at cbs.dtu.dk=
      |
address:                |___  +45 40383492    __|__       +45 45252425   =
  __|
 Dybendalsvej 74 2. th, | Scientific programmer at Center for Biological =
    |
 2720 Vanl=F8se, Danmark. |  Sequence Analysis, Technical University of D=
enmark|




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