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

[Koster]

From: Brian Hook
> 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?

> Well, that depends on what you want, right?  The more you have in
> a dynamic scripted environment the more customizable the game is
> by non-programmers, and you should be able to do "hot fixes" by
> dynamically reloading scripts on the fly.

I've been following this discussion, and I just want to play Devil's
Advocate here. I say that because I am a huge proponent of
scripting, but I've been bitten hard by it several times

Scripting is hard. We don't like to think of it that way, but it is.
This echoes an old debate from years gone by, when people would
frequently compare the LP and Diku codebases. There's a reason
there's more Diku-derived muds out there, and it's because it's
easier to develop content for systems that don't give you
scripting. Scripting is basically a great length of rope that you
can do all sorts of cool things with, but also lets you hang
yourself.

Some of the key temptations that scripting can lead you towards:

  - custom-crafting content with scripts rather than having content
  fit templatized data formats

  - allowing development of systems by novices that call for a high
  level of technical skill

  - scripting typically doesn't come with the profiling tools that
  code does, so it's easy to create CPU-sucking scripts

There's more, but it boils down to the fact that I disagree with
Brian here. The game that is most customizable by non-programmers
isn't the one that is scripted. It's the one that has the best
fill-in-the-blank system. Making tables more robust tends to avoid
all of the above problems.

The one that is really killer is having your main content pipeline
running through scripts. I speak from experience. For example, it's
a lot easier to fill out reset tables than it is to deal with a
spawn script that gets attached to objects.

My personal take on it is that you should have a robust scripting
engine that can do anything in the game. Then you don't let most of
your imms use it. Make the main content pipelines be data-driven as
much as possible, and in fact, the more rigid they are, the more
content you'll get. Burn the flexibility where you really want it,
but don't give people overly complex tools for the problem they need
to solve. Most of the problems in muds can be solved with simple
tools.

As a concrete example--I'd much rather hardcode the basic combat
engine, and provide script hooks to embellish its behavior, than
code the basic combat engine in script. It'll just lead to more
people touching it than you want, more cruft being added to it, and
odds are, you don't need the basic combat system to change that
often once you get it nailed. Plus, you'll want the speed anyway.

You can ameliorate these issues with management. But you could also
just not create the management problem in the first place.

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