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

[Brian Hook]

On Thu, 12 Feb 2004 17:38:50 -0800, Koster, Raph wrote:

> 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

There are implementation issues that can really, REALLY kick your
ass. Specifically, depending on the language choice, the
availability of tools, the ability to catch common (static) errors,
type checking, debugging, profiling, etc.

I'm using Lua, and it's a love-hate relationship, because stupid
errors that a typed language would catch are caught before they have
a chance to screw you up.

  function foo( a, b, c )
     ...
  end

  foo( c, b, a ) -- assuming these are different types, the compiler
                 -- saves your ass

or something simple like this:

  c.nname = "Davey Jones"

In Lua, that will just automatically create a new slot in the 'c'
table called 'nname', and that's not what you want.

This problem isn't specific to Lua, you'd run into something similar
with ECMAScript and other dynamic languages.  Lua also lacks types
and inheritance as a first-class ability.

That said, I still like it, and being able to edit/tweak a bunch of
stuff without requiring a recompile (or server restart) is very
nice.  Prototyping code is much faster as well.

Flexibility vs robustness is what it really comes down to.

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

Another way of looking at this is whether you want to be data-driven
or procedurally-driven (simulationist vs. emulationist I think are
the terms I've seen used).  I use a database back-end for everything
so by and large I'm data-driven, but I can selectively override
scripts if necessary (the overrides are specified in the DB).

> There's more, but it boils down to the fact that I disagree with
> Brian here.

Odd, how is that you disagree with me but I agree with you? =)

Scripting is dangerous and a pain in the ass at times, and it's not
the cure-all magical tool that some suggest, but it has its
advantages.

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

Well....there's a large body of work in mods for shooters that
demonstrates otherwise.  Fill-in-the-blank is easier, but it's
usually far less expressive.

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

Absolutely.  Scripting is not for everyone, and as I described about
Lua, it's freakin' dangerous if you're not careful.  I can trash my
server by loading a script that I didn't fully test -- I know, I do
it all the time.

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

I agree with that as well.

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

Yes.  So what are we disagreeing about again?

I would say that using a script to define mobs is absolutely the
wrong thing to do:

  function make_orc()
  {
     orc = new( "orc" )

     orc.x = ..
     orc.y = ..
     orc.name = "an orc"
     orc.hp = 20
     orc.faction = "orcs"
     .
     .
     .
  }

BAD BAD BAD.  I would never recommend something like that.

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

I'd rather prototype the basic combat engine in script, then
"harden" it by moving it into the kernel when it no longer needed to
be mucked with.  This is how I've been handling a lot of stuff, and
I think that works (on a one-programmer team, granted).

Prototype, harden, rinse, repeat.

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