[MUD-Dev] Re: Furcadia improvement

[Dr. Cat]

From: "Zach Collins (Siege)" <zcollins at seidata.com>
 
> I have found that DragonSpeak is easy to use because it has an
> editor; otherwise it is just Assembly for Furcadia maps.  A good
> editor (and yours is very good) can do amazing things for the
> usability of a language.

That's an interesting perspective, I had to stop and think about it
for a bit, because that's not the way I perceive it.  I can
understand where you're coming from, because DragonSpeak has a
number of design goals that I feel make it actually LESS appealing
to programmers, but more appealing to non-programmers.  Which I
think is an overall gain, since there are so many more
non-programmers in the world, and I've been able to get a bunch of
them scripting in my scripting language.

Control structures are absolutely as weak as a very primitive sort
of assembly language - weaker than most, you can't do a jump or a
branch or a loop or a subroutine call!  On the other hand, it is an
entirely event-driven language, which is not inherently true of any
assembly language I'm familiar with, but it is something that I
think is a lot easier for people to grasp and to work with.  I find
it nice to work with myself, since "when a certain thing happens in
the game, make a certain other thing happen" is really what's
important and fun and interesting to do, and not annoying like all
that wrapping and "window dressing" you need to make to even make a
Windows program do anything at all.

And the actual things you do are much higher level than assembly
language functions of accessing or modifying a register, memory
location, or port on an I/O device - an "atomic" operation in
DragonSpeak is more like playing a sound effect, changing a large
stone into a cave entrance, or moving a player to another spot on a
game map.  I suppose you could look at it as "an assembly language
with a collection of really neat subroutines".  But it might make
more sense to think of it as the "Furcadia Virtual Machine", which
was "wired" to have these high level interesting things as its
machine instructions.  (I remember seeing the Lisp machines at MIT
that were actually built to run Lisp as their assembly language -
I'm sure we'll never go that far with DragonSpeak though!  It was
1983, and they were around as tall as I was, with tons of
wirewrapping showing in the back.  I asked the bearded, t-shirted
hacker giving my dad and I a tour if they weren't an awful lot of
work to make when they wanted a new one.  He said the first few had
been, but then they hooked a robot arm up to one and taught it how
to help them make more of 'em!)

The design of that virtual machine is a very important part of what
makes the language so usable, appealing, and effective, in my view.
It's important for the "types of things users want to do a lot" to
be doable in just a few lines and easy to figure out...  And it's
also important for a significantly large minority of the ways you
could string together the "atoms" of the language to be meaningful
and do something potentially interesting or worthwhile.  The
majority of randomly constructed strings would still be useless
gibberish - but the percentage that are meaningful is orders of
magnitude higher than in a conventional programming language.  And
with a human creating the commands, and going with the many
contextual hints to actually TRY to create meaningful strings of
atoms, their odds are really very high of success, which is
important for novice scripters.

I'm also very proud of the way the core structure of the interpreter
is designed from the ground up to run in a nicely distributed
fashion, keeping multiple machines synched over a WAN while running
synched copies of the same world-state and same script, with (in
most cases) very modest bandwidth usage that won't overload a dialup
modem.  That's another thing that you don't find in a typical
assembly language.

I will agree though, in terms of raw power, control structures,
etc. it falls far, far short of C, Perl, Pascal, BASIC, even
Fortran.  Or most any other language you might care to name.
(Python, anyone?)  This is by design.  It's kind of a bit of a new
thing - a new design philosophy, anyway.  I call it a scripting
language to avoid scaring off the many people who will never touch
anything called a "programming language".  But even scripting
languages scare off many, and should, and I'm trying to shoot for
something more and more like building blocks or Lego bricks that you
use to build not out of "shapes" but out of "functionalities".
There was a wonderful game called Chipwits back in the 1980s where
you built a "program" to control your robots by connecting together
little graphic things in a grid of squares, with an arrow pointing
from each one to whichever command thingie would be executed next.
A conditional branch would have two arrows.  Each control had a
little icon on it that showed what it did.  I don't think I'll ever
get to an interface THAT visual for DragonSpeak.  But I do envy the
visuality and accessibility of that idea.

As for the editor...  When we originally released Furcadia, our
"editor" was just notepad!  Our editor would launch a window with
your script, and another that had our standard set of templates so
you could copy and paste them in.  The pieces all being fairly clear
pieces of plain english, and people only having to combine them in a
way that made a sensible sentence, I think it was already easy
enough then that a lot of people with no programming background
picked it up and got into it.  The current "Visual DragonSpeak"
editor was contributed by a user, and it lets you get the same
results with fewer keystrokes and mouseclicks and a nicer interface.
I do think that makes the language more usable, but it still falls
far short of the kind of interface I want in my ideal editor - which
we'll finally be taking a crack at in our Beta version.  It's just
not right to have people dealing with "When such and such happens,
place object 1 at this spot" when you could put the icon of the red
pillow with the tassels in the display of their script right where
you'd see the text "object 1" right now.  We'll get there.

There is going to be one more intermediate generation before our
beta, though.  We couldn't get in touch with the author of "Visual
DragonSpeak" to adapt it to support text and variables correctly for
our rapidly approaching next update.  So we got in touch with the
nice fellow in Czechoslovakia that wrote "Visual DragonSpeak++".
He's making a modified version of it that supports our new features,
has syntax highlighting in different colors, a better layout and
better controls...  And one of my long-ago-planned but
never-yet-implemented features...  Skill levels.  It starts out with
only a few of the easiest DragonSpeak commands shown in the
selection windows.  Each time you click to go up one skill level, it
shows more and more of them, until at the top level you have them
all.  This is really essential now, with this update adding over 100
new commands.  We had enough before to justify it, frankly.

Visual DS++ is an interesting tool itself - and much more pleasing
to the programmers, I'm sure.  He made a precompiler that supported
variables and loops, and then expands everything out and makes a
"normal" DragonSpeak file as its output, with the loops unwound and
the variables replaces with constants.  It's essentially a
pre-processor that lets you work in a more powerful version of the
language.

For anyone that's wondering - a big part of why I avoid classic
control structures is that this is meant to be a language where you
cannot create an infinite loop, or a program that crashes or badly
misbehaves in any other way.  I figured that if I make a form of
subroutine calls that can ONLY call routines that are further down
in the script, and never further up, you could be guaranteed to
eventually bottom out and return all the way up and finish.  And I
have some thoughts on putting serious limits on what kind of loop
indexes you could specify that might make loops acceptable.  It
would probably be necessary to limit nesting too, to either two
nested loops maximum, or just one loop at a time with no nesting.
Otherwise it gets too easy to make a CPU hogging script.

I do have one interesting new structure I'm very pleased with that's
going into the next update - it's already programmed and working.
Variables can be a position on the map, which can be manipulated as
a single entity in scripts.  There's no "typing" to learn, any of
the variables can be used at any moment as a number or as an x,y
coordinate.  Each variable stores two numbers, and when using a
command that's not coordinate related, only the first one is used.
(You can also specify %varname.x or %varname.y to access the parts.)
The programmer side of me feels the way I have this set up is a bit
sloppy, with the absence of "strong typing".  But I like to think
I'm still in touch with how non-programmers think, being a game
designer, writer, manager (ick), markter, raconteur and bon-vivant
(As well as origami master.)  Not having to learn about (or screw up
a script with mistakes in) commands for declaring types, or even
knowing what types are, that's one more thing I can free users from.
The inevitable mistakes in switching back and forth between using a
variable both ways won't be so terrible, in most cases.

Sorry gor going on at such length, but DragonSpeak is one of my
favorite things in the world.  It's really important to me to make a
way for the more "average" sorts of computer users to move from
being "users of pre-built forms of functionality" to "creators of
functionality of their own choosing".  Hypercard on the Macintosh
took a significant step in that direction.  I guess Director and
Powerpoint and maybe even Flash have done important things there
too.  But I think being even more tightly coupled to a given narrow
solution-space for people only trying to create solutions to a
certain narrow category of problems lets you get a lot more "high
level" in your primitives, and thus a lot easier and more accessible
to the general public.  I think that's important, and it would be
interesting to create "dialects" of DragonSpeak tailored to other
areas of human endeavor.  Maybe even things like building message
boards, or for database applications, or telling your TV set what
programs to record for you and when.  Or for scripting animated web
greeting cards to send your friends, without having to just used
them exactly as they appear for everyone else sending the same card
from the same website.  I dunno.  It's just what my instincts tell
me is a direction software ought to be going right now.  :X)

