[MUD-Dev] A place of my own

[Shawn Halpenny]

On Thu, 25 Sep 1997, Jon A. Lambert wrote:

[ players having someplace to hang their hats]

> I think this topic deserves it's own little time in the sun.  
> I am highly interested in this aspect of virtual worlds and I suspect 
> that there may be many others.  So off the top-of-me-head a few
> questions:
> 
> Should players have houses, castles, furniture, hirelings, etc.?
> 
> How does one go about obtaining this good stuff?

These things should definitely be available.  I intend to let players
either create these things for themselves (and they'll work along with
whatever else, depending on the object security (which is still somewhat
fluid as I'm in the midst of designing it)) or they can purchase them for
favors, cash, or whatever from shops, NPCs, or other players.  In the
second case, these things are prefabricated.  That is, you could buy a
house rather than having to build it.  Each of these devolves down to
essentially the same thing, since once a player has a house, he can modify
it however he pleases.  Essentially, anything can be turned into anything
else, but if you start with something fairly close to what you want, you
can derive a new object from that and modify methods and variables
to make it look and act like your goal object.  There is no reason, though,
why you couldn't take a piece of paper and turn it into a house, it would
just take a lot more work than taking an open room somewhere and making a
house out of it.

> Can it be built by the player, purchased, rented, designed?

All of the above.

> What security mechanisms can a player place in his own space?

First, I'll draw the distinction between security of one's space and
security of the objects one designs.  The latter is managed at a
fundamental game-object level and will (hopefully) be completely
ignorable by those using the objects.  It will prevent things like
Bubba coming along and using his free-user programming talents to
wipe all the descriptions for the rooms of your house and remove all
the locks on the doors without you saying he could.  

The security of one's space can be managed at a much higher level (I
say "can be" since it is certainly not required).  The player can buy
locks for his doors, for example, or program up locks of his own. 
Now these locks can still be bypassed if the intruder is aware of the
interface to the locks, and has the appropriate skills and what not
to get around them.  The difference in this case is that the intruder
will be required to use objects and methods that haven't been
programmed by some user (or that have, but have been accepted into
the game as valid objects (*)).  I'm not yet entirely sure this
scheme will be possible in the fashion I'd like, but I hope to have a
better idea once I've finished the fundamental game object design. 
At the moment, it seems possible and even plausible.

* Any user can create any object that he would like.  The catch is
that the object is allowed limited interaction with other game
objects--it cannot modify any object's data if the object it wants to
modify has been accepted by an administrator.  It can, however,
freely interact with (not entirely the same as modify) any other
user-programmed object that has not yet been accepted by an
administrator.  This is one of the base premises for my low-level
object security.  More details at some point in the future since I
want to bounce this off all of you, but at the moment the model is
in such a form as I would be embarrassed to post.

> Locks, guards, wards, safes, dungeons, chests, secret passages, 
> walls, windows, etc.?

Yep, as above.

> How many rooms, locations, lands, gardens, shops, farms, etc. ?

As many as they'd like.  There is, of course, a cost for these sorts
of things, whether you buy them or you create them yourself.

> What can a player keep there, how about a family, spouse, kids, 
> brothers, sisters, parents?

Anything.  There's no reason a player couldn't have a family.  The
question becomes "how does this player that just built a house get a
family?"  Buying one seems rather awkward, but so does deriving one
from a generic family object (and how would that sort of thing be
represented in a mud world--for me, I suppose a possible out is that
they are cloned or grown in a vat because those sorts of things are
perfectly reasonable in my scenario).

> How about peasants, slaves and other hirelings?  Livestock anyone?

Yep, as above.

> Does a players property produce stuff or resources?  

Well, now, yes it could, but see below.

> How much maintenance and upkeep is required?

Unfortunately in some cases, tonnes.  There exists no way for your
hireling objects to automatically know about your garden object
unless they are programmed that way.  They can't even learn about it,
since they have no idea that they are hirelings.  This is the one,
IMO, huge drawback to user programming:  automatically uniting all
the objects to work together.  I don't think that it can be done. 
The user has to determine how his objects will interact with other
objects, or at least define the interface to allow other objects to
interact with it.  Not for the faint of heart, but wow!  the stuff
you can do.  

To a degree, the impact of this can be lessened with properly
designed generic objects (clearly, I'm hoping I can offset much of
this onto object derivation and put much less emphasis on creating
new object or turning that paper into a house), since if someone has
already done all the work of creating a bunch of hirelings who know
how to garden and all you want to do is have your own, it should be
easy to get them.  

I agree that this topic could do with some sun...probably a lot of
sun.  All this trumpeting of what I'm doing while posing no new
questions.	Hopefully it'll spark some ideas, rather than this wordy
"cool, me too!".

--
Shawn Halpenny

"You got a one way ticket on your last chance ride."
                                        - "Coma"