Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CF: ideas for next experiments
- To: "'crossfire mailing list '" <crossfire (at) ifi.uio.no>
- Subject: RE: CF: ideas for next experiments
- From: dragonm <>
- Date: Mon, 13 Sep 1999 10:50:30 -0700
- Sender:
-----Original Message-----
From: Mark Wedel
To: crossfire mailing list
Sent: 9/12/99 11:05 PM
Subject: Re: CF: ideas for next experiments
<snip>
----------------
No opinion about boomerangs
----------------
>
> - per-type damage (major change)
> This would require a major change, but since a major object
rewrite is
> in the works now, this seems like a good time to suggest it. We would
have
> a lot more flexibility if instead of one amount of damage that comes
equally
> from an array of attacktypes, each type in an attack had a seperate
amount
> of damage. Instead of taking damage only from whichever type does the
most
> damage with the given base amount, you would take damage from each
type
> you're not immune to that has a non-zero amount.
> This would allow things like darts of lethal poison that do 2
points of
> physical damage and 32 points of poison damage. A flametongue sword
would
> do 8 points of physical damage, and an additional 8 of fire damage.
Against
> a physical-immune, fire-vulnerable creature, it would do 0 physical
damage
> and 16 fire damage, for the same result.
> This would turn attacks into an array of 18 integers instead of
one
> integer for damage and one for the attacktype bitmask, but I think the
> increased flexibility would make it worthwhile.
Having that number of damages to deal with really seems excessive. I am
also not sure if it makes total sense - if you get hit by an arrow, it does
some amount of damage.
What you really seem to be looking at/describing is special effects
damage. (poisoning, arrow bursting into fire, etc). I would instead
suggest that adding a hidden inventory to the weapon and apply/inserting the
weapons inventory into the creature an easier and potentially more flexible
way of dealing with it.
For example, you could have arrows of fireball, which contain a small
fireball object. When the arrow hits, it bursts into a fireball. Or
javelins of lightning (to take AD&D)
----------------
Different damages for different attacktypes is very traditional. Go for it.
But Mark's comments about doing it the easy way are well taken.
----------------
>
> - seperate hitback
> If there was a hitback achetype, a "force" object with attack
stats,
> that could be used for hitback instead of normal attack damage. This
would
> allow things like Flame Shield, which would protect from cold and do
fire
> damage to anyone who hits you, without applying your weapon damage as
well.
> If there is no hitback object present, but the hitback flag is set,
the
> creature's normal attack would be used, as it is currently.
This seems reasonable, and should not be that hard to implement. Costs
some CPU cycles, as anytime an object with hitback is hit, its inventory
needs to be examined for that hitback object. But probably not a big deal.
----------------
Another traditional feature. Go for it. And burn those CPU cycles. It's
not like we have a music engine or a complex 3D graphics engine that needs
the CPU time. :)
----------------
>
> - protection from magic
> Attacktype: magic indicates that an attack is magical, unless it's
the
> only attacktype present, in which case it means that the attack is raw
> magic, such as magic bullets, speedballs, or my new raw magic spells.
> Either way, immunity to magic means you're immune to the whole attack.
> Shouldn't protection from magic similarly protect from the whole
attack? As
> it stands now, protection from magic only protects from raw magic
attacks,
> which aren't really all that common.
Probably so. Not a big change for that.
----------------
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.
However, if you really feel the need to differentiate between a magical fire
attack and a non-magical fire attack, then have immunity to magic provide
some fraction of the benefits of fire immunity against a magical fire
attack, and none for non-magical. (Are there even non-magical fire attacks
available? Is dragon fire considered magical or not?) I wouldn't want a
generic magic immunity to totally negate all effects of more sophisticated
spells. I suspect it would throw play balance for wizards out of whack. A
wizard could just learn that one spell for magic protection, couple it with
a spell for physical protection, and be well-nigh invulnerable.
----------------
> One other concern is that players could set a teleport marker when
they
> pick up some treasure, wait for the map to reset, then create the
portal and
> just step through, into the newly restocked treasure chamber. Or
Recall out
> of the treasure room, wait for reset, and Return back in.
> The first solution that comes to mind is to simply disallow
inter-map
> portals if either one is surrounded by anti-magic fields, and to not
mark a
> Recall location for Return if that location is surrounded by
anti-magic.
> Most treasure rooms already are, to prevent Dimension Door.
> Another method that I like less, but is easier to implement, is to
set a
> short time limit on both Portal and Return, or to make them only work
until
> the map resets.
The 'surrounded by magic' would be a suspect method at best. There are
at least a few treasure chambers out there that you get to by some final
exit to a final map. On this final map with the treasure, no anti magic
spaces are around, because all the protections are to get to the map itself.
It also doesn't work uf there was a gate/door that originally protect the
area but has since been removed for the player to get to the treasure room.
Not being able to teleport to maps that are reset fixes that possible
problem. I wonder if the spells would still be useful enough for there to
still be much interest.
----------------
If there are only a few treasure chambers out there that aren't protected,
it should be easy enough to apply surrounded by 'magic protection' to them.
Unfortunately, while magic Portals that aren't part of a map are another
fairly traditional item, the Crossfire universe doesn't lend itself very
well to their use. The constant map resets are the biggest problem I can
see. As Mark says, they tend to negate any benefit if they disappear when a
map is reset.
Now that the client and server are distinct, we might give some thought to
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.
DM
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]