> However, I think that upgrading the client, perhaps using a
> different graphical toolkit, is your best bet for improving the
> game's initial experience.  I have a few complaints with it, that
> I think are best aired in an open forum, especially since many of
> them probably should be covered in any similar MU* client or
> single-player game as well.

Our second programmer (the one that doesn't have to do management,
marketing, business deals, write magazine articles, or placate upset
staff members, and thus can actually crank out a lot of coding) is
working on a brand new interface and graphic toolkit called Horus,
which he hopes to potentially license on its own as a product, and
on top of that we'll be building our new Beta client.  It'll support
16 bit graphics at least, maybe 24 or 32 bit, and we'll finally have
a REAL user interface like we've had in mind since 1996 (and
before), not just the temporary, kludgey interface that'd been
pieced together to make things at least functional during the alpha
period.

>   1) Neither the client window, nor any of its subpanes, are
>   resizeable.  While this means that making hidden zones on a
>   given map is easier to do, it also means that the text pane
>   needs a "more" function to be readable in many places.  I would
>   suggest a 'floating panel' approach to this problem, so that
>   every part of the GUI can be fixed-size or resizeable as
>   necessary.

Agreed, and we'll have multiple text windows with the ability for
the users to decide which types of messages go into which windows.
The map window, however, is going to have ITS size (and zoom level)
controlled by the creator of the dream (our name for maps) that
you're in, rather than the user.  That way the owner can still
control what's hidden and from where, make sure all the people in
the same area are having the same kind of user experience, and very
importantly, keep it so that if person A can see person B, then
person B can see person A.  If different people have different zoom
levels or map window sizes, that may not always be the case.  It
also destroys my nice clear principle of "if you can see them on
your graphic window, you can hear their talk in your text window, if
you can't see them then you can't hear them" principle.  "Mutuality"
is the term my partner 'Manda often uses, and I think it's very
important in online games, especially socially oriented ones.

