WIP: Spells

[ghost]

This is a WIP for defining the "Spells" system.

[ghost]

@Nemikolh and I were thinking about trying to rework this proposal to get a more functional approach, which could make things easier to understand.

We will thus need to define the syntax and system to:

• Transform my current "tree" structure into a Directed Acyclic Graph
  • Need to define how to assign different outputs to a single input
  • Need to define what kind of properties an output must meet to be assigned to an input
  • What kind of storage will each node require
• Probably need to define some standard functions, like foreach, enumerate etc.
• What do we expose to AaribaScript VS what we expose to this scripting language
• ... And probably many more questions

cc @lethom

[ghost]

I updated the proposal after a discussion with @Nemikolh. There are still many unresolved questions, such as:

• how to introduce a list of "ignored" entities for a projectile/AOE (for example to implement a piercing projectile)
• how to introduce time for an AOE
• how to introduce variable hitbox, maybe speed as well ...

[lthms]

I’m loving what I just read.

[ghost]

About the time for an AOE, was thinking about an effect that trigger another spell every X ticks / ms For instance, a "blizzard" spell would have as a main spell-effect, an effect that triggers another spell (with the uuid of that spell as metadata somewhere) every X ms, for a set duration (or as casted spell, as long as the spell is casted)

I personnaly think that key resides in the spell effects arch-types that your system will be able to handle, while keeping the spell as a whole quite simple, the effects arch-types can be really complex on the other hand :)

Keep up the good work :)

[Nemikolh]

@arenglebert Thanks for the feedback! I think the main problem we currently have with AOEs is to about deciding "when" an AOE should be executed and what does it "sees":

1. Is the AOE script executed independently of the entities arriving and leaving?
2. Does the AOE script sees all entities?
3. Or maybe the AOE script only see 'enter' and 'leave' for each entity and can apply effect that are handled by lycan?

All those situations solves problems and have their own problems.

In case 1), the logic is easy to understand but you may have weird situation for slow AOE. An entity could pass over it without being affected whereas another one would be affected as soon as it enters the AOE. A solution for this is to have the script being started per entity traversing.

However, what if we want to apply damages proportional to the number of entities in the AOE, or maybe something more complex? The easiest way to go with that would be to give to the script the list of all entities. But then, this no longer work with the solution of the first problem. But we could just say, that it is a limitation of the system, period.

Last, we might simplify even more the system, and says we see only 'enter' and 'leave' event, and simply apply effects that only Lycan controls. This has benefit from the implementation point of view because it "leaks" less the way Lycan actually works to the scripts. However, we are not sure of the kind of effects we want.

@Vaelden might also have other concerns.

I personnaly think that key resides in the spell effects arch-types that your system will be able to handle

I am not sure, what do you mean by "arch-types"?

Keep up the good work :)

Thanks a lot! :sunny:

[lthms]

Nice to see you here, @arenglebert (: Hope you will stay quite a while.

However, what if we want to apply damages proportional to the number of entities in the AOE, or maybe something more complex?

I think this sentence can explain what an “arch-types” is from the point of view of @arenglebert. I will correct me if I am wrong, but I think an arch-types is a kind of spell, like maybe a “meta spell” the game designer thereafter instanctiate with precise effect. What @Nemikolh is describing can then be seen as one arch-types among others.

So we can easily imagine several state of the art arch-type with this definition, for instance a spell can either:

• apply to the launcher
• target one character
• be a projectile

In a similar matter, we can imagine a spell which:

• heals
• burns
• etc.

All of these can be seen as “arch-types” of what a spell can be.

The point being, we can actually have that with the aariba script. We can easily imagine a sort of standard library for aaribascript which simplify a lot the burden to write a proper spell, by providing well defined arch-type… yep we will still be able to tweak the system to add a new arch-type without the pain to modify lycan. And this is what we are looking for here with this RSP, I think.

[ghost]

Well, I dont know if u guys sticked around the emulation of WoW server. I took great pleasure in analysing the system that blizzard made around the spells. Without going into deep-lengths, it goes like this (substituing all the client PoV (rendering, etc.))

First off, from what I understand, u want to build a spell system with real particles as specific entities (we can compare this to bullets in a FPS) meanwhile, the particles in the spellsystem of blizzard looks more like about a projectile that is locked onto targets (that might evade it or not), or it's just an area with "constant" damage, not corresponding to the actual projectiles shown on the client. Entering a "blizzard" area, u will take "constant" damage even if u actually dodge the particles of that area (that are only cosmetics).

On that system, a spell is defined by a uuid, references a caster (uuid of that entity), a target (can be a position (x-y-z), another entity referenced by uuid, or a list of them, etc.) and list of "spell-effects".

This is where is stand my idea of "arch-type", a spell effect is generic, and is customised by each spells via parameters. Just to say a few of them to see the idea :

• SPELL_EFFECT_SCHOOL_DAMAGE which has a parameter BasePoint (the base damage before calculation of spellpower of the caster, and the damage mitigation of the target, this is this parameter that will be changed to tweak the actual power of the spell, the more the basepoint is, the more powerful the spell is, etc.)
• SPELL_EFFECT_APPLY_AURA which has a parameter BasePoint (the uuid of the aura to apply on the target, which is another spell, that has her own effects, one of them could be AURA_EFFECT_PERIODICALLY_TRIGGER_SPELL which also have a BasePoint ref. the uuid of another spell that could deal dmg)

U see how, with this type of system, blizzard employees are able to construct spells usable by the players. The actual "blizzard" spell works just like that, cast an aura on a position, which will periodically trigger another spell on that position, that will do damage to entities inside the size of that area.

So spells are just an uuid and a list of parametrized arch-type effects.

Now about spells script, for targeting purpose for instance, the script should be able to retrieve in a way or another a list of targets via some functions. Again, it's possible to do it with some parameters. Let's say a blizzard can target only creatures & players on a range of 2 tiles in a circle around a certain tile for instance.

Of course, all of this can only work with the idea of projectiles not being entities on their own except for cosmetic matters...

I dont know if it answers your questions about my remarks :)

