[MUD-Dev] Re: regulating player-created objects

[Nathan F Yospe]

On Wed, 29 Apr 1998, Dan Shiovitz wrote:

:(apologies if I get something wrong here in the posting style .. I've
:been reading for a while but haven't posted anything in ages)

I've been meaning to post for ages... time to get back to it.

:Anyway, so it seems like players creating objects is a major part of
:any sort of "big ecosystem" game (ie, one where players play more
:roles than "insert coins into circulation; remove loaves of bread and 
:monsters from circulation"). I know a bunch of people here are working
:on variants of this. I was wondering what kind of regulation there is
:on the objects players can create. 

Templates for objects tie to construction skills, use resources that fit an
acceptable specification for components. Builders can create new templates,
but there is no reasonable way to allow, say, a smith to invent, without an
existing template, a helicopter. (An inventer is a person with a chance for
sudden addition of a new template while exercizing related forms... there's
going to be a lot of templates that are not actually in the game or learned
from any non player source; inventers are people with high enough scores in
intuition, creativity, and specified knowledge to suddenly gain possession,
and if they are smart, a patent (OK, that one isn't game supported) of that
template. This sort of bridges the gap between atomic simulation and useful
modeling. Character bodies, incidentally, are similar templates. Templates,
of course, are NOT hardcoded, but they are assembled, and as I have said in
earlier posts, (my) assemblies are not really a _programming_ language, but
instead a reactive behavior language... I'll post an up to date document on
the language specification and linkage to objects at some point. Motivated,
reactive, spontanious, and static behaviors are all supported, but none are
coded procedurally; they use a directive table. I'm still working on these,
as they incorporate elements of associative AI... and I'd like to make it a
usable interface for creating objects with behaviors beyond those inherited
from components.

:For instance, say I have the woodworking skill. Assuming I have some
:logs, appropriate tools, and nails, I ought to be able to build a
:table. This seems like a reasonable use of the skill. But how does it
:work? Are there are a list of five things I can create with
:woodworking, so I type "woodwork #5" and it says "ok, you create a
:table"? I guess the alternative would be to make no such game object
:as "tables", but you'd do something like "carve flat piece of
:wood. nail sticks to the bottom of the flat piece of wood" and presto,
:there's your table. This is obviously more flexible than the previous
:method but also pretty clearly harder to do. Or is there some
:in-between stage that I'm missing?

You have a list of things you know how to make. Bound components (the table
top or leg) as opposed to merged components (an egg in a loaf of bread) can
be treated seperately, allowing, say, a table to have its glass top etched,
its wooden legs carved and stained... Associated components are not even in
the fixed piece, so a table's chairs could be a part of the dining set, but
seperately removable without disassembly. (Disassembly is much simpler than
assembly; disassembly without damage to components requires the template, a
knowledge of that particular disassociateive method, and luck.) Assembly is
composed of knowing the template AND skill in the associative method, so it
is quite concievable that a theoretical physicist would have to teach an ME
the template for a fusion reactor... because the scientist couldn't weld it
together. As far as commands themselves... as always, the more you specify,
the better the result. 

    > Build a table
    You look around. There is an old rotting plank and two logs here. There
    is nothing that resembles a saw, but you see a large rock and four iron
    pegs. You put the plank on the logs, pick up the rock, and pound two of
    the pegs through the plank into each log. You have a low, lopsided, and
    crude table.
    > Damn it, I meant go into the workshop and build a table!
    Tough cookies. I'm just a dumb character. You weren't very specific.

(OK, that was VERY exagerated. I HOPE the client gets that smart someday.)

:Regardless, once I've made a table somehow, can I customize it? It
:seems like you really have to let players do this to make object
:creation of any interest and have the hopes of creating a real economy
:where someone could sell tables for a living. But how do you let
:people create tables that look like "This table is made out of
:polished oak with a carving of a dragon inlaid in dark stone on the
:surface" but not tables that look like "*** YOU HAVE DIED ***" or some
:other sort of joke items, which AFAICT totally blow away any system's
:chances for realism. 

Would have been easier to do before they nailed it together, but that's the
way it goes. They could *carve* "*** YOU HAVE DIED ***" into it, but that's
just going to produce "A Table with something carved into it"...

:I know other people have thought about this more than me, so has
:anyone come up with a good solution? (one obvious one is that wizards
:occasionally check out newly created items and dispose of those that
:aren't in the spirit of the game. But that's a pain in the
:ass. another is to disallow player customization and describe the
:table based on character skill level, so a woodworking 10 person makes
:"This is a rough wooden table, sturdy but with lots of splinters" and
:a woodworking 90 person makes the previously-mentioned dragon
:table. But what if the woodworking 90 person wanted to make a rough
:table? Yet another solution is to say all items get made by wizards,
:so if you want a table, you place an order with Bob the NPC woodworker
:and he carves you one to order, unless you give a silly
:description. But this is even more of a pain in the ass than wizards
:just checking out new items.)

Helps to have a modular componential assembly system... and to have command
interpretation on the client side, where detail can be specified from a set
of simple commands like "build table. Sell table." to detailed commands for
exact control... you can interupt the client to specify detail as well. And
thus players get to be part of the environment, and to affect it, without a
danger of them abusing the ability. Builders are a lot more dangerous, with
levels of builder getting the ability to muck deeper and deeper in the base
universe stuff. Of course, there is only one coder... me... and there is an
extreme disctinction between coding and building, unlike coldC or LPC, with
building having more in common with CASE coding than anything else...
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/




--
MUD-Dev: Advancing an unrealised future.