>   2) There is no pathing.  This means lots of repetitive clicking
>   or typing, or holding down a key and risk overshooting one's
>   goal.  My suggestion would be a simple beeline or a one- to
>   eight-node Minotaur's maze, which would be very workable given
>   the small size and gridded layout of the maps.  You could even
>   let the user specify whether to circle to the left or right of
>   obstacles, if you wanted.  Since this is a client-side
>   improvement, you wouldn't even have to adjust the server to
>   accomodate pathed clients; just let them ask to move in a given
>   direction each cycle, and account for conditions normally.

I've thought about doing something like this a lot.  I like
maintaining an interface that lets you very easily move "just
exactly one step and ONLY one step" for allowing people to deal with
puzzles (or at some point, maybe combat systems) where each
individual step can be highly significant, and you wouldn't want to
take three steps when you meant to take only one.  That should be
doable, though there'll likely be a few mis-steps if pathing is easy
to access (which of course it should be).

I have mixed feelings on whether to do it client or server.  I've
been fooling around on Dransik a little, which my friends Jeff Dee
and Denis Loubet are working on, along with some other "Origin
Alumni" from way back.  You can certainly move around very fast on
there when holding down the mouse button.  Though they don't do
pathing, and you have to sweep the pointer around to get around
obstacles.  You can hold down the mouse button on Furcadia too, but
it's limited to three steps per second, same as I set the keyboard
repeat rate on the arrow-key movement to.  Maybe in this day and age
I should go higher.  Having clients send individual move commands
inherently interleaves long pathing sequences rather than "player A
moves 9 steps, then player B moves 7 steps, then..."  But if the
server handled the movement, it could interleave people's motions in
a more "egalitarian" fashion.  That could be good if players are
getting a lot less moves in due to inferior bandwidth, latency, or
being stuck on an old 486-50.  It could be bad if some players are
just trying to move a lot further and a lot more, and are getting
slowed down more than they should be by players that aren't really
trying to move much (though few moves should mean they don't slow
down much.)

I could also do things like send each whole multi-step path to the
other clients right when someone starts, and have the clients
animate it over time at N steps per second.  That really messes with
the DragonSpeak model of "when the server says to set this effect
off, all the clients will have all the players at the same spots at
the same time", unless I wait for animations to finish before
setting off each DS trigger.