[ghost]

Hi @arenglebert thanks for the feedback! This is greatly appreciated :)

projectiles not being entities on their own except for cosmetic matters...

I think we will want to keep projectiles as entities of their own, because what we want to achieve is slightly different than what WoW does. If I remember correctly, in WoW, a player had to select a target and then cast a spell, and the spell could then only hit that target (evading being purely a percentage based on various stats). In Slayers, we are more aiming towards a skillshot-based system, like the old 2D Zeldas: you can shoot an arrow in front of you, and it will hit the first monster it touches. So we need to actually check collisions on the projectile, which is why we considered it roughly like an entity.

For AoE nothing has been decided yet, but what I was in mind was quite close to what you described actually (so no projectile-based stuff, although it might be possible to create one with an AoE that regularly spawns smaller AoE with a visual effect and damage associated with them ...). The base idea was to have, in a spell, the definition of an AoE comprising a position (I only thought of (x,y), but an entity is also a good idea), a shape and a list of spell effects. As @Nemikolh described, the biggest question in my mind was when should we execute the associated spell effects. If I am not mistaken, the WoW way has the problem of someone quickly entering/exiting a blizzard may not be hit at all, which I would like to avoid, hence the possibility of enter/exit scripts that could immediately apply effects. One of the WoW advantages is that it only needs to check collisions at given points in time, not at every update/tick.

Another possibility would be to check collisions every tick, but then putting players hit by the spell in a "blacklist" for a given/configurable amount of time (e.g. 0.33s) so the player would be hit as soon as he enters. The problem would be that it might be more difficult to get the list of players currently in the AoE, as they would most likely be "hit" during different ticks.

So for now in each solution I see some potentially painful tradeoffs, and I hope to find a better solution! If not, then we will need to choose between what has already been proposed.

I am a bit curious about those arch-type effects. Were all of those defined in the code itself (or could there be arch-type effects based on other arch-type effects)? Were them the "lowest-level" way a spell designer could interact with the game engine?

[ghost]

the arch-types spells are defined in a client database (known as dbc). Those dbc are extracted from the client then used by the server. the spell designer dont create new archtype, he can only design a spell using a mix of them & defining the parameters of those.

When he creates a spell, he just has to define the list of spell-effect, combining differents arch-type to litteraly create what his spell should do.

On the emulation part, u can see a full list of them here : https://github.com/TrinityCore/TrinityCore/blob/6.x/src/server/game/Spells/SpellEffects.cpp https://github.com/TrinityCore/TrinityCore/blob/6.x/src/server/game/Spells/Auras/SpellAuraEffects.cpp

of course, since it's only emulation, every spell effect hasnt been fully identified, or dont fully work. But u can have a rought idea of all the possibilities by mixing everything up from there.

I see now what u want to achieve as a skillshot-based spell system. In fact for AoE, u have great costly tradeoff. I do think that checking collision every tick will be virtually impossible when u will have a large amount of players & a large amount of AoE simultaneously, destroying performance of the server.

In wow, u do have a possibility of a player entering & leaving a AoE without taking damage, since it only applies damage every X ms (u can altough nullify that idea by setting a ms range really low for instance). But again, it could be just like checking collision every tick or so.

Maybe for AoE u should mix things up, having a enter/leave system of the aoe, the aoe would have a degeneration status, saying how much hp the player should loose / gain per second. Then every second, u do adjust the players hp correspondly, as well as when he leaves, calculating the number of millisec he stayed in at the end, receiving a % of the degeneration status. The only problem i see with that approach is when players dies because of that AoE. Let's say the AoE should inflict 1000HP/sec & u enter while having 600 HP. U should be dead in 0.6sec meanwhile this system will only kill u after a complete second.

[lthms]

Thanks a lot for te pointers.

Then every second, u do adjust the players hp correspondly, as well as when he leaves, calculating the number of millisec he stayed in at the end, receiving a % of the degeneration status.

Well actually, I am not sure this is really useful and the way of WoW (only applying damage at ticks, event if you just entered) does not seems that bad.