Introductions and

s001gmu at nova.wright.edu s001gmu at nova.wright.edu
Fri Dec 12 16:45:22 CET 1997


On Fri, 12 Dec 1997 coder at ibm.net wrote:

> 
> On 10/12/97 at 01:33 PM, s001gmu at nova.wright.edu said:
> 
> 
> >On Tue, 9 Dec 1997 coder at ibm.net wrote:
> >> On 18/11/97 at 07:47 PM, Mike Sellers <mike at online-alchemy.com> said:
> 
> >> Because I expect namespace viruses to become very common...
> 
> >can you give a definition for 'namespace virus' please?  I'm having 
> >problems pickup one up from the context clues. :}
> 
> Given private namespaces and free user programming, one of the first
> targets to be attacked are characters private namespaces.  Essentially a
> namespace virus is something which attempts to corrupt, delete, or
> re-write a character's namespace without the character's knowledge or
> consent.

Ahh... quaint.  Sounds very similar to one of the side effects of a spell 
system I was thinking about.  I was toying with storing the 'code' for 
spells in the game database.  The interesting side effect is that since many 
spells would be designed to modify the database, what's to stop a spell 
from modifying another spell?
 
> >> thinking about this one.  I currently have two types of mappings:  a name
> >> string that maps to an internal unique ID value, and a name string that
> >> maps to a list of such ID values (ie individuals and groups).  Creating a
> >> group is a special process as compared to creating an individual name
> >> assignment.  In the general case I have newer name assignments override
> >> ones, thus:
> >> 
> >>   > l
> >>   There is a troll here.
> >>   > name troll Bubba.
> >>   > l
> >>   Bubba is here.
> >>   An elf walks in.
> >>   > name elf Bubba
> >>     // I'm in debate over whether to warn the character over the prior 
> >>     // existance of the Bubba name assignment, or to prompt directly into 
> >>     // a Bubba group name assignment.  Currently I do the latter, but 
> >>     // allow replacement for:
> >>   > l
> >>   Bubba is here.
> >>   There is a troll here.
> 
> >mmm.. but what if they really are both named Bubba?  
> 
> Who cares?  Remember: private namespaces.  They have no names until you
> name them.

ok, better question, what if I want to name both of them bubba, in 
defference to their requests to be named as such?
 
> >I personally know several Mikes.  
> 
> No, you know several people whom you happen to call, "Mike",  The fact
> that they also prefer to be called "Mike" and are commonly called "Mike"
> is both coincidental and convenient.  

Aye, true.  I personally know several ppl whom I label Mike.  Better? :)

> I don't encourage either that convenience or coincidence in my game.  I
> almost encourage the reverse.

Is this to 'solve' the problem by making sure it doesn't arise, or do you 
have other, in game reasons?

> <snip problems with multiple bubba/mikes>

> True, this is a weakness.  <sigh>  I really don't want to have to do a
> category deliniation every time I have two objects with identical assigned
> names...(ie find a suitable deliniating difference).  More thought is
> required.

I don't see how you can get around it.
 
> >> Ideally the list would be keyed by most recent reference, most significant
> >> interaction with character etc rathe than simple race.
> 
> >I think this idea solves the problem... just show (for the above case):
> 
> >>l
> >You see:
> >Bubba the elf (or other defining characteristic)
> >Bubba the troll (...)
> 
> If I do go for a graphical system I can of course ignore it for the
> general case of the game telling the user what he sees.  Just label each
> body "Bubba".  The interesting part arrives when the player attempts to
> reference a specific Bubba.

Well, technically, you're not ignoring it.  You are letting the graphical 
image provide the more subtle, delineating differences.  A picture is 
worth a thousand words, neh?

As for referencing a specific Bubba, I'd be tempted to fall back on a 
diku-ism.  'Say "hi" to 1.bubba.'  Kludgy, but saves a LOT of typing and 
parsing.  Heck, build the parsing in and allow the #.<name> as an option, 
if you insist.  :)
 
> >This ties in nicely with another thread which appears to have died off, 
> >about determining what characteristics of a character are most striking, 
> >to generate a decent description when you don't know the person's name 
> >(IE: a man with striking blue eyes is here).  you can apply the same 
> >algorithms to the subset of Bubbas the character knows and tag them by 
> >their striking characteristics (IE: Bubba w/ blue eyes, Bubba the Troll, 
> >etc).
> 
> True...
> 
> >I'd be tempted to take it a step further and allow the player to override
> > the later descirption with a surname of sorts... so instead of getting 
> >Bubba the troll with a large nose, the player could just assign Bubba 
> >Bignose or somesuch.
> 
> Yup, I currently have support for this, but it really is an incompleat
> answer.

How so?  If you have a system that lets you fist assign the name 'Bubba' 
to the 'Troll with a large nose', and then 'Bubba' to the 'Troll with 
Blue eyes', giving you 

 >l
 Bubba, the large nosed troll,
 Bubba, the blue eyed troll

when they are in the same room, and then the ability to further assign 
'Bignose' as a surname to the first Bubba, resulting in

 >l
 Bubba Bignose,
 Bubba, the blue eyed troll

what situations doesn't it cover? If we can get a nice and convoluted 
example of where this fails, maybe we can work something else out to be 
more generalized.  :)

-Greg



More information about the mud-dev-archive mailing list