- Joined
- Sep 10, 2013
- Messages
- 818
- Reaction score
- 708
Hi there,
without alot of extra talk, I'd like to suggest a new algorithm for missile damage calculation. It assumes that the game engine supports a halfway efficient retrieval of a block's neighbours (both adjacent and diagonal neighbours).
Simply put: the goal is to achieve explosion "holes" that are a) procedurally (randomly) generated each time instead of smooth spheres, b) look halfway realistic and "rough", like you would expect a hole in the side of a battleship to look like, and c) destroy exactly as many blocks worth of EHP as the missile damage. Admittedly this system would not synergize with preset missile damage radius maximums except using them as hard-cap for maximum spread of block destruction (like it is the case now).
Update: Note that it would performance-wise perhaps be more feasible to just precompute 10-20 different explosions and then choose one each time and go through the blocks in the list produced by the algorithm in exact order from top to bottom until the damage is "used up". A block list produced by the algorithm makes for a valid explosion when cut off at an arbitrary point, too, because blocks are added to the list roughly from the inside out.
Adjustable to the max!
- Fraction of blocks deleted from candidate list each "phase". 25% works really well I think.
- Ability to enforce certain patterns (like shrapnel weapon effects) by chaining multiple phases with very low retention rate after short numbers of phases with more average settings, or making a more clustered retention selection in some phases to force more sharply distorted non-cubes, or by adding single random additional outlier blocks not connected to the current list of blocks
- Would technically allow an entire rework of how area damage is handled for the explosive weapon effect on cannons, too!
Also, at no point are trigonometric functions needed. Using the same random seed, the procedural generation could take place in exactly the same way in all clients.
without alot of extra talk, I'd like to suggest a new algorithm for missile damage calculation. It assumes that the game engine supports a halfway efficient retrieval of a block's neighbours (both adjacent and diagonal neighbours).
Simply put: the goal is to achieve explosion "holes" that are a) procedurally (randomly) generated each time instead of smooth spheres, b) look halfway realistic and "rough", like you would expect a hole in the side of a battleship to look like, and c) destroy exactly as many blocks worth of EHP as the missile damage. Admittedly this system would not synergize with preset missile damage radius maximums except using them as hard-cap for maximum spread of block destruction (like it is the case now).
Update: Note that it would performance-wise perhaps be more feasible to just precompute 10-20 different explosions and then choose one each time and go through the blocks in the list produced by the algorithm in exact order from top to bottom until the damage is "used up". A block list produced by the algorithm makes for a valid explosion when cut off at an arbitrary point, too, because blocks are added to the list roughly from the inside out.
Types are only rough suggestions, I don't know how things are modeled exactly.
Code:
explosionDamage(Missile missile) {
blocksToKill <-- missile.getBlockInPosition();
double damageLeftover = missile.damage - blocksToKill.get(0).hp
boolean diagonal = true;
while (damageLeftover > 0) { //continue causing havoc
blockNeighbours = selectNeighboursOf(blocksToKill, diagonal)
diagonal = !diagonal;
randomlyDeselect25%(blockNeighbours)
foreach block in blockNeighbours: {
damageLeftover -= block.effectiveHealth;
blocksToKill.add(block);
if (damageLeftover <= 0) break;
}
}
}
A: Any "hole" in the growing blocksToKill list (shown in white) will be considered for "filling it up" with a chance of 75% every single phase. As such, roughness almost only occurs in the very outmost borders of the thing, as well as influencing the general shape of the growing crater.
Adjustable to the max!
- Fraction of blocks deleted from candidate list each "phase". 25% works really well I think.
- Ability to enforce certain patterns (like shrapnel weapon effects) by chaining multiple phases with very low retention rate after short numbers of phases with more average settings, or making a more clustered retention selection in some phases to force more sharply distorted non-cubes, or by adding single random additional outlier blocks not connected to the current list of blocks
- Would technically allow an entire rework of how area damage is handled for the explosive weapon effect on cannons, too!
Also, at no point are trigonometric functions needed. Using the same random seed, the procedural generation could take place in exactly the same way in all clients.
Last edited:
