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
On Sat, 16 May 1998, Brandon J. Rickman wrote:
> On Fri, 15 May 1998, Adam Wiggins wrote:
> > Hrm - that's adding in a whole 'nother layer. I like it :)
> > Of course, it's a pretty complicated layer. I was assuming that the
> > shapes would have basic "socket" types, allowing them to be composited
> > together with shapes that fit into that socket. This allows you to avoid
> > going into detail about *what*, exactly, is holding that axehead in place.
> > Ie, an axehead has a cylinder socket. A wooden shaft has two cylinder
> > ends. This of course, also begs the question of whether you want to store
> > orientation data for the composited objects, or if they just get shoved
> > together into a big mush.
>
> Primitive axes are made with a split/forked piece of wood and the head
> jammed in the split. This is the type of axe more likely to be made by a
> player lost in the woods, which I would think is a more likely reason for
> someone to want to "make" an axe in the first place.
>
> Woods
> You are lost in the woods.
> There is a piece of metal here.
> % look metal
> It is an axehead. On the back you can read the words: "Forged by Chicago
> Steel Ltd. Inc."
> % get catalog from pack
> You take a Sears Roebuck catalog from your pack.
> % order axehandle from catalog
> You flip through the catalog...
> Flipping...
> 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?
> > Yeah - this is where extra data like orientation would come in handy.
> > We never planned to take it this far, mainly because the world we were
> > trying to model at the time didn't have anything this complex anyways!
> > However, now that I think of it, your tree-chopping machine should work
> > just fine. Moreover, a player could easily turn it into an paddling
> > machine by just pulling out all the axes and inserting a bunch of paddles,
> > or a tennis-playing machine by inserting tennis rackets, or a fan or
> > whatever else you want. The 'work' in the system would be defining the
> > components (in this case, the spinning cylinder to which all the sockets
> > belong). From there players could do whatever they like.
> > If there were special-case templates which were too complex to be (easily)
> > handled by this, some special logic (soft or hard code, doesn't matter)
> > could be inserted to handle it...although I'd stay away from anything that
> > requires this sort of complexity, since the whole idea of this system is
> > to avoid special casing like this.
>
> Any kind of template system needs to be very robust and fairly fuzzy. I
> like the idea of standardized sockets, and this would certainly give an,
> er, industrial feel to the game. Can one really not fit a square peg in a
> round hole? In addition to being able to build things in the game, making
> non-standard or jury-rigged things would enhance this kind of template
> system.
Nods - your whole world is made out of tinker toys, leggos, and bristle
blocks. It may not make perfect sense for every case (especially as your
world's technology level increases), but it should be fun regardless.
> > Um, for purposes of what we're discussing, they do NOT make a table.
> > I would be quite confused if I saw:
> >
> > % n
> > Dirt Field
> > There is a table here.
> > % l table
> > The table is made of three people and a staff with a door across the top.
> > % say wtf?!?!
>
> 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.
> > I would much rather see:
> >
> > % n
> > Dirt Field
> > There are three people and a staff support a piece of wood with a knob
> > on it.
>
> This is the computer playing dumb. I would append "one might call it
> a table," to the description. It is now excessively verbose.
Right. You could also append, "...and it's large enough that you could
seek shelter from the rain under it, or sleep on top of it." Where do you
want to draw the line?
> > Remember, the whole *purpose* of the templates is for identification.
> > Rather than telling people every time they see a table that they are
> > looking at "Four wooden legs supporting a flat piece of wood", they
> > just see a wooden table. The templates do not necessarily identify
> > function - I would assume that, if you had rudimentary physics in the
> > world, you can easily place objects on any flat surface and expect them
> > to stay there. You don't need an object template for that, nor do you
> > want one.
>
> 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?
> 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.
> 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.
> > % l
> > You are in a room. There is a door here.
> > % open door
> > You push the door around a little bit.
> > % enter door
> > You crawl under the door and try to hide.
> > % say wtf?
> > % l door
> > The door is a piece of wood with a knob attached.
> > % bug The door in this room doesn't work!!!
>
> - Swinging doors don't stay open.
> - A curtain can act as a door.
> - A window can be used as a door.
>
> The function of these different "doors" is clear to the player, even when
> the object description is poor. From the above, an unhinged door can be a
> lot of fun for the admins: 'Well, today we got another 3 bug reports about
> 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."
To summarize: Templates describe both what an object is constructed of,
and what its implict function(s) are, if any. Thus a curtain is defined
as a sheet of pliant material connected to some sort of sliding mechanism
(say, rings), but does not necessarily have implict function. A door is
defined as a rigid plane attached to hinges. Its implict function is to
stand in doorways. Any other state should be specifically noted.
> > > The final problem: object templates are not hierarchical. Let a bed be a
> > > surface that a person can comfortably lie on.
> >
> > By that definition, practically anything in the world is a bed. If we're
> > going to use definitions that broad, what's the point in having templates?
>
> 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.
> 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!
> > Note that you can handle different folks (from different upbringings,
> > probably) have different familiarity with different templates. A cave man
> > might not know what a table or a bed was, and so when walking into the
> > room would just see strange contraptions of wood and metal. Ditto for a
> > medieval knight seeing a computer.
>
> Ok, so what function would the caveman attribute to the table? Probably a
None. That's the point.
> 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.
> > > A bed can act like a table, if the bed isn't
> > > simply a pile of straw on the floor. This is an area where 3d
> > > representation actually helps: visually, the player may recognize a table,
> > > or a bed, or a sacrificial altar without being told "There is a
> > > table/bed/altar here." But we need the game to recognize the object
> >
> > Right - that was the whole point with templates, was trying to lump things
> > into categories for purposes of display, while still retaining the
> > 'atomic' functionality of the components. As I mentioned before in this
> > thread, if you have a 3d view the need for that starts to disappear. The
> > great thing would be that players *could* build brand new things by
> > attaching materials to other materials (no need for sockets, really) in
> > whatever they configuration they wanted. If they were good they'd produce
> > something which other players would recognize as serving a specific
> > function, as well as actually serving that function.
>
> 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.
Adam
--
MUD-Dev: Advancing an unrealised future. - regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
- 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