Aiming point(s) vs pivot point

So here is the problem:
ships attacking some target that has collision shape. While shape is sphere everything is trivial: trying to aim at center (while it’s safe distance for them not to collide with target physically) and fire. Fire is allowed until angle between centers line and attacker’s facing direction is less than that defined by target’s radius. Now, say, we have torus. Obviously it is nearly useless to aim at center (which is still convenient as pivot point anyway). Neither it is good solution to aim at some single point defined on torus’ body since it can be farthest part of torus (at given moment), and attacker can be well vaporized before he’s in a distance to shoot, or can start collision evasion maneuver already, not to hit closest part of torus. So probably here’s better idea to have number of points defined on torus and to pick the closest, for instance. The question is how (where in terms of ES) to better store them? Either aiming algorithm has to decide what kind of shape it is (to check them by shape component class not null? Or to store shape type elsewhere? That would double the function as shape is defined by component class already), or it has to just pick some point from somehow sorted container not calculating anything by itself? What would be most flexible approach without doing same work twice?

Sounds very wired your description. I read twice and still have no clue what exactly you want.

I would say your ships have a colilision shape and your “bullets” as well. Now you just need to keep orientation and position of that collision shape (which does not need to be the same like your model shape) and which is any way there to display the model. Now you need a collision system which detects (and maybe also calculates the damage) somehow. Thats it.

I really don’t understand that if the shape component is null idea in your description? Sounds wrong and wired in a ES approach.

I’m not sure this data about ‘target locations’ needs to be stored in a component at all. Somehow the component indicates a collision shape and it seems to me relative to that. There is probably only one system that cares how to find targets on a torus and it can have a strategy to do that.

Too often, I think people try to store the actual collision shape in a component… which would be the same as storing the actual model in a component. ie: silly. Imagine if you were storing these things in a database and had built up all of this game data and then a year from now you decide to slightly tweak the torus-shaped ships… now you have all of this invalid data.

More likely, you have some ModelInfo() component that says it’s a “torus-ship” and that somehow maps to an asset for the systems that need assets… and maybe maps to a collision shape for the systems that need collision shapes… and maps to target locations for systems that need target locations. But all that’s stored in the entity is that one ModelInfo() component. (I personally use separate model and collision shape components but it’s still generally based on a simpler ID that is then used to look up the real value… for any game where everything isn’t just a sphere collision shape that is.)

I am sorry if my description looks messy. This is not about collision detection in principle (collision detection is implemented, and well separated from this). For instance, it tells the ship: “Oh, here’s an obstacle in proximity, you have to shift your direction to avoid!” - and that’s it. Problem is where to aim at on some non-primitive shapes - and where to store that information. So the component mentioned was not “collision” component but “collision shape” component that basically defines is your target sphere or box or torus or whatever else…

Might also be that english is not my first language, but I guess @pspeed did understand it :slight_smile:
I really thought it is about collision… But what is the reason not use a sphere for what you want and I mean you could even place a couple of spheres to mimic a more complex ship/station/obstacle which you want to avoid. You then even could have hole in that obstacle (I think that is the only really valid argument not using spheres).

But yeah also here it could be that I think to simplistic :wink: To positive thing is for a sphere you can store the radius (the only thing you need). Or is storing the radius of a collision shape also not a good thing? Don’t know - I do…

So, this one system once it has found target point has to signal that point to everyone interested, and since it is system, the signal has to be some component containing that point. Then firing system once it got “aim at” component opens fire (probably after checking that there are no obstacles in between)… schematically is this the right way for them to exchange?

Oh… well… or… that ModelInfo component has to have link to where the target point is stored for that entity… wherever this mystical place is… and this point is updated there separately… hmm…

Well, I like to keep things simple as well, but once you start you quickly go into trade-offs… what if you have a flat (relatively to its planar dimensions) triangle object - how many spheres you will need to approximate? You will also need something to describe their relative placement, so it quickly becomes complicated one way or another. Yeah, sphere test itself is quick and easy, but the complexity will just shift to array generation part… and performance will still experience multiplication by the number of spheres hit…

What is this “everyone interested”?

Isn’t there one system doing targeting?

Hmm, yes, a valid question, indeed there’s one system doing “direct” targeting (for weapons that need aim), OK, but I need to get information out of that system anyway. I need my target to know if it is in aim, to, say, lit up danger indicator in cockpit for player. And likewise for flying NPC to it could start reacting.

Yeah, but those other cases may do better with a less accurate check. I mean it seems a little unlikely that me flying around would know “Hey, the dude over there can now target my left exhaust port!”

I mean if everyone else really does care about accurate target solutions then you publish those links as entities like one might do for hits or contacts, etc…

There’s still only one system that cares about the per-model list of detailed target locations, though.

So “everything is entity”… ok, thanks, I need to think it a bit :slight_smile: it’s so bit unusual to think this way, imperatively I’d just start with “if isAimed(attackerId) {…”, but that way I’d have to repeat it everywhere… instead of having it in one place.