April 1998
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Chris Gray
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. J C Lawrence
- OT: This is a test of a system config change. coder@ibm.net
- MUD Development Digest Dr. Cat
- MUD Development Digest Justin McKinnerney
- MUD Development Digest Nathan F Yospe
- MUD Development Digest Justin McKinnerney
- MUD Development Digest J C Lawrence
- MUD Development Digest J C Lawrence
- MUD Development Digest Jon A. Lambert
- MUD Development Digest Chris Gray
- MUD Development Digest J C Lawrence
- MUD Development Digest J C Lawrence
- MUD Development Digest J C Lawrence
- MUD Development Digest Ben Greear
- MUD Development Digest Jon A. Lambert
- MUD Development Digest Chris Gray
- MUD Development Digest Ben Greear
- MUD Development Digest Dr. Cat
- MUD Development Digest Ben Greear
- MUD Development Digest Justin McKinnerney
- MUD Development Digest Dr. Cat
- MUD Development Digest Justin McKinnerney
- MUD Development Digest Dr. Cat
- MUD Development Digest J C Lawrence
- MUD Development Digest Matt Chatterley
- MUD Development Digest J C Lawrence
- GRUMPS maddog@best.com
- caved in: Algorithms for for storing free space. Ben Greear
- internet connections Chris Gray
- GRUPMS? Vadim Tkachenko
- [Fwd: MUD-Dev] Richard Woolcock
- [Fwd: MUD-Dev] Nathan F Yospe
- [Fwd: MUD-Dev] coder@ibm.net
- [Fwd: MUD-Dev] Katrina McClelan
- [Fwd: MUD-Dev] Richard Woolcock
- [Fwd: MUD-Dev] J C Lawrence
- [Fwd: MUD-Dev] Travis S. Casey
- [Fwd: MUD-Dev] maddog@best.com
- [Fwd: MUD-Dev] J C Lawrence
- [Fwd: MUD-Dev] J C Lawrence
- [Fwd: MUD-Dev] Jon A. Lambert
- [Fwd: MUD-Dev] Richard Woolcock
- Meta: who dat guy, wot dat web? coder@ibm.net
- Meta: who dat guy, wot dat web? Katrina McClelan
- Meta: who dat guy, wot dat web? s001gmu@nova.wright.edu
- Meta: who dat guy, wot dat web? J C Lawrence
- Meta: who dat guy, wot dat web? Jon A. Lambert
- Meta: who dat guy, wot dat web? J C Lawrence
- [META] Mailing lists Katrina McClelan
- [META] Mailing lists Travis S. Casey
- META: The web presence and wot it ain't gonna be J C Lawrence
- META: The web presence and wot it ain't gonna be Shawn Halpenny
- META: The web presence and wot it ain't gonna be J C Lawrence
- META: The web presence and wot it ain't gonna be J C Lawrence
- (fwd) code for teleport coder@ibm.net
- (fwd) code for teleport Ben Greear
- (fwd) code for teleport s001gmu@nova.wright.edu
- (fwd) code for teleport J C Lawrence
- META: Archive of Megami/Wout's list's traffic? Archive of the CC: list? J C Lawrence
- Resisting Charm or you're cute and nice, but not to die for. Jon A. Lambert
- Resisting Charm or you're cute and nice, but not to die for. s001gmu@nova.wright.edu
- Resisting Charm or you're cute and nice, but not to die for. Katrina McClelan
- Resisting Charm or you're cute and nice, but not to die for. J C Lawrence
- Genetic Algorithms Jon A. Lambert
- MUD Development Digest J C Lawrence
- MUD Development Digest Alex Oren
- MUD Development Digest Chris Gray
- MUD Development Digest Jon Leonard
- MUD Development Digest Jon A. Lambert
- Resisting Charm or you're cute and nice, but not Jon A. Lambert
- Unreal J C Lawrence
- META: The web archives are up for review (alpha 1) J C Lawrence
- META: Archive of Megami/Wout's list's traffic? Archive of Alex Oren
- RGMA Alex Oren
- META: That bloke Yaltec. Khan one
- META: That bloke Yaltec. J C Lawrence
- a fruitful exchange on classlessness in r.g.m.admin Cimri
- MAGE 2 MAGE v. 0.88 J C Lawrence
- META: membership (was a fruitful exchange on classlessness in r.g.m.admin) coder@ibm.net
- META: Archive of Megami/Wout's list's traffic? Archive of Wout Mertens
- (fwd) Development of new code base coder@ibm.net
- Seductions of Sim: Policy as a Simulation Jon A. Lambert
- Seductions of Sim: Policy as a Simulation J C Lawrence
- META: membership (was a fruitful exchange on clas Jon A. Lambert
- Resisting Charm or you're cute and nice, but not t Jon A. Lambert
- META: Web futures and the demise of MUD civilisation as we know it. coder@ibm.net
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! Caliban Tiresias Darklock
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Richard Woolcock
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Vadim Tkachenko
- There can be.. only ONE! Jon A. Lambert
- There can be.. only ONE! Vadim Tkachenko
- There can be.. only ONE! Jon A. Lambert
- There can be.. only ONE! Richard Woolcock
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Ling
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! J C Lawrence
- OT: Caballah [was Character development] Alex Oren
- OT: Caballah [was Character development] Caliban Tiresias Darklock
- OT: Caballah [was Character development] Vadim Tkachenko
- OT: Caballah [was Character development] Vadim Tkachenko
- OT: Caballah [was Character development] Marian Griffith
- OT: Caballah [was Character development] Jon A. Lambert
- Personality modelling Oliver Jowett
- Personality modelling J C Lawrence
- Personality modelling J C Lawrence
- META: membership Holly Sommer
- META: membership Cimri
- META: membership s001gmu@nova.wright.edu
- META: membership Katrina McClelan
- META: Other mailing lists Alex Oren
- META: Other mailing lists J C Lawrence
- META: Web site backgrounds and readability J C Lawrence
- META: Web site backgrounds and readability Cimri
- META: Web site backgrounds and readability Holly Sommer
- META: Web site backgrounds and readability plateau
- META: Web site backgrounds and readability Vadim Tkachenko
- META: Web site backgrounds and readability Caliban Tiresias Darklock
- META: Web site backgrounds and readability Vadim Tkachenko
- META: Web site backgrounds and readability Greg Munt
- META: Web site backgrounds and readability J C Lawrence
- META: Web site backgrounds and readability Caliban Tiresias Darklock
- META: Web site backgrounds and readability Matt Chatterley
- META: Web site backgrounds and readability Holly Sommer
- META: Web site backgrounds and readability Jon A. Lambert
- META: Web site backgrounds and readability Caliban Tiresias Darklock
- META: Web site backgrounds and readability Jon A. Lambert
- META: Web site backgrounds and readability J C Lawrence
- META: Archive message format J C Lawrence
- (fwd) equipment J C Lawrence
- 3D evaluation? J C Lawrence
- META: Archive searching now works... J C Lawrence
- META: Archive searching now works... Bruce Mitchener
- META: Archive searching now works... J C Lawrence
- Fw: [DESIGN] Combat system Richard Woolcock
- [Fwd: Grids and curvature of a sphere] Richard Woolcock
- [Fwd: Grids and curvature of a sphere] Caliban Tiresias Darklock
- [Fwd: Grids and curvature of a sphere] J C Lawrence
- [Fwd: Grids and curvature of a sphere] J C Lawrence
- SfD: AI and muds; several approaches Nathan F Yospe
- META: We have moved. J C Lawrence
- (fwd) Mudlib Design J C Lawrence
- (fwd) SERVER: New Code Base in VB Started J C Lawrence
- (fwd) SERVER: New Code Base in VB Started Jon A. Lambert
- Graphical MUD project (Sea Of Blood) J C Lawrence
- (fwd) Sea of Blood Graphical MUD J C Lawrence
- MAPPING: Creating a bitmaped graphic from map coordinates John Bertoglio
- MAPPING: Creating a bitmaped graphic from map coordinates Nathan F Yospe
- MAPPING: Creating a bitmaped graphic from map coordinates John Bertoglio
- MAPPING: Creating a bitmaped graphic from map coordinates s001gmu@nova.wright.edu
- MAPPING: Creating a bitmaped graphic from map coordinates Jon Leonard
- MAPPING: Creating a bitmaped graphic from map coordinates Caliban Tiresias Darklock
- MAPPING: Creating a bitmaped graphic from map coordinates J C Lawrence
- MAPPING: Creating a bitmaped graphic from map coordinates Vadim Tkachenko
- Gentle Reminder J C Lawrence
- Systems you use Ling
- Systems you use Caliban Tiresias Darklock
- Systems you use J C Lawrence
- Systems you use Adam Wiggins
- Systems you use Jon A. Lambert
- Systems you use Katrina McClelan
- Systems you use J C Lawrence
- Systems you use Katrina McClelan
- (fwd) CODE RELEASE: [client] Jcrossclient - java client to "crossfire" J C Lawrence
- Teamwork Ling
- Teamwork J C Lawrence
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- MAPPING: Creating a bitmaped graphic from map J C Lawrence
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- MAPPING: Creating a bitmaped graphic from map John Bertoglio
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- MAPPING: Creating a bitmaped graphic from map Caliban Tiresias Darklock
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Ben Greear
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Matt Chatterley
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Chris Gray
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
- (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Jay Sax
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Caliban Tiresias Darklock
- (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Matt Chatterley
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Chris Gray
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) Adam Wiggins
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) Jon A. Lambert
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- How to represent a 3d object... Ben Greear
- How to represent a 3d object... Oliver Jowett
- How to represent a 3d object... Ben Greear
- How to represent a 3d object... Justin McKinnerney
- How to represent a 3d object... J C Lawrence
- fwd Room descriptions, was Roleplaying John Bertoglio
- fwd Room descriptions, was Roleplaying Chris Gray
- fwd Room descriptions, was Roleplaying Ling
- fwd Room descriptions, was Roleplaying J C Lawrence
- Room descriptions, was Roleplaying Richard Woolcock
- Room descriptions, was Roleplaying John Bertoglio
- Java for Mud Client (Crossfire MUD topic) Justin McKinnerney
- Java for Mud Client (Crossfire MUD topic) Joel Dillon
- Java for Mud Client (Crossfire MUD topic) Justin McKinnerney
- Java for Mud Client (Crossfire MUD topic) Joel Dillon
- Java for Mud Client (Crossfire MUD topic) s001gmu@nova.wright.edu
- Java for Mud Client (Crossfire MUD topic) J C Lawrence
- Java for Mud Client (Crossfire MUD topic) J C Lawrence
- Java for Mud Client (Crossfire MUD topic) Ben Greear
- Java for Mud Client (Crossfire MUD topic) J C Lawrence
- META: mud-dev@null.net is now decommissioned. J C Lawrence
- META: mud-dev@null.net is now decommissioned. John Bertoglio
- META: mud-dev@null.net is now decommissioned. J C Lawrence
- Group mechanics/Leadership [was: Room descriptions] Shawn Halpenny
- Group mechanics/Leadership [was: Room descriptions] John Bertoglio
- (fwd) [DESIGN] Macro semi-language J C Lawrence
- (fwd) [DESIGN] Macro semi-language J C Lawrence
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Dr. Cat
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Marian Griffith
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Chris Gray
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Koster, Raph
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Adam Wiggins
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- OT: Birth announcement Koster, Raph
- OT: Birth announcement Nathan F Yospe
- OT: Birth announcement J C Lawrence
- OT: Birth announcement J C Lawrence
- OT: Birth announcement John Bertoglio
- OT: Birth announcement J C Lawrence
- OT: Birth announcement Jon A. Lambert
- OT: Birth announcement Koster, Raph
- (fwd) POLL: Games ruined by bad players (Playe Jon A. Lambert
- (fwd) POLL: Games ruined by bad players (Playe Dr. Cat
- (fwd) POLL: Games ruined by bad players (Playe J C Lawrence
- (fwd) POLL: Games ruined by bad players (Playe Dr. Cat
- (fwd) POLL: Games ruined by bad players (Playe J C Lawrence
- (fwd) POLL: Games ruined by bad players (Playe Richard Woolcock
- Some thoughts on languages and users - was: Macro semi Jon A. Lambert
- PK's: A solution? John Bertoglio
- PK's: A solution? Shawn Halpenny
- PK's: A solution? Michael Hohensee
- PK's: A solution? s001gmu@nova.wright.edu
- PK's: A solution? J C Lawrence
- PK's: A solution? Katrina McClelan
- PK's: A solution? John Bertoglio
- PK's: A solution? Holly Sommer
- PK's: A solution? J C Lawrence
- PK's: A solution? John Bertoglio
- META: Membership authentication J C Lawrence
- (fwd) MOB or player? Global Communications on Muds J C Lawrence
- (fwd) MOB or player? Global Communications on Muds John Bertoglio
- (fwd) Confusing? J C Lawrence
- (fwd) Confusing? Chris Gray
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- PK and my "Mobless MUD" idea Jay Sax
- PK and my "Mobless MUD" idea Caliban Tiresias Darklock
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Chris Gray
- PK and my "Mobless MUD" idea Ling
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Koster, Raph
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Jon A. Lambert
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Koster, Raph
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Alex Oren
- PK and my "Mobless MUD" idea Jon A. Lambert
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea s001gmu@nova.wright.edu
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Koster, Raph
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Caliban Tiresias Darklock
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Caliban Tiresias Darklock
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea John Bertoglio
- META: Mail archives and MIME attachments J C Lawrence
- META: Mail archives and MIME attachments Jon A. Lambert
- Bio of John Bertoglio J C Lawrence
- Reuters: Cheaters Never Prosper J C Lawrence
- Correction s001gmu@nova.wright.edu
- Supporting articles found for UOL play style J C Lawrence
- Supporting articles found for UOL play style John Bertoglio
- Supporting articles found for UOL play style J C Lawrence
- Supporting articles found for UOL play style John Bertoglio
- Supporting articles found for UOL play style Koster, Raph
- Supporting articles found for UOL play style J C Lawrence
- Supporting articles found for UOL play style Koster, Raph
- Mud-Client, and specifically, COOLMud and SFWhite Jay Sax
- regulating player-created objects Dan Shiovitz
- regulating player-created objects Adam Wiggins
- regulating player-created objects Dan Shiovitz
- regulating player-created objects Adam Wiggins
- regulating player-created objects s001gmu@nova.wright.edu
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Marian Griffith
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
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
- regulating player-created objects Adam Wiggins
- regulating player-created objects Nathan F Yospe
- regulating player-created objects Nathan F Yospe
- regulating player-created objects Nathan F Yospe
- regulating player-created objects Dan Shiovitz
- regulating player-created objects Shawn Halpenny
- regulating player-created objects J C Lawrence
- regulating player-created objects J C Lawrence
- regulating player-created objects John Bertoglio
- atomic functions Felix A. Croes
- atomic functions Shawn Halpenny
- atomic functions Felix A. Croes
- atomic functions Shawn Halpenny
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Joel Dillon
- atomic functions Jon A. Lambert
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions J C Lawrence
- atomic functions Chris Gray
- atomic functions Jon A. Lambert
- atomic functions Shawn Halpenny
- atomic functions Adam Wiggins
- atomic functions Adam Wiggins
- atomic functions Shawn Halpenny
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions Shawn Halpenny
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Shawn Halpenny
- atomic functions Jon A. Lambert
- atomic functions J C Lawrence
- Atomic functions Par Winzell
- Atomic Functions Ben
- Atomic functions Felix A. Croes
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- (fwd) AD: [custom graphical] whitestar Caliban Tiresias Darklock
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- (fwd) AD: [custom graphical] whitestar J C Lawrence
- DOOM Gets a Storyline? Holly Sommer
- DOOM Gets a Storyline? Koster, Raph
- META: Filtering suggestions J C Lawrence
- (fwd) AD: [custom graphical] whitestar s001gmu@nova.wright.edu
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- (fwd) AD: [custom graphical] whitestar J C Lawrence
- UO in Wired, was OT: Birth announcement Koster, Raph