Difference between revisions of "Ability"
(→Q&A) |
m (→Q&A) |
||
| Line 158: | Line 158: | ||
A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from abi_base.xls, a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts. | A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from abi_base.xls, a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts. | ||
| − | This is one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature: | + | This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature: |
Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information. | Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information. | ||
Revision as of 22:39, 26 October 2009
Note: This page is in process of being rewritten.
Overview
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.
Detailed Description
Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.
The most important 2da file for abilities is 'abi_base.xls', as it defines each ability and all aspects of execution and handling in both scripting and engine code.
| Ability Design Notes
When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow. For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant (such as cunning for rogues) to ensure they stay useful throughout the game.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.
Abilities within the same chain should follow a common theme.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibilityor magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades). |
Basic Ability Types
There are 3 basic ability types in the game, defined by the field 'use_type' in abi_base.xls.
Passive Abilities
Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.
A passive ability may grant up to 3 modifications to creature properties (properties.xls). Those modifications are defined in the passive_abilities worksheet of abi_base.xls and linked to the ability through the passive_id column in abi_base.xls.
Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.
Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids (e.g. HasAbility(oCreature, ABILITY_TALENT_LETHALITY)) directly in the combat resolution scripts. The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.
Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.
Sustained Abilities
Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user. Most 'buffs' are implemented this way.
Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).
Most sustained abilities follow the same pattern:
- They do not have any activation cost, encouraging tactical use of buffs.
- They increase the users Fatigue property, therefore increasing the activation cost of all other abilities.
- They reduce the users maximum available mana or stamina by a constant value.
- They use cooldown to prevent the user from being too opportunistic with their use.
- Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.
Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in abi_base.xls. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).
Gameplay Design Note
|
Activated Abilities
Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as
- Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
- Ground targeted abilities (such as Blizzard or various Glyphs)
- Self targeted activated abilities.
Targeting Behavior
An abilities targeting behavior is controlled by several settings in abi_base.xls
AutoTarget is a boolean field that defines how the UI resolves targeting.
| 0 | The UI will always bring up a targeting cursor. |
| 1 | The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting. |
Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -
TargetType is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.
| Bitmask | Effect |
| 0x1 | Self |
| 0x2 | Friendly Creature |
| 0x4 | Hostile Creature |
| 0x8 | Placeable Object |
| 0x10 | Area of Effect Object (deprecated) |
| 0x20 | Ground (see details) |
| 0x40 | Dead Body (deprecated) |
| 0x80 | Party Member |
AutoDraw is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.
| 0 | The ability will not affect the player's weapon sheath status. |
| 1 | The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities. |
| 2 | The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly. |
Q&A
Q: Where do we find the exact formula for abilities.
A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from abi_base.xls, a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.
This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:
Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.
