<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: regulating player-created objects --> <!--X-From-R13: Oqnz Ivttvaf <nqnzNnatry.pbz> --> <!--X-Date: Sun, 24 May 1998 03:36:18 -0700 --> <!--X-Message-Id: Pine.SGI.3.95.980524024431.17852E-100000#mail,angel.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: Pine.LNX.3.93.980523172548.2997A-100000#pc4,zennet.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: regulating player-created objects</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:adam#angel,com"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00813.html">Previous</a> | <a href="msg00815.html">Next</a> ] Thread: [ <a href="msg00810.html">Previous</a> | <a href="msg00482.html">Next</a> ] Index: [ <A HREF="author.html#00814">Author</A> | <A HREF="#00814">Date</A> | <A HREF="thread.html#00814">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: regulating player-created objects</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: regulating player-created objects</LI> <LI><em>From</em>: Adam Wiggins <<A HREF="mailto:adam#angel,com">adam#angel,com</A>></LI> <LI><em>Date</em>: Sun, 24 May 1998 03:35:24 -0700 (PDT)</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On Sat, 23 May 1998, Brandon J. Rickman wrote: > You are trying to build a garden hoe. A hoe has three parts: a wooden > shaft, a metal handle, and a hoe blade. A shaft has two male sockets, > let us say Class C Round Socket, and both the handle and blade have female > Class C Round Sockets. > > In a standardized world, putting the hoe together would be > straightforward. But if each socket has a slight deviation from the > standard (not a statistical deviation, but more like small flaws or > special characteristics - a little split in the wood, not perfectly round > - abstracted into a number) then things won't always fit perfectly. > > The shaft has two ends, {male Class C Round, 1138}, {male Class C > Round, 76118}. A handle with {female Class C Round, 65024} might fit on > the second end ( | 76118 - 65024 | < some minimum fit value) , but not on > the first. > > So it isn't merely a matter of finding all the right parts, but finding > parts that fit together well. This is a bit on the micro-management side > of things, where every little component has to be manually or otherwise > evaluated to actually put something together. A good use for a tinker > skill. Hrm...yes, one could certainly do something like this. I don't see it adding much at first glance; probably the best effect would be: % skill woodcarving Your skill at woodcarving is poor. % carve shaft to fit axehead You begin trying to make the end of the shaft fit into the axehead's socket. [...] You finish your work. % fit shaft into axehead You shove the shaft into the axhead's socket. Hmmm, it seems pretty loose. A person with a good woodcarving ability would get a "The fit is perfect!" message and would have much less of a chance of the axehead flying off in the middle of combat. > > So? If you could seek shelter from the rain under it, shouldn't it say > > "You see here a rain-shelther."? IMO it's not the server's job to list > > out every possible use for a given composite object. It *is* its job to > > try to consolidate object descriptions by assigning the 'obvious' label to > > something. > > Think about scale. To a mouse, or a mouse-sized man, an "ordinary table" > may look more like a "rain shelter". But then in my case it is less Ah, but we've had some good discussion of this... I would postulate that if I can see enough of the object, I can classify it regardless of scale. I table does *not* look the same as a shelter to me, regardless of size. Tables have certain traits - beveling on the legs, smoothly finished tops, perhaps fold-out sections or other table features. A shelter may have similar components, but they will most likely not be made the same way, unless it was made out of material that originaly came from a table. Now, for the purpose of the system, we are ignoring these differences. But the high-level result is that templates simulate this data. From the code standpoint, my character recognizes the table because it is a table template. From the player's point of view, they recognize it as a table and not something else because of all those little features which we associate with tables but not with rain shelters or beds or anything else. This is why I think it makes perfect sense to have poorly built objects less recognizable. At some point you cease to be able to make out enough detail on the object for you to be able to tell it's a table. Either it gets so big that you're only looking at a small part of it at any one time, or it's so small that you can't discern the details. Either way it should be replaced with an ambiguous description, with the option to examine it closer in order to attempt to recognize it. Ie: There is a small brown speck on the floor. % exam spec On closer inspection, you realize it is a miniature table. or: A black shape looms in the sky. % exam shape You step back to try to get a bettter look at the shape. You realize that it is a Q'lonian mothership. > important that the server gets the _name_ of an object correct, more > important for it to get the _implied function_ of the object correct. Yeah...I suppose this is where the ambiguity comes in. I'm kind of pushing both of these things together into a single lump. For something like a table or a bed this seems to work, although I wonder if there would not be problems with other objects that I haven't thought of yet, due to this lumping. > But how can the system be made to recognize specifically when a particular > set of physical characteristics fits into a template? Hmm, this is going > in circles. You're right. In a nutshell: - There is a list of materials (oak, iron, flesh, water, diamond..) which the basic shapes in the world can be made of. The shapes consist of simple geometrical objects such as planes, cylinders, spheres, domes, wedges, and so on. The more basic shapes you define the easier it will be to form simple and obvious templates, but the less flexible and extensible the system will become. This is the choice between having an axe template use an axehead and a shaft, or using a wedge and a cylinder. In the second case some subclassing would be necessary (depending somewhat on the game world and method of display), to indicate the difference beweteen a doorstop and an axehead. - Templates are a list of shapes containing data about how they are connected to one another, and how they are oriented in relationship to each other. They also define the obvious function (and therefore, name) of the object. Personally, I would prefer to go for the more open-ended system. An axe template only gives the object its name and possibly stores some wieldability values based on the skill of whoever constructed it (ie, balance and grip). How it actually damages things is based on the physics of the wedge impacting other surfaces. By the same token, objects can rest on any plane given the proper friction-to-angle of incline ratio. The fact that said flat plane is raised off the ground on four legs is only a convenience for characters; if the plane was resting on the ground it would still function identically, it would just be less useful as you'd have to bend down to interact with the objects upon it. > > Well, that is the idea with templates. But the labels which templates > > assign are just supposed to help classify the world in a way which is > > reasonable to the players. This shouldn't preclude them using the objects > > in non-standard ways. A common example is being able to use any object as > > a weapon. Generally there are certain things that you'd rather use as > > weapons since they are more effective (in terms of both wieldability and > > ability to do damage), but that shouldn't stop you from beating Bubba over > > the head with your loaf of bread. However, I don't believe that the > > server should say, "There is a tasty looking loaf of broad here, which is > > also useful for beating people over the head" when you enter the room. > > How I'm trying to invert the problem: It doesn't matter what the player > sees, but what the system thinks that the player is seeing. Because the > system has to decide between: > > Bubba is holding a loaf of bread. > > or > > Bubba is wielding a loaf of bread. > > (Does it matter how Bubba's command was parsed, whether he typed > 'hold bread' versus 'wield bread'? Or that Bubba is a known bastard? > That a metal rod has been baked into the bread?) Nod - which is why I like to sidestep this issue altogether. Bubba has a loaf of bread in his right hand, and that's all players see when they look at him. However, I suppose it would be perfectly reasonable to assume that there is a difference between a fighting grip (holding it near the base for better swing leverage) and a normal grip (holding in the center for ease of balance/support). Thus: % i You are holding a loaf of bread. Boffo attacks you! You shift your loaf of bread into a fighting grip. % i You are wielding a loaf of bread. > > The word "door" doesn't make sense, IMO, for a curtain or a window. Doors > > are almost always hinged planes that block entryways until you open them. > > This is the 'default' behavior for them, so if you see one that is > > behaving this way, you shouldn't get any special message except for "you > > see a door here." Windows are similar. If either of these things is > > lying on the ground in the room, they should give special messages, since > > they are NOT behaving in their normal fashion. Ie, "You see an unhinged > > door lying on the floor here." > > A curtain, on the other hand, is not so well-defined as to its function. > > Normally it covers something, but it can vary - it could cover a window, > > or a door, or a dressing area, or a shower. It is not implictly known > > that the curtain forms an egress to another location. Thus, one should > > see "There is a curtain blocking a doorway here." or "There is a curtain > > hanging in front of a window here." > > This is a builder problem, and an implementer problem. Builders can be > notoriously crafty in their descriptions - to know about the runes you > have to look at the altar (sometime the alter), to know about the altar... > - and may not know how to describe something like "an unhinged door". But > then the implementers rarely provide much in the way of specific style > guidelines for the builders to use. This problem has carried over into > object based environments, there can generally be only one > name per object, because implementers think that all those messy > exceptions will slow down the code. ;) Once again, this is part of the point of templates. Builders do not make objects and assign them a string of "a large oaken door". Instead, they load up a door template, set the plane component to be made of oak, and modify the size of the door until it appears "large" to the average-sized player. They add "unhinged" by simply remoing the hinge components. They cause it to display "is on the ground here" instead of "is here" by simply placing it on the ground instead of placing it in a doorway. I imagine it would be nearly impossible to make templates work the way I've outlined if you allowed builders to just name objects anything they wanted. This is, of course, extremely unsuitable for a mud which promotes user-building, or a mud which wishes to contain silly locations and objects. It IS suitable for a "realistic" mud - ie, one where the implemtentors wish the game to be more like a consistent and believable world and less like a beefed up Zork. > > > The street is not a good place to sleep. > > > > It's not a *good* place to sleep for a number of reasons. One is it's not > > comfortable. This is a material property, just like the lake. A street > > made out of matresses is actually a great place to sleep. The second > > reason it's not a good place to sleep is that it's probably not very safe > > and not protected from the elements. Both of these things have nothing to > > do with the object templates; if I built a street in my house, it would be > > a perfectly safe place to sleep if not all that comfortable. > > When a player types "sleep", shouldn't that be interpreted as "if there is > a comfortable place try to sleep here, otherwise get confirmation"? And Hrm, I suppose it depends on how much you want to automate. It seems reasonable if not completely user-friendly to just have them plop down on whatever surface they happen to be standing on (ie, the ground) if they type "sleep", or more reasonably "lie down". If they specify a location they will sleep there instead. However, if you *did* want to insert this sort of semi-smart command handler, I'd want to keep things atomic. When responding to "sleep", the command handler would search for the nearest flat surface of the appropriate height, with a pliancy value as close as possible to that character's ideal pliancy for sleeping surfaces, that was large enough to hold their prone form, and which looked sturdy enough to support their weight. By the same token, droping an object would cause the command handler to search for a flat surface large enough to hold the object, near as possible (in x, y, AND z) to the character's hand, and which looked sturdy enough to hold the object. As it just so happens, most tables are built to fit this list of criteria very closely, so normally if there was one around you'd end up dropping the object onto it. > back to templates and object function, is there not a greater benefit from > sleeping in a bed-template? This goes back to what I mentioned early about how much functionality should be defined by the template, and how much should be extracted from its components. Ideally, you'd want as much as possible to come from the compoents - a bed is consider 'good' if it has a flat surface of the proper pliancy and is the proper size a strength to support the person who wished to sleep upon it. For more complex objects, I could easily see adding extra parameters to the template (like wieldability values for the axe that I mentioned above). > Do people only sleep in actual beds, in > actual houses, to avoid being attacked by random monsters? People sleep in beds because they are comfortable. People sleep in houses because it protects them from disturbance by noise, weather, and other humans (regardless of their intent). So I guess the answer is, sort of. >[If so, do you > not realize how condemning this is of the mud industry? Hm, I don't have > time to go into an anti-testosterone rant here, and Adam's post certainly > doesn't justify one.] Seeking protection from adversity is not something that I find very related to any particular hormone. Of course, I also don't consider testosterone to be the horrible, vile substance that many nowadays seem to. > > The whole idea with the template system I have been describing is to > > *avoid* defining as much functionality as possible. Leave that to the > > players. We were trying to generalize to avoid garbage like: > > > > > wield hammer > > The hammer is a tool, not a weapon. > > > sleep on table > > The table is not a bed! > > > put sword on bed > > The bed is not a table! > > So you _do_ want to allow players to sleep on a table? Absolutely! > > So he sees, "You see something that sparks and fizzes when you smash it > > here."? No, I think he'd see a several strange metal boxes, one of which > > is large and has a colorful piece of glass on the front, another which has > > many small boxes on it with strange markings. This is the advantage of > > templates - builders define objects by their components and then give them > > general descriptions, so breaking it down into a description of the > > objects it is made of is quite easy. > > "quite easy," he said. Heh, well I should say that once you have all the OTHER stuff in place (which is no small feat), that part is the "easy" part. Very little that is discussed on this list is truly easy to implement. > > People make the artwork and don't bother to make the thing function well, > > if at all. Players get excited when they see it, then quickly bored when > > they try to manipulate it. > > Some of the latest generation engines. But I'm also trying to draw some > conclusions about the general trend of high-tech game engines. The 3d is > blindingly fast (if you use pathetic lighting) but ... there ... is ... > no ... content. There is no audience appeal. 3D is easy, given the > present computing power. Perhaps if we even took some of the features out > of the 3d engine and applied that cpu to some kind of usable interface... There's much more to it than simply getting enough CPU time. Designing that interface and then implementing the hardware to make it work is something many have aspired to but few (none?) have succeeded at. People still prefer mouse+keyboard to play Quake, which has *extremely* simple interaction with a 3D world. And the mouse+keyboard interface is still inadequate! Now consider a world where you can actually interact with the environment in ways other than shooting... But yes, I agree. Good graphics are not the problem: graphics getting ahead of the interface is a SERIOUS problem. Adam </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00810" HREF="msg00810.html">[MUD-Dev] Re: regulating player-created objects</A></STRONG> <UL><LI><EM>From:</EM> "Brandon J. Rickman" <ashes#pc4,zennet.com></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00813.html">[MUD-Dev] Re: OT: Java multithreading test source</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00815.html">[MUD-Dev] Re: mudschools</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00810.html">[MUD-Dev] Re: regulating player-created objects</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00482.html">[MUD-Dev] Re: regulating player-created objects</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00814"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00814"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: regulating player-created objects</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00609" HREF="msg00609.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Fri 15 May 1998, 19:56 GMT <UL> <LI><strong><A NAME="00639" HREF="msg00639.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Sun 17 May 1998, 00:08 GMT <UL> <LI><strong><A NAME="00670" HREF="msg00670.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Mon 18 May 1998, 19:26 GMT <UL> <LI><strong><A NAME="00810" HREF="msg00810.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Sun 24 May 1998, 02:41 GMT <UL> <LI><strong><A NAME="00814" HREF="msg00814.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Sun 24 May 1998, 10:36 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> </UL> </LI> </ul> </ul> <LI><strong><A NAME="00482" HREF="msg00482.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 09 May 1998, 07:38 GMT <UL> <LI><strong><A NAME="00483" HREF="msg00483.html">[MUD-Dev] We're Tiny, we're Toonie, we're all a little Loonie!</A></strong>, Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Sat 09 May 1998, 14:22 GMT </LI> </UL> </LI> </ul> <LI><strong><A NAME="00481" HREF="msg00481.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 09 May 1998, 07:24 GMT </LI> </ul> <LI><strong><A NAME="00405" HREF="msg00405.html">[MUD-Dev] Re: regulating player-created objects</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 05 May 1998, 17:03 GMT </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>