Sorry about the late response, I fired off a too-long-for-the-list
post right before leaving on a week cruise. Still, I wanted to chime in
on scripting systems, since they've been troublesome issues for a myriad
of reasons. Go get a drink or something, this is a long one.
----
Let me list what I've seen other people claim as their motivation,
since it appears everyone wants to talk about the neat tech details
without first figuring out whether or not those move them close to their
goals. Often times, people seem to forget that nagging thing called
reality while in pursuit of their idealized (idolized?) dream system. I
think a list will help seperate some of the ideas from the details. That,
and I'm easily confused so it helps me to write them out.
1. Create something that's easy for the non-programmer to use
2. Create something that will let me use language _X_
3. Make the system more fault-tolerant (I believe 'modular' was the word
used here).
Okay. In order, we'll start with #1.
1)
Have you ever played zork? Really, just about any infocom game,
before there were graphics of any sort? 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.
Tiny by our standards, and frankly, they blow away any mud zone
that I've seen. You know why? It's because they are well thought out,
integrated, designed, and tested.
What did it take to do that? I won't lie, it's mainly a matter of
time. You can be the greatest area designer ever, but if you are able to
pump out a zone of even 1/3 the quality of zork, it's going to take you a
month.
What does that have to do with the first goal?
It validates it. No matter how capable you are with any given
language, it would take 2-3 years just to rewrite the stock circlemud
areas with quality, non-repetitive areas that can genuinely add color to
your fantasy world. That means you're going to have to rely on others,
many others, and heavily, to do the majority of the work.
These people are going to need more creative talent than
programming talent. They're going to need an easy, intuitive system that
doesn't require that they memorize too many tables, commands, procedures
or the sort. They're going to need something that fits together like lego
blocks and snaps into place without thought.
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.
You also need to make it easy to test. You'll also need to make
it safe - but we'll cover that in point 3.
Frankly, I think this is not only a good goal, but it should be
the point of utmost importance. Who cares how spiffy your system is if no
one even has the patience to finish off a zone - and if you manage to, how
crappy does that make the rest of your world look, when there's only one
zone where people wave and say "hi."
2)
Selecting any one given language over another is a hard choice -
you need to weigh the advantages each gives for your intended system.
Memory allocation, processor usage are important, flexibility might be
required, and I'm sad to see that people so easily discount the incredible
advantage you can garner from simply using a common/familiar language -
even over one which perhaps suits the situation more exactly.
These points have been covered well enough though, so I don't have
to go over them for any given language. Instead, I'll discount them all.
This language is better than that language is better than this other one -
hogwash.
The 'best' language for the job would be one that's made
specifically for the job. Screw this external dependancy crap, or the
inclusion of multiple types of interpreters. That just makes for more
work without any regard to real world usage (like, getting it done in a
timely fashion, making it fast, easy to use, etc).
The fact is, there isn't any single 'real world' language which is
meant to be used by non programmers directly for the CircleMUD system.
DGScripts, and mobprogs before them were admirable for their focus, though
both still felt like they were just crufted on to the system.
Which they both were.
It also feels like they were difficult to learn, error prone, hard
to test, and in most cases, impossible to tell if you had even made a
syntax error.
So what do we need in a language?
The most important parts are the debugging bits - we need it to
validate syntax, we need it to never run in a loop, we need to
automatically recoginze divison by zero, etc, etc, etc. 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 ....
Next we're going to need a block-y structure. I don't mean object
oriented, though that's what alot of people may be thinking. Frankly,
the object oriented style is just procedural style tucked inside little
boxes. This is all too hard for the neophyte programmer/builder. You
need to make it blocky, like a flow chart - a "while" block, a "if" block,
a "run this command" block. Go ahead and apply whatever programming style
paridigm you'd like, but the basic functionality - variable access,
external procedure calls, and conditional flow control - all need to be
the most simple thing imaginable.
You may think that code like:
if(%actor.hits% > 255) {
do_crazy_dance(%actor%);
}
Is simple, but really, it's not. 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.
You may be a programmer, but the closest experience other users
have had with code was using frontpage to generate html for their crappy
goth poetry page.
I'm talking something that's compatible with a drag-and-drop
interface. Something so simple, your mom could do it.
That doesn't mean you can't have a coexisting, abritrairly complex
system, either seperately or as part of the whole - but look at the real
world use - the majority is going to be by novice-level programmers, and
by-and-large, the actions they are going to want to perform are going to
be the same, even if the results and playthrough are radically different.
Last, we're going to need saftey - and that will be covered
entirely in the 3'd point.
Sadly, that will be in the next (continued) message...
<CONT>
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT