I'm not sure why you'd want much of a collision engine in a wargame, unless it's more action than strategy.
*thwacks himself in the forehead* I said wargame? Stupid me. It's a real-time action/strategy game where players field individual infantry units, bring repair trucks to the field, fly airplanes, etc. It's basically a cooperative third-person game. Sort of like taking third-person shooters, then compressing them to large scale to add more of a strategic connotation. I wanted the bounding boxes to prevent players' units from driving through one another, since the game was intended to be pixel-based. And, when airplanes and stuff flew into each other, I wanted them to feel it. =P
I posted about the game a while back, but it's still as unstarted now as it was then (which is a very good thing, since BfS is sitting right beneath "website" on my TODO pile).
I decided to go ahead and make it a sci-fi combat game, rather than a modern combat game, though -- I couldn't help it, being a sci-fi junkie.
I've discovered over the course of this project, though, that BYOND's current drawing limitations really prevent action isometric from taking off; that's gonna have to wait a while. There are some real coding challenges in there, that while solvable at the raw drawing end, still present a problem for the current system.
Only if you really allow things to overlap. If the bounding box is larger than the whole unit, then overlapping will be prevented except in extreme cases, like aircraft flying overhead. Overlapping might be fun and interesting at times, but I've never seen an isometric game that allows individual parts of the icon to overlay at different layers. =)
Part of the problem is, I'm not really sure the problem of solving for time of collision is solvable. There could be an infinite number of solutions, even though I'm only interested in the smallest value of t such that 0>t>=1. As far as I know, approximation would be the only decent way to boil this one down.
Zero is greater than t, which is greater than or equal to one? (I'll assume you mean less than. ;-) )
The most simple method I can think of is to take a circular bounding box, then skew it according to isometric perspective -- 30 degrees -- and leave it unrotated. Since a perfect 30 degree skewing is attainable by making horizontal distances twice as long as vertical distances in a 2D format, all you'd have to do is take a normal circle, and then divide the angle by 1 through 2 based on how large the sine of the angle along the locus is (assuming angles in standard position), which should produce an accurate ellipse without having to define two points and trace the actual locus.
Lemme see if I can put it into DM terms...
atom/proc/collision_detect(atom/trg)
var/bounding_dist_src = src.bounding_radius / ( 1 + abs( sin( get_angle(src, trg) ) ) )
var/bounding_dist_trg = trg.bounding_radius / ( 1 + abs( sin( get_angle(trg, src) ) ) )
if( (bounding_dist_src + bounding_dist_trg) > get_real_dist(A, B) )
//collision
That depends on non-existent (but relatively easy-to-make) procs: get_angle(), which would return the angle in degrees; and get_real_dist(), which returns the linear distance between the two.
You don't even have to account for the linear skewing, since the sine calculation already handles that.
...Hopefully that makes sense, and works. =)
I'm not sure why you'd want much of a collision engine in a wargame, unless it's more action than strategy.
I've discovered over the course of this project, though, that BYOND's current drawing limitations really prevent action isometric from taking off; that's gonna have to wait a while. There are some real coding challenges in there, that while solvable at the raw drawing end, still present a problem for the current system.
I'm somewhat mathematically inclined, but once the equations get this big my head goes into a bit of a spin.
Part of the problem is, I'm not really sure the problem of solving for time of collision is solvable. There could be an infinite number of solutions, even though I'm only interested in the smallest value of t such that 0>t>=1. As far as I know, approximation would be the only decent way to boil this one down.
It ought to be easier at least to solve the distance problem, but it looks like it's harder than I would have hoped. Yet in theory, it ought to boil down to just 4 possible ratios of K/L; four lines connecting the ellipses at perpendicular points should exist no matter what, so there will always be at least 1 solution, with the others overlapping it as repeated factors in the final equation.
Could be. I'm more analytical than computational myself, which is why this has been a headache.
Lummox JR