If an Artemis missile targets a Swift, it should explode if it does enough damage to kill the Swift even if it misses the hitbox, or so I would argue.
An Artemis missile has the potential to turn around and try to hit the target again.
However, with 1600 damage and 120 AoE against 300 HP, the close misses would easily the destroy the Swift.
So when should the missile explode?
Should the missile explode as soon as it can deal 300 damage to the Swift?That might be considered a premature detonation and other air targets behind the swift might take minimal damage from the blast.
A naive approach is to calculate how much damage the missile would do in this frame and store that.
The next frame, we calculate the new damage the missile would do in this frame. If the value is higher. We store that value. If the value is lower but still above the health of the target, the Swift, we explode the missile.
This means, we are only 1 frame off from dealing maximum damage against the single Swift. We also do more damage to other targets behind the Swift if there are any. The missile will also get more chances to circle around and hit the Swift again, if the damage is too small to actually kill the Swift.
However, against targets with more than 1600 health, maybe we do want to blow the missile in the first pass, regardless if it can kill the target or not. We could potentially set an arbitrary threshold so that the missile only blows if it kills the target or does, lets say, 50% of it's full damage.
Can we do better?Yes, we can precalculate the damage of the next frame for comparison against the current frame using the velocity of the Swift and the missile.
If the predicted damage in the next frame, is lower than the current damage, we explode the missile in the current frame.
Since the missile and the Swift can't turn or accelerate instantly, the inaccuracy will be minimal.
We can also do similar things for mobile bombs such as Snitch, Imp or Limpet.
However, when it comes to mobile bombs, maybe we want to include all the targets that will be hit by the explosion.
We can manually run the Snitch and detonate it ourselves, but that type of micro is quite finnicky, and we might just run past the enemy.
The naive approach is too just calculate the total damage dealt to all nearby enemies in range and store it.
The next frame, we calculate the total new damage dealt to all targets the explosion would do in this frame. If the damage is higher, we store that damage value again. If the damage value is lower or equal, we explode the bomb if the damage threshold or range threshold value is reached.
I think we really need a threshold here, because a target that is faster than the bomb, can potentially just enter the blast radius in 1 frame and move out of it the next frame, and the explosion would deal minimal damage.
Can we do better?Yes, but the computational complexity is higher than calculating it versus a single target.
If we want to precalculate the next frame using the velocities of the bomb and all the targets, it is potentially an unbounded amount of units our bomb could hit.
If we want to be really accurate, we also have to consider what units can enter the blast radius the next frame.
The units that can enter the blast radius depends on the velocities of nearby units.
If a unit has high enough velocity, it can potentially enter the range from the other side of the map in 1 frame.
Although that is unrealistic, and a unit moving at that speed would also kill itself on impact with the ground.
It is probably also unecessary to consider boosting Swifts and such extreme cases.
So if we have to increase the search area, it would arguably be enough to add, the highest non-air mobile unit max speed, to the blast radius, when we look for targets the next frame.
What about the cost of the targets?If we want to switch "total damage dealt" to "total metal cost", that would be possible.
We can do
math.min(damage/currentHP, currentHP/maxHP) * unitCost
and use that as a value for our comparison.
Shouldn't we count a kill more than almost killing something?Maybe there is a fudge factor here that can be used.
But explosions aren't instant in Zero-K. Don't we have to account for the speed of the blast?No, we don't.
Explosion damage in the Spring/Recoil engine are always calculated the frame the explosion occurs. The damage is just dealt some frames later depending on the distance to the center of the explosion.
Should this be a widget or a gadget?It can be widget, but then our inaccuracy window is the whole network delay.
It becomes almost impractical to try and predict the future that far ahead if we have high ping.
If we want to precalculate the future, the search area for units that can potentially enter the blast radius becomes much bigger.
Also network latency can be quite random aswell, which complicates stuff further.
But isn't it fun to manually control and try to predict when to explode your bombs?Do we really have to automate this away?Yes, it can be fun. But I'd argue it can also be frustrating.
Isn't predicting the future always fun?This might seem like a tangent, but I'd argue that most of our fun, when playing games and sports, or betting and even gambling, is about predicting the future or fooling ourselves into that we can predict the future.
The fun of predicting the future in ball games, such as soccer or basketball, is partly about predicting where the ball will be, and if You can move your body in time to control the path of the ball. This is not unlike Newton cannons or dropping units from transports in Zero-K.
The fun of predicting the future is also about outsmarting and "outpredicting" your opponent. This is similar to 1v1s in Zero-K.
The fun of predicting the future is also about understanding your teammates, so that you can be in the right place, at the right time, to make your team score. This is not unlike teamgames in Zero-K.
When does predicting the future become frustrating?It becomes frustrating when the ball bounces randomly from uneven ground or because it is broken.
It becomes frustrating when you are constantly outsmarted by your opponent.
It becomes frustrating when your teammates don't do what you expect them to.
It becomes frustrating when your opponent teases you so that you miss the ball.
Using mobile bombs in Zero-K requires planning.
However can you predict where your attention will be when the bomb is supposed to go off?
So is this a fun feature to implement in Zero-K?
What do you predict?
