Hacker News Reader

Comment by Tade0 | Hacker News Reader

Back in college I had this course during which we were supposed to design an object-oriented app in Java using concurrency and networking - games were the usual use case.

Our professor asked us how would we implement hit detection - there were a few answers, but none touched the underlying idea that when there's no agent(user, AI) input, objects move in a predictable way, so the distance between them is some function of time.

For example the distance function of two objects moving in a linear fashion is (IIRC) a squared parabola, so you only need to sample three points in time to get the whole function.

And, of course, you only need to recalculate this function for objects that changed direction.

View on HN

I've worked on a hobby ballistics simulator for some time now. This is of course a well studied field, with military applications going back hundreds of years. What's interesting (well, it was to me) is that the state if the art is not closed form solutions, because as you refine solutions and take into account bullet spin, wind, Coriolis effect etc, that becomes too cumbersome. Modern ballistics uses discrete simulation to calculate trajectories.

Something like montecarlo sequential resampling? Do you have any good papers you could reference?

Why would you use Monte Carlo for this? There's no randomness as stated. What op is probably talking about is numerical solutions to pdes (which is also considered "simulation").

"Ballistics: Theory and Design of Guns and Ammunition" by Carlucci et al. is (from what I can tell - again I'm just a hobbiest, it's the book I work from most) a thorough yet accessible standard work on this topic, detailed in the mathematics, lots of references, covers most of the details that matter, yet 'practical' - you can tell the authors were in the military where they had to produce results and not just papers. I'm not 100% sure how to exactly classify the approach in terms of mathematics. It's basically just 'over the next 10 cm, the bullet drops this much, yaws this much, rolls this much, ...' etc, so basically just incrementally calculating position. Very 'primitive' from a math point of view, but that's exactly what I found interesting - how a brute force numerical approach is considered superior to an elegant closed form solution.

Edit: I should add that part of the reason for this is that some of the external forces on a bullet are non-continuous, like wind coming around a building. That sort of pesky real world effects makes elegant solutions a lot more difficult.

This sounds a lot like what GP is saying, a time integration algorithm to solve a set of ODEs. Probably it's a variant of velocity Verlet?

https://en.wikipedia.org/wiki/Verlet_integration

When I started reading ‘college’ and ‘OOP’, for a moment I feared a solution that every bullet should be an object... :)

Gamasutra fortunately is mostly written by actual professionals.

They are objects with a reference to the gun that fired it and everything it could possibly interact with in the game and indeed the game itself. How else is it going to have a “shoot()” method with no arguments?

Is that really a problem outside of large scale RTS games like Supreme Commander? I would be surprised if something like Counter Strike would see more than maybe a few dozen concurrently flying bullets in any possible situation.

Just fyi. I thought counter strike didn't used projectiles but used raycasts for almost every weapon.

But your point still stands and applies for most shooters.

I think each bullet in Supreme Commander IS it's own object. I know they nearly all are individually simulated. That game is STILL hard to run at high framerates in certain "5000 unit vs 5000 unit" circumstances

I think thijsvandien meant object not in terms of simulation, but in terms of architecture: An instance of a Bullet class, instead of some sort of fancy representation optimized for SIMD.

> […] for a moment I feared a solution that every bullet should be an object.

Why not, if you use the flyweight pattern?

If you want to read further on this topic the term is “continuous collision detection”. Bullet physics is a good open source physics library with it implemented.

> For example the distance function of two objects moving in a linear fashion is (IIRC) a squared parabola

This is only true for points. It’s demonstrably untrue for arbitrary shapes.

Well, actually it's also true for spheres.

Then you can approximate any shape with spheres and use that as an optimisation before actually calculating the more costly distance functions.

Approximating a (solid) object with spheres means the spheres are in constant distance and angles with each other. So their trajectories are no longer linear if there is any kind of rotation.

What is a linear rotation? If one sphere is in linear rotation, why can't two?

The point isn't to approximate a solid object as several spheres, but to approximate it with one enclosing sphere. If two objects aren't close enough for their bounding spheres to touch, then you don't need to do a collision detection using the more complicated geometry.

Oh, right. Thanks for the clarification.

Reply on news.ycombinator.com