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

[Nathan F Yospe]

On Thu, 30 Apr 1998, Adam Wiggins wrote:

:On Wed, 29 Apr 1998, Dan Shiovitz wrote:
:> 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. 

:This is possibly one of the toughest issues.  It all relates back to "at
:what level am I modeling the world?"  As someone pointed out, if all you
:do is model the individual atoms and their reactions with one another, you
:could potentially do about anything.  Naturally this is not feasible just
:yet for a number of reasons.  The main thing is that the effort for which
:it takes to get specific "neat" stuff in your universe is inversely 
:proportional to how atomic you set things up.  It's for this reason that
:most muds have opted for simple scripting along the lines of:

:NPC::Dragon::AttackRoutine[chance to occur = 30%]
:begin
:   if myself.Fatigue < 0
:      return

:   myself.InRoom.Message("The dragon breathes deadly flame!")
:   myself.InRoom.Damage(DAM_FIRE, dice(4, 6))
:   myself.AffectFatigue(-10)
:end

:Thus it's very easy for anyone to implement a fire-breathing dragon.  If,
:however, you're trying to model realistic creature anatomies, or realistic
:room damage, or are using non-room systems (all things that some folks on 
:this list have attempted), it gets much more complicated.  You need to
:create some sort of streaming fire that lasts for X amount of time, you
:need to calculate the effect of the fire on the blast area (meaning the
:floor, the furniture near it, any characters near it, anything the
:characters are wearing or hoilding), how the fire originates and then
:affects the dragon's anatomy.  What happens when a brave warrior shoves a
:lance through the dragon's belly when it's building up its internal fires?
:And on and on.  Naturally the results of all of this stuff can be very
:cool.  But this is just an illustration of how difficult it is to
:implement "standard" mud devices.

Of course, to some degree this is self perpetuating, especially in a system
with a good object oriented basis. As far as a firebreathing dragon goes,
well... I will have to think on this briefly; obviously, it isn't as simple
as it would be above to do something like this on Physmud++... using some
base objects from Singularity, I'm going to pull a reptilian creature
template. I'm fairly sure I have one that is general enough to become a
dragon. Now, the fire breathing mechanism. Here it gets hairy... because I
need to model a genuine fire generation mechanism, and rectify the fact 
that my reptile as yet can't survive a fire in its belly. OK, I have some
flexible organic structures designed to insulate extreme heat... go down
to the resperation system (inherited) and add another object. A furnace? I
think we're better off with a flamable gas ejection system. Now we have a
creature that _can_ exhale a stream of methane and ignite it... Alter the
shape a bit... OK... Size... now it can't survive on the old metabolism...
behavior template for fire breathing... we'll have to make this one warm
blooded, the metabolism is too slow... it won't be hunting like a lizard
anymore... there's a nice behavior template that fits this interface for
marsh-gromlens... maybe tweak it for habitat to mountaintop... OK, how do
we make the dragon smarter? Ah... reptilian sapient behavior template base.
Good, that base is _very_ ethnocentric. Hum... has anyone got a behavior
set for gold hording? No? Damn. OK, that's going to require some real code,
and no mistake. Behavior scripting is rather touchy. Pavlovian cues to gold
and just go with that? And so forth... Doesn't require programming, as
such. I'm planning to handle this assembly system with a GUI. But it is a
tough thing to do, if you can't find templates. I'm hoping to get the set
of templates waaaay up in numbers.

:> 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

:That's all I've ever seen.  My first run in with it was the tanning skill
:on (I believe) the SillyMUD base, where you typed "tan corpse leggings" to
:get a pair of leggings based on the race of the critter that died.
:More recently, watching my friends play Ultima Online I see them doing
:carpentry by clicking on a piece of wood and getting a menu with icons of
:all the different things they can try to create - the same thing only
:visual.

Well, yes. There's not much else one CAN do... best you can do is allow a
large number of things, and a lot of them really basic, and allow things
to be joined in fundamental manners (IE, four posts and a flat sheet are
a table, by any other name, when nailed together.)

:> 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?

:I would imagine the effect you describe here would be suited only for a
:graphical environment (realtime 3d to be exact).  There it's very easy to
:have an object "a chunk of uncut wood" that you apply a saw to and the
:player can shape new objects of whatever shape they want.  Making table
:legs is therefore you and your character's abillity to guide the saw the
:way you want it.  Making boxes for legs is going to be much easier than
:making nice rounded ones.  From there you attach them however you like to
:other pieces of wood.  The only thing that defines it as a "table" is
:whoever owns it; the server doesn't care.  The physics of the world
:(collision handling and gravity to be exact) will take care of the fact
:that a well-built table will have a level top where you can put whatever
:you like.

