This describes how combat is realized in the game. It contains low-level programmer explanation,
and therefore might not be suitable for a random visitor.
This is sub-layout for documentation pages
As the game engine was written, there are abilities, that character might use.
They are divided into different groups, but the basic idea is, that whatever damage/combat action is taking place, an ability is being used. If some new element would be added to game (for example burn damage over time, or poison damage over time), then simply new ability would be added to database, hidden from players (as poison might not be used as ability by player/monster, since it will be only the resulting effect of some damage.
Therefore, if a weapon or standard attack shall poison enemy or set it on fire, a new instance of such ability is created, and attached to the player object.
Abilities are divided to 2 groups: basic and non-basic. They are further divided to following categories according to their type:
A basic ability can be any ability of any ability type described above.
To know, whether it is basic ability, in a database is in a table
containing ability info column with a bit, telling whether the ability is basic or not.
All basic abilities are assigned to every character in-game world. That includes the Player, Monster. There might be a restriction for using the basic ability, such as level, or something else.
A non-basic ability must be acquired by a player, by buying a scroll, etc. A scroll is a special item that provides some specific ability.
To describe abilities, the structures used by abilities must be described first. Here, structure is just a set of information that relates to an ability.
Every ability has this related set of information.
Ability info structure contains general information about the ability, such as
whether it is basic ability, or not, cooldown time ...
Damage info is held in table dol_abilityInfo in the database
Damage info structure contains information related to damage that the ability
might deal. Surprisingly, not all abilities have that (such as aura, which might
not deal any damage at all).
Damage info is held in table dol_abilityDamageInfo in the database
AOE info structure contains information related to only area of effect
That info is held in table dol_abilityAoeInfo in the database
Aura info structure contains information related to the only aura
ability. Contains info such as the foreign key to stats modifier,
or whether the aura is a repetitive effect, available targets...
That info is held in table dol_abilityAuraInfo in the database
Projectile info structure contains information related to the only projectile ability.
Contains info such as the maximum lifetime of projectile
That info is held in table dol_abilityProjectileInfo in the database
Teleport info structure contains information related to the only teleport ability.
Contains info such as where the teleport leads to
That info is held in table dol_abilityTeleport in the database
Melee ability might be used only when a character is near to the target
(= exists incident path node to the target's current path node, and the
attacker is standing on it).
Note: Of course, there are other restrictions, such as level, freeze effect, etc.
Melee ability has related damage structure and ability info structure
Projectile ability creates a projectile, which heads in some direction.
The behavior of the projectile depends on the projectile class structure.
The projectile, however, never chases the target. Projectile ability has related damage structure, projectile info structure and ability info structure
Missile ability is Projectile ability (the structures and databse structure stays same),
only has different behavior of projectile.
The casted projectile has target character assigned, and chases the character forever.
In database is bit telling whether projectile ability is a missile
Projectile ability has related damage structure, projectile info structure and ability info structure
Let's imagine, that we have 3 players, where 2 players attack the third:
Let's imagine, that player 3 dies.
Because he dies, he will respawn, and as he is respawned, calling function to ask, whether he is valid target will return true (because he is alive...).
This would result in fact, that even after death, monsters will continue to attack you, which is unwanted behavior.
To solve this, there must be somehow removed reference from player 1 and player 2
to player 3 in order to stop attack.
Naive solution would be as follows:
The idea is to keep a key in each character (Player / Monster),
which will be copied to attacker.
Attacker will attack target, if keys match (plus some other game checks for rules).
If we want to stop anyone from attacking some specific character, then we simply change the key.
Once attacker want's to attack target, and keys do not match,
then attacker will remove the target reference, and will no longer attempt to attack him.
The complexity of this solution is \(O(1)\)