Help with boids

newt someone made this a behavior!? tanoshimi ? I assume its lost in time...?

Yeah C2 only.

It would be nice to have a C3 version, but I'm betting something much more robust could be done with the C3 runtime and WASM what with all the existing C++ code.

piranha305 was doing something but it was put on hold.

Bunnymark ftw

jobel Thanks for the feedback :)

one thing that is weird, when there's a potential head-on-collision the boid doesn't react, it just collides and moves through. Did you do this purposefully?

Don't worry, nobody gets hurt, they're flying over and under one another ;P

Seriously though, there's nothing in the conditions that factors in the angle of the neighbouring boid, only the angle to it, so it shouldn't really make a difference to its behaviour. If you turn up the strength to 1 it looks like they do react a little to boids coming directly at them, just not enough to guarantee missing each other.

It could be that in the 10th of a second that they do the check there's another boid that's closer so they react to that one instead. Another reason could be that the maximum turn rate is too slow for avoiding head-on collisions so although they're reacting, by the time they start turning they've already collided.

Ideally I'd work out a group angle with weighting for proximity but it hurts my head trying to figure it out - maybe for the next version.

construct3.ideas.aha.io/ideas/C3-I-165

Just sayin

newt Added a vote - it's fun trying to figure it out in events though :)

Yep. I've been through many different ways like using ticks to iterate the instances rather than for each. Events can only provide for a relatively small number of objects.

That's not to say a script version might work nice, but I think this type of movement deserves to be an official one.

voted as well!

There is a definite need for a new movement behavior that is more AI-driven. This could be extrapolated to all kinds of uses.

nevermind I think Eren hosted it... I think that's only for C2 though..

oyunkulturu.com/temp/file/boids_behaviour.zip

c3runtime

oyunkulturu.com/temp/file/boids_behaviour_c3runtime.zip

Thanks! Eren

It can handle a bunch of instances.

Eren wow, you are on top of this! thanks so much!!

Still a lot of overhead if there's a lot of instances.

Might be a great candidate for Wasm.

Anything like this in the works? Nepeo

So I did a quick profile of the project dop2000 shared, with the instances cranked up to 100. I wasn't surprised to find most of the time was spent raycasting. Depending on how it's used raycasting can be quite expensive ( if you watch the original BOIDs video I'm fairly sure Sebastian had the same problem in unity ). You are effectively checking every line segment against every other one in the possible collision area. Hence you're looking at n^2 behaviour if every entity is checking every other. Ironically the older version of LOS might have been faster here, I think it bailed after the first collision is found, but when raycasting was added it became a requirement to know which collision is the closest so it has to keep going.

I'm not aware of any work being done on LOS, but I'm somewhat out of the loop. It's plausible that rewriting parts of the collision engine in WASM would improve performance, but there's a cost moving data between JS and WASM ( and there's lots of data involved in the collision engine ). I'd personally be curious what sort of performance a custom made BOIDs plugin written entirely in WASM got.

Then that brings up how such a movement should behave with the Solid Behavior, or obstacle avoidance.

If it even should work like a solid object, and not be allowed to cross a collision poly, or if it should even work with the behavior and just rely on added obstacles, and treat them like other birds.

I think obviously some will want both.

newt Both valid points, but I don't think either of them would be show stoppers. The collision boxes for any obstacles would need to be synced to the BOID WASM module, but that only needs to occur once per tick before the BOID logic ticks.

As for actually moving and interacting with solid objects, most movement behaviours work like so if move_does_not_collide(x, y) { move(x, y) }. They will also check if they have somehow become stuck in something since their last tick before that, as movement updates occur independently. The BOID module would do checks for such things, then update the positions of all instances in the engine. So plausibly it would be the same as the existing movement behaviours.

At worst it would have to behave as the physics behaviour does, where everything is controlled by the physics module. But it could probably avoid that.

Having both add obstacle, and solid detection would be awesome. In fact I think both would used together quite a lot.

One of the most asked questions on the forum is how to do multiple instance pathfinding.

This would work quite well in conjunction.

I guess the next question would be would something like Add Waypoint like how Moveto works be worth doing?

I'm kind of rolling that over in my head an I don't think it would, because if it were pathfinding, you wouldn't want each to find a path. You would use a single objects path, and "flock" to that object.

Mmm interesting to think about a waypointing system. You can add in an attraction force, which tells the flock to try and move that way. But if a wall is in the way they will just keep bouncing off the wall instead of going around it like path finding would.

You could potentially use path finding to build a route, then use that route as unobstructed attraction points. Is that what you were thinking? It might prove to be hard to decide when to move to the next waypoint. Unless each entity followed the waypoints individually, but that might change the flock dynamic. *shrugs* all needs testing to find out really.