# Handle (magic) projectile (damage) calculations on cast or on hit?

Im not asking about any code or implementation details just general theory.

I will try to keep the example simple let’s say the game is a RPG with magical projectiles, they can have different effects but let’s say the projectile deals damage for this example, the damage is based on some caster stats and has to be caculcated, when would you calculcate the projectile damage: When the projectile is casted and then store it and deal the damage when the projectile hits or calculcate and deal the damage on the hit?

The first question could be: does it even matter? Yes and no, it will most likely not make a real difference for the gameplay, but the (damage) calculation could return a different result. Let’s say the caster has a buff which increases the magic damage and casts the projectile, but the buff is removed while the projectile is still in the air and before it hits a target, in this case the (damage) calculcation would return different values depending if the calulcation happend during the cast (with the buff) or during the hit (without the buff).

I was just wondering how other games handle these cases, but I couldn’t find any details, maybe I used the wrong search keywords.

I’ve seen it done both ways, and I think it’s completely up to you how you want your game to feel. It think it makes perfect sense that as long as you “get the shot off” before the buff wears off, the projectile will keep the buff. But it could also be suspenseful to watch a projectile moving towards its target, where you hope it hits before the buff wears off.

Maybe one argument in favor or the projectile receiving the buff when the projectile is fires (instead of when it hits a target) would be that it simplifies powers like “Get double damage on the next fireball you cast”. In that case, you’d want the buff applied to that next fireball, at the time of creation.

Anyway, I’m not sure it makes a huge difference. I think I personally prefer the version where the projectiles get their buffs at creation time. It seems simpler to deal with.

1 Like

On hit. Definitely on hit.

The target may change a status in the time it takes to travel to them.

And even when it doesn’t, you’re better off having a standard method that is easy to read and debug.

And just give the projectile it’s own set of variables upon casting so buffs applied after won’t apply.

3 Likes

Well, I have always done it this way. Calculate the projectile damage on the cast(as you probably don’t want new buffs affecting already shot projectiles) and calculate the damage to the enemy on hit (because it can have some modifiers affecting damage taken, like armor for example).

1 Like

Store relevant properties on cast, but calculate the damage on hit. Both events have relevant context that may be important to the final calculation.

Lets use casting a fireball as an example.

At cast time:

• What is the base damage of the fireball?
• What its its area of effect radius?
• What kind of damage does it deal? (Normal fire, or magic, or…?)
• Are there any attached bonuses? (Eg: caster may do 10% extra damage vs. Orcs.)

At hit time:

• How far away is each enemy in the damage radius?
• Does each enemy have any protection against this type of damage or attack?
• If cover is a thing, is there any and what effect does it have on each enemy?

Unless you can see the future you can’t know the hit time info at casting time, and it’s important, so you need to wait until then before you can calculate damage. But you also need to know some stuff from when it was cast which could potentially change in the mean time. The first solution that springs to my mind is to store relevant data on the projectile at cast time, then use that at hit time to calculate final results.

Of course if your game is turn-based or if your projectiles are effectively instantaneous then cast time and hit time could be the same. Or your game might have simple enough rules that some or all of the above doesn’t matter. In either case, don’t make things more complicated than they need to be.

1 Like