I wonder why the damage isn’t calculated as a proper circular radius. Because it is computationally more expensive? Or because it is more complicated? Or does it just not matter?
It might have been for performance: An explosion damages many enemies, and can cause subsequent explosions which then also damage many enemies, which is O(N*M). During most frames there are no explosions, but any frame may suddenly incur this cost. I imagine that when building an action game you don’t want an occasional event to create a big spike of work that’s bad enough to delay drawing. Think of any game where a complex physics interaction killed your framerate until the objects stopped moving. You might choose to flatten the spikes by making them very cheap, so you wouldn’t need to save much performance headroom and could have high utilization on the work you do every frame.
Doom squeezed a lot of performance out of a home computer of the time. A player would want to have an 80486, which was the first of the x86 series with an integrated FPU for floating-point operations. Square roots in particular were expensive. One technique to avoid a square root during a circular distance check is to instead compare the squares of both sides, and never take the root: Is the square of the distance less than the square of the radii? That’s OK for colliding circles because all you care about is binary – did they touch or not? But to get half the damage at half the distance, you’d still have to translate it back into linear space, so that wouldn’t work here. Besides, we still had to do a few multiplications, and those aren’t as cheap as just subtracting and comparing on each axis.
Whether explosions in Doom would really cause a significant spike with 2D distance checks, I’m not sure. Given that I didn’t know explosions were square until today, maybe their call was that us players wouldn’t notice.
Basically, square roots are slow, so sqrt(dx*dx, dy*dy) will be a much slower operation than doom’s max(dx, dy).