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 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 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). -dak -- +---------------------------------------------------------------+ | 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