Re: CF: ideas for next experiments

[David Andrew Michael Noelle <>]

Mark Wedel wrote:
> 
>  But how many weapons have more than a few attacktypes?  And as you said, many
> attacktypes don't actually do damage, so nothing is needed for that.  And some
> objects can use the standard damage for multiple attacktypes.

    Okay, I'm convinced.  One damage number and an attacktype bitmask is
still the best way to go.  I definitely want to try that attack inventory
idea, though.  There are probably rather few weapons for which it makes
significantly more sense to have multiple attack vectors with seperate
amounts of damage.  And those can just insert an extra attack in the weapon.

    An additional bonus of the attack inventories is the ability to give
them durations or numbers of charges.  Poison is the obvious example, as you
mentioned.  Another that comes to mind is allowing a priest to pick up a
weapon, bless it, and hand it to someone else along with the blessing.  Or
making a holy weapon temporarily unusable if it's used to kill one of it's
god's friendly creatures.  Or a demonic sword that gets a temporary bonus
every time it kills something on its slaying list.  This opens the door to
all kinds of neat effects.


>  Don't be so sure about memory usage.
> 
>  The extra object in the inventory only costs extra memory for copies of those
> object currently in play (ie, on a map, in someones inventory).
[...]

    Point well taken.


>  I think the way it works now is probably fine.  Chaos really should not be an
> attacktype (just like ghosthit probably should not be), since they more describe
> effects than actual damage.
> 
>  With that, chaos really creates the elements of the different types.  IT
> doesn't attack with chaotic fire - it creates fire which then does it normal
> affect.
> 
>  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.


>  The only planned difference in 0.96 is to split creatures (including players)
> inventory with a visible and invisible inventory.  This makes various aspects
> easier (don't have to worry about skipping over invisible objects in containers
> or in the inventory and like), and should make it faster to find the abilities.
> 
>  Being that things are stored on a linked list, there is no easy way to index
> stuff (since the objects themselves are in non contiguous memory) save of
> dynamically creating an array with hashcodes or indexes into the inventory or
> something of the like.

    That's not exactly what I meant.  If there were an array of pointers by
object type, and each object had a pointer to the next and previous object
of the same type in addition to, or instead of, the current next and
previous pointers, it would take up a good deal of extra space, but save a
whole lot of computing.
    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.  
    IMHO, A binary search tree with a parent pointer would be the ideal
structure for this.  fix_player could even balance the tree to improve
performance, since only player inventories are likely to need that, and
fix_player has to look at everything in your inventory anyway.  That, in
addition to a function that takes a list of object types and an inventory
and returns a list of pointers to the objects of those types in that
inventory, would speed things up significantly.
    In terms of space, this option would only require the adition of one
more pointer.


>  Note that archetypes are already indexed by hash table, so when you request a
> new archetype, that is pretty easy.  Since archetypes get loaded once and don't
> change, that is easy to do.

    When I mentioned searching for archetypes, I meant searching for
instances of an archetype in a list, such as a character's inventory or a
stack on a map space.  That is done less frequently than searching by object
type, but it is there.


>  apartments reset just like other maps.  Just the contents don't change.

    Oh yeah.  Right.  That's what I meant.  They don't revert to their
original state (the generic map they're copied from the first time they're
opened) when they reset.


>  Depending how portals are implemented, this may not be a big deal - the second
> portal object (which points back to the apartment) could know it points to an
> apartment and have some flag so it knows that a reset apartment is still valid
> or something.

    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.


>  Note that I believe the current reason for magic protection working the way it
> likes is to probably sort of mimic the AD&D idea of magic resistance in
> monsters.
> 
>  For background, some monsters in AD&D have some percentage value of magic
> resistance.  When hit by a spell, roll the percentile dice, and if less than
> that value, the spell does nothing.

    And there's the difference: percentile.  Crossfire only has 0%, 50% and
100%.  And 200% if you count vulnerability.  When additive protection is
implemented, the current magic-immune creatures can simply be given high
resistance.  The usual reason for magic immunity in monsters is to make them
immune to their own spells.  That can be done more directly with a simple
check to make spells not harm their owners.  (Whether to extend that to
players catching themselves in their own area of effect is debatable.)  This
would mean spellcasting monsters would still be able to harm each other,
though.  Giving them strong, but not complete, magic immunity and reducing
the number of them grouped together would lessen that problem.

    What we might do in the meantime is make magic-immunity provide complete
protection from raw magic attacks, but only 90%, or even 75% protection from
other attacktypes in a magical attack.


>  There has been discussion about making some aspects more persistent.
> 
>  Instead of a shop completely resetting, rotate portions of the inventory
> through.  So eventually all that stuff sold would disappear, and other stuff
> would rotate through the inventory.

    Oh, right.  I forgot about the whole shops thread.  That's probably the
best bet for a next step in persistence.

-- 
            -Dave Noelle,                 
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Disclaimer: Disciples of E(vi)L may receive guidance in alt.religion.emacs.
GNU Emacs is The One True Editor.  The $PATH to redemption is /util/gnu/bin.
U.C.L.A. doesn't share my opinions; even Emacs can't make life that good.

Quote of the Day:
"The fastest way to accelerate a Macintosh is 9.8 m/s^2"
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]