Re: CF: ideas for next experiments

[Mark Wedel <mwedel@scruznet.com>]

David Andrew Michael Noelle wrote:

> >  I personally would prefer to limit the protections/immunities/whatever to the
> > more mainstream attacks.  Chaos also seems to get used so infrequently at this
> > point that adding anything dealing with protections/immunites woudl sort of be a
> > 'who cares' type of feature.
> 
>     But, that's because it's useless.  Chaos only chooses its elemental
> attack when it is placed on the map (with hit_map), so Color Spray and
> Create Wall (pool?) of Chaos are the only usable forms.  Creatures and
> weapons with chaos attacks are ignored.  That's an easy fix, though.  The
> same function (shufle_attack) can be called from hit_player.  Since chaos
> removes itself from the attacktype when placed on the map, that choice would
> stick, and then each time a chaos monster attacks, it would hit with a
> different, random attacktype.

 Ok.  I don't have a problem with hand held chaos items (sword of randomness or
the like).  The value of a sword is actually interesting - everything will
likely be vulnerable to at least one of the attacktypes as it shuffles through
them, but many creatures may be immune/protected from many of those, so those
attacktypes against them are not very good.

 That said, making creatures immune/protected from these chaos attacks then
greatly weakens such a weapon and the attacktype.  As I describe above, it is
generally a weaker but general purpose weapon (you can use it and always know
that at least one attacktype will damage something, but that is weaker than
using a weapon that does that one specific attacktype).  So in that aspect, a
chaos weapon would be interesting.

 But that makes me think that adding protections to chaos is even a worse idea. 
If that general purpose weapon no longer works because people are now protected
and you instead have to go to a specific attack weapon, the usefulness of the
general purpose weapon is greatly reduced.

>     I just thought of a better compromise, though.  Sort objects by type
> when inserting them into either a map or another object.  Inserting an
> object is done much less frequently than scanning a list, so a sorted insert
> would slow things down a lot less than a sorted search would speed things
> up.

 You still need to have an index to these types to be useful.  And you can't
really sort when going on a map - a top down approach is used - you drop
something on the map, and it is the top object.  A pile of objects is not going
to re-arrange itself so all the swords are together.

 But from the other mail message, it seems that CPU issue on the constant
searching should not be a big deal.  Traversing the list itself is pretty quick
(going to the next pointer and whatever).   If anything, the big cost issue
would be the comparisons, so if searching for an item, using a method other than
string comparison would be hte big gain (do these point to the same thing, or
are these integer values the same, etc.)  Comparing a couple 20 character
strings is probably as costly as traversing 100 objects.

> 
>     I was thinking of having the map keep a pointer to the player's marker
> and remove it when it resets.  Apartments would just not bother to do that.
> If the player leaves the game, any portal markers they might have just
> delete themselves and the map's pointer.
>     Of course, the easy way would be to give the player's portal marker an
> expiration date based on the map's reset time.

 I would prefer not to have this state in the maps.  Maps then need to know
there is a portal on them, and where they point (which means that at that time,
the map has to examine all of its objects and when it finds a portal, do the
right thing, assuming the character is still in the game as hasn't left and
saved off to disk).

 My preferred method would be all that info be in the portal object itself. 
Thus, you only need to validate the destination is OK when the player tries to
use it - if the player creates a portal but never tries to use it, you don't
need to worry at all where it may point to.

 If a player does try to use it, then at that point you:

 1) Is the map actually in memory?  If not, is it an apartment map?  If not, the
teleport fails.
 2) Load the other map if necessary, and check to make sure the destination is
still there.  If not, teleport fails.

 Note that portals to apartments needs to be thought.  Suppose merlin has an
apartment, creates one end in that, and goes on an adventure with his friends. 
He creates another portal to go home.  Can his friends use it in that case?  And
if they can, where to they end up?  IF they end up in merlins apartment, that is
now a place they were never able to get before.  IF they end up in their
apartment, that is a little strange since a portal was never created there
(although the fact that as many people can have a unique apartment off the same
map isn't the most realistic)
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]