This always gets me... why should realtime 3D have to be graphical? I handle
it as a protocol that goes by the MICfMIT - maximum information communicated
for minimum information transmitted - principal. The only client I am
designing so far is text-with-multiple-windows. Graphical is possible, even
as complex 3D rendering; this would require a stronger engine, but my
predictive mapping and behavior algorithm tranfer format manage to bypass a
lot of bandwidth limitations...

:As cool as this is, I imagine a server that actually puts this to
:practical use is still a ways off.  Is there something inbetween?
:I think so; I would call this "name compositing."  The tanning on dikumud
:was a basic example of this: when you did "tan corpse leggings" you always
:got a pair of leggings, but they were prefixed by the race creature you
:killed.  One could easily extend this...see below.

Hum... See, I actually take into account composition, state, and components
of things. That means, for example, that those leggings would be made of 
some kind of hide, with a strength, etc based on that... and the markings
would be patterned to them. This will allow a client to determine whether
a player knows what that pattern is... or will have to have it described.

:> 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. 

:Right.  The trick is to make them still have to choose from a fixed list,
:just make that list very large and multi-dimensional.  Thus you might
:have:

:  < i
:  a piece of oak
:  some nails
:  a saw
:  a hammer
:  a brush
:  a pan of dark finish
:  a small brush
:  a small container of gold paint
:  < woodwork oak into table
:  You begin working at the piece of oak.
:  ...
:  You finish creating an oaken table.
:  < l
:  You see here a raw oaken table.
:  < l table
:  The table is simple and made of raw oak.
:  < woodwork table with scrollwork on legs
:  You carve some scrollwork into the legs.
:  < l table
:  The table has some impressive scrollwork on the legs and is made of raw
:  oak.
:  < woodwork table with inlaid dragon on surface
:  You carve an intricate dragon into the surface of the table.
:  < l
:  You see here a raw oaken table inlaid with a dragon.
:  < finish table
:  You hold a brush in your right hand.
:  You grab a pan of woodfinish in your left hand.
:  You apply the finish to the table.
:  < l
:  You see here an dark oaken table inlaid with a dragon.
:  < gild table
:  You painstakingly apply gold paint to the table's scrollwork.
:  < l table
:  The table has some impressived gold-gilded scrollwork on the legs and a
:  gold-guilded dragon carved into the surface.  It is made of darkly
:  finished oak. 

And if they want a mermaid on a rock? (Admittedly, I can't really handle 
that either, beyond a point...)

:I would assume, of course, that someone with insufficient woodworking
:skill might end up with:

:  < l
:  You see here a deeply gouged oaken table.
:  < l table
:  The table is scratched and gouged on the surface and legs.  Gold paint
:  has been splatered here and there.  It is made of darkly finished oak.

:Thus wasting the (expensive? hard to acquire?) materials.

:This is still a finite amount of choices, but seems quite a bit more
:rewarding to me than "woodwork table -> You now have a table."

Yup.

:> 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?

:This reminds me a little of our skill-modifying commands to allow people
:to teach.  It works like so:

:  Bob says, 'I'll give you three jade rings of you'll teach me swords!'
:  < consider bob swordsmanship
:  Bob's swordsmanship seems to be very poor.
:  < skills swordsmanship
:  Your skill in swordsmanship is excellent.
:  < skill swordsmanship on bob at poor
:  You will now use your swordsmanship against Bob as if it were poor.
:  < say okay, let's spar

:So, I could imagine if for whatever reason you wanted to imitate a bad
:carpenter:

:  < skill woodworking on table at terrible
:  You will now use your woodworking skill on the table is if it were terrible.

:> 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.)

:Yeah, this defeats the whole purpose, which is (I assume) to make the
:place appealing to players that fall into Bartle's "explorer" category.
:Getting some member of the admin to rename your ordinary table is hardly
:any fun at all.

True. Of course, there is a point where builders have to step in in _any_
system. For me, low level builders get things like wilderness expanses, any
new assemblies, etc. Higher builders get behavior templates, and higher
still, materials, integrated assemblies...
--

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.