> > 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.
The ZIL code itself wasn't that large in comparison to a standard
area (world + rooms + objs + zone information). The interpreter, of
course, was where the majority of the action took place. Pretty scary
code in there, for the most part.
>
> > 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.
Hm.
I think that even if you have a solid design (be it backstory or
what haveyou relevant to building), you can't necessarily get people
behind you. I think around 95% of the builder's I've seen are crappy;
they have poor literary skills, their areas describe an inconsistent world
view, and worst of all - most abuse the player with jarring use of color
or text formatting. So drop those. The good ones aren't going to stick
around either; there are only a few that will spend 2-3 years working on
a mud with dedication, perhaps because their skills are so suited to doing
something that's more worthwhile.
Builder retension and zone completion are human problems, but
there are alot of technical advantages you can give an admin to solve
them. Anything that lowers the bar to entry is going to help, even if it
only gets another 2% of 'good ones' who would be put off by a seemingly
complicated system..
Here's a good example - Muds had reasonable popularity, but the
inclusion of graphics (Everquest, Ultima Online, etc) and the ability to
point and click where you wanted to go caused the popularity of what was
functionally the same exact game-type to skyrocket.
More people trying - at least - means there's a better chance of
getting a good one.
>
> > 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.
>
I'm okay with typing, though I think this could be taken care of
just as easily by default error handling.
Pseudo code:
"What's the cryped password of this mob?"
Pseudo error:
"Don't do that."
=)
>
> > 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
> affords.
>
> > 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 disagree. Issuing commands is understandable, but they don't
appear to be very entitity oriented. Instead, your entity (the character
object) is your static environment, and the rest is procedural. No to
mention that all previous systems (Zmud, others) operate in a strict
procedural manner. Not that we should do it that way because of them, but
rather, we're covering the point of what the user would be more familiar
with.
> > 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.
Syntax is not the major problem, agreed. Though beginner
programming languages have their place, they are still required (in my
book) to be as full featured as any other 'advanced' language. For
example, pl/sql is not a beginner's language - it's too hard to learn/use
for most without previous experience. Perl, on the other hand, you could
teach your mom the basics of in 15 minutes.
Funny enough, you can easily do much more complicated tasks with
perl than pl/sql.
>
> 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.
>
Actually that was my goal - the underlying language doesn't really
have to be anything special, it just has to have all the basic components
made in such a way to be easy to string together in that afforementioned
visual style. The visual modeler will be responsible for translating flow
charts (or whatever) into actual code.
> 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).
>
I agree with this entirely.
I'd assume that the onus is placed on the visual modeler to
generate the syntactically correct code regardless of what it looks like,
and that it's the responsibility of the code to provide us with facilities
for time sharing, debugging, error handling/trapping, and perhaps resource
control. Of course, this still allows for someone to write the code
directly if they so wish, so long as they're willing to learn the
language.
PjD
--
+---------------------------------------------------------------+
| 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