[MUD-Dev] Scripting languages

[Mark 'Kamikaze' Hughes]

Mon, Jun 30, 2003 at 01:08:46AM -0700 in
<20030630080846.13136.qmail at web21309.mail.yahoo.com>, sanxion
sanxion <sanxion2002 at yahoo.com> spake:
> Monday, June 30, 2003, Mark 'Kamikaze' Hughes said:

>> There's four approaches to doing scripting in Java.

> Thanks for your tips. How would one go about using these scripting
> languages? Is it common to read them on startup and store them in
> memory? I imagine for NPC scripting they will contain lots of
> conditions, i.e. what to do if someone enters the room or someone
> picks up an object. It would be cumbersome to interpet a script
> file whenever something happens?

It depends on how your engine works.

The most important thing is to tightly partition your scripts in
callbacks (aka "listeners", "event handlers", etc.).  A big general
"doTurn" script is going to be slow and hard to write.  An
"afterDrop" callback that only activates when someone drops an item
nearby takes better advantage of the native code, and is much easier
to implement slightly differently on each of 500 mobs.

Hephaestus 1.0 read in the entire adventure script including all of
the event callbacks at startup, because it's a design-up-front CRPG.
In exchange for a slight startup delay while the user watches the
title screen, there are no delays in the game.  That's a good
solution for a Diku-like engine, but not for most dynamic new-style
MUDs (when even Circle has OLC, you know things have changed...)

In a previous GMUD engine I wrote, callbacks contained the filename
of the script, it loaded scripts the first time they were invoked,
and checked the timestamp each time after that to see if it needed
to reload, because it was disk-based.  That introduced some lag on
the first time in an area since a reboot or edit, but once loaded,
it was fast.

Most scripting languages have simpler syntax than Java, C, Python,
or Javascript; if you use one of the lighter languages, they'll
parse and load quickly.  After that, just make sure you cache the
loaded script object.  More complex schemes involving age checking
to clean out little-used scripts can be tacked on when you start
running short on memory...

Invoking scripts is extremely cheap in every scripting language I've
looked at.  Hephaestus normally runs several dozen callbacks in a
turn, and it was a negligible cost even in 1.0 with Minimal, which
was far from optimized.  Hephaestus 2.0 uses reflection to look up
callbacks, and can make enormous numbers of calls faster than the
user will ever notice.

I tend to write a lot of general-case code in the core engine, and
then put only the special-case stuff in each callback; if necessary,
I'll make multiple callbacks for different parts of the same action
(checking ammunition, then firing, for instance) rather than have to
implement core functionality over and over in the scripts.

One of the best resources on how to build an object and scripting
system is the Inform manual <http://www.inform-fiction.org/manual/>.
While it's for a single-user text adventure system, and Inform's a
strange little language with scary syntax, the design philosophy is
brilliant, and it shows exactly where you'll need those callbacks.

--
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev