Re: [M-dev] Hit detection...stop it!

[Chris P. <c_p...@ef...>]

I hate to jump into the fray on this topic, but since Sean Morris believes 
his 
pleas for grid-based hit detection are falling on deaf ears, I'll post my 
thoughts.

First of all, the only advantage (that I can see) to hit detection is that 
enemies are (a) hurt more badly in vital locations, and (b) have multiple 
deaths for taking too much damage in certain areas.   

As for implementation, there are many ways to accomplish this task, several 
of which have been discussed.  Having a grid of damage values corresponding 
to the sprite does, as many have mentioned, provide a lot of accuracy.  It 
might be even more efficient to store several rectangles with monster hit 
points in that area associated with each rect.  However, consider the 
implications of storing lots of values for each 
sprite:
	- First of all, you not only have to store your hit point data for each 
sprite, but for EACH FRAME OF ANIMATION AT EACH POSSIBLE ANGLE.  The point 
here is realism, right?  Doesn't make much sense if shooting an enemy that 
is perpendicular to you in the arm counts as chest damage.

	- Assume you store 8 rectangles for each frame of each enemy.  Each 
rectangle has an integer value associated with it defining how much damage 
the enemy can take if hit in that location.  Rects are usually built 
from 4 integer variables: top, left, bottom, and right.  On a Mac, an 
integer is 32 bits, so for each square you are storing 4 ints (for the 
rect) + 1 int for the damage value = 5 ints * 32 bits = 160 bits.  At 8 
rects a frame (not very accurate, but will do for now), that totals to 160 
* 8 = 1280 bits.  Assume about 52 frames per enemy (that's how many a Pfhor 
fighter has), and that means you have 
1280 * 52 = 66560 bits per enemy.  Say you have 8 different types of 
enemies 
on a single map, and you are storing 66560 * 8 = 532480 bits, just for a 
very basic 8 rect system.  Now, 532480 bits is only 520k, but hey, that's a 
ton of ram for such a simple addition to the engine.

	- Ok, so lets say we decide to live with a 520k RAM hike for this feature. 
 The next problem is storage.  Where will these values be defined and 
stored?  In the shapes file?  In the Physics model?  In MML?  Lets say we 
decide to store it in the Physics model.  First, your standard 16k Physics 
model file is going to jump up to 536k (for 8 enemy hit definitions).  
Second, you will have to make sure the same data is bound to each map where 
you plan on using these definitions, driving the size of the map file up 
substantially.

	- Once that problem is worked around, you have further RAM and space 
problems because new death animations will be necessary to make the hit 
detection scheme worth while.  This is going to result in some serious 
memory requirement changes.

	- Finally, even if all this were implemented and an editor to work with it 
were written, rather major revisions to the Marathon enemy hit detection 
and hit points code will have to be made.  For example, I believe the 
current hit detection function returns TRUE if the point is within the 
monster and FALSE if it is not.  On top of that, each rectangle associated 
with that frame would also be have to be checked, which is an order(n) 
process (Order(n) means that in the worst case, it would take N checks to 
find the correct rectangle... which is a lot for a hit detection function 
that might have to execute multiple times per frame).  Also, if a scheme 
where the enemy had different amounts of hit points for different parts of 
their body was used, you would have to modify the internal enemy structure, 
which, I can tell you right now, is going to truly be a pain in the ass.  
Also, would you create death animations for each vulnerable area?  What 
does a monster who dies of getting shot in the foot look like?  

To summarize, I see implementation of a fairly flexible hit detection 
system (odd-sized rectangles) requiring more ram, more disk space, someone 
to write an editor, modification to existing file formats, new death 
animations, and a lot of hit detection patch code.  And when all this is 
done, the changes you have achieved are, in my mind, extremely minor.  I 
think it is way to much of a hassle at this point.

If someone wanted to write such a system, I would say it is definitely 
possible.  It just seems like a lot of hard work for minimal returns.  
Sorry, but that kind of sours the idea for me.  I would vote to wait for 
polygonal sprites, because 3D hit detection gets _much_ easier when you can 
tie a specific polygon to a projectile in space.

Chris