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
On Mon, 18 May 1998, Adam Wiggins wrote:
> On Sat, 16 May 1998, Brandon J. Rickman wrote:
> > You can't find that item.
> > % search catalog for axehandle
> > You flip through the catalog to the index...
> > Axehandles .. page 83
>
> As amusing as this exmaple was, I'm confused as to what you're getting at.
> Are you saying that my socket definition is too vague, or saying that it
> makes sense?
I was just considering how an Industrial Age mud might play. Having
access to machine tooled and standardized parts is not a normal part
of a medieval mud. But adding some kind of deviation key in addition to
the socket type could disguise this nicely. For example:
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.
> > But such an object could /act/ like a table - you could put things on top
> > of it, or seek shelter from the rain under it.
>
> 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
important that the server gets the _name_ of an object correct, more
important for it to get the _implied function_ of the object correct.
> > I would say you do, because you want the game to understand what you are
> > trying to do. If it doesn't recognize the idea of a table then objects
> > will never "fall off" the table. (Short of a ridiculous amount of "real"
>
> Huh?
If an object isn't recognized as a table then it can't behave like a
table. Perhaps there is a special event when something falls off a table,
a different event than when something falls off a shelf, or out of your
pocket. (In a traditional MOO setup, tables might "contain" objects, a
particularly horrible but consistent implementation.)
> > physics, which in my opinion would detract more from the game in their
> > misapplication than they ever add in the rare case of an object behaving
> > "realistically" - an object falling off of a table.) Players have an
>
> Hrm, I consider those kinds of physics to be a given. It's much too
> difficult to model a "real"-seeming world without some basic rigid-body
> physics; in this case, gravity, but also collision and possibly some
> extras like surface friction, angular momentum, and fluid dynamics. These
> things are particularly easy to implement in a text world where you can
> fudge things quite a bit.
> Figuring out whether an object is going to stay steady on top of another
> object is not difficult. In the shape-based world that I've been
> describing in this thread, I'd simply say that you can only set other
> objects on top of 'plane' shapes whose size is >= the object's size, and
> their chance of falling off is proportional to the plane's angle relative
> to the angle of a given vector of force, where the main vector of force
> that you are interested in is gravity.
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.
> > intuitive sense of function: pointy things are weapons, top-heavy things
> > can be pushed over. How can the game sense that which is obvious to the
> > player?
>
> 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?)
> > the broken door quest.'
>
> Nods...again more ambiguity based on the fact that practially any object
> can be used for any function if you try hard enough. I implemented
> swinging doors on a mud once; the open command gave a message like so:
>
> You open the door, but as soon as you let go it swings back closed.
>
> Later, when we had a slightly more advanced character state system, I made
> it so that the open command would just leave you holding the door open
> until you did something else that required your hands or moved you away
> from the door.
> This might be slightly confusing to someone, but the words "door" and
> "open" still make sense in this context.
> 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. ;)
> > In a very homogenous mud world (which is most of them) yes you can sleep
> > just about anywhere. Is this not absurd? But what is wrong with being
>
> Erm, I don't find it very absurd. When I go camping I sleep on the
> ground. If it's warm and dry out, I need no extra equipment. Does this
> mean that the earth qualifies as a bed? I also have slept at my desk at
> work, the computer lab at UCSD, people's cars, people's floors, lecture
> halls, and a dozen other places. The only thing that is really necessary
> is that I be able to sit down; I can do that pretty much any place that
> contains a semi-rigid surface.
>
> I define a 'bed' as being a bedframe with a matress, a pillow, and a
> blanket. I have never refered to my desk as a bed or my keyboard as a
> pillow, even though they have functioned that way on many occassions.
>
> > able to find a bed/comfortable place to sleep? A lake is not a good bed.
>
> Again, material. Too pliant, therefore doesn't support your weight. Good
> fluid dynamics should take care of this well (a creature which can float
> on water could sleep in the lake just fine); if not, a simple test to see
> if the material of the object you're trying to sleep on is not in a solid
> state (meaning liquid, gaseous, or plasma) will do the trick quite nicely.
>
> > 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
back to templates and object function, is there not a greater benefit from
sleeping in a bed-template? Do people only sleep in actual beds, in
actual houses, to avoid being attacked by random monsters? [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.]
> > We need to be able to find that
> > functionality, or perhaps recognize its lack. Hmm, that is something to
> > think about.
>
> 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?
> > good shelter from the rain. And the knight a computer? Something that
> > sparks and fizzes when you smash it. The destruction of objects is tied
>
> 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.
> > This is the illusion of 3d: it is easier to make something look like an
> > object than to make it behave like an object. Building things
> > quickly loses its charm when the objects don't develop their own
> > behaviors. I have seen enough super-high-tech 3d game engines (object
> > oriented! with behaviors!) to say that this is a major problem, that
> > these simulations lack any kind of large commercial appeal.
>
> Which ones do you refer to?
> And yes, I'd say this is a major problem with games these days in general.
> 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...
- Brandon Rickman
What kind of future was that? - regulating player-created objects Adam Wiggins
- regulating player-created objects Brandon J. Rickman
- 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