[MUD-Dev] How much should be offloaded to Scripting?

Patrick Dughi dughi at austin.rr.com
Wed Feb 11 12:39:24 New Zealand Daylight Time 2004

On Tue, 10 Feb 2004 18:05:16 -0500
Dan Larsen <mortinmonikt at hotmail.com> wrote:

> Now, my question is this.  How much of the game should I offload
> onto my scripts, versus hard-coding it in the server?  If any of
> you are familiar with TADS (Text Adventure Development System),
> the language is comparable to that, which means I could implement
> my entire parser via script, as well as my world and interactions.
> Basically, my server could be totally ignorant of what a 'room' or
> an 'actor' or the command 'say' is.

No matter what others will say, it's going to be a judgment call on
your side based on information we don't really have.  If you're just
doing this as a hobby, where you're one of the only technical
resources, or it's a system which can be easily handled by a single
resource - perhaps there's not such a huge incentive to script

Of course, anytime you expect other people to provide content,
especially non-technical folks, the better your scripting system is,
and the more inclusive, the less you'll have to custom code.

> But does it make more sense, both architecture and
> performance-wise, to shift at least some of the logic to the
> server itself (written in C)?  For example, letting it parse and
> dispatch commands, the vast majority of which simply trigger
> script events.  This saves the scripting language from having to
> parse, and doesn't cost much flexibility, but it is limiting in
> some ways.

It _could_ save some, but what sort of scripting system did you
build where a script needs to be parsed more than one time?  In
fact, many scripting systems out there (for example, lua), allow you
to externally compile your scripts, which are then executed as
simple sets of hard coded instructions nice as you please.  I won't
lie and say it's as fast as native code, but it's reasonable enough
that you shouldn't worry about processing overhead from parsing.

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list