# Help with boids

0 favourites
• 37 posts
From the Asset Store
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported.
• Oh newt you've probably seen this article, but I'll mention it just in case. This is probably the best reference I've found about the different types of pathfinding algorithms redblobgames.com/pathfinding/tower-defense

• Yeah the pathfinding might be a bit much to pile on something that should really simple in design.

I mean it's already two different things a movement, and obstacle avoidance.

Then again should we be looking at just adding obstacle avoidance that could be added to any movement bahavior?

• Nepeo In Sebastian's boid example he uses a SphereCast function, which checks for a possible collision of the size of the boid rather than just a ray intersection, so in a way it's like pathfinding.

C3 doesn't have anything like that except Overlapping at Offset, but not in a line (like a raycast).

• ## Try Construct 3

Develop games in your browser. Powerful, performant & highly capable.

Construct 3 users don't see these ads
• It doesn't sound very spherical, sounds like if you were to stretch a sprite's width, or height to the distance, and use its collision polygon as a detector.

• newt well in Unity colliders are separate components. they use sphere colliders to cast rays, so it makes sense in 3D.

but maybe you are onto something with a stretched 2D collision polygon, it's why I mentioned Collision At Offset could maybe used in a similar way?

• That or use LOS and make it into a ray by changing the distance.

No idea which would work better.

I mean technically both are still a little different than dragging a circle along a line, but not much, at least for boids.

• Obstacle avoidance and attraction is only half of pathfinding. The other half being the defining characteristic of true path finding in my opinion. But I understand your point.

An example you can consider is if you have a V shaped wall, the entity is inside the V and the target is beyond the point of the V. The attraction will pull the entity toward the bottom of the V, but obstacle avoidance will send it the opposite way. Compare this to path finding where it will immediately know that it cannot reach the destination that way, and will go up and around the top of the V shape.

The SphereCast stuff is interesting, I'm not sure how that works mathematically. The trouble with rays is that they have a width of 0, so you need to cast an infinite number to simulate line thickness. You can estimate it by casting a few, and hope nothing is in the gaps. It's possible to do volume based ones using signed distance functions (SDF) and ray marching, but it requires a way to generate an SDF for each collision object. It would also be a fair bit slower I wager. A third option would be to do a capsule intersection test with all the collision objects. I'm not really sure what sort of information you'd get back from that, other than it hit something.

• 37 posts