[CF-Devel] Spell object idea.

[crossfire-devel-admin at archives.real-time.com]

  One of the TODO items for almost eternity is the idea of making spells be 
objects, instead of having a table.  What is below is my write up of that idea.

The reason I am thinking about this mor right now is because of the skill redo - 
one of the ideas mentiond that seem to receive a bit of positive support was to 
split the current set of wizardry into a few subcategories.

  While having spell objects isn't necessary to do that, it makes things easier 
- it is likely there are some number of spells that should be available to these 
multiple disciplines - under the current mechanism, that basically means adding 
a new spell for each of those cases, with some amount of code.  With spell 
objects, its just a matter of another arch, and that's it.

  Plus, I think its a good idea put as many things as reasonable into object 
form - this reduces code.  One case this coudl be considered an advantage is 
scripting - if spells are objects, the basic building blocks are already there 
for the scripts to manipulate this informatin (give playera new spell, remove 
one from their inventory, etc).

--

  In the old model, each spell had a specific number associated with it.
Monster spell abilities, while object, just said to use spell number
X.  Given that everything else in the game is object, this hardcoding
of spells was less than ideal.

In the new system, spells are objects.  The spell object the player knows
has the characteristics of the spell.  As a first pass, the existing
spells are just converted to object form.  As time passes, new spells
can be easily added in this system.  It also simplifies the code - the
spells a player knows are now objects in his inventory.  The spell
a wand casts is the spell in its inventory.  The spell a scroll casts
is the spell in its inventory, and the spell you learn by reading
a spellbook is the spell in its inventory.

This model makes it very easy to make variations of some spells.  Want
to make an extra large fireball?  All this is needed is to take the
large fireball arch, increase a few paramters, and your all set.

The following is the fields in the object structure, and how they
correspond to a spell.  Fields that are not mentioned are not used.

char *name: Name of the spell (large fireball, icestorm, etc)
char *lore: Description of the spell to be put in books, or perhaps even
    to just let the player see.  In a sense, this puts documentation of
    the spells within the object, instead of having to maintain seperate
    files.
float casting_speed:  How long it takes to cast the spell (was time)
face/anim: If the spells is a generic spell that doesn't have an other_arch
    pointer, this is the face (or animation to use when the spell is
    cast.
uint8 type: SPELL (to denote this is spell object)
sint16 resist[] values: For protection spells, resistance they provide.
uint32 attacktype: Attacktype of the spell.
uint32 path_*: spell path information.  Note as of this writing, only
     path_attuned is expected to mean anything.  However, I can envision
     the user of path_repelled/denied to denote that if the caster is
     attuned to some path, they have penalties in casting this spell.
sint32 value: Base value of this spell for scroll, spellbooks, wands, rods.
sint16 level: Level of the spell
other_arch: archetype this spell uses.
char *skill (new): Skill needed to cast this spell.
sint32 subtype (new): Sub classification for this spell.  It sort of
     relates to the existing spell number, but in a more general form.
     At first pass, subtypes would fall into protection spells, bolt
     spells, ball spells, cone spells, stat increase spells.  There
     are a number of spells which can not be abstracted and are unique
     in their own right (dimension door, word of recall, polymorph, etc).
     In these cases, there will be one value for that spell type.

 From living/stats substructure:
Str, Dex, etc: If spell changes and ability, this is the ability it changes.
sint16 dam: Base damage the spell does:
sint16 sp: how many spellpoints the spell costs
sint16 grace: how much grace the spell costs
sint16 maxsp/maxgrace: Every 'maxsp/maxgrace' levels beyond its base level,
     the spell cost doubles (this is pro rated like the old code.  For example,
     if a first level spell costs 5 sp, and maxsp is 5, then at level 6 it
     would cost 10 sp.  However, at level 2, it is 6 sp, level 3 is 7 sp,
     etc.

TBD:
bdur (base duration), ldam (level adjustment for damage), ldur (level
adjustment for duration): These need to get put into some field -
I'm undecided if it makes more sense to add new fields (instead of
overloading existing ones).

There are also many fields in the spell structure which are not
copied - charges, scrolls, scroll_chance, books, range, defensive,
cleric, onself.

The defensive, range, and onself can largely be derived from the
subtype above.  if subtype is protection or healing, it'd be
self.  A cone, bolt, or ball would be range.

range is very important - range would determine blast area of ball
spells, range of cones, etc, and thus probably be one of the fields
that people are more likely to update (huge fireball, etc).

cleric is basically redundant now - the skill says what skill to use
for this spell.  Note that a spell could in theory cost both mana
and grace - what it costs is not necessarily tied to a skill.  However,
it would be bad practice to make a wizardry spell use mana.  However,
I could potentially see hybrid skills that have some variosu benefits,
or if we have say a 'magic' god, perhaps some special spells it provides
a use mana.

So lets next touch on the idea of treasurelist for spell objects.

As mentioned above, spell objects, like wands, spellbooks, scrolls,
etc, contain the spell they cast.  The way spells end up in those
objects is via a mechanism there is already code for - treasurelists.

Currently, the treasure generation code notices if a wand, rod, spellbook,
or scroll is generated.  If so, it calls special code that looks
at the field of the spell structure and randomly chooses a spell.

Instead, this is just replaced with treasurelists.  The scroll object
would have a 'randomitems scroll', wands a 'randomitems wand',etc.  These
may be big treasure lists, but that shouldn't post any problem.  More
likely, these lists would be broken up into smaller pieces (eg,
scroll_low_level, scroll_medium_level, scroll_high_level).

  This provides finer resolution than is currently allowed in the spell
structure - you could make some spell available only in rods, but not
wands.  you can better adjust things to better spells show up in
tougher dungeons, etc,  The only thing that is really missing here is
how to figure out how many charges to put into wands.


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel