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

[Jim Purbrick]

From: Koster, Raph [mailto:rkoster at soe.sony.com]

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

This is really interesting. I often wonder what the "best" mix of
code, script and database is. Presumably in your mix the code knows
what the basic data structures populated by database tables are and
the database is structured in terms of these basic structures. Run
of the mill content just adds data to these tables, while scripted
content can operate on these structures to add extra functionality
where needed? This model taken to the extreme seems to be to write
all content in code and make sure that the game is extensible enough
by adding data, presumably tooling up this database update
pipeline. At the opposite end of the spectrum, would be a content is
script approach whereby scripts can define data structures for
different kinds of items which are just dumped in to a database as
tuples. The database becomes a persistent object store and the
tooling work goes in to making it easy to define new structures in
script and the scripts to run them. This approach seems to be
championed by the Dungeon Seige team. At either extreme things seem
easy to fathom, at your proposed sweet spot in the middle how do you
decide what should be script and what should be code operating on
data? Doesn't allowing content to be added either way dilute the
tools effort? How is the interface between code and script
embelishments managed?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev