Re: Scripting System..

From: Daniel A. Koepke (
Date: 12/03/02

On Sun, 1 Dec 2002, Patrick Dughi wrote:

> These games were usually set in what we might think of as a zone in our
> muds - about 40 rooms, maybe 30-40 items, and perhaps only a dozen
> different living things.  Of course, the majority of the game relied on
> a very substantial scripting system.

Zork I was 110 rooms and 60 items.  It was implemented entirely in ZIL, a
proprietary LISP dialect, and compiled to bytecode that ran on a virtual
machine.  (A fact that's quite entertaining when you consider all of the
marketing hype around Java and Sun's, "write once, run anywhere," slogan.)
There was no scripting system.  On the contrary, Zork was monolithic -- to
borrow from our vernacular, it used spec procs.

> How many of you have had builders burn out just making zones?  Now you
> want them to put five times the effort into it to make it alive with
> scripting?  You need to make it easy for them so they can finish.

Perhaps we're seeking a technical solution for a human problem?  Lethargy
seems more a product of choosing the wrong people and not having the right
ideas.  Too many people mistake ambitions for ideas.  We suffer a great
many of the sort who set out with a feature list, rather than a design; a
set of goals, rather than a set of ideas.  Worse yet, we see goals
achieved via back-formation: "I have 9 races and 20 classes, I just don't
know what they are, yet."  That's almost always an indication that there's
no real creative direction to the game.  Once you have a solid design, you
can get people behind you.  And then the trouble is *finding* them.

> That implies running it in a circle-specific sandbox, and that would let
> us safely test the code as well.  This should be in point 3 ....

This implies good static anaylsis.  And strong typing.

> Frankly, the object oriented style is just procedural style tucked
> inside little boxes.

Superficially, yes.  You can, after all, write object oriented code in a
procedural language.  Marketing types were surprisingly accurate in their
use of "paradigm shift" for once.  OOP is a different perspective on the
same ol' system.  The new point of view provides for different and, quite
often, more powerful abstractions than what the procedural methodology

> This is all too hard for the neophyte programmer/builder.

OTOH, mudders are intimately familiar with the concept of issuing commands
to control an entity in the game world (their PCs).  It's not a large leap
from there to OOP.

> I have to look up the keyword, I have to remember the syntax for
> variables, I have to remember how to compare things which may be
> numbers, vs. things that might be words.  Most important, I need to know
> the syntactic sugar to make my block 'go' - where the curly braces and
> parens go.

I abhor the concept of "beginner" programming languages (except Logo, but
that's different), especially those that propose to make programming
easier by simplifying (or Anglicizing) syntax.  As I see it, the major
problem beginning programmers face are conceptual, not syntactical.  The
brain loves repeating patterns; programming language syntax is nothing if
not repetitious.

This leads to an alternate theory about why a visual programming system,
like the one you propose, is a winning idea (and has been every time some
smart person has hit upon the idea): it's not because it removes the
burden of syntax from the user -- that only saves some tedium -- but
because it allows the neophyte to visualize (or, better, be shown) the
structure and flow of the program in a simple, high-level way.  I imagine
that once trained on such a system, the user would be quite capable of
picking up a reasonable language's syntax in a few days and be just as
competent a programmer.

That brings us back around to your rather astute observation that
sometimes the way the language's packaged matters more than what it's
really like.  Here, I see no reason not to slide some existing language
under the hood.  If we're going to imagine a graphical front-end for
visual programming, we can also imagine that this program would be capable
of walking through the graph created by such a program and performing all
of the static analysis we need (and can realistically perform).


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT