[MUD-Dev] MOBPROG and other scripting languages

[Lazarus]

On Sat, 12 Jan 2002, J C Lawrence wrote:
> On Sat, 12 Jan 2002 13:11:34 -0700 
> helpsfamily  <Acius> wrote:

> There are dozens (literally) of readily available (mostly)
> agreeably licensed scripting languages out there from Lua to
> Python, Perl, lisp, scheme, guile, Java, C#, ARC, E, TOM, Tcl,
> Ruby, Cecil, Eiffel, AspectJ, Squeak, YoYo, and others.  Range of
> choice is not the problem. Determining exactly what the problem
> you're trying to solve with a scripting language, and then what
> the criteria, desirable qualities, and constraints are for the
> scripting solution you will choose is the problem.

Isn't this true about all engineering problems?  The issue is rarely
the number of solutions, but rather the most appropriate solution
for the problem?

> Who is going to use the scripting language?  To do what?  With
> what access and use methods?  What are the security constraints?
> OO desired or not?  Security constraints?  Performance concerns?
> Runtime morphic?  Reactive only or self-automating (ie runtime
> limits)?  The list is long and many flavoured.

Good list of questions.  His introduction does answer several of
them. As I am sure you are aware, mobprogs are a custom interpreted
scripting language included in Merc 2.2 that provides no OO
structure, very limited security, used by all builders crafters on
the mud as well as some players where the author of the mobprogs
claimed his scripting was even faster than hard c..  Perhaps your
role of a facilitator in this subject in asking him to flesh out his
requirements will help all parties better understand the issues he
faces.

> Happily, its a problem that is subject to standard engineering
> analysis.

As are most (if not all) topics discussed on this forum :)

The thing that mobprogs bring to conventional hack and slash muds is
a tight integration into the game system allowing area builders the
ability to extend the hard code methods without access to the base
implementation code. There are no general purpose methods, only mud
specific methods.  While getting a script like

  if self.str > oponent.str
    send_to_room self.name + " pushes " oponent.name + " to the floor"
    oponent.position = POS_SITTING
  else
    send_to_room self.name + " bounces off " + oponent.name
    self.damage(100)
    self.posion = POS_SITTING

to work in mudprogs is trivial, presenting the mud environment to
python, lua, ... any of the volumous list of scripting languages
presented ...  sufficiently to allow the implementation of that
simple idea is non-trivial.  Fortunately there are attempts at
automating to create the wrapper functions to bind C objects to
python objects and potentially other scripting languages.
Unfortunately, none of the attempts I have reviewed are self
sufficient(http://www.swig.org/ being the first one that comes to
mind). All require some hand modification of the methods after
automatic generation making the addition of new methods to the
underlying code base tedious.

For my needs, the ability to access ALL fields of ALL objects in the
game (where the word objects is used in the OO sense and not the
game sense) from a single definition of the object in both the base
implementation language and the script language becomes the most
technically challanging requirement.  It becomes slightly more
challanging when you have a pre-existing game in the base
implementation language that you wish to minimize changes to.

Beyound that, do you like begin .. end to define blocks or { } or
various numbers of white spaces?  I suppose that becomes more a
matter of taste.



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