Re: CF: ideas for next experiments

[Mark Wedel <mwedel@scruznet.com>]

David Andrew Michael Noelle wrote:
> 

> 
>     If special effects damage and multiple independent attacktypes were
> rare, I'd agree, but they're not.  After the first few levels, you don't
> encounter many creatures with only one attacktype, and it doesn't take long
> for most players to start hitting with four or five different attacks, which
> might all be from different sources.  As it is now, the damage value of the
> weapon determines the strength of all of the attacks.  Which means the fire
> in a Flame Tongue sword burns hotter for stronger players, and creatures
> take the same damage whether they're immune to the fire, immune to the
> physical sword, or neither.

 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.

 But also how the special attacktypes do damage could be a matter of opinion. 
The blade of ice, for example, could do its cold damage by being extremely cold
- as such, a high strength and other factors for damage makes just as much sense
as for physical attacks (the rational for physical attacks is that high strength
means the weapon is impaled further, and the same for a blade of ice would be
true - the extrem cold affects would affect more/deeper into the body).

 This may not work for poison, since it actually creates a long term poison arch
to add into the creature.  REally, poison should be handled by the additional of
an inventory item in the weapon (thus would also allow players to actually
poison their weapons).


>     Special effects in a weapon's inventory are a good idea, and
> significantly easier to implement, but I'd rather use those for special
> effects and keep the common effects together, but independent of each
> other.  If things like Flame Tongue and poisoned arrows have extra objects
> attached to them for their poison and fire effects, that will cost
> considerably more memory than a few more integers in the attack type.  I
> think a specific example is in order.

 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).

 If you add extra damage fields (or any extra fields), that memory usage will be
for all objects of that type.  So if the weapon object type is made larger, than
all weapons use more memory.

 In the end, there is some tradeoffs (maybe 10 objects with the extra fields is
the same as 1 object with inventory).  Note of course not all weapons would have
inventories - in fact, as I see it, it would actually be a fairly small number.

 In addition, that object in the inventory may be an actual different object
type (an effect and not a weapon), which is likely to have a smaller memory
footprint.

 The analysis of memory in this case is not worth it.  What I would really say
is lets not use memory usage as a justification for one method or another at
this point.  I personally would prefer cleaner code and the expense of memory
and cryptic code that minimizes memory usage.  Which is sort of what the 0.95 to
0.96 tradeoff will be (although I have yet to do an actual memory analysis
there)



>     By the way, some anomalies I discovered while testing my "mental"
> attacktype:
> 
>     chaos - Protection from, immunity to, and vulnerability to chaos don't
> exist.  Attacktype chaos does nothing at all for weapons or missiles.  It
> only works for spells.  I suggest making chaos a flag, like magic, that
> qualifies other types of attacks.  That way protection from chaos would
> protect from whatever form the chaos currently takes, in addition to your
> normal vuln/prot/immunity to that attacktype.  Ex. A player who is
> vulnerable to fire and takes double damage from normal or magical fire, but
> has protection from chaos, only takes half damage from chaotic fire.

 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.


>     Since most things that have hitback wouldn't have much of an inventory,
> it shouldn't cost much to search for it.  Which reminds me--  Are the new
> 0.96 objects going to be indexed by type or sorted by archetype or
> something?  Hash codes maybe?  We need a better way to search inventories
> for certain types of objects.  There are way too many repetitions of the
> same basic loop that scans a player's inventory, sometimes recursively.

 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.

 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.

 For players, where the size of the inventory may very wildly, that is
difficulty to do.  An index table of 50 won't work very well if the player has
100 items in their inventory (and the more they have, the more you need such a
feature).  So either you make a very large hashtable that you know is large
enough (which then consumes more memory), or you dynamically grow it, which
causes you to re-file the hash table, which impacts cpu at that point.

 There is no good solution to this.  Ideally, better programming may be needed -
if something is going to search the inventory for 10 different objects, it
should just traverse the inventory once, and store the 10 different objects as
it finds them.


>     Sure it would.  You can leave a portal marker in your apartment as long
> as you like, since it doesn't reset.  That way you can always jump right
> back to your apartment, even if it's not in Scorn.  There's also that one
> room in the adventurer's guild where things can be stored.  And even if you
> mark a map that will reset, the mark won't expire for several minutes.  You
> just have to think ahead and only cast a Portal when you intend to use

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

 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.

 You really don't want to have the load the map from disk to see if the
destination is there.  So when a player opens a portal, some quick checks would
be done (does that map exist, and is there a copy in memory or in the temp
area).

David Andrew Michael Noelle wrote:
> 
> dragonm wrote:
> > I've always thought that part of the point of having more sophisticated
> > spells, i.e. fireball instead of raw mana attacks, was to go the extra yard
> > and make the attacktype appear to the attackee as a fire attack, rather than
> > a magic attack.  Where the fire came from should no longer be an issue,
> > magical or non-magical.  Once the spell is cast, the result is real fire.
> > If you want immunity to fire, magical or otherwise, you need immunity to
> > fire.  Immunity to magic should not affect a magical fire attack.
> 
>     This is not my proposal, this is how things currently stand.  Magic is
> only an attacktype when it stands alone.  Otherwise, it is an attacktype
> modifier.  Immunity to magic makes you immune to the direct effects of any
> magic spell, and there are rather a good number of magic immune creatures in
> the game.  The one loophole that allows mages any chance of dealing with
> those creatures is that magically summoned creatures have non-magical
> attacks.  One of the reasons I'm proposing this God of Magic is to put the
> most common magic immune creatures, beholders and skulls, on his slaying
> list.

 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.

 This of course works easy in a real life game where the GM can make judgement
calls on what is magical and not magical and should the monster get a roll or
not, and so on.

 Now maybe that should not be - maybe creatures should really just be immune to
the specific types (fire,cold, electrical, etc), and do away with the idea of
magic resistance (and thus rethink magical attacks).

 I don't really have a good answer - the current implementation makes things
more complicated, and a mage can't do a thing against a magic immune monster.


> > taking advantage of the existence of the server and having a more persistent
> > universe.  I think that would dovetail well with the stated intent to become
> > more RPG-oriented.  It would obviously have some truly immense ramifications
> > to how maps are made and how quests are implemented and basically how the
> > game is played today.  However, I think it deserves some thought, and some
> > consideration as a long-term goal.
> 
>     Yow.  Major change there.  Even if that was adopted as a long term goal,
> I don't know how we could move in that direction without changing the basic
> nature of the game.  Maybe a few non-resetting rooms here and there in
> towns, but all of the dungeons are designed on the principle of being reset
> frequently.  I suppose artifacts could be made more unique by not placing
> them on their maps if any player who is known to have one either in their
> inventory or in their apartment(s) is currently in the game.  That's about
> as far as I can see it going without a complete replacement of all the maps.

 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.

 The problem with doing this with dungeons is there is no current method of
regenation - if cleared out, it is empty until it resets.  And to try to put
programming logic in this would be very difficult.

 as an multiplayer game, you sort of need stuff to reset - otherwise, the first
people that venture onto the server would do all the maps, and leave nothing for
anyone else.

 But it is unrealistic that stuff does just reappear - you completed the pirate
quest, and two days later they are back again.

 From an RPG perspective, that makes it less itneresting, because the player
feels he didn't complete anything that has a permanent (or even long lasting)
affects.

 I don't have a good solution to that however.
-
[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]