I think having the client do it all is probably the way to go.  But
if and when I get to that point, I want to sit around and try to
come up with some more pros and cons to mull over in my head.

>   3) The fonts are okay, but being able to use OS standard fonts,
>   or even TrueType fonts, would be better.  Combined with a
>   floating resizeable panel (maybe with transparent background),
>   this would be much more effective than the current method of
>   simple scrollback and constant logging, for keeping track of
>   conversations and important messages.  You could even offer the
>   user the ability to change the default font colors for the
>   different message types, or add multiple panes to sort messages
>   into.

We are going to have alpha blending and translucent overlays.  Text
color is a major source of mental anguish for me still, because I
know there's 100 things it could and should be used to quickly and
easily indicate, and choosing which one or two or ten of them it
actually WILL represent is not something I know how to do yet.  Of
course we'll have multiple ways users can use color according to
their preferences, but what the default way is becomes a very
critical decision, because most people will use it.  And there might
be some elements that the user can't choose for consistency, ability
for US to direct attention as we choose (system announcements
standing out is a Good Thing, especially when they announce a new
limited time special price on dragons that will help us put
cochinita pibil on the table), etc. and in other areas we might make
choices limited in scope.  It's a tough thing to decide on.

People will also spoof any standard type of thing that becomes
spoofable, which is a constant concern in a system as flexible as
ours.  Our latest trick we've heard of...  The system announcements
ALWAYS start with [=] at the left edge of the screen.  All user
speech, poses and descriptions are indented to make spoofing have an
extra visual cue that they're fake.  Dream owners can "emit"
dream-wide messages, which always start with [#].  Someone
apparently made a patched font for their dream where the # graphic
in the font is replaced with an =.  Then they emitted messages in
their dream that looked like they started with [=], and they also
duplicated the standard bit of opening text on every system
announcement, fooling a number of people into believing we'd
announced some fairly weird and unlikely planned changes to the
game.

>   4) This one requires some server-side adjustments: Being able to
>   carry more than one object at a time, and to have those objects
>   be more useful, would be a massive improvement.  This could mean
>   adding inventory tests to DragonSpeak, or altering what tests
>   currently exist.  It also means adjusting the GUI to accomodate
>   more objects.

Our original Alpha 1.0 client actually had art in the lower left
corner (then not-yet-used for any functionality at all) that said
"My Inventory" very dimmed out, and had a group of squares that were
obviously meant to show things you were carrying.  (This didn't keep
us from getting at least half a dozen players suggesting "Hey, why
don't you add an inventory function?")

I do want to deliberately put off implementing inventory until some
underlying design decisions are made about what the whole "object
economy" will be.  What can and can't be brought between different
maps, what will continue to be manufacturable in infinite quantities
by any player, and what (if any) objects will be limited in supply
and how, what unique properties can be attached to objects if any,
will there be "ownership" of some to make theft of them impossible
(I'm very tempted to support that for purposes of Utopianism), etc.
Once I have decided what some of the answers to those questions are,
we'll get inventory in.  There's a lot of other major subsystems
that have to go in first though - permanent or semi-permanent
dreams, attention economy, PhoenixSpeak for player use of persistent
databases and other functions good for supporting stat-based RP
systems they want to build, matchmakers, high score tables,
membership lists, or a variety of other cool things.  Of course once
attention economy is in it becomes pretty desirable to have some
things to buy.  (Though our currency is "mana" which decays within a
week, so it's not really "money" and the act of "buying" will be
more like "conjuring into existence" unless you're giving mana to
another player in exchange for something they have.)

> These are just my opinions, of course, and I haven't touched the
> darn thing in several months, but I think it had to be said.

Thanks for taking the time to offer some opinions.  I don't get to
gab about Furcadia design ideas very often these days, too busy
making and operating the dang thing.  Though I'm getting pretty
eager to get the business to where I can spend time building a
second world/game/service based on the engine, especially if I can
link up with one of my Top Three choices of Big Huge Companies.
(Wish I had someone to work full-time at schmoozing and negotiating,
rather than having to squeeze that in with everyting else.)

Well, back to the bitmines now.  Hope I didn't bore everyone to
tears or anything.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free download!
*-------------------------------------------**   http://www.furcadia.com
  Supporting user-created graphical worlds. ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev